public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Corinna Vinschen <vinschen@redhat.com>
To: gdb-patches@sourceware.org
Subject: Re: [rfa] frame address size incorrect if address size != ptr size
Date: Wed, 04 Aug 2010 11:35:00 -0000	[thread overview]
Message-ID: <20100804113501.GU8324@calimero.vinschen.de> (raw)
In-Reply-To: <20100726145236.GA16155@calimero.vinschen.de>

Ping?  This affects generic code in dwarf2-frame.c...

On Jul 26 16:52, Corinna Vinschen wrote:
> 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

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

  reply	other threads:[~2010-08-04 11:35 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-26 14:53 Corinna Vinschen
2010-08-04 11:35 ` Corinna Vinschen [this message]
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=20100804113501.GU8324@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).