bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH] test-c-stack2.sh: skip if the platform sent SIGILL on an


From: Bruno Haible
Subject: Re: [RFC PATCH] test-c-stack2.sh: skip if the platform sent SIGILL on an invalid address.
Date: Sun, 30 Dec 2018 05:49:24 +0100
User-agent: KMail/5.1.3 (Linux/4.4.0-141-generic; KDE/5.18.0; x86_64; ; )

Hi Ivan,

Thank you for sharing your insights!

> > It would mean that Linux/e2k can hardly conform to
> > POSIX well, as Bruno said, because POSIX requires different signals for
> > different cases and incompatibilities can't be forgiven on the reason of
> > speculative computations in the CPU.

> The compiler would know how to
> replay the faulty speculative computation, so it would be able
> generate code to do this non-speculatively and trigger the real fault.

Yes, you need to think at the kernel and the compiler together.

As I understand it, the general approach in such cases is to:

  1) See in the hardware manual whether there is a way to retrieve the
     exception details (exception code, and memory address in case of a
     memory access) from the speculative execution. If so, use it in the
     kernel, in linux/<arch>/mm/fault.c.
  If not:

  2) Implement a proposed solution in the compiler that results in
     discarding the speculative execution results when there was an
     exception during speculative execution.
  3) Implement another proposed solution in the compiler that completely
     disables speculative execution for instructions that may produce
     exceptions (and leave it enabled only for guaranteed exception-free
     instructions, such as integer arithmetic instructions).
     [It is not unheard of that processor features get completely disabled.
     For example, OpenBSD/x86_64 disables hyperthreading, which many
     people previously thought to be a valuable processor feature.]

  4) Benchmark the performance impact of 2) and 3) on programs. Choose
     the one with less impact.

  5) If the impact is high, then invent a compiler option that allows
     the application developer to choose among POSIX compliant code or
     fast code. [This is the approach used e.g. for floating-point instructions
     on alpha in GCC: The instructions provided by the hardware are not
     IEEE 854 compliant, and the workaround that GCC adds to make it
     it IEEE 854 compliant is so much of a performance hit that it is
     only enabled through a compiler option.]

Bruno




reply via email to

[Prev in Thread] Current Thread [Next in Thread]