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=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A,RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 6788 invoked from network); 1 Aug 2022 11:30:58 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 1 Aug 2022 11:30:58 -0000 Received: (qmail 13546 invoked by uid 550); 1 Aug 2022 11:30:55 -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 13514 invoked from network); 1 Aug 2022 11:30:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xen0n.name; s=mail; t=1659353440; bh=GlKSqmTuU5rOZHpbJw3V+G5Q7h/f/Q1ckK6vmkVlgu0=; h=Date:Subject:To:References:From:In-Reply-To:From; b=V8xI2R18JIw+rEFrHxOzC8xx0tRjQG+DgoeLMiExcwg6zO2F2MBolZeUrBO5s0dCl v6T6iZc+5ztjCupbaIBb/L/Pf1PoqSB98pCe3EOYfT0ZBRK/wPEaRuWoz4QsTy4Q6l qFbqboz26ERhqvNftMm95GHe+aelCEzmVpCogob0= Message-ID: <94a5c853-995d-8290-6d18-d6f2368622fb@xen0n.name> Date: Mon, 1 Aug 2022 19:30:39 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:105.0) Gecko/20100101 Thunderbird/105.0a1 Content-Language: en-US To: musl@lists.openwall.com References: <41f29835-b94f-ccfb-e437-b0bb48785aab@loongson.cn> From: WANG Xuerui In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [musl] A question about SA_RESTORER On 2022/8/1 19:11, Dmitry Selyutin wrote: > On Mon, Aug 1, 2022 at 12:27 PM 王洪亮 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.