thorpej@shagadelic.org said:
> But I thought the issue here is that, with certain types of GPFs,
> there isn't enough info to send a proper SIGSEGV or SIGBUS

We probably need to keep the keep the SIGSEGV for GPF. The processor
does a GPF on accesses outside the segment limit (which is at 0xbfc00000),
and it would foil the abstraction of signal types if one would
get SEGV on some and ILL on other unmapped memory accesses.
I'm not happy with this, but I think that consistency is of higher
value than SUSv3 compliance here.
This means that we send a SEGV also on all these alignment/descriptor/
permission problems which cause a GPF. This violates the semantics
of SEGV, but it doesn't seem to be a problem in practice.

christos@zoulas.com said:
> I don't see the benefit of changing the signal from SIGBUS to SIGILL
> just because we don't have the faulting address available. I really

The use of SIGBUS on i386 as done now just doesn't make sense IMHO.
The descriptor loading etc problems caught here are rather CPU internal,
and I doubt they can be caused by user actions which do not clearly
qualify as "illegal instuction". And the si_codes used are unrelated
to the causes of the trap. (except perhaps BUS_ADRALN, but afaict
the T_ALIGNFLT can't be enabled by any legal user action)

best regards
Matthias