From: Rich Felker <dalias@libc.org>
To: lixing <lixing@loongson.cn>
Cc: musl@lists.openwall.com
Subject: Re: [musl] Add PAGESIZE definition for LoongArch
Date: Tue, 7 May 2024 11:09:22 -0400 [thread overview]
Message-ID: <20240507150921.GO10433@brightrain.aerifal.cx> (raw)
In-Reply-To: <a84dc516-375d-21e5-729c-cba3afc7de69@loongson.cn>
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
prev parent reply other threads:[~2024-05-07 15:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-06 9:05 lixing
2024-05-06 12:36 ` Rich Felker
2024-05-07 1:30 ` lixing
2024-05-07 1:39 ` Rich Felker
2024-05-07 1:45 ` lixing
2024-05-07 15:09 ` Rich Felker [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240507150921.GO10433@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=lixing@loongson.cn \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).