[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID:
<SY8P300MB0860FFA341272F7E65F7C0D1FDDA2@SY8P300MB0860.AUSP300.PROD.OUTLOOK.COM>
Date: Sat, 22 Mar 2025 02:40:30 +0000
From: Mouri Kenji <Kenji.Mouri@...look.com>
To: Rich Felker <dalias@...c.org>, Leah Neukirchen <leah@...u.org>
CC: MouriNaruto <mourinaruto@...il.com>, "musl@...ts.openwall.com"
<musl@...ts.openwall.com>
Subject: RE: [PATCH] workaround the issue that pthread_getattr_np won't
return in FreeBSD Linuxulator
>> FreeBSD took precautions to make "linprocfs" work in such a way that
>> glibc parses it properly
> I think this is promising that they might also fix mremap so that musl
> can interpret it properly.
I had talked this way before with Edward Tomasz Napierala like this:
> Actually, I have some ideas for that if we need to make a patch to musl
> mainline.
>
> ```
> @MoVM-FreeBSD:~ $ uname --help
> BusyBox v1.37.0 (2025-01-17 18:12:01 UTC) multi-call binary.
>
> Usage: uname [-amnrspvio]
>
> Print system information
>
> -a Print all
> -m Machine (hardware) type
> -n Hostname
> -r Kernel release
> -s Kernel name (default)
> -p Processor type
> -v Kernel version
> -i Hardware platform
> -o OS name
> @MoVM-FreeBSD:~ $ uname -v
> FreeBSD 14.2-RELEASE-p1 GENERIC
> @MoVM-FreeBSD:~ $ cat /proc/self/maps
> 0000000001021000-0000000001027000 r--p 00000000 00:00 3366673 /bin/busybox
> 0000000001027000-00000000010c1000 r-xp 00006000 00:00 3366673 /bin/busybox
> 00000000010c1000-00000000010e3000 r--p 000a0000 00:00 3366673 /bin/busybox
> 00000000010e3000-00000000010e7000 r--p 00182000 00:00 3366673 /bin/busybox
> 00000000010e7000-00000000010e8000 rw-p 00000000 00:00 0
> 00000000010e8000-00000000010e9000 ---p 00001000 00:00 0
> 00000000010e9000-00000000010ea000 rw-p 00002000 00:00 0
> 00000008010e3000-00000008010f7000 r--p 00000000 00:00 2166162 /compat/alpine/lib/ld-musl-x86_64.so.1
> 00000008010f7000-000000080114e000 r-xp 00014000 00:00 2166162 /compat/alpine/lib/ld-musl-x86_64.so.1
> 000000080114e000-0000000801184000 r--p 0006b000 00:00 2166162 /compat/alpine/lib/ld-musl-x86_64.so.1
> 0000000801184000-0000000801185000 r--p 00140000 00:00 2166162 /compat/alpine/lib/ld-musl-x86_64.so.1
> 0000000801185000-0000000801189000 rw-p 00000000 00:00 0
> 00007ffffffdd000-00007fffffffd000 rw-p 00000000 00:00 0 [stack]
> 00007fffffffd000-00007fffffffe000 r-xs 00000000 00:00 0
> 00007fffffffe000-0000800000000000 r-xs 00000000 00:00 0 [vdso]
> @MoVM-FreeBSD:~ $
> ```
>
> According my simple experiments with some commands in FreeBSD Linuxulator.
> I think may be we can:
>
> (1) Use uname function to check the environment is FreeBSD Linuxulator or not.
> (check the version string has FreeBSD string or not)
> (2) Get the current stack address.
> (3) Parse the /proc/self/maps to find which item matches the current stack
> address, then calculate the size.
>
> It looks dirty but may be can match the musl author's need.
And I got the following replies:
> I wonder if we could just parse /proc/self/maps in all cases?
> Could you tell me how many iterations (calls to mremap(2))
> pthread_getattr_np() makes per call, under Linux, in some typical case?
In my opinion, I only have these questions:
- Does pthread_getattr_np will be called frequently in typical cases?
- If I start to make a patch which parses /proc/self/maps to resolve this issue,
what should I do that can make musl mainline happy to accept?
Regards,
Kenji Mouri (https://github.com/MouriNaruto)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
