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


Hello Andreas,

>> From reading the docs it appeared to me that possibly using a SECTIONS
>> command in the linker script might do the trick - so added the
>> following to the end of the linker script:
>>
>> SECTIONS{
>>   fpc.ressym    : { *(fpc.ressym) }
>>   fpc.resstr    : { *(fpc.resstr) }
>>   fpc.reshash   : { *(fpc.reshash) }
>>   fpc.resdata   : { *(fpc.resdata) }
>>   fpc.resspare  : { *(fpc.resspare) }
>> }

AS> You could try to put all fpc.* sections in a single output section.

No, this doesn't help. They need to be in separated sections.

Here's why:

First of all: The goal was to implement a replaceable resource system
for FPC's ELF flavors that is similar to Kylix ones.

The goals in particular were:

- Resources can be embedded into the executable by the compiler
- Resources can be accessed from inside the executable at runtime
- It's possible to add, extract and change resources in a compiled
  executable.

The ELF binary format doesn't really provide support for all this.
Most importantly it does not support resizing of sections in the
binary.

This is solved in Kylix (and now for FPC) the following way: Inside
the ELF binary there are a bunch of new sections, holding the
resources, their names, pointers to the sections - and, here is the
clever trick: A spare section that has 0 bytes saved in the exe, but
is marked as the same size as the currently embedded resources are
(this is possible in ELF). It directly follows the section that has
the resource data. Now, if after compiling the resources are changed,
both the resource data section and the spare section get resized. This
means that at maxmimum, you can double the size of the resources in an
exisiting exe. This always should be enough headroom. It's important
to point out, that the spare section does not take up any space. It's
just that empty address room of the same size as the current resource
data get's reserved, which later can be re-used.

Simon



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