[PATCH] D38239: [ELF] - Define linkerscript symbols early.

[George Rimar via llvm-commits]

> I would suggest starting a new review with the attached patch and adding
> Peter and Teresa as reviewers as we could really use some help from a
> ThinLTO expert.

I'll do that.

>> Now if we use -defsym instead:
>> ld.lld first.o -defsym=bar=11 -o out
>> It links fine and result output contains ABS bar with value of 0xb.
>>
>> And it works only because defsym logic uses replaceSymbol<Defined>, so it replaces
>> already existent Defined symbol bar (from BC) instead of reporting multiple declaration.
>> If logic would use addDefined, it would fail.
>> That probably means that -defsym still does not work as "this makes the linkerscript defined symbol
>> just like .o defined symbols". And it is actually unclear for me why we should not just report error here.
>
>True, the linker script symbols are still somewhat special. We have to
>at least handling
>
>foo = 41
>foo += 1
>
>The ability to replace existing symbols seems intentional and was
>implemented in r291459 / D27276.

Yeah, my concerns are about -defsym still. 
LLD handles it just like script symbols. 
We are very different from GNU linkers. Difference blowing my mind sometimes.

To summarize:
1) If we have test.s with
.global foo
foo = 0x123

Then LLD can overload it with defsym:
ld.lld -defsym=foo=0x99 test.o -o test
(1: 0000000000000099     0 NOTYPE  GLOBAL DEFAULT  ABS foo)
and bfd can not:
ld.bfd  -defsym=foo=0x99 test.o -o test
multiple definition of `foo'

In that case ld.bfd behaves exactly like "-defsym makes foo to be symbol from .o". Which is very straightforward.
And we are breaking it. We already discussed it and came to conclusion it is fine.

Though probably if we would follow bfd logic for -defsym then I guess thinLTO logic would be fine.
(LTO see that have symbol that is redefined not prevealing and returns it so that linker can decide what to do with it,
report multiple definition or may be replace, like we could do for regular linker script symbols, for example). 
In that case current testcase breakage seems valid.

2) If we use both script and -defsym (one or multiple for the same symbol):
test.script:            
 foo = 0x26;             

and change order of -defsym and script in invocation:
linker -defsym=foo=0x77 -defsym=foo=0x99 --script test.script test.o -o test
linker  --script test.script -defsym=foo=0x77 -defsym=foo=0x99 test.o -o test

Then LLD always produce the same value, 0x99. Its because we always handle -defsym after script.
ld.bfd produces either 0x26 or 0x99 depending on order.

Technically I guess the last option should override others as it usually happens,
in that case LLD do wrong thing currently. It also atm breaks assumption that -defsym are just regular
linker script assignments, as we always handle them out of order.

George.