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;
next prev parent 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