[PATCH] D16599: ELF: Define another entry point.

Rafael EspĂ­ndola via llvm-commits llvm-commits at lists.llvm.org
Mon Feb 1 07:45:48 PST 2016

I just reread the related threads, let me try to summarize:

* Some user caused errors (duplicated symbols for example) are better
handled with non-fatal handling. Since that doesn't impact libraries
and we want it anyway, lets just ignore those in here (i.e.:, use this
to look at the hard issues).

* I would really not want us to be in a situation where we have bugs
but they are not fixed. If not failing gracefully given broken files
is to be considered a bug, we *have* to fuzz the linker and fix them.
A particularly nasty case is relocations being used in ABI invalid
cases. For example, if a R_X86_64_REX_GOTPCRELX is used in a position
that doesn't follow a REX prefix, do we have to report the error or
can we produce garbage when given garbage? Note that checking means
disassembling the entire section to see if a given byte is a rex
prefix for a instruction or just a byte of the previous instruction.

The options I see then are:

A) Fuzz the linker, make sure it can handle every combination of
broken file we can throw at it. This is a lot of work and not
something I will sign up for. I can help review and benchmark, but I
would also ask that this be delayed. We are still refactoring the
linker as features are added and I losing the simplicity we have now
would be really bad for design work.

B) Provide a way of isolating the liking "task". I particularly like
this since we should be able to provide a *very* robust solution and
go on to implement the rest of the linker. There are a few
  * A library cannot know what command line options the program it is in takes.
  * There are big restrictions to using fork and threads.
  For posix, I think the best we can do is provide a function that
calls fork only (not exec) and is documented to do so. It is part of
its contract that it cannot be called with threads active. In a
program that wants to use multiple threads and call it, it should
setup a zygote for calling it (and we can provide code to help it do
  Any ideas on how to do this on windows?

C) Similar to A, but use a handler that either call exit or throws if
exceptions are enabled. This would still add a *lot* of checks, but I
don't think the error handling would degrade the code as much. This
means that lld the program would be built without exceptions, but lld
the library would require it. Like A I would ask that this be delayed
until more of the linker is done.


On 26 January 2016 at 20:43, Rui Ueyama <ruiu at google.com> wrote:
> ruiu added a comment.
> Ah, right, if you link lld with your program, lld may not exist as an independent command file on your system. You may be able to install lld along with your command, but the whole point of this patch is to provide an easy migration path for existing users, so it wouldn't make much sense, I guess.
> Maybe I should switch back to use fork on Unix, with a notice saying that you shouldn't use in a multi-threaded program. Or, if wouldn't work, we can just throw this patch out and wait until we do real stuff. I want to try a few ideas to handle errors in a better way that would probably make link() always return, so maybe we can live without this.
> http://reviews.llvm.org/D16599

More information about the llvm-commits mailing list