|
|
Ian Collins wrote:
Flash Gordon wrote:
jacob navia wrote, On 28/03/08 21:39:
2) See at what offset from the frame pointer is the pushed return
address
If there is anything to tell you other than the function prologue. Of
course the return address might not have been saved to RAM either due to
function inlining (as an optimisation) or because it did not need to for
some other reason.
Interesting point, if your coding style is anything like mine, you will
have lots of small functions that do get inlined, leaving a pretty
useless call stack
3) The value stored in the saved frame pointer position points to
the next frame.
If there is a saved frame pointer. Not all implementations use a
separate frame pointer.
x64 is a prime example, very difficult even for a debugger to work out
the callstack in optimised code.
Yes, my debugger has still problems even with slightly
optimized code.
The first 4 arguments are not in the stack, but in
RCX,RDX,R8,and R9.
Sometimes I optimize the writing of those registers
and skip any stores. This confuses the debugger completely.
I tried to emit in the compiler, records to tell the debugger
in which registers the variable lives, but since I alias
a register to several variables at the same time if possible
(when the variables have disjoint lifetimes) that is a further
complication.
In any case for the straight backtrace there is no problem since
lcc-win ALWAYS emits a frame pointer.
I thought that for the time being, I will emit frame pointers until
I find a way of telling the debugger where the return address should
be. If not, you just can't debug optimized code!
There was recently a discussion in the gcc mailing list about the
updating of the debug information to support optimized code.
I had the impression that the poor guy that tried to do that didn't
receive much support from the compiler people, maybe because everyone
ws convinced that the task is just too difficult and would
imply a lot of modifications in the compiler.
I will try to avoid that situation. I prefer slower code but
code that can be debugged, sorry. Specially in x64, the
machines are so fast that making the code undebuggable is
just not worth the price you pay for it in undiscovered bugs!
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
|
|