This is the mail archive of the binutils@sourceware.org mailing list for the binutils 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: debug_info strangeness (arm-mingw32ce)


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


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