Re: sh-elf shared library dilemma

[kaz Kojima <kkojima at rr dot iij4u dot or dot jp>]

Hi,

Richard Henderson <rth@redhat.com> wrote:
>We treat basicly all relocs as partial-in-place on sh-elf.  Probably
>because coff did and it allowed more code to be copied.  But we're a
>RELA target because some of the relaxation relocs abuse the addend to
>store data.  The result of this is that we lose the addend at runtime.
>
>I see two solutions:
>
>  (1) Stop doing partial-in-place stuff and use the RELA addend
>      as it's supposed to.
>
>  (2) Leave the object file relocations alone and use REL dynamic
>      relocations.
>
>Both solutions have binary compatibility issues: the later only
>affects sh-linux; the former affects everyone.  The former seems
>more Correct.

I agreed.

Currently sh-linux people use a local patch which copies in-place
relocation to the addend at the final relocation stage of the shared
objects for some types of relocs and use a minimal hack in ld.so also.
This situation seems not so good.
There is another small problem in current sh-elf based on partial-
in-place relocation. For example, as I reported in this list, it can't
handle correctly the difference of the two symbols which are in the
different sections. We often hit by such nasty things in the shared
library.

Some sh-linux people were talking about new elf32-sh-lin.c which is
not a wrapper of elf32-sh.c but a standalone one which implements
usual RELA addends and a similar new stuff like tc-sh-lin.c in gas,
i.e. (1) on linux.
I was personally inclined to this though there is a maintenance problem
for such things.
Anyway, sh-linux guys don't complain about the binary incompatibility.
Maybe. sh-linux is still so yang.

	kaz