[llvm-dev] Need help with code generation

[Rafael Espíndola via llvm-dev]

>>
>> * I don't want to trade my time implementing stuff users will see
(linker script, debug index, speed) for things users will not.
>
>
> Don't you think that you are somehow trading your time for other people's
time when they'll have to build other features on top of the codebase?
> I understand you're putting the cursor toward end-users facing interface,
but the reason I'm working on clang/LLVM in the first place is especially
that care is given to what other developers will have to cope with in the
project (while being somehow pragmatic as well to make forward progress
"quickly").

I don't think I am trading other developers time in this. You can make that
argument for things like global state (I still think the way we are doing
it is more developer time efficient overall), but I don't think so for
security.

>> * I don't want to pretend that cherry picking a few bound checks will
make lld safe on untrusted input.
>
> My impression is that there is a kind of "philosophical" view at stand:
are we treating such crash as bugs and prioritize fixing them accordingly
or not. I believe we had the same kind of philosophical disagreement with
the development practices (no global state, etc.) a few months ago: while
acknowledging that "perfect is the enemy of good", some long-term core
principles can be set, and the development can tend toward these design
goals, while still having some tradeoff for "getting things done" in a
reasonable time.
>

I don't really think it is philosophical. Llvm is utterly inappropriate for
a security context on its own. You need to get help from the OS or
something like NaCl. Take a quick look at the work that went into securing
libressl and imagine the same being done to llvm. What allocator would you
start with?

With security out of the way, the question that remains is how visible a
given issue is. It is critical for clang to handle broken code, since it is
given broken code all the time. In an IDE it gets it almost at every
keystroke.

It less important to gracefully handle things like the example I posted,
just because it is far less likely to be hit.

A broken object file is orders of magnitude less likely.

Cheers,
Rafael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160321/ef7a3ff9/attachment.html>