[Dwarf-Discuss] target address dependency of the FDE header in DWARF CFI

[Eli Bendersky]

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
> this
> > information in a file written with DWARFv3 info?
>
> GDB follows the architecture of that FDE, which is taken from the
> architecture
> of the file (decode_frame_entry_1).
>
> gdb/gdbarch.sh:
> # 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
> size,
> # 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
more telling.


> From the DWARF point of view it is fixed in v4.
>

Indeed.

Thanks,
Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20111210/7fc94e3c/attachment.htm>