Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Mark Kettenis <kettenis@chello.nl>
To: drow@false.org
Cc: kevinb@redhat.com, gdb-patches@sources.redhat.com, hunt@redhat.com
Subject: Re: [RFA] dwarf2-frame.c sign extension patch
Date: Thu, 22 Jul 2004 20:46:00 -0000	[thread overview]
Message-ID: <200407222045.i6MKjk1T003278@elgar.kettenis.dyndns.org> (raw)
In-Reply-To: <20040722004621.GA27215@nevyn.them.org> (message from Daniel Jacobowitz on Wed, 21 Jul 2004 20:46:21 -0400)

   Date: Wed, 21 Jul 2004 20:46:21 -0400
   From: Daniel Jacobowitz <drow@false.org>

   On Wed, Jul 21, 2004 at 05:41:36PM -0700, Kevin Buettner wrote:
   > > Any use of bits_per_address, IMO, is a bug.  Take a look at how this
   > > field is set on MIPS; it's based on the architecture, not the ABI or
   > > the pointer size or the dwarf address size or anything like that.
   > 
   > I agree.
   > 
   > > TYPE_LENGTH doesn't seem like an ideal replacement.  Can we use the
   > > value in the compilation unit header here?
   > 
   > I considered doing this, but was told that the information in
   > .debug_frame should be independent of the CU header.  I really
   > don't know what the "right" solution is.

   Oh, right, we're in .debug_frame here.  I care very much about being
   .able to use .debug_frame without .debug_info.  Debian distributes
   library images with only .debug_frame, to provide backtraces.

Ah yes, the standard explicitly says that .debug_frame is
self-contained.

   .debug_frame doesn't provide this information.  That's a known defect;
   I think that Jim proposed correcting it on the dwarf2 list.

Hmm, I'm starting to wonder why we set unit->addr_size at all.  It's
only used in decode_frame_entry_1().  I suppose it makes sense to
cache this value, although I have no data to support that.

   Does anyone know if .eh_frame solves this problem somehow?

In many cases it directly encodes the size of pointers.

   Otherwise, I think that using TYPE_LENGTH (with a big comment
   explaining the issue) may be the best we can do.

Actually, it would make things more symmetric if we'd use TYPE_LENGTH.
Even better, avoid the issue completely by initializing the CIE
encoding to DW_EH_PE_absptr.  How about the attached patch?  Does it
solve your problems Martin?

Mark


Index: ChangeLog
from  Mark Kettenis  <kettenis@gnu.org>

	* dwarf2-frame.c (struct dwarf2_cie): Delete `addr_size' member.
	(decode_frame_entry_1): Use DW_EH_PE_absptr as default for CIE
	encoding.
	(dwarf2_build_frame_info): Adjust for removal of `addr_size'
	member of `struct comp_unit'.

Index: dwarf2-frame.c
===================================================================
RCS file: /cvs/src/src/gdb/dwarf2-frame.c,v
retrieving revision 1.36
diff -u -p -r1.36 dwarf2-frame.c
--- dwarf2-frame.c 15 Jun 2004 01:04:19 -0000 1.36
+++ dwarf2-frame.c 22 Jul 2004 20:45:28 -0000
@@ -890,9 +890,6 @@ struct comp_unit
   /* Linked list of CIEs for this object.  */
   struct dwarf2_cie *cie;
 
-  /* Address size for this unit - from unit header.  */
-  unsigned char addr_size;
-
   /* Pointer to the .debug_frame section loaded into memory.  */
   char *dwarf_frame_buffer;
 
@@ -1284,9 +1281,8 @@ decode_frame_entry_1 (struct comp_unit *
       cie->cie_pointer = cie_pointer;
 
       /* The encoding for FDE's in a normal .debug_frame section
-         depends on the target address size as specified in the
-         Compilation Unit Header.  */
-      cie->encoding = encoding_for_size (unit->addr_size);
+         depends on the target address size.  */
+      cie->encoding = DW_EH_PE_absptr;
 
       /* Check version number.  */
       cie_version = read_1_byte (unit->abfd, buf);
@@ -1557,7 +1553,6 @@ dwarf2_build_frame_info (struct objfile 
   /* Build a minimal decoding of the DWARF2 compilation unit.  */
   unit.abfd = objfile->obfd;
   unit.objfile = objfile;
-  unit.addr_size = objfile->obfd->arch_info->bits_per_address / 8;
   unit.dbase = 0;
   unit.tbase = 0;
 


  reply	other threads:[~2004-07-22 20:46 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-20 19:11 Martin M. Hunt
2004-07-21 20:30 ` Mark Kettenis
2004-07-21 21:18   ` Daniel Jacobowitz
2004-07-22  0:41     ` Kevin Buettner
2004-07-22  0:47       ` Daniel Jacobowitz
2004-07-22 20:46         ` Mark Kettenis [this message]
2004-07-22 20:59           ` Daniel Jacobowitz
2004-07-23 17:54           ` Martin M. Hunt
2004-07-23 22:10             ` Mark Kettenis

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=200407222045.i6MKjk1T003278@elgar.kettenis.dyndns.org \
    --to=kettenis@chello.nl \
    --cc=drow@false.org \
    --cc=gdb-patches@sources.redhat.com \
    --cc=hunt@redhat.com \
    --cc=kevinb@redhat.com \
    /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