This is an archive of the discontinued LLVM Phabricator instance.

[ELF] - Linker script expressions, ASSERT() command.
AbandonedPublic

Authored by grimar on Feb 5 2016, 7:05 AM.

Details

Summary

This patch implements linker script expressions and also ASSERT() command (is used to check the results for this patch).
Currently I think all possible operators are supported: ^, *, /, +, -, <<, >>, &, |, (, ), +=, -=, *=, /=, <<=, >>=, &=, |=.

This gives ability to assign values to variables and perform different calculations.
Sample of what is possible to do (test.script):

x = 1 + 2 * 3 - (4 - 5) ^ 1;
y = x << 2 & x | 15;
z = (((x + y) - x) + y) * 2;
x <<= (y + z / y);
x >>= (16 & 17);
x &= 0x7F;
x /= (0x1278 - 4696);
c = 1 >> 1;
ASSERT(x - c, "Custom error text");

This will error out "Custom error text" as "x-c" expression gives 0 after evaluation here.
Test cases for all operations are provided.

Diff Detail

Event Timeline

grimar updated this revision to Diff 47015.Feb 5 2016, 7:05 AM
grimar retitled this revision from to [ELF] - Linker script expressions, ASSERT() command..
grimar updated this object.
grimar added reviewers: ruiu, rafael.
grimar added subscribers: llvm-commits, grimar.
grimar updated this object.Feb 5 2016, 7:16 AM
emaste added a subscriber: emaste.Feb 5 2016, 8:13 AM
ruiu edited edge metadata.Feb 5 2016, 10:34 AM

Hi George,

This is probably too much at this moment. I'm not sure if we want to support ASSERT, but even if we want it, it is something we could add as a final step to complete the linker script support (until that point, we will have everything, so adding ASSERT would be very easy.) The expressions in ASSERT is the features users would use in other contexts. Because that is not plugged in to anywhere in your patch, your patch doesn't demonstrate that that would work for a minimal use case.

If you want to start working on the linker script support, can you start from writing a proposal about the overall design? It needs to be simple, easy to implement, and fast. I have a few ideas for that, but I don't have enough time to think deeply about them. Feel free to discuss your idea with me.

davide added a subscriber: davide.Feb 5 2016, 10:58 AM

100% agree. I'd also like to point out that even very complex linker scripts (as the one used by kernels) don't rely on this feature. I'm strongly opposed to see this in until some real consumer shows up. I'm in general opposed to having any linker script directive parsed properly until there's a real use case.
I can't stress enough that I'm disturbed by how badly linker script language "specification" evolved over time.

davide requested changes to this revision.Feb 5 2016, 10:59 AM
davide added a reviewer: davide.
This revision now requires changes to proceed.Feb 5 2016, 10:59 AM

As a point of reference here's the FreeBSD kernel amd64 linker script: https://svnweb.freebsd.org/base/head/sys/conf/ldscript.amd64?view=co

In D16924#345138, @ruiu wrote:

Hi George,

This is probably too much at this moment. I'm not sure if we want to support ASSERT, but even if we want it, it is something we could add as a final step to complete the linker script support (until that point, we will have everything, so adding ASSERT would be very easy.) The expressions in ASSERT is the features users would use in other contexts. Because that is not plugged in to anywhere in your patch, your patch doesn't demonstrate that that would work for a minimal use case.

If you want to start working on the linker script support, can you start from writing a proposal about the overall design? It needs to be simple, easy to implement, and fast. I have a few ideas for that, but I don't have enough time to think deeply about them. Feel free to discuss your idea with me.

I didn`t want to support ASSERT, just had no idea how to check correctly that evaluations works and ASSERT was just simple solution to implement in context of this patch for validation purposes. I hoped to use the expressions in futher calculations, for example for location counter support. Thats why it is not plugged to anywhere else.
Probably you're right that overall design is the first step.

100% agree. I'd also like to point out that even very complex linker scripts (as the one used by kernels) don't rely on this feature. I'm strongly opposed to see this in until some real consumer shows up. I'm in general opposed to having any linker script directive parsed properly until there's a real use case.
I can't stress enough that I'm disturbed by how badly linker script language "specification" evolved over time.

Real use case for expressions is everywhere in linkerscript. ASSERT was implemented just for validation of results.

100% agree. I'd also like to point out that even very complex linker scripts (as the one used by kernels) don't rely on this feature. I'm strongly opposed to see this in until some real consumer shows up. I'm in general opposed to having any linker script directive parsed properly until there's a real use case.
I can't stress enough that I'm disturbed by how badly linker script language "specification" evolved over time.

Real use case for expressions is everywhere in linkerscript. ASSERT was implemented just for validation of results.

Sure. Expressions are used. My point is that it's better to support a subset of operators (at least in the beginning) rather than the whole set. If you look at the linker script posted by Ed, you'll notice only a small number of operators is really required. I'm not really familiar with Linux kernel linker script but I'd be really surprised if they make use of all the operators you implemented. I may be wrong.

In any case, I think we're still away from supporting such level of complexity and I'm inclined to keep the linker script code simple enough for people to contribute.

100% agree. I'd also like to point out that even very complex linker scripts (as the one used by kernels) don't rely on this feature. I'm strongly opposed to see this in until some real consumer shows up. I'm in general opposed to having any linker script directive parsed properly until there's a real use case.
I can't stress enough that I'm disturbed by how badly linker script language "specification" evolved over time.

Real use case for expressions is everywhere in linkerscript. ASSERT was implemented just for validation of results.

Sure. Expressions are used. My point is that it's better to support a subset of operators (at least in the beginning) rather than the whole set. If you look at the linker script posted by Ed, you'll notice only a small number of operators is really required. I'm not really familiar with Linux kernel linker script but I'd be really surprised if they make use of all the operators you implemented. I may be wrong.

In any case, I think we're still away from supporting such level of complexity and I'm inclined to keep the linker script code simple enough for people to contribute.

Ok, I understood. But just in case all that specific operations is just a single line for each + record in map. For example "<<=" is:

else if (Op == ">>=")
        HaveResult = AssignResultOp(Arg1, getValue(Arg1) >> toInteger(Arg2));

..

std::map<StringRef, std::pair<uint8_t, bool>> Operators = { .... {"<<=", {0, false}} ....}

so I cant say there is a complexity because of them. If you want to see just a subset, it is easy to remove few lines. That`s easy with current implementation. At fact there is 230 lines of code for all evaluations.

As a point of reference here's the FreeBSD kernel amd64 linker script: https://svnweb.freebsd.org/base/head/sys/conf/ldscript.amd64?view=co

Thanks, thats useful !

grimar added a comment.Feb 5 2016, 2:10 PM
In D16924#345138, @ruiu wrote:

If you want to start working on the linker script support, can you start from writing a proposal about the overall design? It needs to be simple, easy to implement, and fast. I have a few > ideas for that, but I don't have enough time to think deeply about them. Feel free to discuss your idea with me.

I am not sure I can write good overall design for LS. I just hoped to go step by step.
For example I thought about implementation of location counter basing on this one patch.
But I have no global idea how this should work, linker script is very huge and I am not familiar with it it actually. I just can't imagine the whole picture right now.
If you have any ideas with what I can help with (not only LS, but actually any linker relative tasks), please feel free to share with me, I probably will be able to work on something.

grimar abandoned this revision.Feb 6 2016, 4:50 PM