[Bug gdb/17557] Very slow load due to millions of identical lseek syscalls opening shared libs

["xdje42 at gmail dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=17557

Doug Evans <xdje42 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xdje42 at gmail dot com

--- Comment #3 from Doug Evans <xdje42 at gmail dot com> ---
Yeah, more than a little clumsy.

A lot of these are coming from bfd, I haven't looked into what's involved in
making bfd smarter.

However, it's not clear to me that the lseek calls are the high order bit of
the slowness I've seen in my benchmarks.  Although bfd may have changed since I
last collected data.

btw, another thing I'm seeing is massive amounts of calls to
rt_sigaction,rt_sigprocmask to handle SIGSEGV - presumably the new segv
handling we're wrapped around the demangler.  I still have to measure the cost
of doing it per-symbol.

We need to add a mega-program generator to our performance testsuite, and
provide a shareable framework from which to collect and share data.

btw, I'm assuming you're not using .gdb_index
(please correct me if I'm wrong).
https://sourceware.org/gdb/current/onlinedocs/gdb/Index-Files.html#Index-Files
It would be interesting to compare what you see with and without .gdb_index.
.gdb_index won't help with reading ELF symbols (which is where more of the
lseeks are coming from) but it would be interesting data to have.
The index can be added to any program (or, hopefully, .so) with the
gdb-add-index program that comes with gdb.
[Only do this if you have time and the inclination of course.]

Also, OOC, how many shared libraries?
e.g., what's the output of "ldd $program | wc" ?

-- 
You are receiving this mail because:
You are on the CC list for the bug.