Re: [PATCH] [ELF] symbol sets handling

[Fabio Alemagna <falemagn at studenti dot unina dot it>]

On Sat, 8 Feb 2003, Alan Modra wrote:

> On Fri, Feb 07, 2003 at 12:33:09PM +0000, Nick Clifton wrote:
> > [cc'd Alan, since he wrote the original code].
>
> The blame/glory belongs to Ian.
>
> I have poked at the code in question, and Fabio's change looks
> reasonable.  It shouldn't affect the linker since the linker
> needs to resolve section relative symbols anyway.

I tried it and the linker still works as always.

> However, I question whether it's a good idea given that other symbols
> defined in the default linker script are absolute.

That's an issue I came across as well... At first I thought I'd just make
my own script where all the absolute symbols are relative to the section
which makes more sense for them to be relative to, but then I understood
that there's not always such section, hence I decided to take another way:
in my relocate_section(), in case the absolute symbols's value fell into
the range of the executable's address space, I'd transform the relocation
relative to that symbol into a relocation relative to the start of the
_segment_ whose address space contains that symbol's value. For all other
absolute symbol values I just skip the relocation.

In short, all the relocations in final executable are relative to the
segments, and when possible I translate relocations relative to absolute
symbols into relocations relative to the start of the segment which
contains that symbol.

This would solve oth the problem of constructors and script-defined
symbols.

For now I still have to implement that, however I've already implemented
my own relocation section (which is half as short as the normal one),
whose relocations are, for now, section-relative. It will be a joke,
though, to make them segment-relative, since the segments have already
been allocated by the time relocate_section() is invoked.

It seems impossible, though, for the way the elf backend is made, to know
how many segments there will be by the time I have to decide how much big
will the relocation section be...

Also, right now the relocation sections hold into the sh_info field the
number of the section to relocate, however since my loader will work on
segments, rather than sections, it would be better if sh_info contained
the number of a segment... but this would also require to join more
relocation sections so that the resulting one actually refers to the
segment which contains the sections to relocate... This seems impossible
as well...

Regards,
Fabio Alemagna