bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug ld/25021] New: Garbage collecting non-alloc SHF_LINK_ORDER sections


From: i at maskray dot me
Subject: [Bug ld/25021] New: Garbage collecting non-alloc SHF_LINK_ORDER sections
Date: Thu, 19 Sep 2019 15:47:27 +0000

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

            Bug ID: 25021
           Summary: Garbage collecting non-alloc SHF_LINK_ORDER sections
           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: ---

clang -fstack-size-section emits a non-alloc SHF_LINK_ORDER section
.stack_sizes linking to .text

  [ 2] .text             PROGBITS        0000000000000000 000040 000006 00  AX 
0   0 16
  [ 3] .stack_sizes      PROGBITS        0000000000000000 000046 000009 00   L 
2   0  1

Below is a hypothetical -ffunction-sections -fstack-size-section output.
The contents of .stack_sizes are irrelevant to the feature request, so
arbitrary .byte 1 and .byte 2 are used.

# a.s
.section .text.live,"ax",@progbits
.globl live
live:
 nop

# "o" is an llvm-mc extension that sets the SHF_LINK_ORDER flag and sets
sh_link to the referenced section number.
.section .stack_sizes,"o",@progbits,.text.live,unique,0
.byte 1

.section .text.dead,"ax",@progbits
.globl dead
dead:
 nop

.section .stack_sizes,"o",@progbits,.text.dead,unique,1
.byte 2

.section .text.main,"ax",@progbits
.globl _start
_start:
  callq live@PLT


llvm-mc -filetype=obj -triple=x86_64 a.s -o a.o
ld.bfd --gc-sections a.o -o a.bfd   # size(.stack_sizes) = 2
ld.lld --gc-sections a.o -o a.lld   # size(.stack_sizes) = 1

As the result shows, lld can garbage collect non-SHF_ALLOC sections.
The rule is: a non-SHF_ALLOC section is discarded if it has the SHF_LINK_ORDER
flag and its sh_link references a discarded section.

I havn't found other examples leveraging non-alloc SHF_LINK_ORDER sections in
the wild.
Just wanted to ask: is this garbage collecting rule GNU linkers want to have as
well?

The "Possible Duplicates" feature suggested that I posted a related feature
request a few months ago. https://sourceware.org/bugzilla/show_bug.cgi?id=24526
It'd be nice to have feedback on that as well.

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]