* [Bug general/31763] eu-readelf -r is super slow at packed relocation processing
2024-05-20 18:41 [Bug general/31763] New: eu-readelf -r is super slow at packed relocation processing ajax at redhat dot com
@ 2024-05-20 19:03 ` mark at klomp dot org
2024-05-21 13:30 ` mark at klomp dot org
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: mark at klomp dot org @ 2024-05-20 19:03 UTC (permalink / raw)
To: elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=31763
Mark Wielaard <mark at klomp dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mark at klomp dot org
--- Comment #1 from Mark Wielaard <mark at klomp dot org> ---
Hohum. The slowdown comes from the fact that eu-readelf by default tries to do
an symbol lookup for every address it tries to print the function symbol +
offset.
The idea is that the -r output would look something like:
Relocation section [12] '.relr.dyn' at offset 0x4bc88 contains 750 entries:
+0x000000000044bcd0 <__frame_dummy_init_array_entry> *
+0x000000000044bcd8 <__do_global_dtors_aux_fini_array_entry>
+0x000000000044bce0 <__dso_handle>
+0x000000000044bd10 <ossl_ed448_asn1_meth+0x10>
+0x000000000044bd18 <ossl_ed448_asn1_meth+0x18>
+0x000000000044bd20 <ossl_ed448_asn1_meth+0x20>
[...]
But in practice this doesn't actually work for system libraries, since the
.symtab is stripped out, so the symbol lookup always fails (even with debuginfo
installed, since readelf doesn't do a separate .debug file lookup, you'll have
to eu-unstrip the library and debug file). It is super useful for your locally
build binaries though.
Unfortunately even with the .symtab stripped out this symbol lookup is
unreasonably slow.
As a workaround you can use:
-N, --numeric-addresses Do not find symbol names for addresses in DWARF
data
$ time eu-readelf -r ./libcrypto.so.3 | wc -l
17904
real 0m6.676s
user 0m6.648s
sys 0m0.010s
$ time eu-readelf -r -N ./libcrypto.so.3 | wc -l
17904
real 0m0.045s
user 0m0.037s
sys 0m0.013s
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug general/31763] eu-readelf -r is super slow at packed relocation processing
2024-05-20 18:41 [Bug general/31763] New: eu-readelf -r is super slow at packed relocation processing ajax at redhat dot com
2024-05-20 19:03 ` [Bug general/31763] " mark at klomp dot org
@ 2024-05-21 13:30 ` mark at klomp dot org
2024-05-21 13:39 ` ajax at redhat dot com
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: mark at klomp dot org @ 2024-05-21 13:30 UTC (permalink / raw)
To: elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=31763
--- Comment #2 from Mark Wielaard <mark at klomp dot org> ---
So the main issue is libdwfl/dwfl_module_addrsym.c which does a linear search
through all symbol tables each and every time...
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug general/31763] eu-readelf -r is super slow at packed relocation processing
2024-05-20 18:41 [Bug general/31763] New: eu-readelf -r is super slow at packed relocation processing ajax at redhat dot com
2024-05-20 19:03 ` [Bug general/31763] " mark at klomp dot org
2024-05-21 13:30 ` mark at klomp dot org
@ 2024-05-21 13:39 ` ajax at redhat dot com
2024-05-22 7:51 ` fweimer at redhat dot com
2024-05-22 13:48 ` mark at klomp dot org
4 siblings, 0 replies; 6+ messages in thread
From: ajax at redhat dot com @ 2024-05-21 13:39 UTC (permalink / raw)
To: elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=31763
--- Comment #3 from Adam Jackson <ajax at redhat dot com> ---
-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:
> +0x000000000044bcd0 <__frame_dummy_init_array_entry> *
> +0x000000000044bcd8 <__do_global_dtors_aux_fini_array_entry>
> +0x000000000044bce0 <__dso_handle>
> +0x000000000044bd10 <ossl_ed448_asn1_meth+0x10>
> +0x000000000044bd18 <ossl_ed448_asn1_meth+0x18>
> +0x000000000044bd20 <ossl_ed448_asn1_meth+0x20>
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug general/31763] eu-readelf -r is super slow at packed relocation processing
2024-05-20 18:41 [Bug general/31763] New: eu-readelf -r is super slow at packed relocation processing ajax at redhat dot com
` (2 preceding siblings ...)
2024-05-21 13:39 ` ajax at redhat dot com
@ 2024-05-22 7:51 ` fweimer at redhat dot com
2024-05-22 13:48 ` mark at klomp dot org
4 siblings, 0 replies; 6+ messages in thread
From: fweimer at redhat dot com @ 2024-05-22 7:51 UTC (permalink / raw)
To: elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=31763
Florian Weimer <fweimer at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |fweimer at redhat dot com
--- Comment #4 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Mark Wielaard from comment #1)
> But in practice this doesn't actually work for system libraries, since the
> .symtab is stripped out, so the symbol lookup always fails (even with
> debuginfo installed, since readelf doesn't do a separate .debug file lookup,
> you'll have to eu-unstrip the library and debug file). It is super useful
> for your locally build binaries though.
Isn't there a compressed symbol table in .gnu_debugdata?
But that's fairly Fedora/downstream specific, I think.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug general/31763] eu-readelf -r is super slow at packed relocation processing
2024-05-20 18:41 [Bug general/31763] New: eu-readelf -r is super slow at packed relocation processing ajax at redhat dot com
` (3 preceding siblings ...)
2024-05-22 7:51 ` fweimer at redhat dot com
@ 2024-05-22 13:48 ` mark at klomp dot org
4 siblings, 0 replies; 6+ messages in thread
From: mark at klomp dot org @ 2024-05-22 13:48 UTC (permalink / raw)
To: elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=31763
--- Comment #5 from Mark Wielaard <mark at klomp dot org> ---
(In reply to Florian Weimer from comment #4)
> (In reply to Mark Wielaard from comment #1)
> > But in practice this doesn't actually work for system libraries, since the
> > .symtab is stripped out, so the symbol lookup always fails (even with
> > debuginfo installed, since readelf doesn't do a separate .debug file lookup,
> > you'll have to eu-unstrip the library and debug file). It is super useful
> > for your locally build binaries though.
>
> Isn't there a compressed symbol table in .gnu_debugdata?
Yes, there is. And that one is searched. But it only contains STT_FUNC symbols
(since the main purpose is to show symbols for backtraces). And the RELR all
seem to be against addresses in SST_OBJECT symbols.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 6+ messages in thread