This is the mail archive of the 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: RFC: Should .strtab and .shstrtab sections have the SHF_STRINGS flag ?

>   Should the ELF .strtab and .shstrtab sections be allowed to have the
>   SHF_STRINGS flag set ?
>   The Solaris linker currently does this, and I am wondering whether it
>   would be a good thing for our linker to do the same.  The logic of the
>   change is that both of these sections do contain nul terminated
>   strings, so setting the flag bit makes sense.  (It would also mean
>   that we could add an option to the strings program to only dump those
>   sections with the SHF_STRINGS flag bit set, thus possibly reducing the
>   amount of noise produced).
>   The counter argument as I see it, is that the current ELF spec says
>   that these sections do not have any flag bits set (.shstrtab) or just
>   the SHF_ALLOC bit (.strtab, when it is in a loadable segment).
>   But the SHF_STRINGS bit is an extension to the ELF specification, so
>   naturally its use would not be described in the spec.  What worries me
>   though is whether a .strtab or .shstrtab section with the SHF_STRINGS
>   flag bit set would be considered to be non-conforming by some other
>   tool.

SHF_STRINGS *is* part of the ELF spec (yes, it was an extension, but
it was adopted in the gABI 17 years ago).

I don't think there would be anything wrong with setting that bit in
those sections, but the flag is really there for SHF_MERGE sections.
An argument could be made that .strtab and .shstrtab should also have
SHF_MERGE set, but it's not really necessary since those sections
already have special types and the tools already know exactly what
kind of sections they are and how to process them.

Perhaps the gABI could use some clarification to the effect that
SHF_MERGE and SHF_STRINGS are intended for SHT_PROGBITS sections only,
or that the flags are optional (and implied) for SHT_STRTAB sections.
(The former would invalidate what Solaris is doing, while the latter
would allow it.)

(Now that I think about it, I wonder why we didn't just use SHT_STRTAB
for merge string sections in the first place.)


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