Subject: Re: gcc3 "millicode" problems with sh3 (toolchain/22452)
To: None <tech-toolchain@netbsd.org, port-sh3@netbsd.org,>
From: David Laight <david@l8s.co.uk>
List: tech-toolchain
Date: 09/03/2003 15:29:21
> To quote as.info in ".hidden":
> 
>    This directive overrides the named symbols default visibility (which
> is set by their binding: local, global or weak).  The directive sets
> the visibility to `hidden' which means that the symbols are not visible
> to other components.  Such symbols are always considered to be
> `protected' as well.
> 
> And for ".protected":
> 
>    This directive overrides the named symbols default visibility (which
> is set by their binding: local, global or weak).  The directive sets
> the visibility to `protected' which means that any references to the
> symbols from within the components that defines them must be resolved
> to the definition in that component, even if a definition in another
> component would normally preempt this.

Ok, so maybe we ought to process the symbol tables from ALL shared
libraries so that internal symbols are 'hidden' and most of the
interface functions 'protected' (unless libthread needs to override them...).

> > Actually, it ought (surely) be possible to write PLT code that can
> > jump to the correct function without requiring any extra registers?
> > (or is the sh object code particularly brain-dead?)
> 
> The call can only clobber r4, but r4 contains the first argument at
> the time of the call, so we are left with r0 only (that will contain
> the return value upon return) - which, as far as I understand, is not
> enough.

I thought the PLT (once fixed up) just contained a jump to the real function.
One register should be more than enough - but may require more code and
some nasty tricks.

	David

-- 
David Laight: david@l8s.co.uk