[PATCH] D38846: [ELF] - Linkerscript: fix issue with SUBALIGN.

Rui Ueyama via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Oct 23 08:52:23 PDT 2017


ruiu added a comment.

If I understand correctly, you are saying that (1) returning an impossible value (e.g. 17 as an alignment) is fine as long as (2) doing that doesn't cause any assertion failure or something.

So, (1) is simply wrong. We assume that alignments are always powers of two, and you shouldn't break that assumption at any time. We do not want to even think about any value that is not a power of two. I've already described the reason, so I don't know how I can convince you, but this is how we handle errors in lld, and you should follow that.

Maybe, viewing programs as state machines might help you understand why what I was saying makes sense. Any program can be thought as a state machine (as long as it uses finite amount of memory.) The number of states lld can be, for example, is really huge, but it is finite, and on each step of the code, we move from one state to another. Now you can think of a set of "sane" states, in which our internal constraints are all satisfied. You want to keep "sane" states closed under all transitions, simply because we do not write our code for any insane state. We do not guarantee our code's behavior in any sense if a program falls in an impossible state. It could transition back to some sane state, but when that happens, that is a coincidence, and you shouldn't rely on that. You can make "sane" states larger by relaxing some constraints (e.g. temporarily accepting a non-power-of-two as a valid alignment), but that makes your program unnecessarily complicated, or at least makes you think more when you write code. As a result, it makes your code hard to understand.

If you are familiar with parsing, you can also think of the parser error recovery. To recover from a user error, you continue reading a text by assuming that an erroneous token were some different but a valid token. You wouldn't make your parser an impossible state before continue reading, right? It's just like that.

And the second point doesn't really matter. Just like traffic rules, you need to maintain all constraints whether you are being watched or not. We do not sprinkle asserts to many places, but that doesn't mean that setting a variable to an impossible value is accepted.


https://reviews.llvm.org/D38846





More information about the llvm-commits mailing list