bug-binutils
[Top][All Lists]
Advanced

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

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


From: nickc at redhat dot com
Subject: [Bug ld/26404] ld: INSERT [AFTER|BEFORE] variant for extension purposes
Date: Thu, 17 Sep 2020 10:14:51 +0000

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

Nick Clifton <nickc at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nickc at redhat dot com

--- Comment #2 from Nick Clifton <nickc at redhat dot com> ---
(In reply to Fangrui Song from comment #0)
[Sorry for not commenting on this PR earlier...]

Currently linker script fragments specified on the command
line override any conflicts with the built-in script, right ?
So how about:

  Suggestion (d):
   A new command line option to tell the linker that the
   argument is a script fragment that extends the built-in
   script.  eg:

     % cat extend.t
     SECTIONS {
         .data : { KEEP (*.foo) }
     }

     % ld --extension-script extend.t hello.o

  In this scenario any .foo sections from the input files
  will be added to the .data output section, *and* all the
  normal input data sections (.data, .data1, etc) will also 
  be added to the output .data section.

This has the advantage that no new linker script syntax is needed
and the command line is more readable.  (Compared to just placing
the script name on the command line without an option, which I
always find to be confusing).

Cheers
  Nick




The linker already supports augmenting the built-in script via the 
addition of script fragments on the command line, right ?  
not just use that facility.  Eg:


> * Suggestion (a)
> 
>   EXTEND SECTIONS { // another keyword can be used, e.g. OVERRIDE

> * 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.


reply via email to

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