<br><br><div class="gmail_quote">2010/11/15 Török Edwin <span dir="ltr"><<a href="mailto:edwintorok@gmail.com">edwintorok@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">
><br>
> The pros and cons we discussed:<br>
><br>
> Pro:<br>
>  - We reuse all existing MC output functionality.<br>
>  - We have a shorter path to working well with the external system<br>
> tools (the real runtime linker, the debugger, the unwinder).<br>
><br>
> Cons:<br>
>  - Requires developing good object file libraries for LLVM. This is<br>
> also a pro, as it coalesces work other people (Michael Spencer, Nick<br>
> Kledzik) are already interested in doing.<br>
>  - Means JIT is slightly more platform dependent, as the runtime<br>
> linker could have ELF or Mach-O specific bugs that wouldn't show up on<br>
> another platform.<br>
<br>
</div><br>Don't forget PE (or is it pecoff?), otherwise JIT won't work on win32.<br>
But what does the obj format has to do with the JIT?<br>
Sure for debug info its good to have an ELF around to give to gdb, but<br>
otherwise can't you just emit the code to memory, with a small header<br>
to keep info you need, and thats it?<br>
<div><div></div><div class="h5"><br></div></div></blockquote><div><br>If I understand correctly, the idea is to use native platform format (ELF, Mach-O, COFF...) even when emitting code in memory for the JIT.<br></div></div>