similar to: [LLVMdev] MASM Backend

I made some researches how llvm, possibly with other tools, can be a full backend for compiler writers (with the final result being an executable file or dynamic linked library). Here are the results: A. Assemblers When I saw that the I86 target for llvm with the Intel syntax targets MASM (I tested with the MASM version from http://www.masm32.com/ ), it was a bad surprise for me. This is

Hi Anton, You're already a part of the llvm development team by participating actively on the llvm development list :) If you wish we can put you on: http://llvm.cs.uiuc.edu/Developers.html Great to have you on the team, welcome! We (Jeff, Morten, Paolo, the rest of the team and I) are looking forward to cooperate with you and to push win32 and mingw versions even further to stable and

Yes, you are right. During my testings, I tried the llvm produced .S files with the gcc frontend and it compiled and linked them to the final executable. The problem is with the gcc and binutils licence. This is GPL and while this is ok for open source or for academic purposes, it can't be used on commercial projects. In fact one of the strong points of llvm (and clang) is its BSD like

Hi LLVM'ers, has anyone read the license details for MASM32 and understood how these fit in with Open Source projects, especially GPL? - As far as I can see - no one is allowed to license projects under GPL or at worst other OS licenses nor the deritives of the project, if you're using MASM32. Are the MASM backend compatible with the MS version of MASM or other not so license

Here's the new MASM backend. It has the following files :- lib/Target/X86/X86AsmPrinter.h lib/Target/X86/X86AsmPrinter.cpp lib/Target/X86/X86MASMPrinter.h lib/Target/X86/X86MASMPrinter.cpp lib/Target/X86/X86.td lib/Target/X86/X86InstrInfo.td lib/Target/X86/makefile Makefile.rules win32/x86/x86.vcproj

Razvan, You're somewhat misinterpreting the GPL license. Using binutils as a dependency of LLVM does not require that they be linked into any distributable that might contain proprietary code. They can be shipped as separate, purely-GPL'd executables that are called via the command line, thereby avoiding the whole "infection" problem. This is, for instance, how

I'm running a CentOS 6.5 chroot to build Pale Moon (a Firefox fork) for older machines running distros like Puppy linux. Before anyone asks... * Yes, even though the older machines are using "ancient" glibc, etc, they do have security patches back-ported, e.g. http://www.murga-linux.com/puppy/viewtopic.php?t=90461 "Lucid Puppy Revitalized as 5.2.8.7 - December,

Hello, Henrik. You wrote Friday, May 13, 2005, 5:52:11 PM: HB> However, me and others will try to help you to compile the cfe. Please HB> submit your compiling errors on this mailing list. I've compiled CFE on cygwin this winter without any problems. I really didn't change anything to let it work. -- With best regards, Anton mailto:asl at math.spbu.ru

Hi all, I am just curious to know when will the llvm-db be released. I hope I am posting in the right forum. In the latest release 2.2, the llvm-db binary doesn't appear to load the symbol table or debug the bytecode. It spits out a message saying that this feature is still not implemented. Thanks & Regards, -Lokesh -- "It is not God that is worshipped but the group or authority

> -----Ursprüngliche Nachricht----- > Von: asl at math.spbu.ru, LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Gesendet: 13.06.07 23:13:08 > An: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Betreff: Re: [LLVMdev] LLVM binaries for Windows and more > > Hello, Andreas. > > > It seems that the generated ASM code cannot be assembled

Hello, Henrik. You wrote Thursday, January 27, 2005, 12:17:21 AM: HB> I've attached an output. Seems to be some problems with path handling. I think the '/\' in the error line is an indicator, that something went wrong with sys::Path. Maybe, you'll add some debugging code to Win32/Path.inc to see, what's happening when calling destroyFile(), and see, how this path is

Hello, Henrik. You wrote Thursday, May 11, 2006, 5:13:06 AM: HB> Thanks Anton. Nice Job. There was at least one thing I miss in the description: In the step 3 you should unpack runtime libraries from mingw32 distribution into "prefix" (say, w32api and mingw-runtime) before starting configure for GCC. BTW, maybe it will be better just use patched bash (with "pwd" builtin

Hi, There maybe licencing problems with ML/MASM, we need to get someone to check this out if we are going to support them. NASM and YASM were suggested. Aaron

It would be nice to be able to use clang/llvm without GNU toolchain dependencies. Just out of curioisty what does the --x86-asm-syntax=intel actually mean then? Does this not get used? Is this a different syntax than the AT&T variety (forgive me if this is an obvious question)? I tried downloading FASM last night and it seemed handle some of the output, the one thing it didn't like was

Is anyone using the -x86-asm-syntax=intel flag to llc or otherwise using the MASM .s file printing stuff in the X86 backend? My understanding is that masm is really not very useful, and that the code doesn't really work. Going forward, we'd like to be able to just emit a PECOFF file direction, and we will continue to support mingw, so windows plaform support really won't

On Aug 3, 2009, at 11:23 AM, Aaron Gray wrote: > Hi Chris, > > It would be good to get to try to get it as functional as possible > at some point, before abandoning it..maye once I have one the COFF > backend. I'm not proposing to remove COFF support from the asmprinter, just masm support. Using gas will continue to work fine. > Anyway I wll report back when I have

>>  Anyway I wll report back when I have a proper overview of the area, >> it would be good if you could also look into the problem so contact >> me back if you are, also it maybe a good idea to share this with >> Anton and Evan. > > I already spoke to anton.  The MASM support is clearly broken, it > generates .s files with typos for the directives and has other

On Aug 3, 2009, at 12:04 PM, Aaron Gray wrote: > 2009/8/3 Anton Korobeynikov <anton at korobeynikov.info> > >> Anyway I wll report back when I have a proper overview of the > area, > >> it would be good if you could also look into the problem so contact > >> me back if you are, also it maybe a good idea to share this with > >> Anton and Evan.

On Monday 03 August 2009 14:04, Aaron Gray wrote: > 2009/8/3 Anton Korobeynikov <anton at korobeynikov.info> > > > >> Anyway I wll report back when I have a proper overview of the area, > > >> it would be good if you could also look into the problem so contact > > >> me back if you are, also it maybe a good idea to share this with > > >>

2009/8/3 Anton Korobeynikov <anton at korobeynikov.info> > >> Anyway I wll report back when I have a proper overview of the area, > >> it would be good if you could also look into the problem so contact > >> me back if you are, also it maybe a good idea to share this with > >> Anton and Evan. > > > > I already spoke to anton. The MASM