[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Smoking gun: NetBSD 6.0.1 userland instability
>On Thu, Mar 7, 2013 at 11:59 AM, Donald Lee <MacPPC2%c.icompute.com@localhost>
>>>>> In the old days, I would just use "-g", and presume that the
>>>>> optimization was disabled, but modern compilers don't do that any
>>>> 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
>andy@dockstar2:~/src/netbsd/src/sys/arch/macppc/conf$ grep -i altivec GENERIC
>options ALTIVEC # Include AltiVec support
>What if you disable it?
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.
Main Index |
Thread Index |