Linux-man Archive on lore.kernel.org
 help / color / Atom feed
* elf.5.html: Resolving confusion.
@ 2019-12-11 20:19 Robin Kuzmin
  2019-12-12  7:00 ` Michael Kerrisk (man-pages)
  2019-12-12 12:01 ` Florian Weimer
  0 siblings, 2 replies; 4+ messages in thread
From: Robin Kuzmin @ 2019-12-11 20:19 UTC (permalink / raw)
  To: mtk, linux-man

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

---
Join us at C++Now 2020 in May!
Robin Kuzmin, CppNow Speaker Liaison, speakers@cppnow.org. Please
allow 2 - 4 days for my reply.

Robin Kuzmin, kuzmin.robin@gmail.com.
Please share your expert opinion about my recent posts:
* The Build System of My Dream (draft)
* Booleans

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

* Re: elf.5.html: Resolving confusion.
  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
  1 sibling, 0 replies; 4+ messages in thread
From: Michael Kerrisk (man-pages) @ 2019-12-12  7:00 UTC (permalink / raw)
  To: Robin Kuzmin; +Cc: linux-man

Hello Robin,

On Wed, 11 Dec 2019 at 21:19, Robin Kuzmin <kuzmin.robin@gmail.com> wrote:
>
> 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.  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 don't know, but if you have a clarification for the page, let me know.

Thanks,

Michael



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

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

* Re: elf.5.html: Resolving confusion.
  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
  1 sibling, 1 reply; 4+ messages in thread
From: Florian Weimer @ 2019-12-12 12:01 UTC (permalink / raw)
  To: Robin Kuzmin; +Cc: mtk, linux-man, mjw

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

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

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

Cc:ing Mark, in case he has further comments.

Thanks,
Florian


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

* Re: elf.5.html: Resolving confusion.
  2019-12-12 12:01 ` Florian Weimer
@ 2019-12-22 14:17   ` Mark Wielaard
  0 siblings, 0 replies; 4+ messages in thread
From: Mark Wielaard @ 2019-12-22 14:17 UTC (permalink / raw)
  To: Florian Weimer, Robin Kuzmin; +Cc: mtk, linux-man

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

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

end of thread, back to index

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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

Linux-man Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-man/0 linux-man/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-man linux-man/ https://lore.kernel.org/linux-man \
		linux-man@vger.kernel.org
	public-inbox-index linux-man

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-man


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git