This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: debug_info strangeness (arm-mingw32ce)
- From: Dave Korn <dave dot korn dot cygwin at googlemail dot com>
- To: danny dot backx at scarlet dot be
- Cc: Nick Clifton <nickc at redhat dot com>, Alan Modra <amodra at bigpond dot net dot au>, binutils <binutils at sourceware dot org>
- Date: Tue, 15 Dec 2009 17:44:22 +0000
- Subject: Re: debug_info strangeness (arm-mingw32ce)
- References: <1258628885.5171.275.camel@pavilion> <20091119120423.GA24438@bubble.grove.modra.org> <1258652224.5171.290.camel@pavilion> <20091119211601.GB24438@bubble.grove.modra.org> <1258907946.5171.322.camel@pavilion> <1259264606.5171.363.camel@pavilion> <20091127010854.GB692@bubble.grove.modra.org> <1259418805.5171.385.camel@pavilion> <20091130101520.GD692@bubble.grove.modra.org> <1259780646.5171.412.camel@pavilion> <20091202224909.GI692@bubble.grove.modra.org> <1259871025.5171.419.camel@pavilion> <4B20E289.2070504@redhat.com> <1260890750.24127.235.camel@pavilion>
Danny Backx wrote:
> I'm a whole lot further in my adventure now. Remember I am really trying
> to fix arm-mingw32ce-ld so the DLLs will work with Windows Mobile 6.1
> and higher.
>
> Part of the job appears to involve not having separate .edata and .idata
> sections in a DLL, they need to be inside .rdata .
Why isn't this simply a matter of modifying the linker script and nothing else?
> When attempting this it turns out that some of the code isn't in place
> for this, so I had to extend _bfd_XXi_final_link_postscript to find the
> hidden section and put its address in the directory.
By "find the hidden section", do you mean find the start and end addresses
of the block of edata/idata that is now embedded in the middle of the rdata?
I guess so because that makes most sense in the context.
> But then it turned out that the edata RVAs were all wrong, the
> fill_edata function needed to be rerun "with a twist".
>
> That's where my current question lies.
>
> I can rerun fill_edata from (the end of) _bfd_XXi_final_link_postscript
> but it's obvious that this is not the right thing to do.
>
> So from where should I trigger the call to this new version of
> fill_edata ?
I'd much rather we made it DTRT in one pass if we could.
> A second question is how I should go about ensuring that this particular
> piece of the file is written after it is last modified ?
That should "just happen" for any kind of bfd contents shouldn't it?
(Sorry in advance; i've got to go AFK for the rest of the evening now, so
won't be able to answer you straight away).
cheers,
DaveK