This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Handing DW_OP_addr in computed symbol locations


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

  r: record
       a, b: integer;
  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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]