RFC: Handling of libgcc symbols in SH shared libraries

[Kaz Kojima]

Joern Rennecke <joern.rennecke@superh.com> wrote:
> Third, in order to avoid leaking symbols that should never be exported
> from user libraries, in lib1funcs.asm, I've defined a new macro HIDDEN_FUNC,
> and used it for the functions in question.

The function in libgcc.a has hidden visibility which is added by
a trick in building libgcc.a when SHLIB_LINK defined, though it'd
be better to mark them explicitly with HIDDEN_FUNC.
The other changes also seems fine.

> For now, for SFUNC_GOT, I always make function_symbol generate
> @GOT addressing, although for most functions that is not strictly
> necessary: they could use @PLT addressing, as long as it is guaranteed
> that the symbol is resolved at load time (or earlier with pre-linking).
> Is there any good way to do this?  As I understand, the presence of a single
> @GOT relocation would guarantee the timely resolution of the symbol,
> but we don't want to put extra crap in the program so we have a place where
> to put our relocation.
> I think best would be some kind of assembler directive that I can place
> in lib1funcs.asm that will force the symbol to be resolved at load time.

I have no idea about it.  I thought the current design comes from
the assumption that those libgcc functions will be likely used,
so the lazy linking for them is not important.

> There are also some issues with the software floating point functions
> that I am writing.  A number of these are drop-in replacements of
> the fp-bit and newlib functions, except that they use less registers
> (and are faster, obviously).  Leaving more registers unclobbered is
> quite useful on the SH architecture, so the sfunc patterns give an
> exact list of the registers that are clobbered.  That means
> the new functions can be linked with old programs and lobraries, but
> not vice versa.
> For static libraries, we can just make up another name so that we are sure
> that we will get the new functionality.
> For shared libraries, the symbol versioning is the preferred method;
> using a new name needlessly just pollutes the GOT.
> 
> However, these two approaches don't seem to mix very well.  Should I
> rely on someone using a new compiler to compile the programs to link
> against the new libgcc for static linking?

It seems reasonable to me.  It'd be not so surprise that a compiler
doesn't work properly with the different version of libgcc*.a.

Regards,
	kaz