This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Handing DW_OP_addr in computed symbol locations
- From: Jonas Maebe <jonas dot maebe at elis dot ugent dot be>
- To: gdb at sourceware dot org
- Date: Fri, 13 Mar 2009 22:54:36 +0100
- Subject: Handing DW_OP_addr in computed symbol locations
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