This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: debug_info strangeness (arm-mingw32ce)
- From: Danny Backx <danny dot backx at scarlet dot be>
- To: Nick Clifton <nickc at redhat dot com>
- Cc: Alan Modra <amodra at bigpond dot net dot au>, binutils <binutils at sourceware dot org>
- Date: Tue, 15 Dec 2009 16:25:50 +0100
- 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>
- Reply-to: danny dot backx at scarlet dot be
On Thu, 2009-12-10 at 11:59 +0000, Nick Clifton wrote:
> > Then it looks like the check (see above) should not be
> > if (! bfd_coff_link_output_has_begun (sub, & finfo))
> > but simply
> > if (! sub->output_has_begun)
> >
> > This change makes my simple test magically work :-)
[..]
> What it is trying to do is to prevent _bfd_coff_link_input_bfd from
> being called on the bfd that has been selected to contain the glue
> sections. The idea I believe is that this will force the sections in
> this bfd to be written out after all the other sections. (The reason
> for this is that the size of the glue sections is not known until the
> amount of glue code needed is known, and this information will only be
> available once all of the input sections have been processed).
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 .
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.
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 ?
A second question is how I should go about ensuring that this particular
piece of the file is written after it is last modified ?
My current hacks can illustrate my questions : they're at
http://danny.backx.info/download/cegcc/hack-binutils.1 .
Danny
--
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info