mirror of
https://git.haproxy.org/git/haproxy.git/
synced 2025-08-05 22:56:57 +02:00
ca773e1a2a
It's convenient to have a share lib be able to also work as a wrapper. But recent glibc broke support for this dual-mode thing some time ago: https://patchwork.ozlabs.org/project/glibc/patch/20190312130235.8E82C89CE49C@oldenburg2.str.redhat.com/ https://stackoverflow.com/questions/59074126/loading-executable-or-executing-a-library Trying to preload such an executable indeed returns: ERROR: ld.so: object '/path/to/ncpu.so' from LD_PRELOAD cannot be preloaded (cannot dynamically load position-independent executable): ignored. Note that the code still supports it since libc.so is both an executable and a lib. The approach taken here is the same as in the nousr.so wrapper. It consists in dropping the DF_1_PIE flag from the resulting executable since it's what the dynamic linker is looking for. This flag is found in FLAGS_1 in the .dynamic section. As readelf -a suggests, it's after the tag 0x6ffffffb. The value is 0x08000000. We're using objdump to figure the length and offset of the struct, dd to extract the 3 parts, and sed to patch the binary. It's likely that it will only work on 64-bit little endian, though tests should be performed to see what to do on other platforms. At least on x86_64, ld.so is happy and it continues to be possible to use the binary as a .so, and that the platform where most of the development happens so that's fine. In any case the wrapper and the standard shared lib are still made two distinct files so that it's possible to use the non-patched version on unsupported OSes or architectures. |
||
|---|---|---|
| .. | ||
| base64 | ||
| coccinelle | ||
| flags | ||
| gdb | ||
| h2 | ||
| haring | ||
| hpack | ||
| ncpu | ||
| patchbot | ||
| phash | ||
| plug_qdisc | ||
| poll | ||
| qpack | ||
| sslkeylogger | ||
| tcploop | ||
| trace | ||
| udp | ||