[Bug ld/27451] New: ld: Provide a way to make C identifier name sections GCable under __start_/__stop_ references

[i at maskray dot me]

https://sourceware.org/bugzilla/show_bug.cgi?id=27451

            Bug ID: 27451
           Summary: ld: Provide a way to make C identifier name sections
                    GCable under __start_/__stop_ references
           Product: binutils
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: ld
          Assignee: unassigned at sourceware dot org
          Reporter: i at maskray dot me
  Target Milestone: ---

The discussion below is about C identifier name sections.

>From my observation, GNU ld currently has a rule:

  __start_/__stop_ references from a live section retain all the associated C
identifier name sections.

In the following example, __start_meta reference retains both a.o:(meta) and
b.o:(meta).

  # a.s
  .global _start
  .text
  _start:
    leaq __start_meta(%rip), %rdi
    leaq __stop_meta(%rip), %rsi

  .section meta,"a"
  .byte 0

  # b.s
  .section meta,"a"
  .byte 1

In LLD, we have augmented the rule with SHF_LINK_ORDER and SHF_GROUP (after
https://reviews.llvm.org/D96753, target release 13.0.0):

  __start_/__stop_ references from a live section retain all the associated
non-SHF_LINK_ORDER non-SHF_GROUP C identifier name sections.

At this point, some LLVM toolchain folks have concluded that the original rule
does not cary its weight, and I actually have a thought to drop it:

  __start_/__stop_ references from a live section do not retain the associated
C identifier name sections.

  Either use undefined weak __start_/__stop_, or ensure there is at least one
live C identifier name section to avoid "undefined symbol" errors.

There are more details in the "Metadata sections referenced by text sections"
section of
https://maskray.me/blog/2021-01-31-metadata-sections-comdat-and-shf-link-order

There is good chance that not many OSS need adaptation (I have tested thousands
and only swift/systemd have issues.)
I understand that there are still risks, so we may need a linker option to drop
the original rule.

__start_/__stop_ is currently ELF specific, so the option is assumed to be
under -z.
Given https://sourceware.org/pipermail/binutils/2020-June/111685.html "-z
start-stop-visibility=",
we can probably name it -z start-stop-something, e.g.  -z start-stop-gc and -z
nostart-stop-gc.

The option decides whether non-SHF_LINK_ORDER non-SHF_GROUP C identifier name
sections are retained with __start_/__stop_ references.
For SHF_LINK_ORDER or SHF_GROUP sections, it seems that should always be
GCable.

There is a possibility that LLD may switch to default -z start-stop-gc. This
move can be harder for GNU ld because of stronger commitment with existing
behaviors.
(I have asked ClangBuiltLinux folks to test the Linux kernel
https://github.com/ClangBuiltLinux/linux/issues/1307 . I have tested x86-64
defconfig myself and it works.

-- 
You are receiving this mail because:
You are on the CC list for the bug.