diff options
author | Michael Jeanson <mjeanson@efficios.com> | 2024-07-03 12:35:34 -0400 |
---|---|---|
committer | Florian Weimer <fweimer@redhat.com> | 2024-07-03 21:40:30 +0200 |
commit | 2b92982e2369d292560793bee8e730f695f48ff3 (patch) | |
tree | 8622e0a4d18185a6b48d4512d3beca2e3c823071 /sysdeps/htl | |
parent | b85a23d736b31df3284ce0018357a9cea534d6ff (diff) | |
download | glibc-2b92982e2369d292560793bee8e730f695f48ff3.tar.gz glibc-2b92982e2369d292560793bee8e730f695f48ff3.tar.xz glibc-2b92982e2369d292560793bee8e730f695f48ff3.zip |
nptl: fix potential merge of __rseq_* relro symbols
While working on a patch to add support for the extensible rseq ABI, we came across an issue where a new 'const' variable would be merged with the existing '__rseq_size' variable. We tracked this to the use of '-fmerge-all-constants' which allows the compiler to merge identical constant variables. This means that all 'const' variables in a compile unit that are of the same size and are initialized to the same value can be merged. In this specific case, on 32 bit systems 'unsigned int' and 'ptrdiff_t' are both 4 bytes and initialized to 0 which should trigger the merge. However for reasons we haven't delved into when the attribute 'section (".data.rel.ro")' is added to the mix, only variables of the same exact types are merged. As far as we know this behavior is not specified anywhere and could change with a new compiler version, hence this patch. Move the definitions of these variables into an assembler file and add hidden writable aliases for internal use. This has the added bonus of removing the asm workaround to set the values on rseq registration. Tested on Debian 12 with GCC 12.2. Signed-off-by: Michael Jeanson <mjeanson@efficios.com> Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Reviewed-by: Florian Weimer <fweimer@redhat.com>
Diffstat (limited to 'sysdeps/htl')
0 files changed, 0 insertions, 0 deletions