<br><br><div class="gmail_quote">On Sun, May 2, 2010 at 1:47 PM, Aaron Gray <span dir="ltr"><<a href="mailto:aaronngray.lists@googlemail.com">aaronngray.lists@googlemail.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="gmail_quote"><div class="im">On 2 May 2010 19:32, Nathan Jeffords <span dir="ltr"><<a href="mailto:blunted2night@gmail.com" target="_blank">blunted2night@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


Thanks for both of your feedback, I will attempt to make it fit LLVM coding standards better before I resubmit my work.</blockquote><div><br></div></div><div>You can send me early drafts to run past GCC, send me something that works.</div>
</div></blockquote><div><br></div><div>I will test against GCC on my ubuntu virtual machine. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote">
<div> </div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div class="im">

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>As far as the hooks I put in, they are really only there so I could build the object exporter outside of LLVM, I think having it built directly in like others is preferable in the end. I do think it would be useful if projects had the option of extending supported formats without having to modify LLVM itself, but my changes main goal was minimal impact on LLVM sources.</div>



</blockquote></div></div><div><br></div><div>AFAICT The hooks you sent did not call your code at all.</div><br></blockquote><div><br></div><div>The hooks I put in place allow my compiler to specify its own MCStreamer factory function that TargetMachine::addPassesToEmitFile calls when its time to create the streamer object. I also made MCAssembler use a virtual function to construct the MCObjectWriter which I then override in my streamer to make it construct my object writer. To me, this was important to allow the streamer & object writer to be built as part of my compiler and not require me to run a build of LLVM every time I changed something. This aproach also allows me to keep this code in source control as I bounce between development machines multiple times a day.</div>
<div>  </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div>Have a look at the MachOWriter, this is designed to be extendable to other writers. The MCStreamer stuff just needs the same doing probably in TargetAsmBackend. It would be good to have this as a separate patch. This will allow both COFFWriter and ELFWriter as well as the MachOWriter to coexist and be selected by TargetTriple. BTW could you have your Writer and Streamer in different source code files, and follow the MachO code format as far as is possible/reasonable.</div>
</blockquote><div><br></div><div>I have already re-factored the code a bit to better fit LLVM coding standard. The writer & streamer are now two different source files, and code for the coff::file class has been moved directly into the writer instead of multiply inheriting from it.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><br></div><div>JTFYI The COFF code I have written consists of Reader and Writer of COFF internal object modules to/from COFF format. I am looking at producing a linker with the addition of a PE Writer class, and Library Reader class. This should then make LLVM and CLANG more independant on the Windows Platform. I have a COFF Dumper class too which works with the reader and the internal Object Module format.</div>


<div><br></div></blockquote><div><br></div><div>Some time ago, I wrote a simple COFF based linker that would link into series of object files into a memory buffer then write out the linked and loaded image to a bin file for use with a OS project I was playing around with. I revived it to help me test some problems I was having with relocations. Perhaps some of that code could be useful.</div>
<div><br></div><div>hopefully, I can have a version that will compile as part of LLVM later today</div><div><br></div><div>Thanks,</div><div>  Nathan</div></div>