Re: [PATCH] [dwarf2read] Fix crash when loading dwp files: calculate num_sections based on actual section indices, not just the number of sections.

["Jordan Rupprecht via gdb-patches" <gdb-patches at sourceware dot org>]

On Sat, Feb 23, 2019 at 8:01 PM Simon Marchi <simon.marchi@polymtl.ca> wrote:
>
> On 2019-02-22 19:53, Jordan Rupprecht via gdb-patches wrote:
> > When loading dwp files, we create an array of elf sections indexed by
> > the section index in the dwp file. The size of this array is
> > calculated by section_count + 1 (the +1 handling the null section).
> > However, when loading the bfd file, strtab/symtab sections are not
> > added to the list, nor do they increment section_count, so
> > section_count is actually smaller than the number of sections.
>
> Just wondering, is this the expected behavior of BFD, to not make the
> strtab section count as a section (as far as bfd_count_sections is
> concerned)?  If so, why?
I'm not very familiar with bfd, so I don't know if it's expected. It
seems that bfd->sections contains "interesting" sections (e.g.
progbits), and treats sections like strtab/symtab as a kind of
metadata section that get stored differently. The method I'm stepping
through is bfd_section_from_shdr here:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=bfd/elf.c;h=f16acaa08d8e24af9af069efcdcb244b2c19c734;hb=HEAD#l1994.
Running that method over a normal .dwp file, all the .debug_* methods
get added to sections, but .strtab/.symtab/.shstrtab don't.

So it *seems* like that's expected behavior, but I can't say for sure
that it is.

>
> Otherwise can we just elf_numsections instead of bfd_count_sections?
> Since we index the array by ELF section index, using the number of ELF
> sections seems appropriate, it should always match.  We wouldn't need
> the +1 then.

Don't know how I didn't see that. Now I don't need
get_largest_section_index() anymore. Thanks!
All your comments are basically not relevant any more :)