aboutsummaryrefslogtreecommitdiff
path: root/elf/tst-dlopen-nodelete-reloc.h
diff options
context:
space:
mode:
authorFlorian Weimer <fweimer@redhat.com>2019-12-13 10:18:24 +0100
committerFlorian Weimer <fweimer@redhat.com>2019-12-13 10:18:24 +0100
commit365624e2d2a342cdb693b4cc35d2312169959e28 (patch)
tree4a17435022fd7b0c03690c7ad3444b0d3c030ced /elf/tst-dlopen-nodelete-reloc.h
parent186e119bbd4a10895429ffe405ae96dc5c5634b8 (diff)
downloadglibc-365624e2d2a342cdb693b4cc35d2312169959e28.zip
glibc-365624e2d2a342cdb693b4cc35d2312169959e28.tar.gz
glibc-365624e2d2a342cdb693b4cc35d2312169959e28.tar.bz2
dlopen: Fix issues related to NODELETE handling and relocations
The assumption behind the assert in activate_nodelete was wrong: Inconsistency detected by ld.so: dl-open.c: 459: activate_nodelete: Assertion `!imap->l_init_called || imap->l_type != lt_loaded' failed! (edit) It can happen that an already-loaded object that is in the local scope is promoted to NODELETE status, via binding to a unique symbol. Similarly, it is possible that such NODELETE promotion occurs to an already-loaded object from the global scope. This is why the loop in activate_nodelete has to cover all objects in the namespace of the new object. In do_lookup_unique, it could happen that the NODELETE status of an already-loaded object was overwritten with a pending NODELETE status. As a result, if dlopen fails, this could cause a loss of the NODELETE status of the affected object, eventually resulting in an incorrect unload. Fixes commit f63b73814f74032c0e5d0a83300e3d864ef905e5 ("Remove all loaded objects if dlopen fails, ignoring NODELETE [BZ #20839]").
Diffstat (limited to 'elf/tst-dlopen-nodelete-reloc.h')
-rw-r--r--elf/tst-dlopen-nodelete-reloc.h35
1 files changed, 35 insertions, 0 deletions
diff --git a/elf/tst-dlopen-nodelete-reloc.h b/elf/tst-dlopen-nodelete-reloc.h
new file mode 100644
index 0000000..8844de6
--- /dev/null
+++ b/elf/tst-dlopen-nodelete-reloc.h
@@ -0,0 +1,35 @@
+/* Template to produce unique symbols.
+ Copyright (C) 2019 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
+ <https://www.gnu.org/licenses/>. */
+
+/* This template produces a unique symbol definition for an explicit
+ template instantiation (without also incorporating a reference),
+ and an extern template declaration can be used to reference that
+ symbol from another object. The modid parameter is just a
+ placeholder to create different symbols (because it affects the
+ name mangling of the static value member). By convention, it
+ should match the number of the module that contains the
+ definition. */
+
+template <int modid>
+struct unique_symbol
+{
+ static int value;
+};
+
+template <int modid>
+int unique_symbol<modid>::value;