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

[Rafael Espíndola via llvm-commits]

On 1 February 2016 at 15:06, Rui Ueyama <ruiu at google.com> wrote:
> On Mon, Feb 1, 2016 at 11:57 AM, Rafael Espíndola
> <rafael.espindola at gmail.com> wrote:
>>
>> On 1 February 2016 at 14:46, Sean Silva <chisophugis at gmail.com> wrote:
>> > 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?
>>
>> Yes, known good files are a lot easier to handle. We just have to be
>> clear what "known good" is.
>>
>> > 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).
>>
>> Would we still be required to check the offsets so we don't crash? An
>> assembly file can contain
>>
>> .reloc 0, R_X86_64_REX_GOTPCRELX, foo
>> .long 4
>>
>> which would put that relocation in an invalid location. In general, is
>> an arbitrary assembly file to be considered "known good"? Is that true
>> even for things like
>>
>> .section .eh_frame, ....
>> garbage
>>
>> that the linker has to parse?
>
>
> I think the answer is case-by-case, but I don't think we have to guarantee
> to recover from errors caused by carefully-crafted malicious object files.
> (Is there anyone who disagrees with that?)

It is definitely not a use case *I* have an interest in. I just want
to be an agreement on what use case we want to support at the moment.
Is it "any .o file", "any llvm-mc or gas produced .o", "any clang or
gcc produced .o not including inline asm"?

Cheers,
Rafael