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

[Richard Earnshaw (lists)]

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.