Re: debug_info strangeness (arm-mingw32ce)

[Danny Backx <danny dot backx at scarlet dot be>]

On Tue, 2009-12-15 at 17:44 +0000, Dave Korn wrote:
> 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?

Because the existing code will fail to initialize stuff like
 pe_data (abfd)->pe_opthdr.DataDirectory[PE_EXPORT_TABLE].VirtualAddress
after I change the circumstances in the linker script.

And then the content of the moved .edata is invalid because the RVAs
inside are calculated wrong, due to the changed circumstances.

> > 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.

Yes. I added this to the linker script :
    ${RELOCATING+__idata_start__ = .;}
  [.. the normal stuff for .idata ]
    ${RELOCATING+__idata_end__ = .;}
and then in _bfd_XXi_final_link_postscript() :
  h1 = coff_link_hash_lookup (coff_hash_table (info),
                  "__edata_start__", FALSE, FALSE, TRUE);
and fill up
pe_data (abfd)->pe_opthdr.DataDirectory[PE_EXPORT_TABLE].VirtualAddress
based on this.

> > 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.

Sounds good. I must admit I have focused just on getting some sample files in the right
shape, without focussing on code style or structure. Think of it as a proof of concept -
we have had the problem for over a year now that we cannot generate working DLLs for the
newer versions of Windows Mobile, and it's not entirely clear where the problem(s) lie(s).

To me this justifies the current approach... but I need to shift focus
now to getting the job done in the right way.

> > 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?

I'm afraid I'm not sufficiently up to speed on how "ld" really works for
me to answer that question.

	Danny
-- 
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info