upstream/haproxy
1
0
Fork 0
mirror of https://github.com/haproxy/haproxy.git synced 2026-03-01 21:01:26 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions 3
haproxy/dev/ncpu/Makefile

32 lines
867 B
Makefile
Raw Permalink Normal View History

DEV: ncpu: add a simple utility to help with NUMA development Collecting captures of /sys isn't sufficient for NUMA development because haproxy detects the number of CPUs at boot time and will not be able to inspect more than this number. Let's just have a small utility to report a fake number of CPUs, that will be loaded using LD_PRELOAD. It checks the NCPU variable if it exists and will present this number of CPUs, or if it does not exist, will expose the maximum supported number.
2025-01-08 02:48:16 -05:00
include ../../include/make/verbose.mk
CC = cc
OPTIMIZE = -O2 -g
DEFINE =
INCLUDE =
DEV: ncpu: make the wrapper work both as a lib and executable 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.
2025-01-08 03:31:41 -05:00
OBJS = ncpu.so ncpu
OBJDUMP = objdump
DEV: ncpu: add a simple utility to help with NUMA development Collecting captures of /sys isn't sufficient for NUMA development because haproxy detects the number of CPUs at boot time and will not be able to inspect more than this number. Let's just have a small utility to report a fake number of CPUs, that will be loaded using LD_PRELOAD. It checks the NCPU variable if it exists and will present this number of CPUs, or if it does not exist, will expose the maximum supported number.
2025-01-08 02:48:16 -05:00
all: $(OBJS)
DEV: ncpu: make the wrapper work both as a lib and executable 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.
2025-01-08 03:31:41 -05:00
%.o: %.c
$(cmd_CC) $(OPTIMIZE) $(DEFINE) $(INCLUDE) -shared -fPIC -c -o $@ $^
%.so: %.o
$(cmd_CC) -pie -o $@ $^
$(Q)rm -f $^
%: %.so
$(call qinfo, PATCHING)set -- $$($(OBJDUMP) -j .dynamic -h $^ | fgrep .dynamic); \
ofs=$$6; size=$$3; \
dd status=none bs=1 count=$$((0x$$ofs)) if=$^ of=$^-p1; \
dd status=none bs=1 skip=$$((0x$$ofs)) count=$$((0x$$size)) if=$^ of=$^-p2; \
dd status=none bs=1 skip=$$((0x$$ofs+0x$$size)) if=$^ of=$^-p3; \
sed -e 's,\xfb\xff\xff\x6f\x00\x00\x00\x00\x00\x00\x00\x08,\xfb\xff\xff\x6f\x00\x00\x00\x00\x00\x00\x00\x00,g' < $^-p2 > $^-p2-patched; \
cat $^-p1 $^-p2-patched $^-p3 > "$@"
$(Q)rm -f $^-p*
$(Q)chmod 755 "$@"
DEV: ncpu: add a simple utility to help with NUMA development Collecting captures of /sys isn't sufficient for NUMA development because haproxy detects the number of CPUs at boot time and will not be able to inspect more than this number. Let's just have a small utility to report a fake number of CPUs, that will be loaded using LD_PRELOAD. It checks the NCPU variable if it exists and will present this number of CPUs, or if it does not exist, will expose the maximum supported number.
2025-01-08 02:48:16 -05:00
clean:
DEV: ncpu: make the wrapper work both as a lib and executable 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.
2025-01-08 03:31:41 -05:00
rm -f $(OBJS) *.[oas] *.so-* *~
Reference in a new issue Copy permalink