[PATCH] D38239: [ELF] - Define linkerscript symbols early.
George Rimar via llvm-commits
llvm-commits at lists.llvm.org
Tue Dec 26 06:12:03 PST 2017
>I experimented with keeping the symbols as Defined.
>
Thanks !
>The test changes I get seem an improvement:
>
>linker-script-symbols-assign.ll: The symbol foo is undefined. That is
>reasonable since there used definition is the one from the linker
>script.
>
>linker-script-symbols-ipo.ll: Address change.
>
>test/ELF/lto/defsym.ll: bar2 is undefined with regular lto. We get an
>error with thinlto, but I think the issue is in the thinlto
>implementation. It is producing a strong symbol we didn't ask for.
>
>In summary, this makes the linkerscript defined symbol just like .o
>defined symbols. They don't even need CanInline set to false, just
>--wrap symbols do.
>
>What do you think of this direction?
It is probably fine behavior (glad to hear about defsym.ll, I suspected something
is not ok with it, though was not sure).
I do not understand some implementation details though.
Why symbols do not need CanInline anymore ? Is it because of Prevailing flag ?
So does it mean that LTO will never try to inline symbols known to be defined in .o ?
(I would expect that it should not be problem to inline absolute symbols probably,
and in that case it would fail as values would be not final. Do not know details of how
LTO works..).
I noticed you're using Out::ElfHeader as section for Defined symbols and supposed that was
done to make them be non-absolute for some reason, but passing nullptr does not break anything it seems.
(defsym.ll still failing with "duplicate symbol: bar2")
Though currently with Out::ElfHeader following cast asserts for me, because Out::ElfHeader is an input section,
not output: https://github.com/llvm-mirror/lld/blob/master/ELF/SymbolTable.cpp#L441
Is section needed there for something unobvious ?
George.
More information about the llvm-commits
mailing list