Re: [musl] Fwd: mesa | Remove USE_ELF_TLS macro (!17213)

2022-06-27 Thread Markus Wichmann
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.

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.

Ciao,
Markus

[1] https://gitlab.freedesktop.org/mesa/mesa/-/issues/966


Re: [musl] Fwd: mesa | Remove USE_ELF_TLS macro (!17213)

2022-06-27 Thread Szabolcs Nagy
* 罗勇刚(Yonggang Luo)  [2022-06-25 13:25:31 +0800]:
> On Sat, Jun 25, 2022 at 12:47 PM Markus Wichmann  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.)


Re: [musl] Fwd: mesa | Remove USE_ELF_TLS macro (!17213)

2022-06-27 Thread Fangrui Song

On 2022-06-25, 罗勇刚(Yonggang Luo) wrote:

On Sat, Jun 25, 2022 at 12:47 PM Markus Wichmann  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.


It is supported.

For shared objects using the initial-exec TLS model, they must be at load time 
(DT_NEEDED),
not via dlopen.
See https://maskray.me/blog/2021-02-14-all-about-thread-local-storage
for background.





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__`
```
#if defined(__GLIBC__)
#define __THREAD_INITIAL_EXEC thread_local
__attribute__((tls_model("initial-exec")))
#define REALLY_INITIAL_EXEC
#else
#define __THREAD_INITIAL_EXEC thread_local
#endif
```


On x86, you may enable (currently GCC only) -mtls-dialect=gnu2 to get
performance boost. It's just a tiny bit slower than initial-exec.

I added x86-32 TLSDESC and mixed TLS GD/TLSDESC support to lld 14 after
I saw the -mtls-dialect=gnu2 build system improvement in mesa :)





Ciao,
Markus

[1] https://gitlab.freedesktop.org/mesa/mesa/-/issues/966




--
此致
礼
罗勇刚
Yours
   sincerely,
Yonggang Luo


XDC 2022: Registration & Call for Presentations still open!

2022-06-27 Thread Lyude Paul
Hello! This is just a reminder that the CFP for XDC in 2022 is still open!

The 2022 X.Org Developers Conference is being held in conjunction with
the 2022 Wine Developers Conference.  This is a meeting to bring
together developers working on all things open graphics (Linux kernel,
Mesa, DRM, Wayland, X11, etc.) as well as developers for the Wine
Project, a key consumer of open graphics.

Registration & Call for Proposals are now open for both XDC 2022 and
WineConf 2022, which will take place on October 4-6, 2022 in
Minneapolis, Minnesota, USA. 

https://xdc2022.x.org
 
As usual, the conference is free of charge and open to the general
public. If you plan on attending, please make sure to register as early
as possible!
 
In order to register as attendee, you will therefore need to do it via
the XDC website:
 
https://indico.freedesktop.org/event/2/registrations/2/
 
In addition to registration, the CfP is now open for talks, workshops
and demos at XDC 2022. While any serious proposal will be gratefully
considered, topics of interest to X.Org and freedesktop.org developers
are encouraged. The program focus is on new development, ongoing
challenges and anything else that will spark discussions among
attendees in the hallway track.
 
We are open to talks across all layers of the graphics stack, from the
kernel to desktop environments / graphical applications and about how
to make things better for the developers who build them. Head to the
CfP page to learn more: 
 
https://indico.freedesktop.org/event/2/abstracts/
 
The deadline for submissions is Monday July 4th, 2022.
 
Check out our Reimbursement Policy to accept speaker
expenses for X.Org events like XDC 2022:
 
https://www.x.org/wiki/XorgFoundation/Policies/Reimbursement/

If you have any questions, please send me an email to
x...@codeweavers.com, adding on CC the X.org board (board
at foundation.x.org).
 
And don't forget, you can follow us on Twitter for all the latest
updates and to stay connected:
 
https://twitter.com/XOrgDevConf

Best regards,
Lyude Paul, on behalf of X.org



-- 
Cheers,
 Lyude Paul (she/her)
 Software Engineer at Red Hat