From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-4.5 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id CD55E25850 for ; Tue, 7 May 2024 03:30:34 +0200 (CEST) Received: (qmail 25901 invoked by uid 550); 7 May 2024 01:30:28 -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 25841 invoked from network); 7 May 2024 01:30:27 -0000 To: Rich Felker Cc: musl@lists.openwall.com References: <20240506123624.GE10433@brightrain.aerifal.cx> From: lixing Message-ID: Date: Tue, 7 May 2024 09:30:13 +0800 User-Agent: Mozilla/5.0 (X11; Linux loongarch64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20240506123624.GE10433@brightrain.aerifal.cx> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-CM-TRANSID:AQAAf8DxLlUlhDlmJHETAA--.21913S3 X-CM-SenderInfo: pol0x03j6o00pqjv00gofq/ X-Coremail-Antispam: 1Uk129KBj93XoW7CF48AFW3tFWrJF45Aw1DurX_yoW8Gr1xpF ZxZrs3Crs5ta1xKF1Dt347WF43CF43Ga15uFy5Wr4UZr48Zr9Igr1fKrWqgFy7Zw48KFy0 vrs0qFy5CayDAabCm3ZEXasCq-sJn29KB7ZKAUJUUUU8529EdanIXcx71UUUUU7KY7ZEXa sCq-sGcSsGvfJ3Ic02F40EFcxC0VAKzVAqx4xG6I80ebIjqfuFe4nvWSU5nxnvy29KBjDU 0xBIdaVrnRJUUUv0b4IE77IF4wAFF20E14v26r1j6r4UM7CY07I20VC2zVCF04k26cxKx2 IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48v e4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI 0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVW8JVWxJwA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_ Gr0_Gr1UM2AIxVAIcxkEcVAq07x20xvEncxIr21l57IF6xkI12xvs2x26I8E6xACxx1l5I 8CrVACY4xI64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r106r15McIj6I8E87Iv67AK xVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41lc7I2V7IY0VAS07AlzV AYIcxG8wCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E 14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_JF1lIx kGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAF wI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6r1j6r1xMIIF0xvEx4A2jsIE14v26r1j6r 4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2KfnxnUUI43ZEXa7IU1wL05UU UUU== Subject: Re: [musl] Add PAGESIZE definition for LoongArch 在 2024/5/6 下午8:36, Rich Felker 写道: > On Mon, May 06, 2024 at 05:05:36PM +0800, lixing wrote: >> Hi, Rich, >> >>  arch/loongarch64/bits/limits.h | 1 + >>  1 file changed, 1 insertion(+) >>  create mode 100644 arch/loongarch64/bits/limits.h >> >> diff --git a/arch/loongarch64/bits/limits.h b/arch/loongarch64/bits/limits.h >> new file mode 100644 >> index 00000000..5cd9aad6 >> --- /dev/null >> +++ b/arch/loongarch64/bits/limits.h >> @@ -0,0 +1 @@ >> +#define PAGESIZE 16384 > Can you explain why you want this change? I would be very hesitant to > merge it. Defining PAGESIZE for an arch is a contract that the > application-facing runtime page size (i.e. mmap granularity) can > *never*, now or in the future, be anything other than the value you > define this macro as having. when I debuging "indent" program error, the  caculation of relro_start and relro_end in function kernel_mapped_dso get wrong value. It seems the PAGE_SIZE value is 0 and it come from libc.page_size, but the libc.page_size initialized until __dls3. Is there any other way to make the PAGE_SIZE correct at the before __dls3 ? Also, if the xmalloc low and high address aparted by the  protect page in a  loop,  it seems to trigger SIGSEGV when the loop meet the protect page. Can this situation happen? > Rich