Re: Trying to boot Vaxstation using mopd

["Maciej W. Rozycki" <macro%linux-mips.org@localhost>]

On Thu, 30 Jun 2016, Greg Stark wrote:

> > So I decided to dig a little deeper. I checked out the BSD source and
> > built awk from there with -g (btw, it doesn't seem to build cleanly, I
> > have to turn off -Werror due to passing uchar* to libc string
> > functions expecting char *. Strangely I get warnings even if I build
> > with -fsigned-char or -funsigned-char). I still get the core dump and
> > the backtrace is still unintelligible.
> 
> Just for completeness. I rebuit awk with -O0 and it no longer crashes.
> As I was able to reproduce the crash before I think it's clear this is
> just the gcc issues again, not any awk or OS bug.

 I wouldn't be so quick with putting the blame on the compiler.  

 Disabling optimisation merely makes it more conservative, which sometimes 
just happens to make undefined code work as the author seems to have 
intended, however it does not make such code correct and given that the 
compiler is free to apply any transformations to code produced that the 
ISO C language standard (which may sometimes be surprisingly liberal) 
permits, and it happily does it, chances are it's code being compiled 
having the wrong assumptions.  This is particularly true for math code.

 In particular even though ISO C defines IEEE 754 bindings for real 
arithmetic, there's no guarantee that a given implementation will use 
them, and SIGFPE is otherwise a legitimate result for log(0.0).  Here's 
what the ISO C standard has to say about this situation:

"The log functions compute the base-e (natural) logarithm of x.  A domain 
error occurs if the argument is negative.  A pole error may occur if the 
argument is zero."

and:

"On a pole error, the function returns an implementation-defined value; if 
the integer expression math_errhandling & MATH_ERRNO is nonzero, the 
integer expression errno acquires the value ERANGE; if the integer 
expression math_errhandling & MATH_ERREXCEPT is nonzero, the 
`divide-by-zero' floating-point exception is raised."

so for a VAX target which has no NaN support I'd expect the result of 
(math_errhandling & MATH_ERREXCEPT) to be hardcoded to a non-zero value, 
and the compiler respecting it.  Of course it might as well indeed be a 
bug in GCC after all.

 It would help narrowing the cause down too if you could determine which 
specific `-f...' option enabled with `-O...' triggers the problem, and 
what the exact offending C language statement (after preprocessing) is.

  Maciej