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