SECTIONS doesn't seem to be implemented ?

[dcb314]

Package kvm-unit-tests seems to have a linker script as follows:

SECTIONS
{
. = 4M + SIZEOF_HEADERS;
stext = .;
.text : { *(.init) *(.text) (.text.) }
. = ALIGN(4K);
.data : {
*(.data)
exception_table_start = .;
*(.data.ex)
exception_table_end = .;
}
. = ALIGN(16);
.rodata : { *(.rodata) }
. = ALIGN(16);
.bss : { *(.bss) }
. = ALIGN(4K);
edata = .;
}

ENTRY(start)

mold says:

mold: /home/dcb35/rpmbuild/BUILD/kvm-unit-tests-1edfa966328dfc824e9b0351087bbfaf699dce04/x86/flat.lds:1: SECTIONS
^ unknown linker script token

[rui314]

SECTIONS linker script command is intentionally left out. Besides INPUT, GROUP and the like, I don't think we want to support any linker script command.

[Alcaro]

"unknown linker script token" looks like a bug. If it's intentional, maybe change it to something like "SECTIONS command is unimplemented, please use lld for full linker script support".

[rui314]

Good point! Will do.

[BenBE]

Not implementing the SECTION command breaks (m)any usecases that involve building firmware images for embedded systems. E.g., linking firmware for the STM32 MCU family relies on a custom linker script that's basically (with some slight modifications based on the controller):

ENTRY(Reset_Handler)

MEMORY
{
  RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 96K
  RAM2 (xrw) : ORIGIN = 0x10000000, LENGTH = 32K
  FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 1024K
}

SECTIONS
{
  .isr_vector : {
    . = ALIGN(8);
    KEEP(*(.isr_vector)) /* Startup code */
    . = ALIGN(8);
  } >FLASH

  .text : {
    . = ALIGN(8);
    *(.text)
    *(.text*)
    *(.glue_7)
    *(.glue_7t)
    *(.eh_frame)
    KEEP (*(.init))
    KEEP (*(.fini))
    . = ALIGN(8);
    _etext = .;
  } >FLASH

  .rodata : {
    . = ALIGN(8);
    *(.rodata)
    *(.rodata*)
    . = ALIGN(8);
  } >FLASH

  /* other sections */
  
  .init_array : {
    . = ALIGN(8);
    PROVIDE_HIDDEN (__init_array_start = .);
    KEEP (*(SORT(.init_array.*)))
    KEEP (*(.init_array*))
    PROVIDE_HIDDEN (__init_array_end = .);
    . = ALIGN(8);
  } >FLASH

  .fini_array : {
    . = ALIGN(8);
    PROVIDE_HIDDEN (__fini_array_start = .);
    KEEP (*(SORT(.fini_array.*)))
    KEEP (*(.fini_array*))
    PROVIDE_HIDDEN (__fini_array_end = .);
    . = ALIGN(8);
  } >FLASH

  _sidata = LOADADDR(.data);

  .data : {
    . = ALIGN(8);
    _sdata = .;
    *(.data)
    *(.data*)

    . = ALIGN(8);
    _edata = .;
  } >RAM AT> FLASH

  . = ALIGN(4);
  .bss :
  {
    _sbss = .;
    __bss_start__ = _sbss;
    *(.bss)
    *(.bss*)
    *(COMMON)
    . = ALIGN(4);
    _ebss = .;
    __bss_end__ = _ebss;
  } >RAM

  . = ALIGN(4);
  .ram2 : {
    _sram2 = .;
    __ram2_start__ = _sram2;
    *(.ram2)
    *(.ram2*)

    . = ALIGN(4);
    _eram2 = .;
    __ram2_end__ = _eram2;
  } >RAM2

  ._user_heap_stack : {
    . = ALIGN(8);
    PROVIDE ( end = . );
    PROVIDE ( _end = . );
    . = . + _Min_Heap_Size;
    . = . + _Min_Stack_Size;
    . = ALIGN(8);
  } >RAM

  /* Remove information from the standard libraries */
  /DISCARD/ : {
    libc.a ( * )
    libm.a ( * )
    libgcc.a ( * )
  }
}

[dcb314]

Not implementing the SECTION command breaks (m)any usecases that involve building firmware images for >embedded systems.

Quite possibly. I checked all of the more than 7,000 packages in Fedora Linux and I could find only one
package that required the feature.

[BenBE]

For normal package builds on some host OS you're likely very fine without SECTION support. Only when you need to produce image files that can be flashed onto some embedded MCU like Atmel/STM¹ series you'll encounter the toolchains to use this kind of processing.

So while I don't see the feature on the top priority list of things, I'd at least suggest to keeping it in mind for further mid-term development.

---

¹ GNU ARM Embedded Toolchain ↩

[kleinesfilmroellchen]

SerenityOS's kernel linker script also uses sections, however not in a complex way. As far as I can tell, this way of using SECTIONS is well parallelizable and could benefit from mold as well.

FWIW, SerenityOS's userspace doesn't benefit from mold by any measurable degree. There's a lot of dynamically linked binaries and libraries (all libs&bins in userspace are dynamically linked) and the existing parallelization is enough to negate the mold linking benefit currently. The Kernel as the only statically linked large binary could benefit a lot from mold.

[tigercat2000]

This also prevents building the Linux kernel, see module.lds.S

Not that you really need parallel linking for the kernel, it takes a few seconds on modern hardware with lld. I just thought it was an interesting use-case that the lack of SECTIONS support affects.

[rui314]

SECTIONS command is the core of the linker script functionality and core of its complexity. I want to implement a feature that can replace the usage of the linker script. One idea is explained here: https://www.reddit.com/r/programming/comments/p1ad4v/mold_a_modern_linker/h8e2jvs/?utm_source=reddit&utm_medium=web2x&context=3

[jobbautista9]

FYI, this bug is preventing our Mozilla fork (which the Pale Moon browser uses) from using the mold linker. It immediately fails when it goes on to link libxul.so:

1672653579.086131 mold: fatal: ../../../../platform/toolkit/library/StaticXULComponents.ld:1: SECTIONS {}
1672653579.086401                                                                      ^ unknown linker script token
1672653579.086662 collect2: error: ld returned 1 exit status
1672653579.086924 gmake[5]: *** [/home/job/Software/uxp-work/platform/config/rules.mk:773: libxul.so] Error 1
1672653579.087187 gmake[4]: *** [/home/job/Software/uxp-work/platform/config/recurse.mk:71: toolkit/library/target] Error 2
1672653579.087451 gmake[3]: *** [/home/job/Software/uxp-work/platform/config/recurse.mk:33: compile] Error 2
1672653579.087725 gmake[2]: *** [/home/job/Software/uxp-work/platform/config/rules.mk:494: default] Error 2
1672653579.087987 gmake[1]: *** [/home/job/Software/uxp-work/palemoon/client.mk:406: realbuild] Error 2
1672653579.088244 gmake: *** [client.mk:164: build] Error 2

[rui314]

@jobbautista9 Do you know why your program contains the empty SECTIONS directive?

[jobbautista9]

It isn't actually empty; according to toolkit/library/libxul.mk, this SECTIONS directive gets filled when the linker is bfd:

# BFD ld doesn't create multiple PT_LOADs as usual when an unknown section
# exists. Using an implicit linker script to make it fold that section in
# .data.rel.ro makes it create multiple PT_LOADs. That implicit linker
# script however makes gold misbehave, first because it doesn't like that
# the linker script is given after crtbegin.o, and even past that, replaces
# the default section rules with those from the script instead of
# supplementing them. Which leads to a lib with a huge load of sections.
ifneq (OpenBSD,$(OS_TARGET))
ifneq (WINNT,$(OS_TARGET))
ifdef LD_IS_BFD
OS_LDFLAGS += $(topsrcdir)/toolkit/library/StaticXULComponents.ld
endif
endif
endif

And the SECTIONS directive when BFD is detected:

SECTIONS {
  .data.rel.ro : {
    *(.kPStaticModules)
  }
}

This seems to be something we've inherited from Mozilla when we initially forked from mozilla-central 52.6.0: https://bugzilla.mozilla.org/show_bug.cgi?id=938437

Mozilla has moved on from this SECTIONS solution in bug 1541792.

I'm not sure if we can backport this to the platform, and considering that Mozilla seems to have done this to reduce memory overhead for creating a new process (which is a problem we don't have because we intentionally don't use multi-process or e10s as they call it), I think it's unlikely we will do something about this SECTIONS directive.

Now I don't know if it's possible to have it not put a SECTIONS directive at all instead of putting an empty one if it doesn't detect bfd. I'm admittedly not that familiar with linker stuff...

[rui314]

That particular piece of linker script is to mark the .kPStaticModules section into read-only section after process initialization. Can you locate the location in your code where the .kPStaticModules is added? If so, by renaming .kPStaticModules.rel.ro, you can do the same without using the linker script.