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 9253E232ED for ; Tue, 7 May 2024 03:45:55 +0200 (CEST) Received: (qmail 3588 invoked by uid 550); 7 May 2024 01:45:48 -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 3545 invoked from network); 7 May 2024 01:45:48 -0000 To: musl@lists.openwall.com References: <20240506123624.GE10433@brightrain.aerifal.cx> <20240507013921.GN10433@brightrain.aerifal.cx> From: lixing Message-ID: Date: Tue, 7 May 2024 09:45:32 +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: <20240507013921.GN10433@brightrain.aerifal.cx> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-CM-TRANSID:AQAAf8AxgFW8hzlmNXQTAA--.21974S3 X-CM-SenderInfo: pol0x03j6o00pqjv00gofq/ X-Coremail-Antispam: 1Uk129KBj93XoW7WF43AFyDWr13tr4xArWUGFX_yoW8AFy8pr ZIvFZ3Cr4rtw4fK34jvw12gF4ayrsxJw45ury5Wr48Zr4DXasIgr1fKFWDWFyUZw4xtFy0 vr4jqrW3CayUAagCm3ZEXasCq-sJn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7KY7ZEXa sCq-sGcSsGvfJ3Ic02F40EFcxC0VAKzVAqx4xG6I80ebIjqfuFe4nvWSU5nxnvy29KBjDU 0xBIdaVrnRJUUU9Fb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I20VC2zVCF04k26cxKx2 IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48v e4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI 0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVW8JVWxJwA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_ Gr0_Gr1UM2AIxVAIcxkEcVAq07x20xvEncxIr21l57IF6xkI12xvs2x26I8E6xACxx1l5I 8CrVACY4xI64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AK xVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41lc7I2V7IY0VAS07AlzV AYIcxG8wCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwCFI7km07C267AK xVW8ZVWrXwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67 AF67kF1VAFwI0_Jr0_JrylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI 42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6r1j6r1xMI IF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2 KfnxnUUI43ZEXa7IU1CPfJUUUUU== Subject: Re: [musl] Add PAGESIZE definition for LoongArch 在 2024/5/7 上午9:39, Rich Felker 写道: > On Tue, May 07, 2024 at 09:30:13AM +0800, lixing wrote: >> 在 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 ? > I believe this is a known bug that somehow got skipped over in the > last release cycle. I'll get it fixed. It does not mean you need to > define a constant PAGESIZE. ok,thanks. >> 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? > I don't understand. ok, I will do more test to check this happens or not. Thanks. > > Rich