[Bug debug/10000] gcc -g generates location expressions which are not valid in prologue

[werner at almesberger dot net]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10000



------- Additional Comments From werner at almesberger dot net  2003-06-19 01:12 -------
Subject: Re:  gcc -g generates location expressions which are not valid in prologue

dberlin@gcc.gnu.org wrote:
> GCC provides the information for *source level* debugging, not *assembly
> instruction level* debugging.

Maybe I should explain better what I'm after: I want to access local
variables at points that are reasonably well defined in the source:

 - on function entry, before the prologue
 - if there is a useful way for figuring out where the prologue
   ends, I'd love to be able to use that point too
 - at the end of the current function (i.e. when it executes the
   return instruction)
 - wherever the current function returns to
 - when at a label (the labels I use are traps in __asm__, so
   they're reasonably well-behaved)

The main places where I'm running into trouble are:

 - the prologue, because I don't know where it ends, but the
   location information is only valid after executing the prologue.
   This is what my bug report refers to.

   My work-around: I ignore the location information and the
   prologue, and second-guess where gcc may have put the data. This
   works fairly well, but I realize that I'll be in trouble in cases
   where arguments are passed in registers.

 - stack adjustment after returning from a function. Right now, I
   disassemble the sub N,%esp (ia32) after the call, but I'm
   actually surprised myself that this works so often :-)

My "debugger" (http://umlsim.sourceforge.net/) doesn't really need
to handle signals or such, so things are actually easier than, say,
for gdb. On the other hand, my "debugger" is script-driven, so
"just type 'next' if things look fishy at the current location"
(which is what I do when using gdb manually) won't work.

Thanks,
- Werner