Re: bfd enforces a specific value of sh_info on SHT_GNU_verneed

[Alan Modra <amodra@gmail.com>]

On Fri, May 13, 2022 at 09:17:32PM +0200, Thomas Röthenbacher wrote:
> Hello,
> 
> as stated in the subect, bfd (and therefore `objdump -d`) seems to fail
> in _bfd_elf_slurp_version_tables if the value of sh_info for a
> ".gnu.version_r" section (SHT_GNU_verdef) is zero.

SHT_GNU_verneed you mean.  sh_info is the number of version
dependencies in .gnu.version_r.

> I couldn't however find a specification to justify this behaviour or
> anything specifying the sh_info field of this section type at all.
> The only reference I could find, was in the SUN "Linker and Libraries
> Guide", where they defined the sh_info value for their section type
> SHT_SUNW_verdef. But does this standard apply here?

Yes.  SHT_GNU_verneed even has the same value as SHT_SUNW_verneed.
If sh_info isn't described in documents specifying .gnu.version.r,
then that is a deficiency of the specification document.

> I'm asking, because a program I work with generates binaries that
> violate this constraint, but can't really justify why it should NOT
> just have a sh_info of zero in this section.

I can give you a reason why sh_info has a count.  Consider the
contents of .gnu.version_r, both Elfxx_Verneed and Elfxx_Vernaux
structures.  You can't calculate the number of entries from the
section size.  Thus without reading the section you can't validate
.gnu.version entries.  If that isn't persuasive, justify it by the
need to work with other programs that interpret ELF files!

-- 
Alan Modra
Australia Development Lab, IBM