From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 11237 invoked from network); 28 Oct 2020 23:50:48 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 28 Oct 2020 23:50:48 -0000 Received: (qmail 11877 invoked by uid 550); 28 Oct 2020 23:50:44 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 11847 invoked from network); 28 Oct 2020 23:50:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mforney-org.20150623.gappssmtp.com; s=20150623; h=date:to:subject:from:message-id:user-agent; bh=UmRoKPVHgwvk6i96o8X1o2nLooNOXosbKYGIgQERMWk=; b=JpghZ0vl9ByC0c857AWmmCgFZCmdZ21fyuBuTO/EvmdY4xJewAtNKosJ3rG6zEu70Y G6Rabzmie4cT1eI8mTtpssr9KFQdy/uPo5/ub86LnREtkqtbVQn5gIei3k7g12gCY4j3 r13iazZOcE6tixTWOF19EHrmTLHkUi3PYx7SB+s6Oh7QusdKor3vKsQpD8ga7HxiXIs6 lBJEA0Q5Gu3ExUtmExHuoE5oqQ+AeNbyDWTMJm4VN+YHxqW/905alGLQUlQg60qqAIrb ZBzoE1JuEqsiO6v5PCCeqX4Ex27OBe0gB3IOns0HljrKQcKXMBfaDdfSEYgWAPOSkHwA NPsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:to:subject:from:message-id:user-agent; bh=UmRoKPVHgwvk6i96o8X1o2nLooNOXosbKYGIgQERMWk=; b=l8zMzjpejsg3nBdStOOgrEWBGEh3tRrrcEd7BABxOxpfu7+G78v0jb9j3/LR4WaphY l//U2QH9FOE/eITJzloiKAUfKh2K9+IRyDyAYfhuVE6wFNhW0oesw5BxSzClmmA9o9lf ilRNKMoAr6lEVHOrfigsk4i7R7J+KGLt/zcbcqI2TKo9xR0y7emKHFkzAwlLBDmFHCpN upxS+rk2OOaJoFEQFqTSAp42IEzxVoO8Y+/o61Nlv3yEfwXZntc1wYLM7vrjNcRAabME 1CkOq9Fy9Lalh675rrfVxAYePhJmoxUhO8E5y/NYeKvHohjZSB4y1alUQ1ElV+o8i5ro DokA== X-Gm-Message-State: AOAM5323aQpGb2VKjeeq4FnX4Vgd9Uk1V223/S2PMOwqAAf4RRLBWDog yhpY9rQKfZ5SLnCb95OM+KyPEeD/ZQGM7xvd588= X-Google-Smtp-Source: ABdhPJwiMwcpdWDdHBN35wnWrq0XUr5YjNWPIxX9GRiYyidswIsdy7VAuyrGGFq/Mnt/dyVq3adMXg== X-Received: by 2002:a63:ae4b:: with SMTP id e11mr1664184pgp.80.1603929031445; Wed, 28 Oct 2020 16:50:31 -0700 (PDT) Date: Wed, 28 Oct 2020 16:50:29 -0700 To: musl@lists.openwall.com From: Michael Forney Message-Id: <3634W4XGB9R4L.2UYZLDJ6W0AET@mforney.org> User-Agent: mblaze/1.0 Subject: [musl] qemu-user and musl Hi, I'm trying to get various musl compatibility issues in qemu fixed upstream. Here are the issues I've encountered: 1. To implement the timer_create syscall, qemu just translates between host and target sigevent, then calls the libc timer_create. For SIGEV_THREAD, both glibc and musl implement this using the Linux-specific SIGEV_THREAD_ID. However, musl's timer_create does not support SIGEV_THREAD_ID from the application, so it fails with EINVAL. This means that any application using timers with SIGEV_THREAD does not work with qemu-user running on musl. This issue appears as a build time error due to the use of glibc-internal _sigev_un._tid member during sigevent translation. Most distributions patch this by introducing a `host_sigevent` matching the glibc layout and translating to that instead of libc's sigevent. For the reasons mentioned above, this does not actually fix the problem. I see there is a patch on the mailing list adding support for SIGEV_THREAD_ID which looks ready to merge. Rich, since you're working towards getting ready for the next musl release, do you think this might make it in? That way, we could just patch qemu to add #ifndef sigev_notify_thread_id #define sigev_notify_thread_id _sigev_un._tid #endif and replace _sigev_un._tid with sigev_notify_thread_id. 2. qemu uses long obsolete F_SHLCK and F_EXLCK in the translation of struct flock between host and target, which musl does not define. Most musl distributions patch qemu to define these constants itself if they are missing, but seeing as these lock types are unsupported by Linux since 2.2, I sent a patch to just drop them (you'll get EINVAL either way). 3. qemu uses the following configure test to check for clock_adjtime: #include int main(void) { return clock_adjtime(0, 0); } However, musl declares clock_adjtime in sys/timex.h, as indicated by the linux man page, while glibc only declares it in time.h (i.e. it is not just a case of glibc implicitly including other headers). So, including one or the other is not enough. A real application will need both anyway for the clockid_t values and struct timex, but this mismatch seems a bit strange and I'm not sure if it was deliberate. (of course, this is easy to fix by just adding an include of to the test, but I thought I'd mention it in case there was anything actionable here) 4. Until recently qemu used the __SIGRTMIN and __SIGRTMAX macros in its signal translation code. It looks like this was recently refactored, and all that remains is a static assert: QEMU_BUILD_BUG_ON(__SIGRTMAX + 1 != _NSIG); I think the intention is to ensure that any possible value of SIGRTMAX is smaller than _NSIG and will not index past past the end of the host-to-target translation table. However, I think this is a safe assumption and the assert can be dropped (or at least, wrapped in #ifdef __SIGRTMAX). Any suggestions for any of these proposed fixes are welcome. -Michael