On 19/11/2015 12:15, Peter Maydell wrote: > On 19 November 2015 at 10:22, Laurent Vivier <lviv...@redhat.com> wrote: >> Hi, >> >> On 19/11/2015 10:28, John Paul Adrian Glaubitz wrote: >>> On 11/19/2015 10:17 AM, Peter Maydell wrote: >>>> Unfortunately this isn't sufficient. You also need to add >>>> the code to the sh4-specific functions in linux-user/signal.c >>>> which honours the requested sigaltstack when taking and returning >>>> from signal handlers. >> >> it seems all needed functions for sh4 signal handling are already >> written in linux-user/signal.c, I thing about setup_frame(), >> setup_rt_frame(), do_sigreturn() and do_rt_sigreturn(). > > Other architectures have calls to do_sigaltstack or other > sigaltstack handling in their frame setup and sigreturn > functions. SH4 doesn't, which implied to me that we were > missing something beyond just enabling the call to do_sigaltstack. > Maybe that's for something else?
Well, I didn't really check the code in these functions, but SH4 has the call in do_rt_sigreturn(). The only check I did is to compare setup_frame() with the one from kernel and it seems ok. But I think the patch from Adrian is just fixing a forgetting in the original SH4 patch: c3b5bc8 SH4: Signal handling for the user space emulator, by Magnus Damm. This patch uses do_sigaltstack() without enabling sigaltstack() syscall. > (Incidentally the only targets other than SH4 not listed in > this ifdef are CRIS, Microblaze, TileGX and Unicore32. > Maybe we should just go ahead and remove the ifdef entirely, > if do_sigaltstack() doesn't really have any target-specific > requirements?) I don't know if these targets have a lot of users. At least for SH4, we can enable it and see if someone is screaming (I like the "crash-test method" :) ). I think Adrian will take care of this (and I can help). Thanks, Laurent
