Re: Smoking gun: NetBSD 6.0.1 userland instability

[Donald Lee <MacPPC2%c.icompute.com@localhost>]

>On Thu, Mar 7, 2013 at 11:59 AM, Donald Lee <MacPPC2%c.icompute.com@localhost> 
>wrote:
>>>>> In the old days, I would just use "-g", and presume that the
>>>>> optimization was disabled, but modern compilers don't do that any
>>>>> more.
>>>> The only thing -g should do is enable debugging symbols; it doesn't
>>>> generally have an effect on optimization.  Perhaps you mean -O0?
>>>
>>>No, I think more likely -dgl- was talking about "the old days", when,
>>>yes, -g did indeed kill the optimizer.  It's been a while, but there
>>>was such a time.
>>
>> ...back when the dinosaurs roamed the earth, and computers had front panels
>> with switches and lights.
>>
>> Thus sayeth the Old Guys. ;->
>>
>> If anyone can give me some confidence in what switches I need to use to
>> get what we need, I can do the experiment(s).
>
>I hope I'm not talking out of turn here, but the kernel config has an
>Altivec option:
>
>andy@dockstar2:~/src/netbsd/src/sys/arch/macppc/conf$ grep -i altivec GENERIC
>options         ALTIVEC         # Include AltiVec support
>
>What if you disable it?
>
>Andy

My paranoia runs deep.  Experience.

Changing the options would require a kernel build, right?.  I have no experience
with cross-building.  My 5.2 installation is pretty "rustic", if you know
what I mean.

There is also the question of what, exactly that option does.  What happens
if ALTIVEC is disabled via option, and an executable tries to use
said instructions?  Does the kernel emulate via traps?  Have the
traps been tested?  This might simply be unexplored territory. ;->

Given that something might be busted in my kernel, is it wise to build a kernel
on a broken machine to test for a bug?  If someone is willing to build me 
such a kernel (6.0.1 - altivec), I can easily test it, but I'm not
sure what it would tell us.

-dgl-