[OpenIndiana-discuss] 32-bit and/or 64-bit programs (Was: Bash bug issue)

[Andrew Gabriel]

Bruce Lilly wrote:
> On Tue, Nov 11, 2014 at 7:21 AM, Andrew Gabriel <
> illumos at cucumber.demon.co.uk> wrote
>   
>> We currently support 32 bit and 64 bit kernel. A bug fix needs to work on
>> both 32 and 64 bit versions, so that would not be acceptable as a bug fix
>> for this issue (if it was something you were trying to fix in the distro).
>>
>>     
>
> There isn't anything specific in the program in question that would
> definitively qualify as a "bug".
> The program operates correctly e.g. even when compiled as a 32-bit
> application on NetBSD:
>
> # file grap
> grap: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically
> linked (uses shared libs), for NetBSD 6.1.5, not stripped
> # ./grap -d grap.defines test.grap | grep aligned
> line invis "2038-01-20T23:59:59" aligned from Frame.Bottom.end + (0, -0.4)
> to Frame.Bottom.start + (0, -0.4)
>
> There are two parts of the problem, neither of which is specific to
> application code:
> 1. 32-bit time_t provided by Solaris-derived kernel, run-time, and build
> system is inadequate (well-known, long-standing issue)
> 2. default build on Solaris-derived 64-bit systems is 32-bits.  Even though
> the 64-bit version works as expected on OI, it isn't built as 64-bit
> without special effort; i.e. by default anything using time_t is broken,
> even on 64-bit OI.
>
> Other OSes (e.g. NetBSD as shown above) have solved issue #1.
> If issue #1 is solved on illumos, issue #2 becomes strictly a performance
> tweak.
> If there's a "bug" involved here, it is issue #1.
>
> Issue #2 means that without special Solaris-specific effort, applications
> using time_t or any library functions that directly or indirectly use
> time_t may exhibit anomalous behavior when built for Solaris or illumos,
> even on 64-bit systems.
>
> Applications which need to handle dates outside of the operating system
>   
>> time (such as dates of births, deaths, marriages, retirements, etc)
>> shouldn't be using time_t -- that's very well established.
>>     
>
>
> You have an alternative?
> Note that every standard time-based function eventually involves time_t.
> That includes strftime() and strptime() as in the example, time(),
> clock_gettime(), all of the ctime functions (localtime(), gmtime(), etc.) ,
> mktime(), difftime(), and so on.
>   

These are all for handling times related to the operating system - 
time_t is not for handling arbitrary dates/times.
No banking/finance, spreadsheet, statistical or other application 
handling general dates goes anywhere near these functions. It's a bug in 
grap if it does. I just checked the AT&T grap, and it doesn't (although 
I'm not sure if it has any support for dates).

>> Generally, 32 bit apps which are simply rebuilt as 64 bit (without being
>> modified to explicitly make use of larger address space) run faster on x86
>> because of the extra registers available for compiler optimisation, and run
>> slower on sparc because of the larger working set size.
>>
>>     
>
> That sounds like a good reason (in addition to the time_t correctness
> issue) for making 64-bit builds the default, at least on 64-bit x86.
>   

The Solaris philosphy is that the default build is to build something 
that works on all supported x86 platforms.
If you want to build for specific architectures, instruction set 
features, or even for the very specific features of processor you are 
currently running on, those options exist, but selecting them 
unwittingly gets people into trouble when they build a binary and then 
find it won't work on some other system. If you then start building 
multiple binaries, the testing complexity multiplies considerably. The 
performance difference is almost always never worth the effort. There 
are some other reasons which make the effort necessary, such as a 
debugger needing to be 64 bit to debug a 64 bit process, or a large 
application which can make good use of more than 4GB address space.

If openindiana drops support for 32bit kernel at some point, then it 
might make sense.

-- 
Andrew