public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
* bfd enforces a specific value of sh_info on SHT_GNU_verneed
@ 2022-05-13 19:17 Thomas Röthenbacher
  2022-05-14  1:06 ` Alan Modra
  0 siblings, 1 reply; 2+ messages in thread
From: Thomas Röthenbacher @ 2022-05-13 19:17 UTC (permalink / raw)
  To: binutils

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.
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?

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.


Thanks in advance for your replies,
Thomas


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: bfd enforces a specific value of sh_info on SHT_GNU_verneed
  2022-05-13 19:17 bfd enforces a specific value of sh_info on SHT_GNU_verneed Thomas Röthenbacher
@ 2022-05-14  1:06 ` Alan Modra
  0 siblings, 0 replies; 2+ messages in thread
From: Alan Modra @ 2022-05-14  1:06 UTC (permalink / raw)
  To: Thomas Röthenbacher; +Cc: binutils

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2022-05-14  1:06 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-05-13 19:17 bfd enforces a specific value of sh_info on SHT_GNU_verneed Thomas Röthenbacher
2022-05-14  1:06 ` Alan Modra

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).