search for: referencedsymbols

...he representation of a symbol (section+offset) can vary among passes. In the GC pass, its rule only works for simple expressions like --defsym d=foo, but not any slightly complex expressions. In lld, it would be difficult to drop the following rule in MarkLive.cpp: for (StringRef s : script->referencedSymbols) markSymbol(symtab->find(s)); The issue can be demonstrated by the following call tree: LinkerDriver::link markLive ... resolveReloc // Defined::section is nullptr for `d` because the assignment d=foo hasn't been evaluated yet. writeResult Writer<ELFT>::run...

...r .text_bar is retained; lld will retain .text_foo. > > For --defsym from=an_expression_with_to, GNU ld appears to add a > reference from 'from' to 'to'. lld's behavior > (https://reviews.llvm.org/D34195) is more conservative. > > If we stop treating script->referencedSymbols as GC roots, > instructions like `movabs $d, %rax` will no longer be able to access > the intended section. We can tweak our behavior to be like GNU ld, but > the additional complexity may not be worthwhile. I think it would be a step too far for defsym symbol=expression to have no effect...

LLD treats any symbol referenced from a linker script as a GC root, which makes sense. Unfortunately, it also processes --defsym as a linker script fragment internally, so all target symbols of a --defsym also get treated as GC roots (i.e., if you have something like --defsym SRC=TGT, TGT will become a GC root). I believe this to be unnecessary for defsym specifically, since you're just