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.
