[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20220625094810.GT1320090@port70.net>
Date: Sat, 25 Jun 2022 11:48:10 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: 罗勇刚(Yonggang Luo) <luoyonggang@...il.com>
Cc: Musl <musl@...ts.openwall.com>, mesa-dev@...ts.freedesktop.org
Subject: Re: Fwd: mesa | Remove USE_ELF_TLS macro (!17213)
* 罗勇刚(Yonggang Luo) <luoyonggang@...il.com> [2022-06-25 13:25:31 +0800]:
> On Sat, Jun 25, 2022 at 12:47 PM Markus Wichmann <nullplan@....net> wrote:
> >
> > On Sat, Jun 25, 2022 at 11:36:09AM +0800, 罗勇刚(Yonggang Luo) wrote:
> > > So I am confused. What's the situation about ELF-TLS support in musl?
> > > Is that still broken now?
> >
> > musl has always supported ELF-TLS anywhere except in libc itself. That
> > was also never the problem. The problem was that the mesa people select
> > the initial-exec TLS model explicitly, even though libGL ends up being
> > dlopen()ed quite often, and then you should be using the general-dynamic
> > model instead.
>
> My question is does musl support ELS-TLS when using dl-open.
>
musl supports ELF TLS with or without dlopen.
if something crashes that's most likely a bug in mesa.
>
> >
> > According to [1], Rich proposed dropping the initial-exec attribute and
> > replacing it with -mtls-dialect=gnu2 eight years ago. Has that happened
> > yet? If so, dlopen()ing libGL with musl ought to work.
>
> `initial-exec` are only specified for __GLIBC__, If musl not predefined
> macro ` __GLIBC__`
note: initial-exec tls is wrong for both glibc and musl.
(glibc reserves initial tls for ld_audit and dlmopen namespaces, it's
not there for mesa. i.e. this only happens to work because it's
unlikely that a process uses all the glibc features for which static
tls is reserved, but if that happens then mesa will fail to load.)
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.
