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
> 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
> 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.
Josef