From: Daniel Jacobowitz <drow@false.org>
To: Mark Kettenis <kettenis@gnu.org>
Cc: cagney@gnu.org, gdb-patches@sources.redhat.com
Subject: Re: [COMMIT] Fix decoding CIE's in DWARF frame info
Date: Fri, 05 Nov 2004 20:41:00 -0000 [thread overview]
Message-ID: <20041105204101.GA23606@nevyn.them.org> (raw)
In-Reply-To: <200411052036.iA5KaHFK014692@elgar.sibelius.xs4all.nl>
On Fri, Nov 05, 2004 at 09:36:17PM +0100, Mark Kettenis wrote:
> Date: Fri, 5 Nov 2004 14:12:17 -0500
> From: Daniel Jacobowitz <drow@false.org>
>
> On Fri, Nov 05, 2004 at 07:53:51PM +0100, Mark Kettenis wrote:
> > Date: Fri, 05 Nov 2004 12:00:12 -0500
> > From: Andrew Cagney <cagney@gnu.org>
> >
> > Mark Kettenis wrote:
> > > The old code didn't take into account that the encoding used to
> > > specify the personality routine in the augmentation could be
> > > DW_PE_EH_aligned.
> > >
> > > Fixed by the attach patch.
> > >
> > > Committed to mainline. I'll commit this to the branch later today.
> >
> > How are you testing this? I'm seeing:
> >
> > dwarf2-frame.c:1083: internal-error: Unsupported encoding: DW_EH_PE_indirect
> >
> > If your toolchain really generates DW_EH_PE_indirect, it's a different
> > problem; I don't know how to properly support this :-(.
>
> I do know that some GCC toolchains emit DW_EH_PE_indirect - I ran into
> it yesterday on PowerPC. It's exactly what it says; after applying
> whatever other encoding (pcrel, etc), dereference the result. Adding
> this to read_encoded_value should be pretty straightforward.
>
> I don't think so. We read the encoded pointers when we load the
> executable in GDB. But if the value of these encoded pointers is
> known at that point, why doesn't the (static) linker resolve things
> instead of having us goe through the indirection process?
Because this is used, as far as I know, only for PIC code in shared
libraries (which we only load after they've been dynamically
relocated). DW_EH_PE_indirect is used so that symbols which will need
a runtime RELATIVE relocation live in the data segment, instead of the
with the rest of the exception data, which could otherwise be read-only.
It's true that in general we'd have to delay the read until it was
used, but I think it'll work OK to read it right away for all cases I
know of. But I don't have a test case, so I'll just save this thought
for later.
--
Daniel Jacobowitz
next prev parent reply other threads:[~2004-11-05 20:41 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-05 15:43 Mark Kettenis
2004-11-05 17:00 ` Andrew Cagney
2004-11-05 18:54 ` Mark Kettenis
2004-11-05 19:12 ` Daniel Jacobowitz
2004-11-05 20:37 ` Mark Kettenis
2004-11-05 20:41 ` Daniel Jacobowitz [this message]
2004-11-05 20:53 ` Mark Kettenis
2004-11-05 21:22 ` Andrew Cagney
2004-11-05 21:25 ` Daniel Jacobowitz
2004-11-05 22:00 ` Mark Kettenis
2004-11-05 22:11 ` Andrew Cagney
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=20041105204101.GA23606@nevyn.them.org \
--to=drow@false.org \
--cc=cagney@gnu.org \
--cc=gdb-patches@sources.redhat.com \
--cc=kettenis@gnu.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