mailing list of musl libc
 help / color / mirror / code / Atom feed
* [musl] A question about SA_RESTORER
@ 2022-08-01  9:27 王洪亮
  2022-08-01 11:11 ` Dmitry Selyutin
  0 siblings, 1 reply; 4+ messages in thread
From: 王洪亮 @ 2022-08-01  9:27 UTC (permalink / raw)
  To: musl

Hi,

I have a question about SA_RESTORER:

In src/signal/sigaction.c,there is a reference of SA_RESTORER:
ksa.flags = sa->sa_flags | SA_RESTORER;

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?

thanks.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [musl] A question about SA_RESTORER
  2022-08-01  9:27 [musl] A question about SA_RESTORER 王洪亮
@ 2022-08-01 11:11 ` Dmitry Selyutin
  2022-08-01 11:30   ` WANG Xuerui
  0 siblings, 1 reply; 4+ messages in thread
From: Dmitry Selyutin @ 2022-08-01 11:11 UTC (permalink / raw)
  To: musl

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?

-- 
Best regards,
Dmitry Selyutin

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [musl] A question about SA_RESTORER
  2022-08-01 11:11 ` Dmitry Selyutin
@ 2022-08-01 11:30   ` WANG Xuerui
  2022-08-01 17:06     ` Rich Felker
  0 siblings, 1 reply; 4+ messages in thread
From: WANG Xuerui @ 2022-08-01 11:30 UTC (permalink / raw)
  To: musl

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.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [musl] A question about SA_RESTORER
  2022-08-01 11:30   ` WANG Xuerui
@ 2022-08-01 17:06     ` Rich Felker
  0 siblings, 0 replies; 4+ messages in thread
From: Rich Felker @ 2022-08-01 17:06 UTC (permalink / raw)
  To: WANG Xuerui; +Cc: musl

On Mon, Aug 01, 2022 at 07:30:39PM +0800, WANG Xuerui wrote:
> 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.

Applications really should not be using SA_RESTORER at all. It does
not do anything at the application level; libc ignores any restorer
provided by the application. But if you really don't want to expose
SA_RESTORER, I think the definition as 0 could be in the arch's
ksigaction.h rather than the public signal.h bits. Does that work?

Rich

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2022-08-01 17:06 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-01  9:27 [musl] A question about SA_RESTORER 王洪亮
2022-08-01 11:11 ` Dmitry Selyutin
2022-08-01 11:30   ` WANG Xuerui
2022-08-01 17:06     ` Rich Felker

Code repositories for project(s) associated with this 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).