[PATCH v2] elf: Keep SHT_NULL sections for objcopy

[Jan Beulich]

On 30.06.2025 02:22, H.J. Lu wrote:
> ELF assembler and linker initialize unknown section type to SHT_NULL
> since when the section type is initialized, BFD doesn't know what the
> final section type will be.  Since the final section type is determined
> by assembler and linker based on input information later, we can't keep
> SHT_NULL section type as is.
> 
> 1. Always keep SHT_NULL sections when creating BFD sections from ELF
> input.  GNU assembler and linker will create only a single SHT_NULL
> section.

Building on this (current) behavior feels fragile.

>  But some linkers generate multiple SHT_NULL sections:
> 
> Section Headers:
>   [Nr] Name              Type             Address           Offset
>        Size              EntSize          Flags  Link  Info  Align
>   [ 0]                   NULL             0000000000000000  00000000
>        0000000000000000  0000000000000000   A       0     0     0
>   [ 1] .phdr             NULL             0000000000000040  00000040
>        0000000000000000  0000000000000000   A       0     0     0
>   [ 2] .shdr             NULL             0000000000000238  00000238
>        0000000000000000  0000000000000000   A       0     0     0
>   [ 3] .note.gnu.pr[...] NOTE             0000000000000938  00000938
> ...
>  Section to Segment mapping:
>   Segment Sections...
>    00
>    01     .phdr .shdr .note.gnu.property .gnu.hash .dynsym .dynstr .gnu.version
> .gnu.version_r .rela.dyn .rodata .eh_frame_hdr .eh_frame
> 
> Removing these SHT_NULL sections may change section indexes in SHT_DYNSYM
> section.
> 
> 2. Add a keep_SHT_NULL_type field to bfd.  If it is set, SHT_NULL type
> is kept.  Objcopy clears keep_SHT_NULL_type when sections are added or
> section flags are changed.
> 
> bfd/
> 
> PR binutils/33119
> * bfd-in2.h: Regenerated.
> * bfd.c (bfd): Add keep_SHT_NULL_type.
> * elf.c (bfd_section_from_shdr): Always keep SHT_NULL sections.
> (elf_fake_sections): Keep SHT_NULL section type if
> keep_SHT_NULL_type is set.

I fear I'm still not following. The only time elf_fake_sections() is
used is from _bfd_elf_compute_section_file_positions(). How does that
fit with the toggling of the new flag in 4 places? Oh, the function
is called not only from _bfd_elf_write_object_contents(), but also
from _bfd_elf_set_section_contents(). That's another dependency (of
objcopy on a libbfd implementation detail) that I view as potentially
problematic going forward.

And how do pre-existing SHT_NULL sections in an object interact with
sections being added? The new testcase doesn't cover that case, yet
afaict _bfd_elf_compute_section_file_positions()'es looping over
elf_fake_sections() would cause all SHT_NULL sections to have their
type updated, not just the one(s) being added.

It also feels like a layering violation to put an ELF-specific flag
in struct bfd. But as per above, it looks to me as if this needs to
be a per-section flag anyway. If it was objcopy alone, keying off of
SEC_LINKER_CREATED might be an option, yet while that might then also
fit ld, it likely wouldn't fit gas.

>From a more abstract perspective it looks bogus to me in the first
place to introduce SHT_NULL sections at all into the system, even if
only transiently.

Jan