[Bug ld/26404] New: ld: INSERT [AFTER|BEFORE] variant for extension purposes

[i at maskray dot me]

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

            Bug ID: 26404
           Summary: ld: INSERT [AFTER|BEFORE] variant for extension
                    purposes
           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: ---

`SECTIONS { ... } INSERT [AFTER|BEFORE]` complements the internal linker
script.

This is nice: because in many cases the internal one works quite well and the
user does not want to reset the internal linker script.  Users tend to leverage
this property to provide extensions to the internal linker script.

However, the section anchor after [AFTER|BEFORE] makes extensions somewhat
cumbersome: there may not be a suitable anchor or the user just does
not want to set an anchor. The default orphan placement works well.

On one occasion, I've seen a user who wants to write:

  .note.gnu.build-id : {
    PROVIDE_HIDDEN (__build_id_start = . + 16);
    *(.note.gnu.build-id)
    PROVIDE_HIDDEN (__build_id_end = .);
  }
  // __build_id_start / __build_id_end delimiters the build ID payload (16 is
  // the size of the note header)


On another occasion, a user wants to assign some sections KEEP semantics
(https://sourceware.org/binutils/docs/ld/Input-Section-Keep.html#Input-Section-Keep)
but does not want to provide an external linker script.


I have sympathy with both feature requests but cannot convince myself that the
use cases are beyond the ad-hoc category. A natural generalization is that we
can have a syntax similar to INSERT [AFTER|BEFORE] but does not require an
anchor.

About the syntax,

* Suggestion (a)

  EXTEND SECTIONS { // another keyword can be used, e.g. OVERRIDE
    .foo : { KEEP(*(.foo)) }
    .bar : { KEEP(*(.bar)) }
    sym = .;   // symbol assignments are disallowed
  }
  // What if the internal linker script defines .foo as well?

* Suggestion (b)

  SECTIONS {
    .foo : { KEEP(*(.foo)) }
    .bar : { KEEP(*(.bar)) }
    sym = .;   // symbol assignments are disallowed
  } EXTEND;

* Suggestion (c)

  SECTIONS {
    .foo : { KEEP(*(.foo)) }
    .bar : { KEEP(*(.bar)) }
  } REPLACE .data;
  // If the internal linker script defines .data, replace it with the content
in
  // the braces. Otherwise, treat .foo and .bar as orphans?

---

Some properties and edge cases need thoughts, e.g.

* It had better not interfere with normal orphan placement.
* When an output section is described by both the internal linker script and
the
  external one, what should happen? For INSERT, the interaction is currently
undocumented. It seems that the internal one is applied first, followed by the
description from INSERT AFTER|BEFORE, e.g.

    SECTIONS { .data : { data_begin = .; *(.data) }} INSERT BEFORE .bss;
    // place .data.* into .data because the internal description does so.

    SECTIONS { .data : { data_begin = .; *(.data) *(.data1) }} INSERT BEFORE
.bss;
    // place .data1 into .data

---

For the two feature requests, I think they don't need to define semantics when
there is a collision. The important thing is to have a syntax (not getting in
the way in the future). The collision cases can be considered "undefined
behaviors" for now.

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