[llvm-dev] [lld] Questions regarding linker scripts

Justin Cady via llvm-dev llvm-dev at lists.llvm.org
Thu Apr 22 11:00:08 PDT 2021


Hi,

I have two questions regarding lld behavior related to linker/version scripts.

1. It seems that lld does not strictly obey linker scripts, specifically regarding section collapsing. For example, a directive like this:

  SECTIONS
  {
    [...]
    .rela.text      : { *(.rela.text .rela.text.* .rela.gnu.linkonce.t.*) }
    [...]

I see no collapsing of these sections in the resulting object, with many .rela.text.<mangled_function_name> sections present. Is this expected behavior?


2. Regarding version scripts specifically, they are currently ignored for relocatable objects:

  https://github.com/llvm/llvm-project/blob/main/lld/ELF/Driver.cpp
  [...]
  // Apply version scripts.
  //
  // For a relocatable output, version scripts don't make sense, and
  // parsing a symbol version string (e.g. dropping "@ver1" from a symbol
  // name "foo at ver1") rather do harm, so we don't call this if -r is given.
  if (!config->relocatable) {
  [...]

I understand the motivation here from the perspective of actual symbol versioning. But an anonymous version script, for example:

{
  global: foo; bar;
  local: *;
}

...would still be useful for relocatable objects, I think. Without this capability, the only way I'm aware of to broadly apply symbol binding is to use objcopy after linking is complete. It can be prohibitively slow. But in fact, that's the approach that FreeBSD takes:

  https://github.com/freebsd/freebsd-src/blob/main/sys/conf/kmod.mk#L262
  https://github.com/freebsd/freebsd-src/blob/main/sys/conf/kmod_syms.awk

Is it reasonable to suggest allowing version scripts for relocatable objects, or providing an option to do so? (FYI I also tried using a VERSION section inside a larger linker script to no avail.)

Both of these behaviors of lld were surprising to me, and since they both relate to linker script input I decided to bundle my questions together.

Thank you for any insight,

Justin


More information about the llvm-dev mailing list