Multi-threading and _bfd_section_id

[Tom Tromey]

I found out today about the _bfd_section_id global and how its use
introduces data races when trying to use BFD from multiple threads.
This was discovered in

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

_bfd_section_id seems to primarily be used to assign a globally unique
ID to each section.  This by itself is no big deal -- fixing the races
here could be done either by acquiring the existing BFD global lock when
using the global, or by making it atomic.  (I did only find one use of
section_id in the tree, so removing it seems tempting, but I don't know
how difficult that would be.)

However, bfd_preserve_save and friends save and restore the global.  My
inclination would be to just remove this code, since it doesn't seem
like a big deal to waste a few IDs.

But, when looking  into this, I found this code in elf64-ppc.c:

    int
    ppc64_elf_setup_section_lists (struct bfd_link_info *info)
    {
      unsigned int id;
      size_t amt;
      struct ppc_link_hash_table *htab = ppc_hash_table (info);

      if (htab == NULL)
        return -1;

      htab->sec_info_arr_size = _bfd_section_id;

... and I was wondering whether having holes in the section ID space
would cause problems here.

I'd appreciate some advice here, as I don't know what this code is for.
Like, would there be some other way to count the number of sections?  Or
would having unused slots be harmless?

thanks,
Tom