Question on ELF extension: what's the rationale of choosing each marking constant?

Question on ELF extension: what's the rationale of choosing each marking constant?

[Daisuke HATAYAMA]

Hi Alan,

I have a question about rationale for ELF extension. Is there a
special meaning for each marking constant? ``each marking constant'' I
mean here is:
  - PN_XNUM(0xffff) for e_phnum,
  - 0 for e_shnum, and
  - SHN_XINDEX(0xffff) for e_shstrndx.

In my sense, PN_XNUM was chosen for e_phnum because it is nearest to
the real number within the range of what e_phnum can represent, and 0
for e_shnum because e_shoff shows section header table exists, and
choosing 0 prevents ordinary tools not supporting the ELF extension
from recognizing this. Also, I have no idea why SHN_XINDEX was chosen.

Is the consideration right? If not, could you tell me anything about
this?

I've questioned this to you because I saw your patch to this mailing
list, http://sourceware.org/ml/binutils/2001-12/msg00151.html, so I
guessed you know something to understand about this.

Thanks,
HATAYAMA Daisuke

Re: Question on ELF extension: what's the rationale of choosing each marking constant?

[Alan Modra]

On Fri, Jun 04, 2010 at 10:21:13AM +0900, Daisuke HATAYAMA wrote:
> I have a question about rationale for ELF extension. Is there a
> special meaning for each marking constant? ``each marking constant'' I
> mean here is:
>   - PN_XNUM(0xffff) for e_phnum,
>   - 0 for e_shnum, and
>   - SHN_XINDEX(0xffff) for e_shstrndx.
> 
> In my sense, PN_XNUM was chosen for e_phnum because it is nearest to
> the real number within the range of what e_phnum can represent, and 0
> for e_shnum because e_shoff shows section header table exists, and
> choosing 0 prevents ordinary tools not supporting the ELF extension
> from recognizing this. Also, I have no idea why SHN_XINDEX was chosen.
> 
> Is the consideration right? If not, could you tell me anything about
> this?

I don't recall that I had any say in the ELF extension for more than
64k sections, but if I had I would have made the same decisions.
If you want to extend a 16-bit field to store more than 64k values you
need to widen the field, but you can't do that if you want backwards
compatibility.  So you reserve one (or more) values to signify that
some other field holds the real value.  If your original field already
had reserved or unused values then one (or more) of those values is an
ideal choice to signify an extended field.  That is the case for
e_shnum, or at least, you would never see a zero in e_shnum when
e_shoff was non-zero.  The other fields don't have reserved values, so
the best choice is to hijack the least commonly used value.

-- 
Alan Modra
Australia Development Lab, IBM

Re: Question on ELF extension: what's the rationale of choosing each marking constant?

[Daisuke HATAYAMA]

From: Alan Modra <amodra@gmail.com>
Subject: Re: Question on ELF extension: what's the rationale of choosing each marking constant?
Date: Fri, 4 Jun 2010 17:29:18 +0930

> On Fri, Jun 04, 2010 at 10:21:13AM +0900, Daisuke HATAYAMA wrote:
>> I have a question about rationale for ELF extension. Is there a
>> special meaning for each marking constant? ``each marking constant'' I
>> mean here is:
>>   - PN_XNUM(0xffff) for e_phnum,
>>   - 0 for e_shnum, and
>>   - SHN_XINDEX(0xffff) for e_shstrndx.
>> 
>> In my sense, PN_XNUM was chosen for e_phnum because it is nearest to
>> the real number within the range of what e_phnum can represent, and 0
>> for e_shnum because e_shoff shows section header table exists, and
>> choosing 0 prevents ordinary tools not supporting the ELF extension
>> from recognizing this. Also, I have no idea why SHN_XINDEX was chosen.
>> 
>> Is the consideration right? If not, could you tell me anything about
>> this?
> 
> I don't recall that I had any say in the ELF extension for more than
> 64k sections, but if I had I would have made the same decisions.
> If you want to extend a 16-bit field to store more than 64k values you
> need to widen the field, but you can't do that if you want backwards
> compatibility.  So you reserve one (or more) values to signify that
> some other field holds the real value.  If your original field already
> had reserved or unused values then one (or more) of those values is an
> ideal choice to signify an extended field.  That is the case for
> e_shnum, or at least, you would never see a zero in e_shnum when
> e_shoff was non-zero.  The other fields don't have reserved values, so
> the best choice is to hijack the least commonly used value.

Thanks to your explanation, I understand I lacked the idea of the last
two lines.

Thanks.
HATAYAMA, Daisuke