[Qemu-devel] [PATCH RFC] linux-user: peform __SIGRTMIN hack only when __SIGRTMIN is defined

[Qemu-devel] [PATCH RFC] linux-user: peform __SIGRTMIN hack only when __SIGRTMIN is defined

[Felix Janda]

This fixes a compilation error with the musl c library.
---
I don't really understand the purpose of the hack, which was
introduced in

http://git.qemu.org/?p=qemu.git;a=commit;h=624f7979058b84cbf81c76d45f302ce757b213ca

but musl does not have a separate thread library (it is included in
libc.so), so I doubt that the hack is applies to it.
---
 linux-user/signal.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/linux-user/signal.c b/linux-user/signal.c
index c750053..c89f83d 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -73,12 +73,14 @@ static uint8_t host_to_target_signal_table[_NSIG] = {
     [SIGPWR] = TARGET_SIGPWR,
     [SIGSYS] = TARGET_SIGSYS,
     /* next signals stay the same */
+#ifdef __SIGRTMIN
     /* Nasty hack: Reverse SIGRTMIN and SIGRTMAX to avoid overlap with
        host libpthread signals.  This assumes no one actually uses SIGRTMAX :-/
        To fix this properly we need to do manual signal delivery multiplexed
        over a single host signal.  */
     [__SIGRTMIN] = __SIGRTMAX,
     [__SIGRTMAX] = __SIGRTMIN,
+#endif
 };
 static uint8_t target_to_host_signal_table[_NSIG];
 
-- 
2.7.3

Re: [Qemu-devel] [PATCH RFC] linux-user: peform __SIGRTMIN hack only when __SIGRTMIN is defined

[no-reply]

Hi,

Your series seems to have some coding style problems. See output below for
more information:

Type: series
Message-id: 20160930234101.GD5887@nyan
Subject: [Qemu-devel] [PATCH RFC] linux-user: peform __SIGRTMIN hack only when __SIGRTMIN is defined

=== TEST SCRIPT BEGIN ===
#!/bin/bash

BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0

# Useful git options
git config --local diff.renamelimit 0
git config --local diff.renames True

commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
    echo "Checking PATCH $n/$total: $(git show --no-patch --format=%s $c)..."
    if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
        failed=1
        echo
    fi
    n=$((n+1))
done

exit $failed
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag]         patchew/20160930234021.GC5887@nyan -> patchew/20160930234021.GC5887@nyan
 * [new tag]         patchew/20160930234101.GD5887@nyan -> patchew/20160930234101.GD5887@nyan
Switched to a new branch 'test'
5a29f11 linux-user: peform __SIGRTMIN hack only when __SIGRTMIN is defined

=== OUTPUT BEGIN ===
Checking PATCH 1/1: linux-user: peform __SIGRTMIN hack only when __SIGRTMIN is defined...
WARNING: architecture specific defines should be avoided
#18: FILE: linux-user/signal.c:76:
+#ifdef __SIGRTMIN

ERROR: Missing Signed-off-by: line(s)

total: 1 errors, 1 warnings, 14 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

=== OUTPUT END ===

Test command exited with code: 1


---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-devel@freelists.org

Re: [Qemu-devel] [PATCH RFC] linux-user: peform __SIGRTMIN hack only when __SIGRTMIN is defined

[Peter Maydell]

On 30 September 2016 at 16:41, Felix Janda <felix.janda@posteo.de> wrote:
> This fixes a compilation error with the musl c library.
> ---
> I don't really understand the purpose of the hack, which was
> introduced in
>
> http://git.qemu.org/?p=qemu.git;a=commit;h=624f7979058b84cbf81c76d45f302ce757b213ca
>
> but musl does not have a separate thread library (it is included in
> libc.so), so I doubt that the hack is applies to it.

The reason for the hack is that glibc uses SIGRTMAX (ie signal 63)
for its own internal purposes (it uses it for between-thread
communication to implement the posix threading APIs). If we
didn't reverse SIGRTMIN and SIGRTMAX then both the glibc in
the host process and the glibc in the guest process would try
to use the same signal and the guest's threading APIs would
break.

I'm pretty sure musl is going to need to use a signal to
implement threads too, so I expect this hack will be
needed there too, not just on glibc.

It would be better to figure out how to identify the
range of RT signals on musl...


> ---
>  linux-user/signal.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/linux-user/signal.c b/linux-user/signal.c
> index c750053..c89f83d 100644
> --- a/linux-user/signal.c
> +++ b/linux-user/signal.c
> @@ -73,12 +73,14 @@ static uint8_t host_to_target_signal_table[_NSIG] = {
>      [SIGPWR] = TARGET_SIGPWR,
>      [SIGSYS] = TARGET_SIGSYS,
>      /* next signals stay the same */
> +#ifdef __SIGRTMIN
>      /* Nasty hack: Reverse SIGRTMIN and SIGRTMAX to avoid overlap with
>         host libpthread signals.  This assumes no one actually uses SIGRTMAX :-/
>         To fix this properly we need to do manual signal delivery multiplexed
>         over a single host signal.  */
>      [__SIGRTMIN] = __SIGRTMAX,
>      [__SIGRTMAX] = __SIGRTMIN,
> +#endif
>  };
>  static uint8_t target_to_host_signal_table[_NSIG];
>
> --
> 2.7.3
>

thanks
-- PMM

Re: [Qemu-devel] [PATCH RFC] linux-user: peform __SIGRTMIN hack only when __SIGRTMIN is defined

[Felix Janda]

Peter Maydell wrote:
> On 30 September 2016 at 16:41, Felix Janda <felix.janda@posteo.de> wrote:
> > This fixes a compilation error with the musl c library.
> > ---
> > I don't really understand the purpose of the hack, which was
> > introduced in
> >
> > http://git.qemu.org/?p=qemu.git;a=commit;h=624f7979058b84cbf81c76d45f302ce757b213ca
> >
> > but musl does not have a separate thread library (it is included in
> > libc.so), so I doubt that the hack is applies to it.
> 
> The reason for the hack is that glibc uses SIGRTMAX (ie signal 63)
> for its own internal purposes (it uses it for between-thread
> communication to implement the posix threading APIs). If we
> didn't reverse SIGRTMIN and SIGRTMAX then both the glibc in
> the host process and the glibc in the guest process would try
> to use the same signal and the guest's threading APIs would
> break.

Thanks for explaining this.

> I'm pretty sure musl is going to need to use a signal to
> implement threads too, so I expect this hack will be
> needed there too, not just on glibc.

musl uses signal 34 (internally called SIGSYNCCALL) to implement
threads.

> It would be better to figure out how to identify the
> range of RT signals on musl...

musl has SIGRTMIN and SIGRTMAX, but these resolve to functions
__libc_current_sigrtmin() and __libc_current_sigrtmax(). The first
always returns 35, the second _NSIG-1.

But how do these matter? Isn't it only important that signal 34 gets
remapped?

Felix