[PATCH RFC] bfd/ELF: restrict file alignment for object files

[Jan Beulich]

On 09.09.2024 14:02, Richard Earnshaw (lists) wrote:
> On 23/08/2024 11:28, Jan Beulich wrote:
>> While for executables properly aligning sections within the file can be
>> quite relevant, the same is of pretty little importance for relocatable
>> object files. However, compensate this a little for sections with fixed
>> entry sizes, such that they're at least aligned to what conceivably is
>> the granularity within those elements (allowing e.g. REL/RELA sections
>> to still be mmap()-ed and then accessed without needing to deal with
>> mis-alignment of fields).
>> ---
>> RFC: Question is whether some minimal alignment (e.g. the architecture's
>>      word size) should still be retained, then perhaps replacing the
>>      sh_entsize special treatment. Else question is whether e.g. the
>>      symbol tables can also be written at misaligned file positions
>>      (assuming the sh_entsize-based alignment then also would be left
>>      out).
>>
>> The Arm64 test being adjusted has an imo misleading name: I first
>> thought I broke something. Only when going back to the commit that
>> introduced it, I found that the test is about the _absence_ of tail
>> padding. Would people mind if I inserted e.g. "no" on the #name line?
> 
> How would that affect linking of something like
> 
> object1.s
> 
> .text
> .p2align 2
> 	.inst 0
> 	.byte 1
> 
> object2.s
> .text
> // .p2align 2 missing
> 	.inst 2
> 
> Historically the second object has been correctly padded out to the correct alignment and I think changing this now would cause quite a bit of breakage.

There are two different kinds of padding involved here: What the patch
changes is what (really: whether / how much) padding is inserted in the
file, outside of any sections represented by the file. What you're
talking about is padding inside sections (inserted by gas and/or the
linker). That isn't (supposed to be) altered by this change.

Jan