[PATCH v2] elf: Keep SHT_NULL sections for objcopy

H.J. Lu hjl.tools@gmail.com
Mon Jun 30 00:22:21 GMT 2025


On Sun, Jun 29, 2025 at 9:30 PM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 29.06.2025 09:56, H.J. Lu wrote:
> > Some linkers generate SHT_NULL sections in executable and shared
> > library:
> >
> > 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
> >
> > We must keep SHT_NULL sections in executable and shared library if there
> > is a non-empty SHT_DYNSYM section since removing them may change section
> > indexes in SHT_DYNSYM section.
>
> Question: Why would it every be okay to remove / re-use them? IOW
> shouldn't we unconditionally keep them?
>

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.  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.
(assign_file_positions_for_load_sections): Don't change lma of
SHT_NULL sections.

binutils/

PR binutils/33119
* objcopy.c (copy_object): Set keep_SHT_NULL_type on output bfd.
Clear and set keep_SHT_NULL_type on output bfd before and after
sections are added.
(setup_section): Clear keep_SHT_NULL_type on output bfd when
changing section flags.
* testsuite/binutils-all/x86-64/pr33119.so.bz2: New file.
* testsuite/binutils-all/x86-64/x86-64.exp (run_pr33119_test):
New.
Run run_pr33119_test.

OK for master?

Thanks.

--
H.J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: v2-0001-elf-Keep-SHT_NULL-sections-for-objcopy.patch
Type: application/x-patch
Size: 24116 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20250630/9ddd8391/attachment-0001.bin>


More information about the Binutils mailing list