[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Smoking gun: NetBSD 6.0.1 userland instability
>> My bet - FWIW - is that the problem is in the altivec handling. This
>> is something unique to PPC processors, differs between PPC models,
>> and would only affect code that uses altivec. "normal" code - like
>> compilers, gzip, I/O, and lots of other things, could go a long way
>> with altivec broken, and no one would notice.
>Is it possible/feasible to build analog without altivec? That would
>seem to me to be the obvious next thing to try: a non-altivec analog
>under a problematic kernel.
I thought of that. The source to analog is available, and as I recall,
it is not hard to build. - http://www.analog.cx/analog-6.0.tar.gz
I am not familiar enough with the compiler
to be confident I am actually flipping the right gcc switches
to **know** that altivec is, or is not being used. To run that
experiment, I would want to be able to build it and reproduce
the problem with my version as well. What if I can only
make it break with the pre-compiled version?
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. They
reportedly try to optimize more often, even when not necessarily
Main Index |
Thread Index |