| Message ID | 20180308144733.25615-3-peter.maydell@linaro.org |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Drop dead linux-user/unicore32 code | expand |
Le 08/03/2018 à 15:47, Peter Maydell a écrit : > Now we've dropped unicore32, all of the architectures we support > for linux-user implement the signal handling routines. The > dummy "just print a message" versions are unimplemented, so we > can drop them entirely. > > Signed-off-by: Peter Maydell <peter.maydell@linaro.org> > --- > IMHO signal handling support is too important to allow a > hypothetical new architecture target to silently get away > without implementing it. For initial development it's easy > enough to stub out the per-architecture functions, and then > we will have a clear view of which targets (if any) don't > have the signal handling implemented yet, and the missing > feature will show up in code review. > --- > linux-user/signal.c | 27 +-------------------------- > 1 file changed, 1 insertion(+), 26 deletions(-) > Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Le 08/03/2018 à 15:47, Peter Maydell a écrit : > Now we've dropped unicore32, all of the architectures we support > for linux-user implement the signal handling routines. The > dummy "just print a message" versions are unimplemented, so we > can drop them entirely. > > Signed-off-by: Peter Maydell <peter.maydell@linaro.org> > --- > IMHO signal handling support is too important to allow a > hypothetical new architecture target to silently get away > without implementing it. For initial development it's easy > enough to stub out the per-architecture functions, and then > we will have a clear view of which targets (if any) don't > have the signal handling implemented yet, and the missing > feature will show up in code review. > --- > linux-user/signal.c | 27 +-------------------------- > 1 file changed, 1 insertion(+), 26 deletions(-) Applied to my 'linux-user-for-2.12' branch. Thanks, Laurent
diff --git a/linux-user/signal.c b/linux-user/signal.c index bd85dcde17..1f7b5e398e 100644 --- a/linux-user/signal.c +++ b/linux-user/signal.c @@ -6572,32 +6572,7 @@ long do_rt_sigreturn(CPUArchState *env) } #else - -static void setup_frame(int sig, struct target_sigaction *ka, - target_sigset_t *set, CPUArchState *env) -{ - fprintf(stderr, "setup_frame: not implemented\n"); -} - -static void setup_rt_frame(int sig, struct target_sigaction *ka, - target_siginfo_t *info, - target_sigset_t *set, CPUArchState *env) -{ - fprintf(stderr, "setup_rt_frame: not implemented\n"); -} - -long do_sigreturn(CPUArchState *env) -{ - fprintf(stderr, "do_sigreturn: not implemented\n"); - return -TARGET_ENOSYS; -} - -long do_rt_sigreturn(CPUArchState *env) -{ - fprintf(stderr, "do_rt_sigreturn: not implemented\n"); - return -TARGET_ENOSYS; -} - +#error Target needs to add support for signal handling #endif static void handle_pending_signal(CPUArchState *cpu_env, int sig,
Now we've dropped unicore32, all of the architectures we support for linux-user implement the signal handling routines. The dummy "just print a message" versions are unimplemented, so we can drop them entirely. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> --- IMHO signal handling support is too important to allow a hypothetical new architecture target to silently get away without implementing it. For initial development it's easy enough to stub out the per-architecture functions, and then we will have a clear view of which targets (if any) don't have the signal handling implemented yet, and the missing feature will show up in code review. --- linux-user/signal.c | 27 +-------------------------- 1 file changed, 1 insertion(+), 26 deletions(-) -- 2.16.2