Re: [musl] Fwd: mesa | Remove USE_ELF_TLS macro (!17213)
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)
* 罗勇刚(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)
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!
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