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

Rafael EspĂ­ndola via llvm-commits llvm-commits at lists.llvm.org
Mon Feb 1 11:57:29 PST 2016

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, ....

that the linker has to parse?


More information about the llvm-commits mailing list