linux-man.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Wielaard <mjw@fedoraproject.org>
To: Florian Weimer <fweimer@redhat.com>,
	Robin Kuzmin <kuzmin.robin@gmail.com>
Cc: mtk@man7.org, linux-man <linux-man@vger.kernel.org>
Subject: Re: elf.5.html: Resolving confusion.
Date: Sun, 22 Dec 2019 15:17:10 +0100	[thread overview]
Message-ID: <9b418bcbbd1addbca1fc67ac9d5b5cf5a09f39e7.camel@fedoraproject.org> (raw)
In-Reply-To: <87tv65hhvw.fsf@oldenburg2.str.redhat.com>

Hi,

On Thu, 2019-12-12 at 13:01 +0100, Florian Weimer wrote:
> * Robin Kuzmin:
> 
> > http://man7.org/linux/man-pages/man5/elf.5.html
> > 
> > I see the fragment:
> > 
> >        A section header table index is a subscript into this array.  Some
> >        section header table indices are reserved: the initial entry and the
> >        indices between SHN_LORESERVE and SHN_HIRESERVE.  The initial entry
> >        is used in ELF extensions for e_phnum, e_shnum and e_strndx; in other
> >        cases, each field in the initial entry is set to zero.  An object
> >        file does not have sections for these special indices:
> > 
> >        SHN_UNDEF
> >               This value marks an undefined, missing, irrelevant, or other‐
> >               wise meaningless section reference.
> > 
> > I interpret it like this:
> > 
> >        A section header table index **(e_shstrndx)** is a subscript
> > into this array.
> 
> No, e_shstrndx is just one of the possible indices.  It's just the
> string table that is used for section names.

I see "this array" refers to: "The section header table is an array of
Elf32_Shdr or Elf64_Shdr structures."

e_shstrndx is a field of ElfN_Ehdr, which contains an index into the
section header table array. Unless e_shstrndx is either SHN_UNDEF (0),
which means there is no section name string table or
SHN_XINDEX (0xffff), which means the index of the section name string
table can be found in the sh_link field of the initial (0) section
header table element.

My English isn't strong enough to know whether all these descriptions
are the same or not.

> >  Some
> >        section header table indices are reserved:
> >        the initial entry **(index 0)**
> >        and the indices **from** SHN_LORESERVE **to** SHN_HIRESERVE **,
> > inclusive**.
> >        **Such reserved indices, except SHN_XINDEX (0xffff), cannot be
> > used in e_shstrndx.
> >        If e_shstrndx is SHN_XINDEX (0xffff) then the sh_link filed of
> > the initial ElfN_Shdr cannot contain such reserved indices.**
> >        The **three fields in the** initial entry ** - sh_info, sh_size
> > and sh_link - can be** used in ELF extensions for e_phnum, e_shnum and
> > **e_shstrndx correspondingly**. **If they are not used then they are
> > set to zero. All other fields of the initial entry are set to zero.**
> >        **The section header table entries with the following special
> > indices contain special values,         and in the ELF file there are
> > no sections associated with such entries.**
> > 
> >        SHN_UNDEF
> >               This value marks an undefined, missing, irrelevant, or other‐
> >               wise meaningless section reference.
> >               **This index can be 0 in which case it means the initial
> > ElfN_Shdr with a special meaning described above.**
> > 
> > Is such an interpretation correct?
> 
> I'm not sure if your clarifications are correct.  I don't think the
> section header extension mechanism is used for extending e_phum.

Yes, on Solaris and GNU/Linux if e_phnum contains the value PN_XNUM
(0xffff) then the actual number of segments can be found in the sh_info
field of the initial (0) section header. But if sh_info itself is zero
then it is interpreted as having 0xffff segments. This seems to be an
extension that is not standardized beyond GNU and Solaris.

Also note that the "extension mechanism" for e_shnum is different from
e_phnum and e_shstrndx, which both use an explicit extension value
(0xffff). e_shnum uses the value zero when the number of sections is
larger than SHN_LORESERVE (0xff00). In that case you can get the number
of sections from the sh_size field of the initial section (0) (after
checking that e_shoff and e_shentsize are not also zero of course,
otherwise there is simply no section header table).

> The main thing that's not clear to me in the current description is
> whether the 256 reserved indices have still entries in the table
> (probably of type SHT_NULL).

The values have special meaning in certain context, but have no special
section in the section header table. So you can simply have a section
header at index 0xff12 for example. This would be a normal section
without special attributes.

Cheers,

Mark

      reply	other threads:[~2019-12-22 14:25 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-11 20:19 elf.5.html: Resolving confusion Robin Kuzmin
2019-12-12  7:00 ` Michael Kerrisk (man-pages)
2019-12-12 12:01 ` Florian Weimer
2019-12-22 14:17   ` Mark Wielaard [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9b418bcbbd1addbca1fc67ac9d5b5cf5a09f39e7.camel@fedoraproject.org \
    --to=mjw@fedoraproject.org \
    --cc=fweimer@redhat.com \
    --cc=kuzmin.robin@gmail.com \
    --cc=linux-man@vger.kernel.org \
    --cc=mtk@man7.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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 NNTP newsgroup(s).