This is the mail archive of the binutils@sources.redhat.com 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]

[ELF] Relocatable executables issues


Hello,

Here I am again with some other questions, more in-topic this time.

AROS needs its executables to be relocatable. So far AROS has dealt with
this issue, and the ELF format, by simply loading object files linked
together with the -r option of ld. However, I'm now making an
AROS-specific version of the binutils and gcc, and I want to do it in the
cleanest way (hoping that when I'm finished you guys will accept my
patches in the main source tree...), hence I want to make AROS be able to
load standard ELF executables.

However those executables have to be relocatable, so they'll have to
contain relocations info's. The 1st approach I thought of was to use the
-q option of ld, hardcoding it in the AROS-specific ld files. This worked
out well, however it doesn't make it possible using the -s option of ld
without breaking everything, and strip has to be used with the
--strip-unneeded option, which still leaves a lot of symbols around.

The 2nd possible approach has been suggested to me by a friend who is
working on something similar for a project of its own: he has made ld emit
relocation infos for the executable as if the executable where a shared
library, hence no symbol table is needed since all the relocations are of
type RELATIVE. However, this approach forces to load the whole executable
in one single piece of memory, which is ok for OSs which use separate
address spaces for each process, but is not so good for OSs like AROS
which use a single address space for all processes, because in that case
memory fragmentation gets into the way and it may happen that even if
there is enough memory to load the executable, this memory is not in one
single block: in that case allocating space for the single sections
instead than the whole executable could make things work.

That said, the 3rd approach I can think of is like the 1st one, except
that the relocations have to be relative to the sections symbols, not to
the single symbols. The question is: how do I do that? Could you please
tell me where should I start looking at? Basically, what I'm looking for,
is a way to do a sort of "prerelocation" by transforming a relocation
relative to a symbol into a relocation relative to the beginning of the
section where that symbol is in.

Any help would be greatly appreciated.

Thanks,
Fabio Alemagna


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