Currently, no one owns script::Parser buffers, but yet ELFLinkingContext gets
updated with StringRef pointers to data inside Parser buffers. Since this buffer
is locally owned inside GnuLdDriver::evalLinkerScript(), as soon as this
function finishes, all pointers in ELFLinkingContext that comes from linker
scripts get invalid. The problem is that we need someone to own linker scripts
data structures and, since ELFLinkingContext transports references to linker
scripts data, we can simply make it also own all linker scripts data.
Details
Diff Detail
Event Timeline
Adding a test might give more information on the functionality that you are trying to add too.
include/lld/ReaderWriter/ELFLinkingContext.h | ||
---|---|---|
311 | Why do you recognize the master linker script from the rest ? The linker can use more than one -T option to specify more than one linker script too. Input files that are linker scripts are positional too. For example : ld 1.o -lc Where libc.so is a linker script that needs to be handled in command line order. |
Hi Shankar,
Yes, but positional linker scripts are different because they do not
override the default linker script and are typically used just to add a
symbol assignment, a new search path or INPUT/GROUP commands (according to
https://sourceware.org/binutils/docs/ld/Implicit-Linker-Scripts.html#Implicit-Linker-Scripts
).
Is it possible to specify more than one -T? I didn't know. I was expecting
that a single script would override the default linker script. If there can
be multiple -T, I need to change this implementation and just add a bool to
tell "overides default linker script?".
All linker scripts with -T are concatenated. I am not totally certain on what gnu tries to solve here.
I agree that probably in the future we need to add a linker script to the linking context, so that later passes can interpret the linker scripts for their needs. Maybe it's not bad to do that.
But still the way that this patch is trying to do doesn't look good to me. We don't have to distinguish "master" and "implicit" linker scripts as far as I know. The signature of the addLinkerScriptInstance function looks a bit odd -- it always returns a given object to the caller, although the caller is of course knows what is passed to the function. Can we just add one function to the linking context, which takes a linker script and returns void, to transfer the ownership of a linker script?
Can we also eliminate ScriptInstance class? That's a wrapper for Lexer and Parser. If we modify Parser to own a lexer, we can directly use Parser instead of ScriptInstance, no?
I agree, we don't need a master linker script, Shankar was right in that we
can have multiple linker scripts with the -T option. I'll work on your
suggestions, they sound good to me.
Why do you recognize the master linker script from the rest ? The linker can use more than one -T option to specify more than one linker script too.
Input files that are linker scripts are positional too.
For example :
ld 1.o -lc
Where libc.so is a linker script that needs to be handled in command line order.