This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [rfa] frame address size incorrect if address size != ptr size
On Aug 5 00:39, Jan Kratochvil wrote:
> On Wed, 04 Aug 2010 13:35:01 +0200, Corinna Vinschen wrote:
> > Ping? This affects generic code in dwarf2-frame.c...
> >
> > On Jul 26 16:52, Corinna Vinschen wrote:
> [...]
> > /* The target address size. For .eh_frame FDEs this is considered
> > equal to the size of a target pointer. For .dwarf_frame FDEs,
> ^^^^^^^^^^^^ = .debug_frame
> > this is supposed to be the target address size from the associated
> > CU header. FIXME: We do not have a good way to determine the
> > latter. Always use the target pointer size for now. */
> > cie->addr_size = gdbarch_ptr_bit (gdbarch) / TARGET_CHAR_BIT;
> [...]
> > Therefore I propose the below patch. It continues to compute addr_size
> > from gdbarch_ptr_bit for .eh_frame sections, but uses gdbarch_addr_bit
> > in case of .dwarf_frame sections.
> ^^^^^^^^^^^^ = .debug_frame
>
> I find the GDB comment above to be obsolete now. FSF GCC (at least 4.4+ at
> least x86_64-linux) no longer generates .debug_frame sections (unless you
> explicitly use -fno-asynchronous-unwind-tables) as generated .eh_frame
> sections already contains all the needed info.
I tested this with a linux->XStormy16 cross gcc 4.4.3, and it does not
generate .eh_frame sections, but .debug_frame sections. The cie version
is 1, so the address size can't be fetched from the debug info. That's
the case I'm trying to fix.
Besides, there are still a lot of installations using older compiler
versions so the comment is still useful, isn't it?
> I have not built gcc for the xstrormy16 target to check it more. Still
> I believe .eh_frame and .dwarf_frame address size should be treated the same.
That would be fine with me.
I made the difference because the comment explicitely states that
.eh_frame sections are defined to use the target *pointer* size and
.dwarf_frame (sic) sections are using the *address* size as given in
the CU header. This address size is exactly what is defined by
gdbarch_addr_bit().
So, the alternative would be to assume that the address size is always
correct and so is the one generated by the compiler, rather than the
pointer size. This does not affect any target with pointer size ==
address size anyway, nor does it affect targets using a compiler
generating CIEs with a version >= 4.
The alternative patch would be:
* dwarf2-frame.c (decode_frame_entry_1): Fix typo in comment.
Assume target address size rather than target pointer size
to cover small targets.
Index: dwarf2-frame.c
===================================================================
RCS file: /cvs/src/src/gdb/dwarf2-frame.c,v
retrieving revision 1.114
diff -u -p -r1.114 dwarf2-frame.c
--- dwarf2-frame.c 7 Jul 2010 17:26:38 -0000 1.114
+++ dwarf2-frame.c 5 Aug 2010 07:48:07 -0000
@@ -1733,11 +1733,11 @@ decode_frame_entry_1 (struct comp_unit *
cie->encoding = DW_EH_PE_absptr;
/* The target address size. For .eh_frame FDEs this is considered
- equal to the size of a target pointer. For .dwarf_frame FDEs,
+ equal to the size of a target pointer. For .debug_frame FDEs,
this is supposed to be the target address size from the associated
CU header. FIXME: We do not have a good way to determine the
- latter. Always use the target pointer size for now. */
- cie->addr_size = gdbarch_ptr_bit (gdbarch) / TARGET_CHAR_BIT;
+ latter. Always use the target address size for now. */
+ cie->addr_size = gdbarch_addr_bit (gdbarch) / TARGET_CHAR_BIT;
/* We'll determine the final value later, but we need to
initialize it conservatively. */
@@ -1779,7 +1779,7 @@ decode_frame_entry_1 (struct comp_unit *
}
else
{
- cie->addr_size = gdbarch_ptr_bit (gdbarch) / TARGET_CHAR_BIT;
+ cie->addr_size = gdbarch_addr_bit (gdbarch) / TARGET_CHAR_BIT;
cie->segment_size = 0;
}
Corinna
--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat