This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Problem with location lists and variables on stack
On Wed, Oct 01, 2003 at 07:41:42PM +0200, Josef Zlomek wrote:
> > What makes you believe that GDB is the problem? Here's the debug info
> > for argument "g":
> >
> > <2><8e>: Abbrev Number: 3 (DW_TAG_formal_parameter)
> > DW_AT_name : g
> > DW_AT_decl_file : 1
> > DW_AT_decl_line : 4
> > DW_AT_type : <ab>
> > DW_AT_location : 315 (location list)
> >
> > Here's the location list:
> > 0000013b 00000000 00000017 (DW_OP_fbreg: 28)
> > 0000013b 00000017 00000083 (DW_OP_reg3)
> > 0000013b 00000083 00000087 (DW_OP_fbreg: 28)
> >
> > Here's the beginning of func1:
> > 0x8048320 <func1>: push %ebp
> > 0x8048321 <func1+1>: push %edi
> > 0x8048322 <func1+2>: push %esi
> > 0x8048323 <func1+3>: push %ebx
> > 0x8048324 <func1+4>: sub $0x10,%esp
> > 0x8048327 <func1+7>: mov 0x24(%esp,1),%eax
> > 0x804832b <func1+11>: mov 0x2c(%esp,1),%edi
> > 0x804832f <func1+15>: mov 0x38(%esp,1),%esi
> >
> > i.e. those pushes are not accounted for in the debug info. This is
> > something that GCC must do when using -fomit-frame-pointer.
>
> I did not write the part generating the location lists, I do not know DRARF
> much. I thought that the labels LCFIx after each push mean adjustment of the
> frame pointer.
>
> .LVL0:
> # basic block 0
> pushl %ebp
> .LCFI0:
> pushl %edi
> .LCFI1:
> pushl %esi
They do. But they're not used for debug information (.debug_info);
only for .debug_frame, which is _unwind_ information.
> > To quote from the DWARF spec:
> >
> > The DW_OP_fbreg operation provides a signed LEB128 offset from the
> > address specified by the location description in the
> > DW_AT_frame_base attribute of the current function. (This is
> > typically a "stack pointer" register plus or minus some offset. On
> > more sophisticated systems it might be a location list that adjusts
> > the offset according to changes in the stack pointer as the PC
> > changes.)
> >
> > The frame base is evaluated in the function's current context, not via
> > unwinding. So if GCC is using the CFA, then it needs to say so
> > somehow. It would be nice if it could reference the parent's stack
> > pointer somehow and save duplication. A mostly-relevant quote from the
> > spec:
> >
> > In the context of supporting nested subroutines, the DW_AT_frame_base
> > attribute value should obey the following constraints:
> >
> > 1. It should compute a value that does not change during the life of
> > the procedure, and
>
> So shall the location for all variables located on stack be reemitted with the
> changed offset after each push/pop? That would mean longer debug info.
> I thought better idea would be adjusting the offsets from frame base in GDB.
No, but DW_AT_frame_base should be a location list describing the
changes in the frame base.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer