This test removes the __libc_start_main@GLIBC_2.34 symbol, which should
be the only GLIBC_2.34 symbol in 'main' when built with recent (i.e., >
2.34) glibc. Because it is the only symbol, the entry in .gnu.version_r
should also be removed.
Because this is a symbol version test, it's unlikely to work on musl or
anything else which doesn't use glibc symbol versions. In these cases
(or in the case that __libc_start_main is now at a different version),
the test should print a warning, but exit with "0" to report a pass.
Made changes according to feedback from @Mic92 such as moving the
`rewriteSections` inline into every method.
Improved `replace-add-needed.sh` to work with musl libc
MacOS, FreeBSD and Linux using GNU have it, but at least OpenBSD
does not (the non-compatible BSD equivalent jot(1) exists, though).
Counting up is easy enough to do in POSIX sh(1).
Looks like this after GNU make(1)'s escaping and produces the same
big-dynstr.c file:
```
cat main.c > big-dynstr.c
i=1; while [ $i -le 2000 ]; do echo "void f$i(void) { };"; i=$(($i + 1)); done >> big-dynstr.c
```
This is the last bit required to build and pass all tests on OpenBSD
without local patches/dependencies.
As is common with autotools enabled software, building and testing
happens outside the source directory.
The introduction of `contiguous-note-sections` test in 0.13 broke this
by assuming linker scripts to exist in the current working directory.
Point at the absoloute source directory explicitly to unbreak linking in
such build environments.
Spotted on OpenBSD where source and build assets are commonly separated
iff possible.
(Old) linkers such as BFD's ld(1) aka. GNU ld (version 2.17 on OpenBSD)
don't know `--build-id`, but they know `-b input-format` which patchelf
triggers by ommitting the second dash.
LLD's ld(1) seems to cope with this, although it's incorrect usage.
Use the double dash for correctness to get accurate error messages with
such incompatible linkers:
-/usr/bin/ld: invalid BFD target `uild-id'
+/usr/bin/ld: unrecognized option '--build-id'
+/usr/bin/ld: use the --help option for usage information
When it happens that the .gnu.version_r stores the strings in .dynstr it can
come to corruption of the library names written into DT_NEEDED:
-the library names in DT_NEEDED are replaced, new entries are written to the end
of .dynstr
-the version library names are replaced, and written to the end of the string
section.
If the section for the version strings is also ".dynstr", the previous
modifications were _not_ taken into account and things were written from the old
end of .dynstr again. The order in which these strings were written is not the
same as the previous replacement, so things would end up with the same size, but
different offsets. The .gnu.version_r table is correct, the file contents are
fine, but the offsets in the DT_NEEDED entries are wrong. Since they are printed
as 0-terminated strings the first one replaced will always be shown correct,
which also is the case if the argument is only used once as the string is
replaced with itself afterwards.
A PT_PHDR corruption was previously reported and fixed in [1]: the issue was
that the VirtAddr field of the PT_PHDR program header would get overwritten
with the file offset of the program header table rather than the virtual
address. A testcase for this was also added in [2]. However, the tescase is not
included in the Makefile.am regression testsuite and also tries to run a x86_64
prebuilt binary unconditionally, which would not work on other architectures.
To fix this, create a standalone testcase for the PT_PHDR VirtAddr field
corruption and include it in Makefile.am. In order to reproduce [1], a binary
with the following characteristics is needed:
- the ELF file type must be ET_DYN
- the ELF file must contain a PT_PHDR program header
- the file offset and the VirtAddr field of the PT_PHDR program header must be
different
[1] https://github.com/NixOS/patchelf/pull/243
[2] 8f94e116f3
Signed-off-by: Ovidiu Panait <ovpanait@gmail.com>
Currently, "make check" fails on Ubuntu 20.04 because the STRIP variable is not
set in the resulting tests/Makefile:
"""
git clone https://github.com/NixOS/patchelf.git
./bootstrap.sh
./configure
make VERBOSE=1 check
...
gcc -fPIC -shared -o libbig-dynstr.so big-dynstr.c
only-keep-debug libbig-dynstr.so -o libbig-dynstr.debug
/bin/bash: only-keep-debug: command not found
make[2]: [Makefile:1526: libbig-dynstr.debug] Error 127 (ignored)
...
FAIL: no-dynamic-section.sh
===========================
patchelf: getting info about 'libbig-dynstr.debug': No such file or directory
FAIL no-dynamic-section.sh (exit status: 1)
"""
strip is used by the regression testsuite, so add a check for it configure.ac.
Signed-off-by: Ovidiu Panait <ovpanait@gmail.com>
`patchelf --set-rpath` corrupted executables on mips32el: the dynamic
liker crushed with Segmentation fault when loading any executable with
RPATH added that way.
The problem was around the MIPS-specific mechanism of setting up the
debug map pointer. When DT_MIPS_RLD_MAP_REL entry in the dynamic section
is present, it holds the relative address of __RLD_MAP -- an offset
relative to this dynamic section entry. Dynamic linker puts the
pointer to the `r_debug` structure there.
When patchelf updates the executable RPATH, it moves the .dynamic
section both in the binary and in memory, while __RLD_MAP is not moved
in memory, since it belongs to special .rld_map section that has type
PROGBITS. So, the offset stored in DT_MIPS_RLD_MAP_REL entry is not
valid anymore and should be updated.
This commit adds the necessary update.
In the corner case when DT_MIPS_RLD_MAP_REL is present, but
.rld_map section is not, the dynamic loader writes the debug
pointer to some arbitrary bytes in memory. To avoid crushes
on otherwise "working" binaries, we set offset to zero
so that the dynamic loader would just overwrite the dynamic
section.
Here we also import DT_MIPS_RLD_MAP_REL definition in elf.h form
glibc commit a2057c984e4314c3740f04cf54e36c824e4c8f32.
Refs: #82
Signed-off-by: Ivan A. Melnikov <iv@altlinux.org>
Add a testcase for the following reported alignment issue with contiguous note
sections (#275):
"""
If a binary has multiple SHT_NOTE sections and corresponding PT_NOTE
headers, we can see the error:
patchelf: cannot normalize PT_NOTE segment: non-contiguous SHT_NOTE sections
if the SHT_NOTE sections aren't sized to end on aligned boundaries. An example
would be a binary with:
[ 2] .note.ABI-tag NOTE 00000000000002f4 000002f4
0000000000000020 0000000000000000 A 0 0 4
[ 3] .note.gnu.propert NOTE 0000000000000318 00000318
0000000000000030 0000000000000000 A 0 0 8
[ 4] .note.gnu.build-i NOTE 0000000000000348 00000348
0000000000000024 0000000000000000 A 0 0 4
NOTE 0x0000000000000318 0x0000000000000318 0x0000000000000318
0x0000000000000030 0x0000000000000030 R 0x8
NOTE 0x00000000000002f4 0x00000000000002f4 0x00000000000002f4
0x0000000000000078 0x0000000000000074 R 0x4
since the PT_NOTE section at 2f4 covers [2] and [3] but the code
calclates curr_off should be 314, not the 318 in the binary. This
is an alignment issue.
"""
Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com>
Add a testcase for the following reported alignment issue with contiguous note
sections (#275):
"""
If a binary has multiple SHT_NOTE sections and corresponding PT_NOTE
headers, we can see the error:
patchelf: cannot normalize PT_NOTE segment: non-contiguous SHT_NOTE sections
if the SHT_NOTE sections aren't sized to end on aligned boundaries. An example
would be a binary with:
[ 2] .note.ABI-tag NOTE 00000000000002f4 000002f4
0000000000000020 0000000000000000 A 0 0 4
[ 3] .note.gnu.propert NOTE 0000000000000318 00000318
0000000000000030 0000000000000000 A 0 0 8
[ 4] .note.gnu.build-i NOTE 0000000000000348 00000348
0000000000000024 0000000000000000 A 0 0 4
NOTE 0x0000000000000318 0x0000000000000318 0x0000000000000318
0x0000000000000030 0x0000000000000030 R 0x8
NOTE 0x00000000000002f4 0x00000000000002f4 0x00000000000002f4
0x0000000000000078 0x0000000000000074 R 0x4
since the PT_NOTE section at 2f4 covers [2] and [3] but the code
calclates curr_off should be 314, not the 318 in the binary. This
is an alignment issue.
"""
Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com>
Parsing this file results in patchelf segfaulting at:
Program received signal SIGSEGV, Segmentation fault.
std::vector<Elf32_Phdr, std::allocator<Elf32_Phdr> >::_M_realloc_insert<Elf32_Phdr const&> (this=0x7fffffff80a8, __position=..., __args=...)
at /nix/store/h31cy7jm6g7cfqbhc5pm4rf9c53i3qfb-gcc-9.3.0/include/c++/9.3.0/bits/vector.tcc:449
449 _Alloc_traits::construct(this->_M_impl,
(gdb) bt
at /nix/store/h31cy7jm6g7cfqbhc5pm4rf9c53i3qfb-gcc-9.3.0/include/c++/9.3.0/bits/vector.tcc:449
at /nix/store/h31cy7jm6g7cfqbhc5pm4rf9c53i3qfb-gcc-9.3.0/include/c++/9.3.0/bits/stl_vector.h:1195
this=0x7fffffff8088, fileContents=...) at patchelf.cc:421
Parsing this file results in patchelf segfaulting at:
at /nix/store/h31cy7jm6g7cfqbhc5pm4rf9c53i3qfb-gcc-9.3.0/include/c++/9.3.0/bits/char_traits.h:335
at /nix/store/h31cy7jm6g7cfqbhc5pm4rf9c53i3qfb-gcc-9.3.0/include/c++/9.3.0/bits/basic_string.h:527
this=0x7fffffff8028, fileContents=...) at patchelf.cc:449
