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

[Sean Silva via llvm-commits]

I think one of the main use cases that has been requested is to be able to
programmatically call the linker with "known good" object files (i.e.
produced by the compiler). That simplifies things a lot. Rui's recent
patches that are thread_local'izing existing globals seems like a
satisfactory approach. Or am I missing something?

I don't know of anybody that is (currently) requesting in-depth "no crash
no matter what command input is given" behavior. Like you said, that is a
big undertaking that is probably not best to do right now, and I don't
think anybody will dispute that.

The R_X86_64_REX_GOTPCRELX situation can probably be likened to someone
giving clang a piece of source code with an inline asm that has:

.text
.byte <some garbage>

in it. We don't guarantee that the output "makes sense" because there's
really no way for us to know what "makes sense" in a precise way (i.e., a
way that we can program). (Even then, I think that a simple check that the
high nybble of the presumed REX prefix is 4 would be adequate to catch most
issues without any disassembling.)

-- Sean Silva


On Mon, Feb 1, 2016 at 7:45 AM, Rafael Espíndola <rafael.espindola at gmail.com
> wrote:

> 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
> complications:
>   * 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
> so).
>   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.
>
> Cheers,
> Rafael
>
>
> 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
> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160201/a61451c5/attachment.html>