[Bug general/31763] New: eu-readelf -r is super slow at packed relocation processing
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 0x0004acc8 RELASZ168 (bytes) RELAENT 24 (bytes) RELR 0x0004bc88 RELRSZ6000 (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 0x000494a0 RELASZ404592 (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.
[Bug general/31763] eu-readelf -r is super slow at packed relocation processing
https://sourceware.org/bugzilla/show_bug.cgi?id=31763 --- Comment #3 from Adam Jackson --- -N works, not sure how I'd missed it in the docs, thank you. I'm not sure if there's a good way to cache the likely-negative-ness of the symbol lookup here. >From your example: > Relocation section [12] '.relr.dyn' at offset 0x4bc88 contains 750 entries: > +0x0044bcd0 <__frame_dummy_init_array_entry> * > +0x0044bcd8 <__do_global_dtors_aux_fini_array_entry> > +0x0044bce0 <__dso_handle> > +0x0044bd10 > +0x0044bd18 > +0x0044bd20 When you process 0x44bd10 you could look ahead to see that the next two have the same increment (of 0x8, though, why be picky), and probably they, and any more beyond with the same increment, would refer to offsets within a single symbol. I don't know if there's a good way to express that as a heuristic here though. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug tools/28495] Add support for SHT_RELR to eu-readelf
https://sourceware.org/bugzilla/show_bug.cgi?id=28495 Adam Jackson changed: What|Removed |Added CC||ajax at redhat dot com --- Comment #3 from Adam Jackson --- SHT_RELR is shipping now: datura:~% rpm -q glibc elfutils glibc-2.37-4.fc38.x86_64 elfutils-0.189-3.fc38.x86_64 datura:~% eu-readelf -a /usr/lib64/libc.so.6 | grep -m 1 -F .relr.dyn [13] .relr.dyn: 19 00025180 00025180 0108 8 A 0 0 8 -- You are receiving this mail because: You are on the CC list for the bug.
