https://sourceware.org/bugzilla/show_bug.cgi?id=31763
Bug ID: 31763
Summary: eu-readelf -r is super slow at packed relocation
processing
Product: elfutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: general
Assignee: unassigned at sourceware dot org
Reporter: ajax at redhat dot com
CC: elfutils-devel at sourceware dot org
Target Milestone: ---
After upgrading to F40, I was pleased to find that packed relocations were
enabled, but one of my tools uses `eu-readelf -r` and apparently packed relocs
are super slow:
========
# What are we dealing with?
neo:~% eu-readelf -d /usr/lib64/libcrypto.so.3 | grep ^..REL
RELA 0x000000000004acc8
RELASZ 168 (bytes)
RELAENT 24 (bytes)
RELR 0x000000000004bc88
RELRSZ 6000 (bytes)
RELRENT 8 (bytes)
# Not too huge. How bad is it?
neo:~% time eu-readelf -r /usr/lib64/libcrypto.so | wc -l
17904
eu-readelf -r /usr/lib64/libcrypto.so 5.80s user 0.00s system 99% cpu 5.812
total
wc -l 0.00s user 0.00s system 0% cpu 5.811 total
# That's... not good. How does the competition do?
neo:~% time readelf -r /usr/lib64/libcrypto.so | wc -l
17905
readelf -r /usr/lib64/libcrypto.so 0.01s user 0.01s system 95% cpu 0.014 total
wc -l 0.00s user 0.00s system 25% cpu 0.013 total
# That's worse. Did it happen in F39?
neo:~% time toolbox run -c fedora39 eu-readelf -r /usr/lib64/libcrypto.so | wc
-l
17006
toolbox run -c fedora39 eu-readelf -r /usr/lib64/libcrypto.so 0.00s user 0.01s
system 3% cpu 0.348 total
wc -l 0.00s user 0.00s system 1% cpu 0.347 total
# Nope, even the container overhead doesn't come close.
# Does it happen with F40's elfutils but F39's libcrypto?
neo:~% toolbox run -c fedora39 cat /usr/lib64/libcrypto.so > f39-libcrypto.so
neo:~% time eu-readelf -r ./f39-libcrypto.so | wc -l
17006
eu-readelf -r ./f39-libcrypto.so 0.00s user 0.00s system 93% cpu 0.010 total
wc -l 0.00s user 0.00s system 37% cpu 0.009 total
# Nope. What does f39's libcrypto's reloc info look like?
neo:~% eu-readelf -d ./f39-libcrypto.so | grep ^..REL
RELA 0x00000000000494a0
RELASZ 404592 (bytes)
RELAENT 24 (bytes)
RELACOUNT 16851
========
6 seconds is "bad but not awful", but I discovered this on libLLVM where it's
more like eight minutes.
--
You are receiving this mail because:
You are on the CC list for the bug.