[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 1 Aug 2022 19:30:39 +0800
From: WANG Xuerui <i.musl@...0n.name>
To: musl@...ts.openwall.com
Subject: Re: A question about SA_RESTORER
On 2022/8/1 19:11, Dmitry Selyutin wrote:
> On Mon, Aug 1, 2022 at 12:27 PM 王洪亮 <wanghongliang@...ngson.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.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
