[Bug ld/21557] __start_SCN not provided if SCN used in linker script

[amonakov at gmail dot com]

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

--- Comment #2 from Alexander Monakov <amonakov at gmail dot com> ---
Thanks for the reference, I was missing that this handling is explicitly
limited to orphan sections. This makes my testcase invalid, but please consider
that current linker behavior appears inconsistent, for two separate reasons.

First, gc-sections considers these non-orphan sections reachable; taking the
testcase and linking it without '-z defs', with --gc-sections, you get:

$ ld.bfd -shared -o test.so test.o --gc-sections --print-gc-sections -T lds
<no output, section scnfoo was not garbage-collected>

But eliminating the reference from 'bar' allows it to be collected:

$ sed -i -e s/__start_scnfoo/undef/ test.s
$ gcc -c test.s
$ ld.bfd -shared -o test.so test.o --gc-sections --print-gc-sections -T lds
ld.bfd: Removing unused section 'scnfoo' in file 'test.o'

To the user this means that __start_scnfoo was virtually present when sections
were marked for garbage-collection, but not present for actual symbol
resolution.


Second, it implies there's no good way to use linker-scripts, --gc-sections and
__start_SCN together, even if one's use of linker scripts is limited to
rearranging sections. If one tries to manually provide __start_SCN:

SECTIONS {
        .dynamic : { *(.dynamic) }
        .data : { *(.data) }
        PROVIDE(__start_scnfoo = .);
        scnfoo : { *(scnfoo) }
}

... then it leads to scnfoo eliminated with --gc-sections because
__start_scnfoo no longer ties it to public symbol 'bar':

ld.bfd -shared -o test.so test.o --gc-sections --print-gc-sections -T lds
ld.bfd: Removing unused section 'scnfoo' in file 'test.o'

(with linker scripts it's possible to have output sections have different names
than input sections, this may cause ambiguity in what SCN __start_SCN should be
referring to; is that the reason why handling is limited to orphans?)

(it's not clear to me why bug status was set to WAITING, please clarify if
you'd like to see further clarifications, new bugreports for above issues, or
something else)

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