POSIX siginfo

[Brooks Davis]

On Thu, Oct 13, 2005 at 10:31:50AM -0400, John Baldwin wrote:
> On Wednesday 12 October 2005 11:23 pm, David Xu wrote:
> > I am trying to implement POSIX sigqueue, while staring some code
> > in machdep.c and trap.c, I found our si_code for siginfo structure
> > is not in POSIX standard, all are machine dependent magical values
> > pushed by CPU. POSIX lists all these standard codes:
> >
> > http://www.opengroup.org/onlinepubs/009695399/basedefs/signal.h.html
> >
> > /* codes for SIGILL */
> > ILL_ILLOPC
> > ILL_ILLOPN
> > ILL_ILLADR
> > ILL_ILLTRP
> > ILL_PRVOPC
> > ILL_PRVREG
> > ILL_COPROC
> > ILL_BADSTK
> >
> > /* codes for SIGBUS */
> > BUS_ADRALN
> > BUS_ADRERR
> > BUS_OBJERR
> > BUS_RESERVED
> >
> > /* codes for SIGSEGV */
> > SEGV_MAPERR
> > SEGV_ACCERR
> >
> > /* codes for SIGFPE */
> > FPE_INTOVF      1
> > FPE_INTDIV      2
> > FPE_FLTDIV      3
> > FPE_FLTOVF      4
> > FPE_FLTUND      5
> > FPE_FLTRES      6
> > FPE_FLTINV      7
> > FPE_FLTSUB      8
> >
> > /* codes for SIGTRAP */
> > TRAP_BRKPT
> > TRAP_TRACE
> >
> > ...
> >
> > Note that, NetBSD and Linux had already used the POSIX codes, should we
> > use them too?
> 
> Hmm, looks like we do use these values in some cases on i386 at least for 
> SIGFPE and possibly SIGBUS.  I think you should fix all the archs to use 
> these codes.  I would even go ahead and commit that on its own before the 
> POSIX sigqueue stuff.

I agree.

I ran into our lack of many of these just yesterday when working on
porting Open MPI[0].  I've got patches that make us compile there that will
be needed for the foreseeable future, but to be blunt the current status
of si_code support is really lame.  We don't even have a list of
values we do return other then some vague allusions to values SI_ and
FPE_ in sigaction(2).  It would be nice if we could at least define the
values POSIX says we should define and either implement them or document
what we do implement.

-- Brooks

[0] Of course what Open MPI is doing with the values is utterly evil
since it calls all sorts of non-signal safe functions in the signal
handler, but that's another story.

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20051013/131d4a06/attachment.bin