[Dwarf-Discuss] target address dependency of the FDE header in DWARF CFI
eliben at gmail.com
Sat Dec 10 05:16:52 PST 2011
On Sat, Dec 10, 2011 at 14:26, Jan Kratochvil <jan.kratochvil at redhat.com>wrote:
> On Sat, 10 Dec 2011 13:09:32 +0100, Eli Bendersky wrote:
> > But in DWARFv3 there's no such field, so where would I expect to find
> > information in a file written with DWARFv3 info?
> GDB follows the architecture of that FDE, which is taken from the
> of the file (decode_frame_entry_1).
> # dwarf2_addr_size is not used for .eh_frame FDEs, which are generally
> # defined using the target's pointer size so far.
> # Note that dwarf2_addr_size only needs to be redefined by a target if the
> # GCC back-end defines a DWARF2_ADDR_SIZE other than the target pointer
> # and if Dwarf versions < 4 need to be supported.
> And it really defaults to: gdbarch_ptr_bit (gdbarch) / TARGET_CHAR_BIT
> Only gdb/xstormy16-tdep.c uses set_gdbarch_dwarf2_addr_size to change it.
The problem is GDB is that it can cheat - it *knows* the pointer size of
the target architecture, of course, since it has to run it!
But what about a parser library, decoupled from actual execution? I looked
at the code of libdwarf and after some digging it appears that it uses the
EI_CLASS of the enclosing ELF object. If it's ELFCLASS64, it assumes a
8-byte target address size, otherwise 4 bytes.
I wonder if this is indeed the right way to go. I learned that the DWARF
format is quite distinct from target address size. That is, CUs with 8-byte
address size can appear in DWARF32 sections. But perhaps the ELF class is
> From the DWARF point of view it is fixed in v4.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Dwarf-Discuss