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[2]: Help needed - defining the output section order


[Forgot the copy for the list, sorry]

Hi Nick,

>> (Also, I still would love to hear an alternative solution that does
>> not require the compiler to generate all LD default scripts for each
>> platform itself - this sounds like the direct way to version hell).

NC> Ok - how about using objcopy and the --add-section and --remove-section
NC> switches ?  When you need to resize the fpc.* sections you could use
NC> --remove-section to strip the old ones of the executable and then 
NC> --add-section to add in the new ones.  Of course this assumes that you
NC> have some way of recreating the contents of these sections since the
NC> --add-section switch just reads in a file and dumps its contents into
NC> the newly created section.

I have to admit I've got next to no knowledge about objcopy. But
looking at it from the ELF perspective, my logic says to me this can't
work: If one would change the size of a section when replacing it,
sections after it in the ELF would need be relocated. And this again
could only theoretically work if the symbols would still be present
and not stripped.

That's the whole concept behind what I'm trying to achieve - as we
know that it's impossible to resize sections in an ELF executable, we
use a NOBITS section directly following the section containing the
resource data. This way we can make sure there is address space
available in case we later wish to increase the size of the section
containing the resources. Changing the size now simply is a matter of
increasing the size of the resource data section, decreasing the size of the
NOBITS section, and changing the file offsets of the sections after
it - the load addresses of all sections remain unchanged, and
therefore relocation isn't needed.

That's what Borland has implemented on Linux for Kylix. However, they
wrote their own ELF linker to do that. And I'm now trying to achieve
the same thing WITHOUT having to write an own linker ;)

Simon



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