Change to allow signal handlers to set SE and BE bits.
minyard at acm.org
Wed Sep 10 05:19:46 EST 2003
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
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 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 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?
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
More information about the Linuxppc-dev