[PATCH v2 1/2] bfd/ELF: restrict file alignment for object files

[Jan Beulich]

On 10.12.2024 11:46, Matthias Klose wrote:
> On 04.10.24 09:31, 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. Avoid passing "true" into
>> _bfd_elf_assign_file_position_for_section() when dealing with object
>> files, but compensate minimally by applying log_file_align in such
>> cases as a cap to the alignment put in place.
>> ---
>> RFC: Question is whether this minimal alignment shouldn't be applied in
>>       all cases, i.e. also when incoming "align" is "true".
>>
>> 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?
>> ---
>> v2: Replace heuristic in _bfd_elf_assign_file_position_for_section().
> 
> this causes PR gas/32435, a kernel build failure for arm-linux-gnueabihf.  Apparently the modpost tool in the kernel doesn't expect this change, and terminates with a bus error when modules are built with this change (when running an aarch64 kernel). Not sure where to fix that ...

Neither here nor in the bug you say which specific section(s) it is (are)
causing this effect. I wonder in particular whether the RFC remark still
in context above is related. I would have been suspecting .modinfo, but
that section, for the specific case mentioned in the bug, even end up
getting better alignment now.

That said, the diff in the bug doesn't appear to show anything that would
violate the ELF spec.

Jan