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.