similar to: [LLVMdev] llvm COFF linker

On Sun, May 2, 2010 at 1:47 PM, Aaron Gray <aaronngray.lists at googlemail.com>wrote: > On 2 May 2010 19:32, Nathan Jeffords <blunted2night at gmail.com> wrote: > >> Thanks for both of your feedback, I will attempt to make it fit LLVM >> coding standards better before I resubmit my work. > > > You can send me early drafts to run past GCC, send me something

On 2 May 2010 19:32, Nathan Jeffords <blunted2night at gmail.com> wrote: > Thanks for both of your feedback, I will attempt to make it fit LLVM coding > standards better before I resubmit my work. You can send me early drafts to run past GCC, send me something that works. As far as the hooks I put in, they are really only there so I could build > the object exporter outside of

On Mon, Jun 21, 2010 at 9:37 AM, Aaron Gray <aaronngray.lists at gmail.com> wrote: > > Whats going on with having both write_uint32_le() > in WinCOFFObjectWriter::DefineSection() and WriteLE32() in > WinCOFFObjectWriter::WriteFileHeader() ? > Aaron Thanks, missed that one. Nathan used write_uint32_le in WinCOFF.h, and I guess accidentally used it in WinCOFFObjectWriter.cpp.

2009/8/28 Aaron Gray <aaronngray.lists at googlemail.com> > 2009/8/28 Anton Korobeynikov <anton at korobeynikov.info> > >> Hello, Aaron >> >> > -c /home/ang/svn/llvm-gcc-coff/gcc/libgcc2.c -o libgcc/./_popcountsi2.o >> > assertion "V == V2 && "Didn't find key?"" failed: file >> >

2009/8/28 Anton Korobeynikov <anton at korobeynikov.info> > Hello, Aaron > > > -c /home/ang/svn/llvm-gcc-coff/gcc/libgcc2.c -o libgcc/./_popcountsi2.o > > assertion "V == V2 && "Didn't find key?"" failed: file > > "/home/ang/svn/llvm-coff/ > > This is familiar but I cannot remember whether it got fixed or not now. I >

write_uint32_le is used to write into a arbitrary data buffer, where as WriteLE32 is used to write into the object file. On Mon, Jun 21, 2010 at 9:01 AM, Michael Spencer <bigcheesegs at gmail.com>wrote: > On Mon, Jun 21, 2010 at 9:37 AM, Aaron Gray <aaronngray.lists at gmail.com> > wrote: > > > > Whats going on with having both write_uint32_le() > > in

On 28 May 2010 05:59, Nathan Jeffords <blunted2night at gmail.com> wrote: > For those that are interested, I have attached the latest version of my > Win32 COFF support patch. There is no new functionality, I just fixed some > compiler errors due to recent changes in the MC library. > > Nathan, Sorry about this but... On Cygwin with GCC-4.2.4 :- In file included from

On 26 July 2010 04:35, Michael Spencer <bigcheesegs at gmail.com> wrote: > Attached is the 5th and final patch of the beginning of COFF support > for MC. It simply makes the X86 backend use it on Win32 targets and > tests it. > > You probably want to add Cygwin and MinGW32 Triples as well :- case Triple::Win32: + case Triple::Cygwin: + case Triple::MinGW32: return

On Mon, Jul 26, 2010 at 12:04 PM, Aaron Gray <aaronngray.lists at gmail.com> wrote: > You probably want to add Cygwin and MinGW32 Triples as well :- >    case Triple::Win32: > +  case Triple::Cygwin: > +  case Triple::MinGW32: >      return new WindowsX86AsmBackend (T); > Aaron Can someone test this on those platforms? That change would effect quite a few people. -

Oh, so *that's* what happened to MASM. OK, change of plans. Forget NASMW, target ML. Aaron Gray wrote: >>> We still have a dependency on the system linker, but in time that >>> could be addressed. Note that VC++ distributes a native linker, but >>> I don't think it distributes a native assembler (I could be wrong >>> though). >> >>

I am iterating through Modules symbols for 'test/CodeGen/X86/memcpy.bc I get :- ---------- Functions ---------- llvm.memcpy.i64 Mangled name = llvm.memcpy.i64 DefaultVisibility ExternalLinkage - Externally visible. my_memcpy Mangled name = my_memcpy DefaultVisibility ExternalLinkage - Externally visible. my_memcpy2 Mangled name =

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. -Chris > > I get :- > > ---------- Functions ---------- > llvm.memcpy.i64 > Mangled name = llvm.memcpy.i64 > DefaultVisibility > ExternalLinkage -

Hi, I am working on the COFF backend and am wondering where llvm.memcpy gets lowered to memcpy ? It seems to be done by the assembler backends and would have thought it would either be done by a lowering pass or done by the mangler but it does not seem to be either. Many thanks in advance, Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL:

>> We still have a dependency on the system linker, but in time that >> could be addressed. Note that VC++ distributes a native linker, but I >> don't think it distributes a native assembler (I could be wrong though). > > You are correct. Microsoft does not distribute an assembler with Visual > Studio anymore (hasn't for some time). Its called ML.EXE now

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.

On 26 July 2010 18:08, Michael Spencer <bigcheesegs at gmail.com> wrote: > On Mon, Jul 26, 2010 at 12:04 PM, Aaron Gray <aaronngray.lists at gmail.com> > wrote: > > You probably want to add Cygwin and MinGW32 Triples as well :- > > case Triple::Win32: > > + case Triple::Cygwin: > > + case Triple::MinGW32: > > return new

Attached is the 5th and final patch of the beginning of COFF support for MC. It simply makes the X86 backend use it on Win32 targets and tests it. - Michael Spencer -------------- next part -------------- A non-text attachment was scrubbed... Name: ms-coff-patch-5.patch Type: application/octet-stream Size: 23435 bytes Desc: not available URL:

On Sat, Jul 18, 2009 at 2:21 PM, Aaron Gray<aaronngray.lists at googlemail.com> wrote: > I am working on the COFF backend and am wondering where llvm.memcpy gets > lowered to memcpy ? It's done by ISel. See SelectionDAG::getMemcpy. -Eli

Chris Lattner wrote: > On Thu, 9 Jun 2005, Alexander Friedman wrote: > >> On Jun 9, Chris Lattner wrote: >> >>>> I'm happy with .so. What purpose would .o files serve? >>> >>> >>> Speeds up compile time by not having to write out a .s file then run >>> the >>> system assembler on it. Likewise, emitting a .so file

>Aaron Gray wrote: >> What I am after is to be able to emit line number information for COFF >> (Common Object File Format) object module files, basically it comes down >> to >> paired line numbers and virtual address offsets. >> >> I have not really set out to look at this yet, just feeling ahead, and >> was >> prompted by Saman's question