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

[Daisuke HATAYAMA <d dot hatayama at jp dot fujitsu dot com>]

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