[LLVMdev] LLVM built on VS C++ 2005

Aaron Gray angray at beeb.net
Fri Feb 18 10:44:29 PST 2005


>> I still may carry on implementing any mods on the VS2003 port over to 
>> 2005
>> so we know where we are with that. There may well be a second beta so it
>> would be good to get any problems in and reported to Microsoft in lue of
>> that.
>
> ok.

If both you and Jeff are okay with still implementing a VC2005 version 
spawning off changes to the VC2003 port then I am happy to do that.

>> Q. Is abort() used rather than C++ exception handling for compatibility
>> reasons with older C++ compilers ?
>
> These aren't recoverable errors: These abort calls are really put in for 
> the moral equivalent of "assert(0);": in cases where we expect control not 
> to reach.  EH is used when there is some recovery action that can be done 
> to repair the situation.

I should have caught that abort() no return :(

> Actually, AT&T vs Intel syntax is not the issue.  LLC can already emit 
> either syntax (-x86-asm-syntax={intel|att}).  The missing pieces are the 
> various assembler directives that need to be tweaked.  Making this change 
> is much less involved than changing the syntax of the instructions.

Nice, I really need to familiarize myself with LLVM's documentation before 
tackelling
any real programming as such. Porting from 2003 to 2005 was not really that 
deeper problem.

> I think that G++ has some support for linking to native windows libraries, 
> using by MingW?  We should eventually be able to do as well as it does. 
> Note that for non C/C++ compilers, this is not an issue.

Nice, that is encouraging, good old MinGW. It should then be able to compile 
C generated
from LLVM (yes?) and be a Free(dom) alternative to VC++ for Win32.

>> One thing I have been thinking of is direct generation of Windows PE
>> (Portable Executable) EXE and DLL files from ahead of time machine code
>> generation which I believe LLVM can generate ? Also possibly of Microsoft
>> OBJ and LIB files.
>
> Yes, this would be very valuable.

I would like to tackel this area if no one else does, by the time I am 
ready. The only thing is the ABI calling conventions issue, that goes for 
NASM generated code too, yes ? I don't know LLVM's ABI calling convention 
capabilities :(

>>> So the question is, what would you like to work on?
>> Really I will have to think about it when I am more familiar with LLVM 
>> and
>> know the ground better. But if you have any reasonably small/incremental
>> tasks that need doing then I am open to that.
>
> I would suggest working on the AsmWriter to get it to emit directives that 
> NASMW likes.  This should just be a matter of doing the following steps:
>
> 1. Define a new subclass of X86IntelAsmPrinter in the
>    lib/Target/X86/X86AsmPrinter class, name it X86NASMAsmPrinter or
>    something.
> 2. In the subclass, change any behaviors that you don't like (e.g.
>    change it to use the appropriate directives for NASM).
> 3. Add this option to the AsmWriterFlavor variable at the top of the file,
>    so we can say "-x86-asm-syntax=nasm"
> 4. Modify X86TargetMachine.cpp so that addPassesToEmitAssembly() create a
>    NASM target machine if the target triple stored in the module is set to
>    something windows like.  I don't know what the standard target triples
>    are for windows.
>
> Once that's done, everything should work. :)  To figure out what you need 
> to change for #2, just compile a .bc file with '-x86-asm-syntax=intel' and 
> try compiling it with NASM, keep fixing stuff until it takes it. :)

Okay when I have got familular with LLVM enough if no one else has done it 
by then I will take it as first programming task, as it seems quite self 
contained. But I would like to familurize myself with NASM properly first so 
as to no slip on step #2 :)
Sound like fun learning NASM and generating tailored code for it. Is there a 
test set that would be appropriate or adaptable for testing it ?

>> Anyway I will take a couple of weeks to a month to study LLVM properly 
>> and
>> have a play with what is availiable on the Win32 platforms. I have yet to
>> build LLVM properly under Cygwin and will also try MinGW. This is what 
>> I'll
>> do next.
>
> Ok

I am having problems installing GCC 3.4.3 under CygWin, got the path (the 
easy bit) but not the include and library directory paths, having problems 
knowing how to install it over 3.3.3. Any clues welcome. Anyway I put a Q on 
the gcc.help newsgroup.

This *should* be easy. Unfortunately my GNU is a bit on the limited side, 
still really a WindoZer as they say.

If I can get LLVM compiled under CygWin and MinGW then I can 'play' with 
LLVM a bit and get to know its tools.

Cheers,

Aaron





More information about the llvm-dev mailing list