Re: Problem with location lists and variables on stack

[Josef Zlomek <josef.zlomek@email.cz>]

> 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