glibc/elf/tst-dlopen-nodelete-reloc.h
Florian Weimer 365624e2d2 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 f63b73814f ("Remove all
loaded objects if dlopen fails, ignoring NODELETE [BZ #20839]").
2019-12-13 10:18:24 +01:00

36 lines
1.4 KiB
C++

/* 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;