Paul came up with a much better method for this.  I have added a syscall
that does a "debug" return from the signal handler.  It's much cleaner.

I ahve a patch for this, and I've done a number of things besides just
this.  I seemed bad to me to add yet another kludge to the beginning of
DoSyscall for handling yet another signal return value.  So I turned all
the signal return syscalls into normal syscalls.  This should speed up
normal syscall handling by removing four instructions from the syscall
entry.  Is this ok?

I added some new syscalls for each sigreturn option, but there were
already some more that would obviously not work for this.  Should I
convert the others over to work correctly, or should I leave these like
they are?

I made the interface to the debug sigreturn extensible, it takes an
array of two-member structures, where the first member is a debug type
and the second is a debug value.  This should allow a lot of flexibility
for adding new things (probably a lot more than is required).

I also brought the syscall table in asm/unistd.h up to date.

I've got some code for setting dabr from userland and causing traps.  I
could work it into this if someone is interested.  It involves some
complicated code at exception entry.

-Corey

Corey Minyard wrote:

> Here's an example patch (that I have tested) that shows the use of the
> top 16 bits of the trap field as communication between the signal
> handler and the kernel.
>
> -Corey
>
> Corey Minyard wrote:
>
>>
>> Actually, using the SE bit may not be the best way to handle this to
>> cover all the PPC variants.
>>
>> Would it be better to have a special bit field someplace that is used to
>> communicate between the signal handler and the kernel?  Some
>> possibilities are:
>>
>>    * The top 16 bits of the trap field
>>    * The currently unused mq field (except on APUS?)
>>    * A new field in the signal frame
>>
>> I'm thinking that reserving the top 16 bits of the trap field may be the
>> best.  It would always come in as zero (so existing software won't be
>> broken) and it will be available for all processors and will not be used
>> for anything else by the processor.
>>
>> Any thoughts?
>>
>> -Corey
>