>> The compiler doesn't know, where the binary runs later. Or do you mean,
>> that it has to insert some code that checks for the existance of these
>> instructions during program start? Ok that would be a solution, but how
>> do you do this for libraries that are not run in itself?
> It means the compiler for -m686 shouldn't have assumed cmov was
> available
It's not the compiler that is responsible for it. At least in my case.
The problem is that if you compile the glibc than some assembler code
gets included into glibc. So the problem here is glibc and not gcc.
Ok, the way to go for me now will be to make a new glibc without this
instructions. But I still think it would be a step to more fault
tolerance (or tolerance to goofy admins ;-) if we could have an
emulation of this. If I find some time I will do this...
>> but the costs of automatically catching such errors are little in
>> respect of the benefit you get. A running system is always better than
>> a unusable one even if it was the admins fault.
> Then while you are it you can make the kernel magically recover from rm -rf /
> or rm * in /lib...
Let the FS driver copy all modified sectors into a hidden log on the
disk (fixed or dynamic in size or as a ringbuffer). Then e.g during
kernel startup in case you removed most of the system you might be asked
to recover from some point. Such concepts are used by software like
HDD-Sheriff but one level below (disc sector level). On filesystem level
it makes more sense since you may recover partially. All that will bloat
the kernel but it would be possible. This case is one that has (very)
high costs. Not that I want this but I want to show that there _are_
ways to do it.
ron
-- /\/\ Dipl.-Inf. Ronald Wahl /\/\ C S N /\/\ \/\/ ronald.wahl@informatik.tu-chemnitz.de \/\/ ------------------ \/\/ /\/\ http://www.tu-chemnitz.de/~row/ /\/\ network and system /\/\ \/\/ GnuPG/PGP key available \/\/ administration \/\/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/