Handing DW_OP_addr in computed symbol locations

Handing DW_OP_addr in computed symbol locations

[Jonas Maebe]

Hello,

Pascal has an "absolute" statement, with which you can define  
basically an alias for (part of) another variable. E.g.,

var
   r: record
        a, b: integer;
      end;
   b: integer absolute r.b;

This maps "b" to the address of r.b. To enable users to also use "b"  
inside gdb, I now generate the DWARF2 code as follows:

* The original variable:
0x00000051:     TAG_variable [2]
                  AT_name( "R" )
                  AT_location( <0x5> 03 2c 02 00 00  ( addr  
0x0000022c ) )
                  AT_type( {0x000000a2} ( struct  ) )

* An aliases for the second field of the above record:
0x0000005e:     TAG_variable [3]
                  AT_name( "B" )
                  AT_location( <0x7> 03 2c 02 00 00 23 02  ( addr  
0x0000022c, plus uconst 0x0002 ) )
                  AT_type( {0x00000083} ( SMALLINT ) )

Now, the DW_OP_addr for the original variable and the one for the  
alias are handled in a completely different way by gdb's DWARF2 reader:

a) the first one is handled in dwarf2read.c/var_decode_location().  
That function has a special case for symbols whose location consists  
of a single DW_OP_addr. In this case, the address is read and relocated.
b) since the second one also has an additional operation, it is turned  
into a LOC_COMPUTED by var_decode_location(), and its DW_OP_addr is  
instead handled in dwarf2read.c/decode_locdesc(). In this case, the  
address is not relocated in any way.

Nobody probably ever noticed this because
a) GCC probably never generates locations like the above (there's no  
"absolute"-like statement in C that I know of)
b) in most cases the DWARF information has already been relocated by  
the linker, so even if it were generated, it would work fine in most  
cases

Now, in case of the Free Pascal Compiler on Mac OS X, we do generate  
such combinations and the DWARF information is not relocated (as  
displayed above). Hence, things break (both with Apple's own fork of  
gdb, and with Archer head; I assume also with CVS head, but I haven't  
tested).

Now, my question is: how can the argument to DW_OP_addr inside  
var_decode_location() be relocated, given that no symbol information  
appears to be available in that function? Further, I'm also a bit  
worried about the comment in var_decode_location() stating that the  
special handling of DW_OP_addr there is a "degenerate form". It  
suggests to me that the proper thing to do is to actually not relocate  
it, but that seems to be wrong.

Thanks,


Jonas

Re: Handing DW_OP_addr in computed symbol locations

[Jan Kratochvil]

On Fri, 13 Mar 2009 22:54:36 +0100, Jonas Maebe wrote:
> * An aliases for the second field of the above record:
> 0x0000005e:     TAG_variable [3]
>                  AT_name( "B" )
>                  AT_location( <0x7> 03 2c 02 00 00 23 02  ( addr  
> 0x0000022c, plus uconst 0x0002 ) )

This notation is excessive.  You can use single DW_OP_addr already containing
the constant addition.  Any relocations only add the offset, RELA entries use
the (A)rgument explicitly, REL entries implicitly.  It was fixed for GCC in:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37738#c1


>                  AT_type( {0x00000083} ( SMALLINT ) )
>
> Now, the DW_OP_addr for the original variable and the one for the alias 
> are handled in a completely different way by gdb's DWARF2 reader:

Which would no longer exploit the existing GDB relocation bug.



Regards,
Jan

Re: Handing DW_OP_addr in computed symbol locations

[Jonas Maebe]

On 16 Mar 2009, at 21:44, Jan Kratochvil wrote:

> On Fri, 13 Mar 2009 22:54:36 +0100, Jonas Maebe wrote:
>> * An aliases for the second field of the above record:
>> 0x0000005e:     TAG_variable [3]
>>                 AT_name( "B" )
>>                 AT_location( <0x7> 03 2c 02 00 00 23 02  ( addr
>> 0x0000022c, plus uconst 0x0002 ) )
>
> This notation is excessive.  You can use single DW_OP_addr already  
> containing
> the constant addition.  Any relocations only add the offset, RELA  
> entries use
> the (A)rgument explicitly, REL entries implicitly.  It was fixed for  
> GCC in:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37738#c1

Thanks for the tip, this indeed works fine!


Jonas