Re: [Qemu-devel] [PATCH 2/2] linux-user: Remove the unused "not implemented" signal handling stubs

[Laurent Vivier]

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 
> ---
> 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

Re: [Qemu-devel] [PATCH 2/2] linux-user: Remove the unused "not implemented" signal handling stubs

[Laurent Vivier]

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 
> ---
> 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 

[Qemu-devel] [PATCH 2/2] linux-user: Remove the unused "not implemented" signal handling stubs

[Peter Maydell]

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 
---
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(-)

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,
-- 
2.16.2