mailing list of musl libc
 help / color / mirror / code / Atom feed
From: WANG Xuerui <i.musl@xen0n.name>
To: musl@lists.openwall.com
Subject: Re: [musl] A question about SA_RESTORER
Date: Mon, 1 Aug 2022 19:30:39 +0800	[thread overview]
Message-ID: <94a5c853-995d-8290-6d18-d6f2368622fb@xen0n.name> (raw)
In-Reply-To: <CAMqzjesJbXhfVfuR-CwFvaCM1dbZVBZm6K4yAB66VZFZ2AYGSQ@mail.gmail.com>

On 2022/8/1 19:11, Dmitry Selyutin wrote:
> On Mon, Aug 1, 2022 at 12:27 PM 王洪亮 <wanghongliang@loongson.cn> wrote:
>> LoongArch does not support SA_RESTORER,but must be define the macro
>> of SA_RESTORER in LoongArch,otherwise a build error will occur.
>> I want to ask if could consider the unsupported case about the
>> reference of SA_RESTORER in architecture independent code?
> Perhaps you could just `#define SA_RESTORER 0` in the corresponding
> bits/signal.h?
>
Actually, I don't know if any app is going to check whether SA_RESTORER 
is defined and take different codepaths accordingly; if any such app 
exists, it could be broken if SA_RESTORER is defined but in fact not 
needed/supported by the kernel. Otherwise defining it as 0 should be okay.

BTW so far it seems all arches in musl define SA_RESTORER to some 
non-zero value, but at least some are handled differently in kernel and 
glibc (e.g. m68k, or1k and riscv). I don't know if unconditionally 
defining SA_RESTORER could be harmful at all if this is the case and 
nobody reported any related bug yet, but maybe cleaning up the code 
would help in future maintenance by making every project consistent with 
each other.


  reply	other threads:[~2022-08-01 11:30 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-01  9:27 王洪亮
2022-08-01 11:11 ` Dmitry Selyutin
2022-08-01 11:30   ` WANG Xuerui [this message]
2022-08-01 17:06     ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=94a5c853-995d-8290-6d18-d6f2368622fb@xen0n.name \
    --to=i.musl@xen0n.name \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).