We only support assignments inside SECTIONS, but this does not matches the behavior of GNU linker which also allows them outside SECTIONS. The only restriction on assignments outside SECTIONS is that they cannot reference . (they have to be absolute expressions).
Details
Diff Detail
Event Timeline
I'd rather ignore errors and evaluate . as 0 instead of adding the second parameter to many functions.
ELF/LinkerScript.cpp | ||
---|---|---|
662–664 | } else if (SymbolAssignment *Cmd = readProvideOrAssignment(Tok, false)) { |
Is the new version what you had in mind? Do you want to avoid completely ignoring errors, even if . is on the LHS? A different variant I've been also experimenting with is to change the Expr type to something like typedef std::function<uint64_t(optional<uint64_t>)> Expr; and when evaluating Dot inside getSymbolValue, throw an error when . is not available.
I'd even completely ignore the error and not try to make efforts to detect it. It is what we do for . in other contexts such as PHDRs addresses and section's AT command.
ELF/LinkerScript.cpp | ||
---|---|---|
1074–1075 | Please remove dead code. |
ELF/LinkerScript.h | ||
---|---|---|
70–72 | Let's remove this -- as I wrote in the previous comment, this is not an error we are detecting in other contexts, and it is okay to ignore them. I don't think it's a popular error, and it is "undefined behavior" (if there were the linker script language specification.) |
ELF/LinkerScript.h | ||
---|---|---|
70–72 | I believe we still need some way to recognize whether the assignment is inside SECTIONS or not to avoid modifying . in case it's not when assigning addresses inside assignAddress()? |
ELF/LinkerScript.h | ||
---|---|---|
70–72 | Users shouldn't write an assignment outside SECTIONS with . as the RHS, so I don't think we need to worry too much about it. |
ELF/LinkerScript.h | ||
---|---|---|
70–72 | The problem is if . is on LHS (in the assignment outside SECTIONS) because this will affect all subsequent assignments (even those within SECTIONS). |
ELF/LinkerScript.h | ||
---|---|---|
70–72 | Users shouldn't write . on LHS too, no? |
ELF/LinkerScript.h | ||
---|---|---|
70–72 | No they shouldn't, but if they do, shall we just produce incorrect output? I guess that's probably fine since we're not reporting error anyway? |
ELF/LinkerScript.h | ||
---|---|---|
70–72 | Please do nothing and let it just create incorrect outputs for incorrect inputs. We may want to do more fine-grained error checking in future, but at this moment, this error check would be too much compared to other error checks. There are many interesting ways to produce broken output using linker scripts, and we are not trying to stop them from shooting them in the foot. |
Let's remove this -- as I wrote in the previous comment, this is not an error we are detecting in other contexts, and it is okay to ignore them. I don't think it's a popular error, and it is "undefined behavior" (if there were the linker script language specification.)