search for: coffwrit

...> Module not to reference this and have to pick it up from the relocations. > > > If you're iterating over the Module, you're not dealing with the codegen > level. We want the code generator to change as little as possible when > doing codegen. > No I'm doing the COFFWriter, its just that symbols are being introduced via relocations, but AFAICT they are not defined in the Module. This seems to be happening with memcpy and friends. > > Also there is the matter of 'abort' which seems to be defined by most if > not all modules even if it is not bein...

...or writting global data and stubs to. I believe this would not require making JITEmitter and friend visible, but may introduce more runtime overhead. If you could have a look at this patch and see what you think. If things go well I will be working on patches for the ELFWriter and an accompanying COFFWriter. I know I promised this before but unfortunate circumstances stopped me working on it back then. Hopefully I can do some ground work and incremental patches to get some code generated then look at the ABI issues on Windows. Cheers, Aaron -------------- next part -------------- An HTML attachme...

...s. > AFAICT The hooks you sent did not call your code at all. 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. JTFYI The COFF code I have written consists of Reader and Writer of...

Hi All, I have created a minimally functional Win32 COFF Exporter using the new MC framework. I made some minor changes to other libraries to allow me to plug it in without building it as part of the LLVM project. I wanted to share it but wasn't sure how to go about doing so, so I have attached the code to this message. Any feedback on would be appreciated. -------------- next part

...believe this would not require > making JITEmitter and friend visible, but may introduce more runtime > overhead. > > If you could have a look at this patch and see what you think. > > If things go well I will be working on patches for the ELFWriter and > an accompanying COFFWriter. I know I promised this before but > unfortunate circumstances stopped me working on it back then. > > Hopefully I can do some ground work and incremental patches to get > some code generated then look at the ABI issues on Windows. > > Cheers, > > Aaron > > >...

Thanks for both of your feedback, I will attempt to make it fit LLVM coding standards better before I resubmit my work. 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

On Jul 18, 2009, at 3:28 PM, Aaron Gray wrote: > 2009/7/18 Chris Lattner <clattner at apple.com> > On Jul 18, 2009, at 2:56 PM, Aaron Gray wrote: > >> I am iterating through Modules symbols for 'test/CodeGen/X86/ >> memcpy.bc > > If you're iterating over functions, just ignore all intrinsics. > > Okay, but it would be nice if the Module object

...s and have to pick it up from the relocations. >> >> >> If you're iterating over the Module, you're not dealing with the codegen >> level. We want the code generator to change as little as possible when >> doing codegen. >> > > No I'm doing the COFFWriter, its just that symbols are being introduced via > relocations, but AFAICT they are not defined in the Module. This seems to be > happening with memcpy and friends. > > >> >> Also there is the matter of 'abort' which seems to be defined by most if >> not all...

On 2 May 2010 10:53, Anton Korobeynikov <anton at korobeynikov.info> wrote: > Hello, Nathan > I'll let others comment on MC hooks, I just made a very brief look > over the contents of the archive. You can find the comments below. > Yes I looked at this and there are several ways but TargetAsmBackend looked the bast place to deal with the MCStreamer choice for different

...n development machines multiple times a day. > 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. > I have already re-factored the code a bit to bet...

2009/7/18 Chris Lattner <clattner at apple.com> > > On Jul 18, 2009, at 2:56 PM, Aaron Gray wrote: > > I am iterating through Modules symbols for 'test/CodeGen/X86/memcpy.bc > > > If you're iterating over functions, just ignore all intrinsics. > Okay, but it would be nice if the Module object reflected the lowered symbol names like 'memcpy' too.

Spoiler: the following only applies to Windows binary format handling. Potential for extending yaml2obj to support COFF debug directories<https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#debug-directory-image-only> recently came up during a code review<https://reviews.llvm.org/D70606#1873185>. Currently, its COFF