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

[Matthias Klose]

On 10.12.24 12:02, Jan Beulich wrote:
> 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.

I don't know. I have forwarded that to our kernel people who saw that 
issue in the first place.

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

right, I said "Not sure where to fix that ..."

Matthias