Re: gcc3 "millicode" problems with sh3 (toolchain/22452)
"Valeriy E. Ushakov" <[email protected]> Wed, 3 Sep 2003 16:45:52 +0400
| Newsgroups | gmane.os.netbsd.ports.sh3,gmane.os.netbsd.devel.toolchain |
|---|---|
| Message-ID | <[email protected]> |
On Wed, Sep 03, 2003 at 13:34:04 +0100, David Laight wrote: > > To solve this problem we need a static library with PIC code for all > > such functions, marked as ".hidden", we then need to link all shared > > libraries against this millicode library so that all each shared > > library gets its own private __udivsi3 &c that it can call directly. > > We also need a copy of __udivsi3 &c in libgcc.a. > > Why does that help? Or is it some special feature of .hidden? 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. So all calls to __udivsi3 from within a shared library will go to its own .hidden copy of __udivsi3, and such calls will satisfy the assumptions gcc makes (i.e. will not clobber any additional registers). > Usually references to non-static functions in shared libraries are > always called via PLT - because the version (if any) in the user > program should be used in preference to the one in the library. Sure, but __udivsi3 is not a normal library function. It's not even a function, really as it doesn't follow a function call conventions (which is the crux of the problem). > 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. SY, Uwe -- [email protected] | Zu Grunde kommen http://www.ptc.spbu.ru/~uwe/ | Ist zu Grunde gehen