Re: CVS commit: src/tests/lib/libc/gen

[Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>]

On Sun, 22 Apr 2012 08:52:26 +0000, Martin Husemann wrote:
> Module Name:    src
> Committed By:   martin
> Date:           Sun Apr 22 08:52:26 UTC 2012
>
> Modified Files:
>         src/tests/lib/libc/gen: t_siginfo.c
>
> Log Message:
> Do not compare si_addr (address of faulting instruction) against the
> unaligned data address causing the fault - this will always fail.
> If anybody knows a portable way to get the data address involved in 
> the
> fault, please fix the test case as originally intended.

Hmm, siginfo(2) states the following:

     For SIGBUS and SIGSEGV the siginfo structure contains the 
following addi-
     tional members:

           void *si_addr;
           int si_trap;

     si_addr contains the address of the faulting data and si_trap 
contains a
     hardware specific reason.


If the address of the instruction is returned and not the address of 
the faulting data, either the man page is incorrect, or ambiguous.

Concerning x86 (Christoph can perhaps confirm here), I am not aware of 
any CPU that report the faulty address; rather, %cr2 contains the 
address of the fault that happened just before, typically a page fault. 
IMHO this is one of the reason why the mechanism never got much traction 
under x86: it's unreliable.

Reliably obtaining the address would require to fetch eip/rip and 
decode the faulty opcode. Not impossible, but do we want that?

Regarding other architectures, I do not know. I would expect the 
si_addr to contain the address of the unaligned data access, not the one 
from the faulting instruction. SIGBUS is used, not SIGILL.

--
Jean-Yves Migeon
jeanyves.migeon%free.fr@localhost