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=-3.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,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 02EB7266B0 for ; Tue, 7 May 2024 17:09:15 +0200 (CEST) Received: (qmail 5163 invoked by uid 550); 7 May 2024 15:09:09 -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 4092 invoked from network); 7 May 2024 15:09:09 -0000 Date: Tue, 7 May 2024 11:09:22 -0400 From: Rich Felker To: lixing Cc: musl@lists.openwall.com Message-ID: <20240507150921.GO10433@brightrain.aerifal.cx> References: <20240506123624.GE10433@brightrain.aerifal.cx> <20240507013921.GN10433@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Add PAGESIZE definition for LoongArch On Tue, May 07, 2024 at 09:45:32AM +0800, lixing wrote: > > 在 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. OK, the bug was supposedly already fixed by commit f47a8cdd250d9163fcfb39bf4e9d813957c0b187, but that commit didn't actually do anything because of inclusion order issues. A fix for the fix is now available in commit 6f666231bf51703fadbef10460d462fb573548a1. Rich