<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>
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 <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 <BR> global offset table <BR> procedute linkage table <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 -- <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></body>
</html>