Commit Graph

8 Commits

Author SHA1 Message Date
Paul Eggert
dff8da6b3e Update copyright dates with scripts/update-copyrights 2024-01-01 10:53:40 -08:00
Joseph Myers
6d7e8eda9b Update copyright dates with scripts/update-copyrights 2023-01-06 21:14:39 +00:00
Paul Eggert
581c785bf3 Update copyright dates with scripts/update-copyrights
I used these shell commands:

../glibc/scripts/update-copyrights $PWD/../gnulib/build-aux/update-copyright
(cd ../glibc && git commit -am"[this commit message]")

and then ignored the output, which consisted lines saying "FOO: warning:
copyright statement not found" for each of 7061 files FOO.

I then removed trailing white space from math/tgmath.h,
support/tst-support-open-dev-null-range.c, and
sysdeps/x86_64/multiarch/strlen-vec.S, to work around the following
obscure pre-commit check failure diagnostics from Savannah.  I don't
know why I run into these diagnostics whereas others evidently do not.

remote: *** 912-#endif
remote: *** 913:
remote: *** 914-
remote: *** error: lines with trailing whitespace found
...
remote: *** error: sysdeps/unix/sysv/linux/statx_cp.c: trailing lines
2022-01-01 11:40:24 -08:00
Florian Weimer
5d28a8962d elf: Add _dl_find_object function
It can be used to speed up the libgcc unwinder, and the internal
_dl_find_dso_for_object function (which is used for caller
identification in dlopen and related functions, and in dladdr).

_dl_find_object is in the internal namespace due to bug 28503.
If libgcc switches to _dl_find_object, this namespace issue will
be fixed.  It is located in libc for two reasons: it is necessary
to forward the call to the static libc after static dlopen, and
there is a link ordering issue with -static-libgcc and libgcc_eh.a
because libc.so is not a linker script that includes ld.so in the
glibc build tree (so that GCC's internal -lc after libgcc_eh.a does
not pick up ld.so).

It is necessary to do the i386 customization in the
sysdeps/x86/bits/dl_find_object.h header shared with x86-64 because
otherwise, multilib installations are broken.

The implementation uses software transactional memory, as suggested
by Torvald Riegel.  Two copies of the supporting data structures are
used, also achieving full async-signal-safety.

Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>
2021-12-28 22:52:56 +01:00
Florian Weimer
466c1ea15f dlfcn: Rework static dlopen hooks
Consolidate all hooks structures into a single one.  There are
no static dlopen ABI concerns because glibc 2.34 already comes
with substantial ABI-incompatible changes in this area.  (Static
dlopen requires the exact same dynamic glibc version that was used
for static linking.)

The new approach uses a pointer to the hooks structure into
_rtld_global_ro and initalizes it in __rtld_static_init.  This avoids
a back-and-forth with various callback functions.

Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>
2021-06-03 09:12:05 +02:00
Florian Weimer
9ec7fff6cd elf: Initialize GLRO (dl_minsigstacksize) after static dlopen
This is another field of _rtld_global_ro that benefits from
initialization in __rtld_static_init.

Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
2021-05-20 18:56:42 +02:00
Florian Weimer
9dc21009a4 elf: Move static TLS size and alignment into _rtld_global_ro
This helps to clarify that the caching of these fields in libpthread
(in __static_tls_size, __static_tls_align_m1) is unnecessary.

Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>
2021-05-17 10:17:41 +02:00
Florian Weimer
78b31cc834 elf: Partially initialize ld.so after static dlopen (bug 20802)
After static dlopen, a copy of ld.so is loaded into the inner
namespace, but that copy is not initialized at all.  Some
architectures run into serious problems as result, which is why the
_dl_var_init mechanism was invented.  With libpthread moving into
libc and parts into ld.so, more architectures impacted, so it makes
sense to switch to a generic mechanism which performs the partial
initialization.

As a result, getauxval now works after static dlopen (bug 20802).

Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>
2021-05-17 10:06:57 +02:00