Handing DW_OP_addr in computed symbol locations

[Jonas Maebe <jonas.maebe@elis.ugent.be>]

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