Thread support in 0.10 on OpenBSD

[Robert S. Thau]

Daniel Veillard writes:
 > [Had to repost this message which bounced due to too strict checking
 >  for mails loops on the mailing list, Daniel ]
 > 
 > Robert S. Thau Wrote:
 > 
 >   ..in cross-platform development, the simpler you can keep your build
 >   environments, and the less you constrain them, the better.
 > 
 > Having done extensive cross-platform development myself over the years,
 > I have found that dependence on undocumented internal compiler features
 > (such as the register assignment layout in the jmp_buf) lead to more
 > problems than they are ever worth. These things tend to be unstable from
 > compiler release to release and between the compilers of different
 > vendors.

Ummm... it's not actually a compiler feature.  It's a library feature;
setjmp() and longjmp() are library routines, which are generally
written in assembler, but rarely have any specific support in the
compiler per se (other than perhaps some pragmas to warn of screwy
flow control).  This is why it is rather likely to stay stable from
release to release --- changes to jmp_buf format would risk breaking
binary compatibility between releases (particularly if the size
changed).  It certainly won't change between compiler releases or
versions, at least among compilers which are willing to deal with the
stock C runtime library.

 > Although the inline assembler directive may be different between
 > compilers of different vendors, the feature is stable from release to
 > release. The stack pointer register name used in the directive is also
 > stable. Once a port is completed using these well documented directives,
 > it need not be looked at again.

Recent history shows this doesn't always work out; compiling
then-current linux kernels with gcc 2.8 at the time of its initial
release didn't work because some of the inline assembly directives
were processed differently, resulting in bad code.  I know that
there's been some back-and-forth between Linus and various gcc
developers about whether the asm() directives in question ever
*should* have worked, but regardless, the ultimate effect is that code
that used to work stopped working in a new release of the compiler.
(BTW, the one thing that everyone seems to agree on is that the
details of parameter-passing to assembly code were not as
well-documented as they ought to have been, and gcc documents this
more thoroughly than most other compilers).

Also, you might want to use a compiler from a different vendor.  This
is a practical issue; gcc's code generation is substantially inferior
to vendor compilers for quite a few popular RISCs, and mandating gcc
usage on those systems would mandate poor performance, which I think
most people would prefer to avoid if it's possible without undue cost.
Conversely, mandating usage of the vendor compiler would lock out
people who couldn't afford it.

BTW, my opinion here is based on part on substantial experience with
the Apache project; I rewrote the guts of the thing early on, and
getting the rewritten code to run on all the scungy systems to which I
then had access, including AIX, SunOS, and (gagh!) Ultrix, was an
education.  (You could find the most amazing things sitting in Athena
clusters back in those days).  People wanting to switch compilers came
up repeatedly in the Apache group as a practical issue; gcc, in
particular, was the only thing that some people had on HP-UX, but the
code it generated was lousy and people with the vendor compiler often
found it far preferable.  The same may be true of Alpha these days;
last I heard --- admittedly pre-2.8 --- the instruction scheduling had
never been redone for the 21164.

(Of course, end-user preferences of this kind are less of an issue if
you're only doing binary releases, but on an open source project,
there's just no getting away from them, at least not without pissing
people --- i.e., potential collaborators --- off). 

Of course, it's not completely unheard of for people to have multiple
libc's on a given platform either, but it's much less common than
having multiple compilers, and the people who play such games are
often switching compilers as well.  Hence, my own personal choice
among the various unpleasant alternatives, none of which are certain
to work --- jmp_buf layout isn't *certain* to stay stable from release
to release, but *nothing* is certain, and relying on jmp_buf layout
strikes me as less likely to cause trouble than some of the
alternatives.  (About the only platform I'm aware of where this
situation is likely to come up is i386/linux, and the SP there seems
to be at the same offset in both libc5 and libc6, as far as I can tell
from reading header files.  But I haven't actually tried the code, and
YMMV).

But, as you say, with regard to kaffe, the point is moot.

rst