Re: [musl] Add PAGESIZE definition for LoongArch

[lixing <lixing@loongson.cn>]

在 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