Could you run 'objdump -d --no-show-raw-insn vmlinux | grep -3 cmov'
on the nonbooting kernel? If the problem is indeed abs() you will
probably see a few od these (a 486 can't handle conditional moves so
if gcc generates them then that is a problem).
> As previously posted, I compiled the kernel with both the machine and
> architecture defines for both 386 and 486 with (of course) the .config
> set for a '386 with no coprocessor (math emulation).
> The code generated would boot if the code was compiled with the same
> compiler (gcc-2.8.1) compiled on a '486. It would not boot if the
> complier was built on my '686.
same gcc2.8 in the latter case too?
I did a few tests and gcc2.95.1 (std config, on a 686) seems to
produce correct results (cmoves only when -march=i686 is specified),
so that may have been a compiler bug that has since been fixed...
If you can reproduce the problem, could you check if simply adding
'-march=i386' (if your gcc supports that) helps?
> > code generated for the builtin vs proper define (ie one which can
> > take args w/ side effects (the one i saw posted didn't)).
>
> The one posted has enough ()'s to take args with side effects. There
> is only one input variable.
there's only one input, but it's not necessarily a variable...
[no, this does not currently happen anywhere in the kernel. Still
any abs() should do the right thing (ie evaluate the arg only once)]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/