This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]