[M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)

[Rodney M. Bates]

Jay K wrote:
>> They do suggest that the fields will likely be laid out right-to-left
>> on a little-endian machine and conversely.  But even there, it matters
>> what size of "unit" is laid out this way (a native word, for example)
>> before moving on to the next unit, and that is also implementation-defined.
>  
> This is what I was alluding to.
> Even though the rules are explicitly compiler-dependent, it could be
> that to all compiler writers, such as their shared mindset may be,
> there are fairly obvious rules to adopt
> and they pretty much all adopt the same ones. I don't know.
> 
> Not "all compilers", but "gcc on all platforms".
> 
> I suspect that if we said like:
> #if TARGET_BIG_ENDIAN /* or !TARGET_LITTLE_ENDIAN, one of these probably exists */
>   m = TYPE_PRECISION(t) - m.
> #endif
> 
> it'd work.
> 
> 
> Anyway, I put the code back.
> 
> 
> It would also be a good idea to consistently used bitfields for all insert/extract
> forms, instead of just one extract form. That would provide consistency.
> But we also use extract in other places, e.g. division.
>  So consistency between insert and extract isn't actually sufficient.

Ah, are you talking about bit field _operators_ in the intermediate form
generated by parse.c to gcc?  These could well be a different animal
from C source code bit fields.  Or perhaps the C front end does a direct
translation, but gcc has well-defined semantics for them.  I would expect
these would follow a consistent pattern, for gcc.  Might have to do some
heavy code reading to infer it.

> 
> 
> We do use bitfields in an odd way -- for all loads and stores,
> that either have a non-zero offset or that do a type conversion,
> and it bugs me.
> 
> 
> There is something in gcc that decides if you are offseting
> more than a word into something only a word size, throw out the offset,
> or somesuch. OpenBSD/mips64 used to incorrectly access all "globals".
> "Globals" are defined by parse.c as just a block of memory
> with a name for its start, and..we don't know the size, so before
> we said it is arbitrarily small, like a word, as a workaround I
> declare that it is a arbitrarily less small:
> 
> 
> static void
> m3cg_declare_segment (void)
> {
> ...
>   /* we really don't have an idea of what the type of this var is; let's try
>      to put something that will be good enough for all the uses of this var we
>      are going to see before we have a bind_segment. Use a large size so that
>      gcc doesn't think it fits in a register, so that loads out of it do get
>      their offsets applied. */
>   TREE_TYPE (v)
>     = m3_build_type (T_struct, BIGGEST_ALIGNMENT * 2, BIGGEST_ALIGNMENT);
>   layout_decl (v, BIGGEST_ALIGNMENT);
> 
> 
> We do actually know the size though.
> The thing could be declared to be a record with typed fields
>  and we could use "component refs", except we don't bother
>  passing enough information along.
> It's related to what Tony and I said yesterday.
> 
> 
> (OpenBSD/mips64 isn't known to fully work anyway.
> But MIPS is making a comeback, see:
> http://www.openbsd.org/loongson.html
> http://www.lemote.com/en/products/all-in-one/2010/0311/122.html
> http://www.lemote.com/en/products/Notebook/2010/0310/112.html
> etc.
> )
> 
>  - Jay
> 
> ----------------------------------------
>> Date: Sat, 15 May 2010 20:59:18 -0500
>> From: rodney_bates at lcwb.coop
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>
>>
>>
>> Jay K wrote:
>>> I think the layout of bitfields is somewhat up to the compiler -- gcc in this case.
>>> And that bit offsets are interpreted differently for big endian and little endian.
>>> I can NOT confirm that I386_LINUX was broken.
>>> As well I had recently been working with I386_SOLARIS and AMD64_SOLARIS, without problem.
>>>
>>>
>>> I happen to then try a bunch of big endian platforms.
>>>
>>>
>>> Bitfield layout may also be subject to being defined by an ABI, and/or to matching compilers
>>> other than gcc. Like, I386_SOLARIS and I386_DARWIN and I386_LINUX could, I think, concievably,
>>> layout bitfields differently. (Heck, alignment could even cause "simpler" cases to be different,
>>> but I think it is fairly easy to come up with structs without bitfields with the "same" layout
>>> across all architectures, at least for a given wordsize/endian.)
>>>
>>>
>>> I should admit something.
>>> When I read C code with bit fields I have absolutely no idea how to compute the layout in my head.
>>> Lately for this reason I've been removing them from code where I can.
>>> Clearly they have a place, where compactness of data is of the prime importance.
>>>
>>>
>>> It's possible this is just me, that more expert programmers can readily imagine just how
>>> bitfield ought to be laid out, that all the ABIs/compilers follow the obvious rules, and that
>>> therefore they can determine the layout from glancing at the declaration.
>>>
>> According to my C '99 standard, just about everything about bit field layout is
>> implementation-defined, except for the bit count of each field. Harbison and
>> Steele (5th ed.) say pretty much the same thing and ultimately recommend coding
>> using bit-twiddling operators instead of bit fields. Failing that, they recommend
>> doing experiments with your particular compiler to verify your assumptions. Obviously
>> not possible for portable code.
>>
>> They do suggest that the fields will likely be laid out right-to-left on a little-endian
>> machine and conversely. But even there, it matters what size of "unit" is laid out
>> this way (a native word, for example) before moving on to the next unit, and that
>> is also implementation-defined.
>>
>>
>>> I just can't imagine what would be obvious.
>>> Simple example:
>>>
>>> typedef union {
>>> unsigned AsInt32;
>>> struct { unsigned a : 1 } Bits;
>>> } T1;
>>>
>>>
>>> T1 t;
>>> t.Bits.a = 1;
>>>
>>>
>>> printf("%x\n", t.AsInt32);
>>>
>>>
>>> prints 1 or 0x80000000 or what?
>>>
>>>
>>> It could be there are obvious rules, and they are endian dependent, but that otherwise
>>> all ABIs and compilers define them the same.
>>> If that is the case, I think we could get something more "optimal".
>>> However, notice how similar the "optimized" code was.
>>> And we could easily generate that without a bitfield ref.
>>> Just shift right and and with a constant, instead of shift left and then right.
>>>
>>>
>>> Could be that the decision is target-dependent as to what is optimal though.
>>>
>>>
>>> - Jay
>>>
>>>
>>> ----------------------------------------
>>>> From: hosking at cs.purdue.edu
>>>> Date: Sat, 15 May 2010 00:14:54 -0400
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>
>>>> COMPONENT_REF is difficult because of the lack of type info I think. Please revert to what it used to be.
>>>>
>>>>
>>>> On 14 May 2010, at 23:10, Jay K wrote:
>>>>
>>>>> http://gcc.gnu.org/ml/gcc/2006-02/msg00577.html
>>>>>
>>>>> BIT_FIELD_REF considered harmful
>>>>>
>>>>> We should try to use COMPONENT_REF instead.
>>>>>
>>>>> - Jay
>>>>>
>>>>> ----------------------------------------
>>>>>> From: jay.krell at cornell.edu
>>>>>> To: hosking at cs.purdue.edu
>>>>>> Date: Sat, 15 May 2010 01:29:01 +0000
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>
>>>>>>
>>>>>> Well I'm feeling dumb. That test case surely would print 1 for almost anything.
>>>>>> A more accurate one, which shows a problem, is:
>>>>>>
>>>>>> #include
>>>>>>
>>>>>> unsigned F1(unsigned a) { return ((a>> 22) & 1); }
>>>>>> unsigned F2(unsigned a) { return ((a << 22)>> 31); }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> unsigned a = 1 << 22;
>>>>>> printf("%x %x\n", F1(a), F2(a));
>>>>>> return 0;
>>>>>> }
>>>>>>
>>>>>> But I'm still having trouble convincing myself.
>>>>>> I guess the second might give you the 10th bit.
>>>>>> Er, the 9th.
>>>>>>
>>>>>> #include
>>>>>>
>>>>>> unsigned F1(unsigned a) { return ((a>> 22) & 1); }
>>>>>> unsigned F2(unsigned a) { return ((a << 22)>> 31); }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> unsigned a = 1 << 22;
>>>>>> printf("%x %x\n", F1(a), F2(a));
>>>>>>
>>>>>> a = 1 << 9;
>>>>>> printf("%x %x\n", F1(a), F2(a));
>>>>>> return 0;
>>>>>> }
>>>>>>
>>>>>> 1 0
>>>>>> 0 1
>>>>>>
>>>>>> - Jay
>>>>>>
>>>>>> ----------------------------------------
>>>>>>> From: jay.krell at cornell.edu
>>>>>>> To: hosking at cs.purdue.edu
>>>>>>> Date: Sat, 15 May 2010 01:07:27 +0000
>>>>>>> CC: m3devel at elegosoft.com
>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>
>>>>>>>
>>>>>>>> < srl %g1, 22, %g1
>>>>>>>> < and %g1, 1, %g1
>>>>>>>> ---
>>>>>>>>> sll %g1, 22, %g1
>>>>>>>>> srl %g1, 31, %g1
>>>>>>> Er.
>>>>>>> first: a = (a>> 22) & 1;
>>>>>>> second: a = (a << 22)>> 31;
>>>>>>>
>>>>>>> are actually darn close, maybe the same.
>>>>>>> Let's just be lame and test in C:
>>>>>>>
>>>>>>> #include
>>>>>>> int main()
>>>>>>> {
>>>>>>> unsigned a = ~0;
>>>>>>> unsigned b = (a>> 22) & 1;
>>>>>>> unsigned c = (a << 22)>> 31;
>>>>>>> printf("%x %x\n", b, c);
>>>>>>> return 0;
>>>>>>> }
>>>>>>>
>>>>>>> both print 1. So I remain a bit uncertain.
>>>>>>> I think undoing just that one change made it go between working and not working, but I also often lose track of what I've cleaned vs. rebuilt.
>>>>>>> I might dig more before commiting the undo.
>>>>>>> Maybe bit fields of multiple bits are the only ones broken.
>>>>>>>
>>>>>>> - Jay
>>>>>>>
>>>>>>>
>>>>>>> ----------------------------------------
>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>> To: hosking at cs.purdue.edu
>>>>>>>> Date: Sat, 15 May 2010 00:24:03 +0000
>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>
>>>>>>>>
>>>>>>>> Tony I think it is your change to extract_mn.
>>>>>>>> Try it with SOLsun for example.
>>>>>>>> I see these sorts of differences repeatedly (not to mention works vs. not works, having only undone that change):
>>>>>>>>
>>>>>>>>
>>>>>>>> diff cm3-boot-SOLsun-1/Abs.ms cm3-boot-SOLsun-2/Abs.ms
>>>>>>>> 77,78c77,78
>>>>>>>> < srl %g1, 22, %g1
>>>>>>>> < and %g1, 1, %g1
>>>>>>>> ---
>>>>>>>>> sll %g1, 22, %g1
>>>>>>>>> srl %g1, 31, %g1
>>>>>>>> 118,119c118,119
>>>>>>>> < srl %g1, 22, %g1
>>>>>>>> < and %g1, 1, %g1
>>>>>>>> ---
>>>>>>>>> sll %g1, 22, %g1
>>>>>>>>> srl %g1, 31, %g1
>>>>>>>> 197,198c197,198
>>>>>>>> < srl %g1, 21, %g1
>>>>>>>> < and %g1, 1, %g1
>>>>>>>> ---
>>>>>>>>> sll %g1, 21, %g1
>>>>>>>>> srl %g1, 31, %g1
>>>>>>>> 236,237c236,237
>>>>>>>> < srl %g1, 22, %g1
>>>>>>>> < and %g1, 1, %g1
>>>>>>>> ---
>>>>>>>>> sll %g1, 22, %g1
>>>>>>>>> srl %g1, 31, %g1
>>>>>>>> 273,274c273,274
>>>>>>>> < srl %g1, 22, %g1
>>>>>>>> < and %g1, 1, %g1
>>>>>>>>
>>>>>>>>
>>>>>>>> This is not optimized.
>>>>>>>> They seem equally optimal, but very different.
>>>>>>>> Assuming shifts are fast. Could be srl+and is faster than sll+srl.
>>>>>>>> srl+and is clearer.
>>>>>>>> I don't remember which of these worked.
>>>>>>>>
>>>>>>>>
>>>>>>>> < srl %g1, 22, %g1
>>>>>>>>
>>>>>>>> < and %g1, 1, %g1
>>>>>>>>
>>>>>>>> ---
>>>>>>>>
>>>>>>>>> sll %g1, 22, %g1
>>>>>>>>> srl %g1, 31, %g1
>>>>>>>>
>>>>>>>> I read the first as:
>>>>>>>> extract bit 22, plus or minus 1
>>>>>>>> vs.
>>>>>>>> extract bit 32-22=10, plus or minus 1.
>>>>>>>>
>>>>>>>>
>>>>>>>> It would probably be ok to move bits around, but insert would have to match.
>>>>>>>>
>>>>>>>>
>>>>>>>> - Jay
>>>>>>>>
>>>>>>>>
>>>>>>>> ----------------------------------------
>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>> To: hosking at cs.purdue.edu
>>>>>>>>> Date: Fri, 14 May 2010 22:13:58 +0000
>>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> So maybe I386_LINUX is ok..but others not..I need to test more/again/more/again/more/again....
>>>>>>>>>
>>>>>>>>> - Jay
>>>>>>>>>
>>>>>>>>> ----------------------------------------
>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>> To: hosking at cs.purdue.edu
>>>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>>>> Subject: RE: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>> Date: Fri, 14 May 2010 18:25:59 +0000
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I should disclose that I also rolled back hand.c, though that is mostly or completely implied, due to mod/div/set.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I have some extra time today, so, plan:
>>>>>>>>>> retest head on I386_LINUX (still crossing from Darwin/x86), verify it is broken, since it is all working now
>>>>>>>>>> test undo just the bitfield insert/extract change, see if that is the problem
>>>>>>>>>> work through the others if not
>>>>>>>>>> Possibly verify mod/div test coverage (unless it is the problem, in which
>>>>>>>>>> case if I put it back, no need for test coverage, probably nobody will ever
>>>>>>>>>> touch it again, which is fine. :) )
>>>>>>>>>> I'm pretty sure I tested the set stuff well because I was very nervous but
>>>>>>>>>> if others are ruled out I'll undo or test it.
>>>>>>>>>> (To clarify, I wasn't even sure by close inspection of the correctness of my NT386
>>>>>>>>>> set changes. Only through experimentation/testing could I know that
>>>>>>>>>> the definition of bit indices matched up between hand.c and the btc/bts instructions,
>>>>>>>>>> it appeared to be a very convenient coincidence.)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I am surprised that I386_* working and broken.
>>>>>>>>>> I would think wordsize and endian is all that matters here.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I do worry that we are only on gcc 4.3.0 and not even 4.3.3.
>>>>>>>>>> But moving up to 4.4.x or 4.5.x is welcome too. :)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> - Jay
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ----------------------------------------
>>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>>> To: hosking at cs.purdue.edu
>>>>>>>>>>> Date: Fri, 14 May 2010 17:58:29 +0000
>>>>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I don't think anything I've been fiddling with has been dropped by gcc, yet.
>>>>>>>>>>> I might have depended on Irix o32 to get up to a working gcc, but no matter.
>>>>>>>>>>> I agree if they drop it, we have to.
>>>>>>>>>>> Though we could also keep multiple gcc versions if there was really something we wanted,
>>>>>>>>>>> but that's not likely.
>>>>>>>>>>> A C generating backend also solves this.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I think I tested my "set" changes on 32bit, 64bit, little endian, big endian, all four combinations.
>>>>>>>>>>> But I won't guarantee that now and am very willing to undo them if there is a problem.
>>>>>>>>>>> (big endian 64bit would be PPC64_DARWIN, which does have a strong propensity to hang, but also largely works).
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I don't remember about div/mod.
>>>>>>>>>>> While it seems "obvious" that the change is correct, it could be that that part of
>>>>>>>>>>> gcc is little tested: C and Fortran wouldn't use it. But maybe Ada?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I'm also not optimizing at all.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I also agree that rolling forward to any newer gcc is welcome. I just don't know how to do it, at least not
>>>>>>>>>>> easily, and I'm also not keen on the huge testing matrix.
>>>>>>>>>>> (I think it's roughly what I did for Apple's gcc 4.2, but it was tedious.)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> If it is ICEs we are after though, it is fairly easy to do cross builds and test "everything", automated, given the time to build gcc enough times. :)
>>>>>>>>>>> We should really fix the few lingering 32bit/64bit cross bugs, so we can cross build everything.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Rolling back parse.c, I think every target I've tested (running cm3 bootstrap and making
>>>>>>>>>>> sure it gets as far as "can't find cm3.cfg") has worked, except PPC32_OPENBSD.
>>>>>>>>>>> This includes PPC_DARWIN, PPC64_DARWIN, I386_LINUX, SPARC64_SOLARIS,
>>>>>>>>>>> SPARC64_OPENBSD. (SPARC64_SOLARIS now probably working).
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> - Jay
>>>>>>>>>>>
>>>>>>>>>>> ----------------------------------------
>>>>>>>>>>>> From: hosking at cs.purdue.edu
>>>>>>>>>>>> Date: Fri, 14 May 2010 09:59:02 -0400
>>>>>>>>>>>> To: jay.krell at cornell.edu
>>>>>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>>>
>>>>>>>>>>>> Argh. I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.
>>>>>>>>>>>>
>>>>>>>>>>>> Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels. I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution. This is fragile stuff... and it may just be a bug in gcc that we are exercising.
>>>>>>>>>>>>
>>>>>>>>>>>> It may be that we just need to update the backend to a newer version of gcc. It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been. Problem is that newer gcc may not play nice with older targets. I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.
>>>>>>>>>>>>
>>>>>>>>>>>> On 14 May 2010, at 06:27, Jay K wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
>>>>>>>>>>>>> Then I'll have to narrow it down some -- there are two main sets of changes:
>>>>>>>>>>>>> - my changes to set operations
>>>>>>>>>>>>> - my change to div/mod
>>>>>>>>>>>>> - Tony's to bit field operations
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
>>>>>>>>>>>>> to keep them if they don't work.
>>>>>>>>>>>>> (Well, hopefully the NT386 versions can stay. :) )
>>>>>>>>>>>>>
>>>>>>>>>>>>> - Jay
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ----------------------------------------
>>>>>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>>>>>>> Date: Fri, 14 May 2010 09:08:58 +0000
>>>>>>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>>>>>>>>>>>>> PPC_DARWIN, SOLsun, I386_LINUX
>>>>>>>>>>>>>> I'll figure it out. Hopefully soon.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - Jay
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ----------------------------------------
>>>>>>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>>>>>>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>>>>>>>>>>>>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>>>>>>>>>>>>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>>>>>>>>>>>>>> I think it used to mostly work since I deleted some install I had there.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>>>>>>>>>>>>>> (gdb) disassem
>>>>>>>>>>>>>>> Dump of assembler code for function RTLinker__InitRuntime:
>>>>>>>>>>>>>>> 0x00000000004bd01c : save %sp, -224, %sp
>>>>>>>>>>>>>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>>>>>>>>>>>>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>>>>>>>>>>>>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>>>>>>>>>>>>>> 0x00000000004bd02c : nop
>>>>>>>>>>>>>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>>>>>>>>>>>>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>>>>>>>>>>>>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>>>>>>>>>>>>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>>>>>>>>>>>>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>>>>>>>>>>>>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>>>>>>>>>>>>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This seems like it'll be tough going. :(
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I think I'll try with PIC turned off.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - Jay
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>