Bug 235751

Summary: Failure to init TLS variables with func ptr inside shared lib
Product: Base System Reporter: Dennis Clarke <dclarke>
Component: kernAssignee: freebsd-bugs (Nobody) <bugs>
Status: New ---    
Severity: Affects Some People CC: linimon, marklmi26-fbsd, ppc
Priority: ---    
Version: 12.0-RELEASE   
Hardware: powerpc   
OS: Any   

Description Dennis Clarke 2019-02-14 22:17:34 UTC
This is the exact same problem as described in Bug 161344.
Re-discovered this because libmpfr 4.0.2 fails most of its
tests unless one disables thread local storage. 

hydra$ uname -a 
FreeBSD hydra 12.0-RELEASE FreeBSD 12.0-RELEASE r341666 GENERIC  powerpc

hydra$ echo $CC
/usr/local/bin/gcc8

hydra$ echo $CFLAGS 
-g -m64 -std=c99 -fno-builtin -O0 -mcpu=970 -mcall-freebsd -mno-altivec -mno-float128 -mno-float128-hardware -mfull-toc -mregnames -fno-unsafe-math-optimizations

hydra$ cat -n t1.c
     1
     2  int f(int x) {
     3    return x;
     4  }
     5  struct s_t {
     6    int (*func)(int);
     7  };
     8  struct s_t __thread x = { f };
     9
    10
hydra$ 

hydra$ cat -n t2.c
     1
     2
     3  struct s_t {
     4    int (*func)(int);
     5  };
     6  extern struct s_t __thread x;
     7  int main(int argc, const char *argv[]) {
     8    return (*x.func)(argc);
     9  }
    10
hydra$ 

hydra$ $CC $CFLAGS -shared -o t1.so -fPIC t1.c
hydra$ $CC $CFLAGS -o foo t2.c t1.so
hydra$ LD_LIBRARY_PATH=. ./foo
Segmentation fault (core dumped)
hydra$

hydra$ gdb foo foo.core
GNU gdb (GDB) 8.2.1 [GDB v8.2.1 for FreeBSD]
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "powerpc64-portbld-freebsd12.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from foo...done.
[New LWP 100253]
Core was generated by `./foo'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000000010000a1c in main (argc=1, argv=0x3fffffffffffd7f0) at t2.c:8
8         return (*x.func)(argc);
(gdb) where
#0  0x0000000010000a1c in main (argc=1, argv=0x3fffffffffffd7f0) at t2.c:8
(gdb) list
3       struct s_t {
4         int (*func)(int);
5       };
6       extern struct s_t __thread x;
7       int main(int argc, const char *argv[]) {
8         return (*x.func)(argc);
9       }
10
(gdb) quit


However the problem goes away entirely with r344130.

Also tested the situation with mpfr 4.0.2 and TLS seems to work with r344130.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2019-02-15 18:03:13 UTC
I'm confused.  r344130 seems to a be a documentation-only commit.
Comment 2 Mark Millard 2019-02-15 20:10:30 UTC
(In reply to Mark Linimon from comment #1)

My guess: -r344130 was likely not the result of a bisect providing the
first working version --but might provide an upper bound for use in a
bisect.
Comment 3 Dennis Clarke 2019-02-15 20:15:25 UTC
(In reply to Mark Millard from comment #2)

Exactly.  This is merely where I am at the moment when I 
checked out head.  I am doing something similar with a RISC-V
build with r344143 but that is merely the version that I see
from subversion and not anything to do with the most recent
kernel change. 

Not very helpful I know.


-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
Comment 4 Mark Millard 2020-03-10 23:18:45 UTC
Hmm. For:

hydra$ echo $CC
/usr/local/bin/gcc8

hydra$ echo $CFLAGS 
-g -m64 -std=c99 -fno-builtin -O0 -mcpu=970 -mcall-freebsd -mno-altivec -mno-float128 -mno-float128-hardware -mfull-toc -mregnames -fno-unsafe-math-optimizations

the system compiler and libraries were not in use.
I'd expect an ldd on the ./foo to have shown gcc
libraries involved, possibly spanning at least parts
of gcc's thread local storage support.

I'm not so sure that "Base System" was the right place
for this report, in fact it might not even be a FreeBSD
specific issue as presented.