[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250322010920.GL1827@brightrain.aerifal.cx>
Date: Fri, 21 Mar 2025 21:09:20 -0400
From: Rich Felker <dalias@...c.org>
To: Leah Neukirchen <leah@...u.org>
Cc: MouriNaruto <mourinaruto@...il.com>, musl@...ts.openwall.com,
MouriNaruto <Kenji.Mouri@...look.com>
Subject: Re: [PATCH] workaround the issue that pthread_getattr_np
won't return in FreeBSD Linuxulator
On Sat, Mar 22, 2025 at 12:08:56AM +0100, Leah Neukirchen wrote:
> Rich Felker <dalias@...c.org> writes:
>
> > On Fri, Mar 21, 2025 at 11:27:53PM +0100, Leah Neukirchen wrote:
> >> Rich Felker <dalias@...c.org> writes:
> >>
> >> > only tell if it's currently paged in, not if it's mapped. There's
> >> > procfs which could be used if mounted, but that's more of a pain to
> >> > work with and not always present, and I'm not sure it would help on
> >> > FreeBSD anyway.
> >>
> >> FreeBSD took precautions to make "linprocfs" work in such a way that
> >> glibc parses it properly:
> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253337
> >
> > I think this is promising that they might also fix mremap so that musl
> > can interpret it properly.
> >
> > As for procfs, does that include /proc/self/maps? That's what we'd
> > have to parse, and I'm not even sure how rigorously safe it is to
> > parse... so I'd rather not go there.
>
> Exactly, here's an example on FreeBSD:
>
> # cat /tmp/compat/self/maps
> 000027a17ce04000-000027a17ce06000 r--p 00000000 00:00 48618 /bin/cat
> 000027a17ce06000-000027a17ce08000 r-xp 00001000 00:00 48618 /bin/cat
> 000027a17ce08000-000027a17ce09000 r--p 00000000 00:00 0
> 000027a17ce09000-000027a17ce0a000 rw-p 00001000 00:00 0
> 000027a99d469000-000027a99d489000 rw-p 00000000 00:00 0
> 000027a99d60c000-000027a99d60d000 r-xs 00000000 00:00 0
> 000027a99daaa000-000027a99db2f000 r--p 00000000 00:00 39034 /lib/libc.so.7
> 000027a99db30000-000027a99dc7a000 r-xp 00085000 00:00 39034 /lib/libc.so.7
> 000027a99dc7a000-000027a99dc84000 r--p 0039c000 00:00 39034 /lib/libc.so.7
> 000027a99dc84000-000027a99dc8b000 rw-p 003ae000 00:00 39034 /lib/libc.so.7
> 000027a99dc8b000-000027a99ddad000 rw-p 00000000 00:00 0
> 000027a99edad000-000027a99edae000 r--s 00000000 00:00 0
> 00003140936df000-00003140936e6000 r--p 00000000 00:00 39556 /libexec/ld-elf.so.1
> 00003140936e6000-00003140936fc000 r-xp 00006000 00:00 39556 /libexec/ld-elf.so.1
> 00003140936fc000-00003140936fd000 r--p 00036000 00:00 39556 /libexec/ld-elf.so.1
> 00003140936fd000-00003140936fe000 r--p 00000000 00:00 0
> 00003140936fe000-0000314093700000 rw-p 00001000 00:00 0
> 00004acf42400000-00004acf42421000 rw-p 00000000 00:00 0
> 00004acf42600000-00004acf43000000 rw-p 00000000 00:00 0
>
> Notably the [stack] is missing from Linux, but you should infer the
> proper mapping anyway. Else it's just parsing two hex numbers at the
> beginning of the line, not terribly difficult.
As long as you can be sure there are no embedded newlines in the last
field. Which I think you can, but I didn't check. And yes you'd just
find the range containing something on main thread's stack.
Rich
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.
