Re: Debugging a frameless function

[Mark Kettenis <mark dot kettenis at xs4all dot nl>]

> Date: Wed, 29 Apr 2009 21:28:54 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> I'm trying to debug a problem in the DJGPP build of a recent GDB
> snapshot, whereby stepping into a function compiled with
> "-fomit-frame-pointer" throws an error:
> 
>    Cannot access memory at address 0x12
> 
> I reproduce below the test program and the transcript of a GDB session
> where I try to debug this.  Any hints or ideas are welcome.  TIA
> 
> >From what I see, a call to read_reg in dwarf2_frame_cache, that tries
> to read the value of EBP, ends up calling
> sentinel_frame_prev_register, and from there eventually
> target_fetch_registers is called.  But since we are in a frameless
> function, EBP holds a variable, not the frame pointer, so the value
> fetched by target_fetch_registers is 2, which later causes
> dwarf2_frame_this_id to call frame_id_build with the first argument
> whose value is 0x16, so the address of the stack in that frame is
> bogus.  And that is what causes the above error message.

Please realise that -fomit-frame-pointer means that there really isn't
such a thing as a frame pointer anymore.  That should be no problem,
since GDB doesn't really need a frame pointer but uses the unwound
stack pointer instead.  This works fine as long as there is debug
information that describes how to do that.

The fact that dwarf2_frame_cache calls read_reg for %ebp seems to
suggest that the DWARF2 CFI (Call Frame Information) says that the
stack pointer has been saved in %ebp (like it would be if the function
wasn't "frameless").  Since that obviously isn't where the stack
pointer is saved, the compiler must have generated CFI that's wrong.

This matches my experience that the debug information generated by GCC
on i386 with -fomit-frame-pointer was hopelessly broken.  This was
years ago though (the early 3.x days IIRC).