<div><div dir="auto">Couldn’t you write the relocations to the ELF executable?  I don’t know if current linkers have support for this, but it seems possible in theory to make a relinkable executable.  If you want to do this with an already linked executable though, then yea this won’t be possible.</div></div><div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jul 20, 2018 at 10:30 AM Reid Kleckner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Typically people do this kind of thing by writing a loader for the executable format you want to run, and they create libc stubs that either delegate or reimplement enough functionality to get the app in question to run. Wine, for example, uses this approach. It loads native PE executables, and implements enough of the win32 API to run some applications.<div><br></div><div>"Re-linking" would be tough because linking typically throws away static relocations that you would need.</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jul 20, 2018 at 12:46 AM ardi via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
Let's suppose we have an ELF executable that doesn't issue any syscall<br>
(I mean, syscalls are issued from an external dynamic library, not<br>
from the executable, and we can ignore such dynamic library because we<br>
have the proper equivalent library with the proper syscalls in MacOS<br>
and Windows).<br>
<br>
So, the question: Is it "currently possible" (by "currently possible"<br>
I mean that all the needed tools/code already exist) to somehow<br>
"unlink" the code and data from the ELF executable, and relink it as<br>
two new executables: one Mach-O and another PE?<br>
<br>
Would this be possible with just LLVM tools, or would other<br>
libraries/tools also be needed?<br>
<br>
Thanks a lot!<br>
<br>
ardi<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>