Re: Symbols defined via linker script: local or global?

[Alan Modra <amodra at gmail dot com>]

On Thu, Jul 07, 2016 at 07:56:19AM +0200, Sebastian Huber wrote:
> sorry for the delay. I have now a test case. It seems to be related to the
> --gc-sections option.

Indeed.  elf_gc_sweep_symbol is forcing the symbols local.  The
problem is that lang_gc_sections runs fairly early in the linking
process, before sections are laid out, and your script is defining
symbols inside output section statements.  Although
lang_do_assignments runs before lang_gc_sections, it doesn't descend
into output section statements.  That results in the assignments
"SC = .;" and "SD = .;" not being performed.  So SC, which was an
undefined symbol in your object file, stays undefined.  SD remains
unknown, until the "SF = SD;" assignment, where the reference makes it
an undefined symbol.  Somewhat oddly, this assignment doesn't put SF
into the symbol hash table (because the expression for its value
wasn't valid).  So when elf_gc_sweep_symbol runs, it sees SA and SB
defined, and SC, SD and SE undefined.  SF is unknown.  Even though SA,
SC and SE are referenced from your object file, their section is
discarded, and thus relocations in that section do not mark their
symbols.  elf_gc_sweep_symbol forces unmarked undefined symbols
local.

lang_do_assignments probably should descend into output section
statements, and all the fallout from not having a BFD section,
be fixed.

-- 
Alan Modra
Australia Development Lab, IBM