1 /* Verify that TLS access in separate thread in a dlopened library does not
3 Copyright (C) 2015-2019 Free Software Foundation, Inc.
4 This file is part of the GNU C Library.
6 The GNU C Library is free software; you can redistribute it and/or
7 modify it under the terms of the GNU Lesser General Public
8 License as published by the Free Software Foundation; either
9 version 2.1 of the License, or (at your option) any later version.
11 The GNU C Library is distributed in the hope that it will be useful,
12 but WITHOUT ANY WARRANTY; without even the implied warranty of
13 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
14 Lesser General Public License for more details.
16 You should have received a copy of the GNU Lesser General Public
17 License along with the GNU C Library; if not, see
18 <https://www.gnu.org/licenses/>. */
22 /* When one dynamically loads a module, which spawns a thread to perform some
23 activities, it could be possible that TLS storage is accessed for the first
24 time in that thread. This results in an allocation request within the
25 thread, which could result in an attempt to take the rtld load_lock. This
26 is a problem because it would then deadlock with the dlopen (which owns the
27 lock), if the main thread is waiting for the spawned thread to exit. We can
28 at least ensure that this problem does not occur due to accesses within
29 libc.so, by marking TLS variables within libc.so as IE. The problem of an
30 arbitrary variable being accessed and constructed within such a thread still
31 exists but this test case does not verify that. */
36 void *f
= dlopen ("tst-join7mod.so", RTLD_NOW
| RTLD_GLOBAL
);
45 #define TEST_FUNCTION do_test ()
46 #include "../test-skeleton.c"