On Sun, Jun 13, 2010 at 6:34 AM, Matt Fleming <matt at console-pimps.org> wrote:> FYI, I've been working wth Daniel to try and pull all the Mach-O > specific things out of llvm-mc and lib/MC and put them into object file > classes. Once those patches are merged it should be a small matter of > programming to get COFF support for llvm-mc, given that the ObjectWriter > and Streamer stuff is already written.How would this work? Aren't there object type specific directives in assembly files? I know some people are working on native linkers for LLVM. It would be interesting to see an architecture for handling object files that could be shared between lib/MC and a linker. - Michael Spencer
On Sun, Jun 13, 2010 at 12:32 PM, Michael Spencer <bigcheesegs at gmail.com>wrote:> On Sun, Jun 13, 2010 at 6:34 AM, Matt Fleming <matt at console-pimps.org> > wrote: > > FYI, I've been working wth Daniel to try and pull all the Mach-O > > specific things out of llvm-mc and lib/MC and put them into object file > > classes. Once those patches are merged it should be a small matter of > > programming to get COFF support for llvm-mc, given that the ObjectWriter > > and Streamer stuff is already written. > > How would this work? Aren't there object type specific directives in > assembly files? >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.> I know some people are working on native linkers for LLVM. It would be > interesting to see an architecture for handling object files that > could be shared between lib/MC and a linker. >This would be good I think. 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? - Michael Spencer>- Nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100613/5b9538af/attachment.html>
On Sun, Jun 13, 2010 at 4:43 PM, Nathan Jeffords <blunted2night at gmail.com> wrote:>> I know some people are working on native linkers for LLVM. It would be >> interesting to see an architecture for handling object files that >> could be shared between lib/MC and a linker. > > > This would be good I think. > 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?Considering how large object files can get, I would think it's not a good idea to load all the content of all the object files into an IR. However, the object file headers could be loaded into an IR that references the data still on disk, and then lazily load the data when it is time to insert relocations and write out the final executable. I would also assume that the linker should be able to accept llvm byte code and output an executable. In a pure llvm/clang tool chain there should be no reason to use native object files other than linking against code you only have in native format. And back to the topic at hand. I have attached tests that work with the changes Daniel made to lit. I switched to using llc and .ll files instead of llvm-mc and .s files due to the lack of COFF support in llvm-mc. - Michael Spencer -------------- next part -------------- A non-text attachment was scrubbed... Name: COFF-support-test.patch Type: application/octet-stream Size: 22499 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100613/b8eb300f/attachment.obj>