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 D35DE24E2C for ; Tue, 7 May 2024 03:39:13 +0200 (CEST) Received: (qmail 20395 invoked by uid 550); 7 May 2024 01:39:08 -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 20351 invoked from network); 7 May 2024 01:39:07 -0000 Date: Mon, 6 May 2024 21:39:22 -0400 From: Rich Felker To: lixing Cc: musl@lists.openwall.com Message-ID: <20240507013921.GN10433@brightrain.aerifal.cx> References: <20240506123624.GE10433@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: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. > 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. Rich