On Mon, Aug 24, 2015 at 09:01:09AM +0100, Markos Chandras wrote:
> On 08/21/2015 06:03 PM, David Daney wrote:
> > On 08/20/2015 04:45 AM, Markos Chandras wrote:
> >> Traditional signal handlers (ie !SA_SIGINFO) only need only argument
> >> holding the signal number so we drop the additional arguments and fix
> >> the related comments. We also update the comments for the SA_SIGINFO
> >> case where the second argument is a pointer to a siginfo_t structure.
> >>
> >> Signed-off-by: Markos Chandras <markos.chandras@xxxxxxxxxx>
> >> ---
> >> arch/mips/kernel/signal.c | 6 +-----
> >> arch/mips/kernel/signal32.c | 6 +-----
> >> arch/mips/kernel/signal_n32.c | 2 +-
> >> 3 files changed, 3 insertions(+), 11 deletions(-)
> >>
> >> diff --git a/arch/mips/kernel/signal.c b/arch/mips/kernel/signal.c
> >> index be3ac5f7cbbb..3a125331bf8b 100644
> >> --- a/arch/mips/kernel/signal.c
> >> +++ b/arch/mips/kernel/signal.c
> >> @@ -683,15 +683,11 @@ static int setup_frame(void *sig_return, struct
> >> ksignal *ksig,
> >> * Arguments to signal handler:
> >> *
> >> * a0 = signal number
> >> - * a1 = 0 (should be cause)
> >> - * a2 = pointer to struct sigcontext
> >> *
> >> * $25 and c0_epc point to the signal handler, $29 points to the
> >> * struct sigframe.
> >> */
> >> regs->regs[ 4] = ksig->sig;
> >> - regs->regs[ 5] = 0;
> >> - regs->regs[ 6] = (unsigned long) &frame->sf_sc;
> >
> > This changes the kernel ABI.
> >
> > Have you tested this change against all userspace applications that use
> > signals to make sure it doesn't break anything?
> >
> > David Daney
>
> i am confident there is no userland application that uses inline asm to
> fetch additional arguments from (*sa_handler) when using !SA_SIGINFO
>
> --
> markos
I'm not sure where you get the idea that you'd need inline asm to use
the a1/a2 values - you'd just need to declare the extra parameters to
your signal handling function.
This does seem like a scary change! I'm pretty confident you haven't
actually checked every bit of userland code. Would we perhaps be better
off leaving the registers set (which is a trivial cost) and document the
behaviour instead?
Thanks,
Paul
