debug_info strangeness (arm-mingw32ce)
Danny Backx
danny.backx@scarlet.be
Tue Dec 15 15:25:00 GMT 2009
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
More information about the Binutils
mailing list