[PATCH 3/4] ELF: SHF_STRINGS isn't really tied to SHF_MERGE

[Fangrui Song]

On Fri, Jan 17, 2025 at 3:57 AM Richard Earnshaw (lists)
<Richard.Earnshaw@arm.com> wrote:
>
> On 17/01/2025 11:24, Jan Beulich wrote:
> > On 17.01.2025 12:13, H.J. Lu wrote:
> >> It is very undesirable to require changing existing assembly codes
> >> in the real world.  We shouldn't make such assembler changes.
> >> It may be OK for the assembler to issue a warning.  But it should
> >> keep generating correct and working object files.
> >
> > With "working" then meaning something other than "being spec compliant"?
> > Any consumer may legitimately expect spec compliant objects, and error
> > out otherwise. What we did produce before wasn't spec compliant, and
> > hence according to my reading not "working". Something needs to be done
> > about situations like this; it's wrong to leave tools broken just
> > because they have always been broken. It's merely a matter of determining
> > which of perhaps multiple possible approaches may cause the least
> > fallout. All I can do here is encourage people to pay more attention to
> > patches being posted.
> >
> > Jan
>
> It turns out that it's even worse than I thought.  Old versions of gas
> reject any attempt to specify an entity size, so we cannot, as things
> stand, create a source file that can be assembled with both current and
> existing versions of gas.
>
> Eg: try
>
>         .section .str1,"S"
>         .asciz "abc"
>         .section .str2,"S",1
>         .asciz "def"
>         .section .str4,"S",%progbits , 2
>         .short 32, 0
>
> $ as --version
> GNU assembler (GNU Binutils for Ubuntu) 2.38
>
> $ as -o /tmp/x.o string.s
> string.s: Assembler messages:
> string.s:3: Error: junk at end of line, first unrecognised character is `,'
> string.s:5: Error: junk at end of line, first unrecognised character is `,'
>
> $ as-new --version
> GNU assembler (master) 2.43.50.20250117
>
> $ as-new -o /tmp/x.o string.s
> string.s: Assembler messages:
> string.s:1: Warning: entity size for SHF_MERGE / SHF_STRINGS not specified
>
> So I think we have to fix this by silently defaulting the entity size.
> Otherwise there's no safe way forward for existing code.
>
> R.

This is the first instance I've encountered of SHF_STRINGS used
without SHF_MERGE.
Neither GCC nor Clang appear to generate this.
The LLVM linker simply ignores SHF_STRINGS when SHF_MERGE is not present.

For `.section foo,"S"`, traditional gas silently sets sh_entsize to 0,
which doesn't look great.

> SHF_STRINGS - The data elements in the section consist of null-terminated character strings. The size of each character is specified in the section header's sh_entsize field

(Linkers might set sh_entsize as well, but it seems that the rules are
more stringent for linker input (e.g. relocatable files) in practice.)

Given this, assembly files set S but not M with traditionally gas look
fishy to me.
I acknowledge that this change might cause some disruption for those
maintaining the existing codebase,
but I want to state that a warning makes a lot of sense.

Frankly, implicit sh_entsize=1 for the S without M case feels like
adding justification for questionable code patterns in the first
place...