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
