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 that claims to speak in His name. Sin becomes disobedience to authority not violation of integrity." Lokesh Kumar Mobile: +1 917 319 0360
On Mon, 12 May 2008, Lokesh Kumar wrote:> 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.There is no current plan (that I know of) to finish llvm-db at this point. We recommend that you use gdb. -Chris -- http://nondot.org/sabre/ http://llvm.org/
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 especially because the MASM license forbids MASM redistribution both for free or commercial projects so practically this target is useless for a compiler writer who want to distribute his compiler. I think the only excuse for this choice is if the developer didn't know other assemblers syntax or existence. There were some discussions here that in this situation the JIT interpreter can be used. It can be done, but only with a temporary status. I don't think that someone who makes for example an installer or animated e-greetings in which he uses LLVM for scripting and wants to distribute his work, wants his products to have over 3-4 MB (VM+JIT+Runtime). Especially after the clang will be production ready, I don't think it will be used only as a C compiler for a JIT interpreted code. Fortunately there are other better options for an I86 target assembler: 1. NASM ( http://sourceforge.net/projects/nasm ) - it can be used both in Windows and in Linux (and MacOS), without any syntax change. The only drawback for it is the LGPL license, which allows some developers to link to it only using NASM like an external tool or a dynamic library, not as a static library. 2. YASM ( http://www.tortall.net/projects/yasm/ ) - it is NASM compatible and has a BSD license, much as llvm has. A strong point for YASM is that it is from start built like a library (the same as llvm), so it can be simply integrated in a developer tool. YASM is my personal favorite for llvm integration. 3. FASM ( http://flatassembler.net/ ) - it is an assembler written in assembler, which works on Windows and Linux. It has a liberal license and as a strong point it can produce directly executables or dynamic libraries, without a linker. The major problem with it is that it can only be interfaced hardly with code written in C/C++, because it is written in assembler, so I think FASM can be used mainly as a command line utility and not as a library. Like a patch, I suggest to rename the intel syntax for the I86 target in masm-intel (or leave it intel even if I don't know if peoples are using it now in their projects), and create another target, like nasm-intel. It should be a simple problem of tweaking some templates (but don't put me to do it :) ). B. Linkers ( COFF format ) I think most of the linking phase should be done inside the llvm linker, using the native llvm format, because it is a very good optimizing linker. Especially after clang will be able to compile the standard C library (and other libraries), there is no reason to use native object libraries for other reasons than linking functions located in dynamic libraries, or for some special cases where the functions are written in other languages, like the native assembler, etc. I checked many linkers, but most of them seems not maintained anymore or they are producing bad files (like ALINK, http://alink.sourceforge.net/ ). I saw only one linker that I liked: uldar ( http://sourceforge.net/project/showfiles.php?group_id=93970 ), made by the guys from http://www.ultimatepp.org/ . It is a package of a linker and a librarian, so it can also create libraries. The source code is provided inside the U++ package under a very liberal license. Razvan PS: Chris, I'm working on the MSVC patch.
> There's also then entire GNU toolchain, through MinGW and/or Cygwin.Which works perfectly right now without any extra tweaking :) -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.
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 license. To quote from ( http://clang.llvm.org/features.html#enduser ): "We actively indend for clang (and a LLVM as a whole) to be used for commercial projects, and the BSD license is the simplest way to allow this. We feel that the license encourages contributors to pick up the source and work with it, and believe that those individuals and organizations will contribute back their work if they do not want to have to maintain a fork forever (which is time consuming and expensive when merges are involved). Further, nobody makes money on compilers these days, but many people need them to get bigger goals accomplished: it makes sense for everyone to work together." To design the native code generators of llvm to work only with software under much more restrictive licenses like GPL or the MASM license, means to throw away this goal and simply make llvm and clang only another open source project, not suitable for many commercial applications (the ones who can't use the JIT interpreter). There is also another licensing issue: there are some discussions what means for GPL "work based on project" or "work derived from project". The tendency is that if an independent project fully depends for its work on a GPL project (like a code generator which only generates code for GAS) to be considered a "work based on project" or even "work derived from project", so the intent is to also apply the GPL license to it, even this means lawsuits. Even if right now the need for a native code generator for a *free as llvm* assembler maybe is not really perceived, I think it will arise sharply when the clang will be production ready. In that respect, if someone can adapt the MASM templates to produce NASM directives (it is the only thing that needs to be changed), these updates will be more than welcome. Razvan ----- Original Message ----- From: "Anton Korobeynikov" <asl at math.spbu.ru> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Tuesday, May 13, 2008 8:19 AM Subject: Re: [LLVMdev] win32 assemblers and linkers for llvm>> There's also then entire GNU toolchain, through MinGW and/or Cygwin. > Which works perfectly right now without any extra tweaking :) > > -- > With best regards, Anton Korobeynikov. > > Faculty of Mathematics & Mechanics, Saint Petersburg State University. > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Hello, Razvan> 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.This is not true. Bunch of commercial products have gcc/binutils shipped with them. Having GPLed standalone executable component won't make your whole project under GPL. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.