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