<div class="gmail_quote">On Sun, Jun 13, 2010 at 12:32 PM, Michael Spencer <span dir="ltr"><<a href="mailto:bigcheesegs@gmail.com">bigcheesegs@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Sun, Jun 13, 2010 at 6:34 AM, Matt Fleming <<a href="mailto:matt@console-pimps.org">matt@console-pimps.org</a>> wrote:<br>
> FYI, I've been working wth Daniel to try and pull all the Mach-O<br>
> specific things out of llvm-mc and lib/MC and put them into object file<br>
> classes. Once those patches are merged it should be a small matter of<br>
> programming to get COFF support for llvm-mc, given that the ObjectWriter<br>
> and Streamer stuff is already written.<br>
<br>
</div>How would this work? Aren't there object type specific directives in<br>
assembly files?<br></blockquote><div><br></div><div>Once the assembler is no longer directly dependent on MachO, all sections would be the object file specific versions. At that point it would be a matter of adding support for the few COFF specific attributes.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I know some people are working on native linkers for LLVM. It would be<br>
interesting to see an architecture for handling object files that<br>
could be shared between lib/MC and a linker.<br></blockquote><div> </div><div><div>This would be good I think.</div><div><br></div><div>If a linker loaded object files into an IR, maybe CAssembler could handle the linking process also. Would it be safe to assume that on a development/build machine, the executable image, and all the object files it will be made up of could be loaded into memory in some IR? Or would an architecture where the linker only reads headers and symbol information into memory and then copies data sections into the final EXE on the fly?</div>
</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
- Michael Spencer<br>
</blockquote></div><br><div>- Nathan</div>