Re: pkg/57445: firefox crashes on startup

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

The following reply was made to PR pkg/57445; it has been noted by GNATS.

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: 
Cc: Martin Husemann <martin%NetBSD.org@localhost>, gnats-bugs%NetBSD.org@localhost,
	joerg%NetBSD.org@localhost, tnn%NetBSD.org@localhost
Subject: Re: pkg/57445: firefox crashes on startup
Date: Thu, 1 Jun 2023 14:31:30 +0000

 > Date: Thu, 1 Jun 2023 12:46:25 +0000
 > From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
 >=20
 > Here's a reproducer.  I think I got everything relevant here, but the
 > excerpts I asked martin for don't tell me the exact order or arguments
 > of dlopens that firefox issues, so I guessed.
 >=20
 > So, I think the massive kludge of `just define the symbol in multiple
 > libraries without extern' probably never actually worked, but maybe
 > did paper over the symptoms in the past.
 >=20
 > $ head -40 glapi.c GL.c swrast_dri.c firefox.c
 > =3D=3D> glapi.c <=3D=3D
 > __thread int _glapi_tls_Context __attribute__((tls_model("initial-exec"))=
 ) =3D 0;
 > [...]
 > =3D=3D> GL.c <=3D=3D
 > __thread int _glapi_tls_Context __attribute__((tls_model("initial-exec"))=
 ) =3D 0;
 > [...]
 > $ ./firefox
 > GL 0x794c549be044
 > GL glapi 0x794c549be044
 > dri 0x794c549bf850
 > dri glapi 0x794c549be044
 
 If I change GL.c to use extern, this is what I get:
 
 $ ./firefox
 GL 0x7ca9ba272850
 GL glapi 0x7ca9ba271044
 dri 0x7ca9ba271044
 dri glapi 0x7ca9ba271044
 
 So, this would explain why the duplicate definition -- instead of
 using extern -- seemed to solve the problem in the past:
 
 1. When libglapi defines _glapi_tls_Context and libGL declares it
    extern, they disagree on it.
 
 2. When libglapi and libGL both define _glapi_tls_Context, they agree
    on it.
 
 But the problem is that in case (2), swrast_dri.so disagrees with both
 of them -- and I observe this whether swrast_dri.so has a third
 definition of _glapi_tls_Context or another extern declaration.
 
 If I put:
 
 - definition in libglapi
 - extern in libGL
 - extern in swrast_dri.so
 
 and run it with the patched ld.elf_so, it works:
 
 $ ./firefox
 GL 0x7d6bb813103c
 GL glapi 0x7d6bb813103c
 dri 0x7d6bb813103c
 dri glapi 0x7d6bb813103c
 
 So I think that fixing ld.elf_so to resolve the tls offset in the
 defining object rather than the referencing object (which will take a
 bit of work to disentangle all the const, or to resolve the tls offset
 earlier), and having a single definition with only extern declarations
 (`removing the massive kludge'), may fix the issue once and for all.