public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Corinna Vinschen <vinschen@redhat.com>
To: gdb-patches@sourceware.org
Subject: [rfa] frame address size incorrect if address size != ptr size
Date: Mon, 26 Jul 2010 14:53:00 -0000	[thread overview]
Message-ID: <20100726145236.GA16155@calimero.vinschen.de> (raw)

Hi,

while analyzing some problem in XStormy16, I came across a weird effect.
Even though the dwarf2 frame unwinder is suppose to be preferred over
the xstormy16 unwinder, the code almost always called the
xstormy16_frame_prev_register function, rather than the
dwarf2_frame_prev_register function.

Debugging turned up that the "address_range" entry in almost all fde's
was incorrect, so the dwarf2_frame_find_fde function almost never found
a matching fde.

More debugging then pointed to the decode_frame_entry_1 function.  The
storage size of address_range is supposed to be cie->addr_size.

cie->addr_size is computed like this:

  /* The target address size.  For .eh_frame FDEs this is considered
     equal to the size of a target pointer.  For .dwarf_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;

  [...]

  if (cie->version >= 4)
    {
      /* FIXME: check that this is the same as from the CU header.  */
      cie->addr_size = read_1_byte (unit->abfd, buf);
      ++buf;
      cie->segment_size = read_1_byte (unit->abfd, buf);
      ++buf;
    }
  else
    {
      cie->addr_size = gdbarch_ptr_bit (gdbarch) / TARGET_CHAR_BIT;
      cie->segment_size = 0;
    }
		  
This is not helpful for .dwarf_frame sections in case cie->version < 4.

The address size of a target is not necessarily the size of a pointer.
And that's exactly the problem in the XStormy16 case.  The target is
very size sensitive.  The address range of the CPU is potentially 32
bit, so the address size for the target is 32 bit.  However, the
pointer size for this target is deliberately set to 16 bit, which
allows for smaller code, and also pointers fit into a single 16 bit
register.

The effect is that the above statements set cie->addr_size to 2, because
that's the size of a pointer.  But the address size is 4 byte and the
debug info has to use the address size to be able to cover the entire
address space of the target.  Consequentially GCC emits debug info
using the address size of the XStormy16 target, 4 bytes.

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.

Tested with XStormy16.  Now the dwarf2 unwinder is actually preferred over
the "manual" xstormy16 unwinder, because the dwarf2_frame_find_fde
function actually finds matching FDEs now.

Ok to apply?

Thanks,
Corinna


	* dwarf2-frame.c (decode_frame_entry_1): If addr_size isn't available
	in CIE, use address size rather than pointer size when decoding
	.dwarf_frame info.


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	26 Jul 2010 14:49:34 -0000
@@ -1736,8 +1736,12 @@ decode_frame_entry_1 (struct comp_unit *
 	 equal to the size of a target pointer.  For .dwarf_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 .dwarf_frame
+	 sections for now.  */
+      if (eh_frame_p)
+	cie->addr_size = gdbarch_ptr_bit (gdbarch) / TARGET_CHAR_BIT;
+      else
+	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 +1783,10 @@ decode_frame_entry_1 (struct comp_unit *
 	}
       else
 	{
-	  cie->addr_size = gdbarch_ptr_bit (gdbarch) / TARGET_CHAR_BIT;
+	  if (eh_frame_p)
+	    cie->addr_size = gdbarch_ptr_bit (gdbarch) / TARGET_CHAR_BIT;
+	  else
+	    cie->addr_size = gdbarch_addr_bit (gdbarch) / TARGET_CHAR_BIT;
 	  cie->segment_size = 0;
 	}
 


-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

             reply	other threads:[~2010-07-26 14:53 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-26 14:53 Corinna Vinschen [this message]
2010-08-04 11:35 ` Corinna Vinschen
2010-08-04 22:40   ` Jan Kratochvil
2010-08-05  8:06     ` Corinna Vinschen
2010-08-05 10:04       ` Ulrich Weigand
2010-08-05 12:30         ` Corinna Vinschen
2010-08-05 14:08           ` Ulrich Weigand
2010-08-05 14:30             ` Corinna Vinschen
2010-08-05 14:59               ` Ulrich Weigand
2010-08-05 15:30                 ` Corinna Vinschen
2010-08-05 16:52                   ` Ulrich Weigand
2010-08-06 10:48                     ` Corinna Vinschen
2010-08-06 11:17                       ` Mark Kettenis
2010-08-06 12:01                         ` Corinna Vinschen
2010-08-06 14:51                       ` Ulrich Weigand
2010-08-06 15:57                         ` Corinna Vinschen
2010-08-06 16:27                           ` Ulrich Weigand
2010-08-06 16:59                             ` Corinna Vinschen
2010-08-06 19:03                               ` Corinna Vinschen
2010-08-08 14:55                                 ` Ulrich Weigand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100726145236.GA16155@calimero.vinschen.de \
    --to=vinschen@redhat.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).