On Sep 2,  5:45pm, thorpej@wasabisystems.com (Jason Thorpe) wrote:
-- Subject: Re: SA_SIGINFO patch

| For non-siginfo signals, you should continue to use 
| __sigtramp_sigcontext_1.  For siginfo signals, you should use 
| __sigtramp_siginfo_1 (i.e. rename your __sigtramp_sigcontext_2 to 
| __sigtramp_siginfo_1).

I don't think that it is a good idea to keep the sigcontext/sigreturn
signal handling around. It is only needed for compatibility code now,
and maintaining two signal code paths is just more work.

| I intended the ABI version to be within the domain of the trampoline 
| type.  So, "sigcontext"-type handlers have one ABI domain, and 
| "siginfo"-type handlers have another ABI domain.

I think that checking one number, is a lot easier than checking both a
number and a flag and then maintaining two sets of ABI's. I really want
to get rid of the old sigcontext code, since it is not portable across
architectures and does not provide enough information about the signal
cause to userland.

| Note that this also means that your kernel "osigframe" is really 
| "sigframe_sigcontext" and your new "sigframe" is really 
| "sigframe_siginfo".

These are good names. I will change them.

| If the handler does not have SA_SIGINFO set, then use 
| __sigtramp_sigcontext_1, else use __sigtramp_siginfo_1.
| 
| It is important to name the signinfo trampoline 
| "__sigtramp_siginfo_...", since GDB will use the "siginfo" part of the 
| name to decide how to decode the arguments passed to the handler.  Oh, 
| guess what, you get to update GDB for this, too :-)  (GDB 5.3 and later 
| have support for our userland signal trampolines.)

I will fix gdb, but as I said above, I don't want to maintain two signal
paths.

christos