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

Thu Jun 12 14:23:17 CEST 2008

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.comTo: m3devel at elegosoft.comSubject: 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 runat 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/4b97fea1/attachment-0002.html>