[M3devel] SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..?

[Tony Hosking]

I think I agree with you here.

On Jun 12, 2008, at 1:23 PM, Jay wrote:

> My inclination on the FloatMode/libsunmath issue is to not build the  
> SOLsun FloatMode support, and then see/hope if libsunmath isn't  
> otherwise needed, and -z text otherwise "works" -- if the rest of  
> the system can be built with it.
> The majority of all platforms and all "current" "active" platforms  
> do not implement FloatMode.
> It is a negative trend, but I can go along.
> If that changes, then I'd reconsider.
> Hopefully there is a better libsunmath.a available too though, or a  
> better way to implement this, perhaps in assembly, maybe some of  
> those new #pragma fenv things..
>
>  - Jay
>
> From: jayk123 at hotmail.com
> To: m3devel at elegosoft.com
> Subject: SOLsun/libgcc/libsunmath/FloatMode/dynamic linking/..?
> Date: Thu, 12 Jun 2008 05:04:22 +0000
>
> SOLsun..using cm3cg..
> a bit of a contradiction there?
>
> What SOLsun means:
>   Sun cc? Yes.
>   Sun ld? I think so.
>   Only Sun libs? I think so.
>
> But cm3cg, emits references to functions in libgcc.
> Currently just two trivial functions.
>
> In fact, I am tempted here to give their "spec"
> so someone can provide a "free" (non GPL) implementation.
> Since they get linked into client code.
>
> These functions provide unsigned 64 bit division and modulus.
> Rather than being sensibly named like _uint64div and
> _uint64mod, their names derive from gcc calling "int64"
> a "double integer" or "DI". A "single integer" or "SI" is 32 bits.
>
> The function prototypes are:
>
> unsigned long long __udivdi3 (unsigned long long x, unsigned long  
> long y);
> unsigned long long  __umoddi3 (unsigned long long x, unsigned long  
> long y);
>
> Can someone provide "free" implementations?
> I saw GPLed versions already so I can't.
> I think I provide a hint though.
> They can each be implemented in one line of C.
> As long as the C compiler used
>  - "open codes" then
>  or - calls out to functions with a different name
>
> Even if the same name is used, there's a possible workaround using  
> in-between functions.
>
> These functions are small enough that static linking should be viable.
> Currently they are exported from libm3core.so however.
> Make a separate lib?
> Currently they are in m3-libs/m3core/src/Csupport/libgcc.
> Maybe m3-libs/m3coremath/src?
>
> This would also be required in SOLsun, and nowhere else currently.
>
> There is another "problem" with SOLsun.
> FloatMode.m3 requires libsunmath.a.
> Ideally .so files are "fully" position independent and readonly.
> That is, not merely "relocatable", not merely "patchable" to run
> at any address, but can run at any address and all "patching" is done
> "specially" via something like a "RTOC" and/or "GOT" / "PLT"
>  runtime table of contents
>  global offset table
>  procedute linkage table
> and/or position indepenent addressing modes (for references to self).
>
> Tangent:
>   There are a surprisingly number of variables when dynamic linking.
>   Many decisions to make as to the exact semantics.
>   Are things "delay loaded" aka "statically loaded"?
>   When I load m3.so that depends on m3core.so is
>     m3core.so loaded immediately?
>     Are all the functions that m3.so calls resolved immediately?
>   This is a variable one can control through various linker switches.
>   As well, for any function that m3core.so calls and implements,
>    can either another .so, m3.so, or the executable itself, also
>    implement and "replace" or "intercept" or "interpose" those  
> functions?
>   Again, the answer varies.
>   On Windows, the answer is essentially no, not never. Unless you go  
> to
>    some extra length to allow for it.
>   On Unix the answer seems to vary per system and switches.
>    Allowing this interception often requires less efficient code.
>    And at least in one place resulted in buggy code, that I fixed  
> recently,
>      I think it was on AMD64_LINUX. Going through the indirection  
> mechanism, the PLT,
>      trashes the static link in rcx, or something like that.
>  And it is just unnecessary indirection in almost all cases.
>  So, the questions become, what do people want/expect for Modula-3?
>   And, does it vary from person to person? System to system?
>   Windows is "never" going to allow the interposition.
>  Allowing "interposition" also goes by the description "allow
>    unresolved symbols in shared objects", to be resolved at load time.
>  Unix often has one global namespace for all functions in a process.
>  Apple has a similar thing between "one level namespaces" and "two  
> level namespaces".
>   In an older release, they had only one level namespace. Every  
> dynamically imported
>   function would be searched for in all dynamically loaded files.
>   Usually at build time you know the name of the shared object you  
> expect to find
>   the function in. So you can have a "two level namespace" where  
> function names
>   are associated with a particular file name, and only that file is  
> searched.
>   Apple encourages this usage, though of course is bound somewhat by  
> compatibility.
>   You can perhaps still build binaries that run on 10.0, and  
> binaries built to run
>    on 10.0 in the first place can still run today.
>   The need to do either of these is always diminishing but hard to  
> deem zero.
>
>  SOLsun linker has two related switches.
>  libsunmath.a apparently is not built fully position independent.
>  libm3core.so must link to it, and therefore does not have a fully  
> read only text section.
>
>  what to do?
>
>  A few options:
>   Go back to allowing unresolved symbols in SOLsun, enabling  
> "interposition".
>   Then I think libsunmath.a isn't used by .sos, just executables.
>   I don't like this option. Binding functions to particular file  
> names (not paths)
>    seems right and is encouraged by Apple and about the only option  
> on Windows.
>    It seems good to use when available.
>
>  Allow writable text section in all .so.
>    This is what I commited.
>
>  Allow writable text section in only libm3core.so.
>    This is a better compromise than previous.
>
>  Move FloatMode.m3 into a separate so... libm3coremath.so,
>    and only let it have a writable text section.
>    This is a better compromise in terms of amount of writable text,  
> but also
>     adds another .so. The fewer .sos the better, arguably.
>
>  Change FloatMode.m3 somehow to not use libsunmath.a.
>    I think the only way to do this is to make it do nothing at all,  
> which
>    is probably what most of the implementations do, but I'd have to  
> check.
>    FloatMode.m3 is generally implementable on many systems, like via  
> _controlfp
>    on NT386. It is also dangerous to be mucking with the floating  
> mode --
>    what code in the process depends on the default and will be  
> broken by it changing?
>
>  Worse, the SPARC implementation has a comment saying it is  
> implemented process-wide
>   instead of per-thread. Really there are arguments either way.
>
>  The "common" implementation just asserts false.
>   DS3100, VAX, IRIX, SPARC, SUN386, implement FloatMode.
>   NT386, *_DARWIN, *_LINUX, *_FREEBSD, SOLgnu do not.
>
>  Maybe just turn it off for SOLsun too?
>  or go through and provide it everywhere? Always per-thread if  
> possible?
>  Only on pthreads implementations preferably?
>   (I'm not a fan of user threads in general, so don't wish to make  
> them "better".)
>
>  I think removing FloatMode for SOLsun is probably the way to go.
>   See if that removes requirement on libsunmath.a.
>   See if that then allows fully position independent and "resolved"  
> symbols.
>
>  And maybe there is an updated libsunmath.a?
>  I just have a "random" version of Solaris 10 from eBay.
>  I could try a newer OpenSolaris/Nevada version.
>
>  Or drop SOLsun as uninteresting?
>   (My internet is slow as I said. I finally finished downloading
>   the "normal" gcc and can build it and try the more active SOLgnu  
> instead.)
>
>  That would at least ease figuring out the names of:
>    I386_SOLARIS, AMD64_SOLARIS, SPARC64_SOLARIS
>
>  no need to have two of these of those. :)
>
>  And is SOLgnu meant to use GNU ld or not?
>  It looks like not. SOLsun and SOLgnu config files are "the same"  
> here.
>  Could be GNU ld is compatible in command line usage though.
>
>  (not yet -- I almost have the 64 bit hosted cm3cg bug figured out.
>  it occurs the same on SPARC64_OPENBSD as AMD64_LINUX. Something about
>  assignment being DImode vs. VOIDmode. Occurs in many places,  
> including
>  RTRuntimeError.Self, by virtue of it using TRY.)
>
>  - Jay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080612/cfbf7ab0/attachment-0002.html>