Re: [PATCH] gdb: do not add const sections to the section map

[Ilya Leoshkevich <iii@linux.ibm.com>]

On Thu, 2022-05-19 at 09:10 -0600, Tom Tromey wrote:
> > > > > > Ilya Leoshkevich <iii@linux.ibm.com> writes:
> 
> > From: Ulrich Weigand <ulrich.weigand@de.ibm.com>
> > build_objfile_section_table () creates four synthetic sections,
> > which
> > significantly slow down section map sorting.  This is especially
> > noticeable when debugging JITs that report a lot of objfiles. 
> > Since
> > these sections are not useful for find_pc_section (), do not add
> > them
> > to the section map.
> 
> How does it slow down the sorting?

CoreCLR JIT reports each compiled function as a separate objfile with
a single .text section and a few debug sections [1].  Once you have a
few thousand of them - which is easily reachable - std::sort becomes a
bottleneck.  Ignoring synthetic sections from each objfile reduces the
amount of sections to sort significantly.

That's unfortunately not quite enough to debug bigger apps.  But it's
still a noticeable improvement, so I've decided to post it.

I'm currently trying to implement a more complex optimization in the
section map area ([2] - not working yet, and probably not reviewable
either, just FYI).

> It seems a little strange at least to drop the *ABS* section, since
> IIUC
> that's for symbols that specify some kind of absolute address. 
> Couldn't
> these matter for lookup purposes?  It's probable I don't really know
> what's going on here...

All four seem to have a size of 0, so they should never be returned
by find_pc_section ().

> I wonder if we can drop all support for all these sections from gdb.

They were added in 65cf35635977, which introduced
gdb_bfd_section_index ().  This function is used in quite a few places,
so I guess as long as bfd can report these sections, this should stay?

> Tom

[1]
https://github.com/dotnet/runtime/blob/v6.0.5/src/coreclr/vm/gdbjit.cpp#L2147
[2]
https://github.com/iii-i/binutils-gdb/releases/tag/section-map-20220519