This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [COMMIT] Fix decoding CIE's in DWARF frame info


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]