Debugger support

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

There is no current plan (that I know of) to finish llvm-db at this point. We recommend that you use gdb.

-Chris

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 :slight_smile: ).

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.

--Owen

There's also then entire GNU toolchain, through MinGW and/or Cygwin.

Which works perfectly right now without any extra tweaking :slight_smile:

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

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.

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 Apple's developer tools can include a non-open source IDE like XCode which can still invoke gas.

--Owen

Perhaps a better example still would be gdb, which is not pluggable component in Xcode (as the compiler is).

— Gordon

I was actually referring to the fact that you can add an .s file to a project in XCode, and it will invoke gas/as on it as appropriate.

--Owen

"Razvan Aciu" <admin@kam.ro> writes:

[snip]

The problem is with the gcc and binutils licence. This is GPL and

[snip]

I agree with Owen Anderson on this one (altough IANAL, etc).

[snip]

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.

Did you notice that YASM claims support for GAS syntax?

Thanks for your replies. This is indeed a helpful mailing list. I made some more researches about the licensing issue and this is what I discovered:

- from FSF it seems that packaging together a GPL application and a commercial one it is a corner case of licensing. Here is what they say:
http://www.fsf.org/licensing/licenses/gpl-faq.html#MereAggregation
http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLInProprietarySystem
It seems that if I use GCC only as a command line tool, it should be ok. Anyway, there is a catch: "But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.".
In our case, the communication means sending entire programs and command line arguments and receiving warnings and error codes. Is this intimate enough or not? I think we need a more authoritative answer here.

- other guys understand GPL by strictly forbidding distribution of the GPL product with a non-GPL one. The nice XVID codec is released under GPL and here is what they say:
http://www.xvid.org/FAQ.42.0.html (go to the license questions).
In that case they say that even I only package the XVID codec with a proprietary software with the soly purpose to install it in Windows and after that I use only the Windows interface to it (like any other proprietary Windows software does) , GPL forbids me to do that.

- I didn't find any commercial projects (not Operating Systems or dual-licensed but simple applications) which package GPL applications with proprietary ones. If you know such applications, please let me know so I can check their license.

- during the testing, I saw that YASM can also assemble a GAS compatible syntax. I tried to use it and it worked well, except the fact that the segments names were too long for the COFF format, because of a standard prefix added to them by the llvm native generator. In that case I don't know if the link phase will be done ok (especially if the linker is able to remove the unused segments or setup the correct segments attributes).

For now, I think for a commercial developer who wants to create a complete compiler toolchain using llvm, trying to package its compiler with GCC is a very dangerous decision. If I am myself in that situation I should not do it, but instead I should try to use a non-GPL assembler and linker. So, from my point of view, the necessity of an I86 native target who address a BSD-like licensed assembler, strongly remains.

Razvan

Thanks for your replies. This is indeed a helpful mailing list. I made some
more researches about the licensing issue and this is what I discovered:

For now, I think for a commercial developer who wants to create a complete
compiler toolchain using llvm, trying to package its compiler with GCC is a
very dangerous decision.

Hi Razvan,

I don't want to discourage you, but you are basically asking for interpretation of legal documents. This is a very tricky area, and taking advise from random people on the internet is not a great idea (extension of the "on the internet noone knows you're a dog" theory). If you really really need to know the answer to questions like these, the best bet is to hire legal council.

If you just want a reasonably sure bet, you can look to the lead of others. In the US, there are many organizations comfortable with integrating LLVM and GCC and using GNU tools in the toolchain of proprietary compilers. If your situation is similar to those, you may be satisfied that you won't have a problem.

If I am myself in that situation I should not do
it, but instead I should try to use a non-GPL assembler and linker. So, from
my point of view, the necessity of an I86 native target who address a
BSD-like licensed assembler, strongly remains.

As I mentioned before, I would support people who wanted to extend the scope of this project to include new toolchain pieces. All that we're missing is for someone to actually do the work :).

-Chris

So, from 
my point of view, the necessity of an I86 native target who address a 
BSD-like licensed assembler, strongly remains.

-x86-asm-syntax=intel and NASM don’t work for some reason?

As I mentioned before, I would support people who wanted to extend the
scope of this project to include new toolchain pieces. All that we’re
missing is for someone to actually do the work :).

Could someone with a tolerance for legal bullshit look at the Open Watcom license (http://www.openwatcom.org/index.php/Open_Watcom_Public_License)) and see if maybe bundling wlink is an option?

Chris is right. I would add that it sounds like you are already getting
nonsense responses.

However, when you look for a lawyer, look for one who has dealt with GPL
before. It is a very different type of license than most, and the
majority of IP lawyers today remain unfamiliar with it. Further, a
lawyer's training is to maximize the interests of their clients, not the
interests of a community. This can lead to misunderstandings.

We experienced all of these issues at IBM when I was there.

shap

Just to chime in here as an IP lawyer:
It's not clear what question you are quite asking , but Chris is
right, you really should talk to an IP lawyer about this.

I will tell you you will get different answers depending on which
lawyers you ask.
There are plenty of proprietary applications that ship alongside GPL code.
It has been done and it will continue to be done, much to the FSF's chagrin.
If you need a recommendation for a lawyer to talk to, I can provide one.

--Dan

In our case, the communication means sending entire programs and command
line arguments and receiving warnings and error codes. Is this intimate
enough or not?

No. Notice the lack of internal data structures. The interface used is the defined by the language standard, the command line, and the normal compiler output (error messages and warning messages).

I think we need a more authoritative answer here.

You'd have to ask the copyright holder, if you cared enough.

- other guys understand GPL by strictly forbidding distribution of the GPL
product with a non-GPL one.

Each use can be different, different uses, different answers. codec are not similar to gcc as a command line tool.

- I didn't find any commercial projects (not Operating Systems or
dual-licensed but simple applications) which package GPL applications with
proprietary ones.

Xcode does.

For now, I think for a commercial developer who wants to create a complete
compiler toolchain using llvm, trying to package its compiler with GCC is a
very dangerous decision.

Yes, it is dangerous if you violate copyright. Hint, don't do that If you don't do that, there is no danger.

Oh, and the canonical place to ask about GNU owned code or the GPL would be gnu.misc.discuss, this isn't the right place.

Hi Chris,

I think you are right. Most of the replies told me to consult a lawyer and this doesn't makes me sure at all that I will not run into troubles if I package the gcc with a commercial application. This thread ( http://groups.google.com/group/gnu.misc.discuss/browse_thread/thread/0dcbb511a50ecffd# ) tells me the same thing, that this is dangerous and I want to keep myself out of troubles.

So I made up my mind and I will not use gcc. Since I need an I86 native target for a BSD-like licensed assembler after about 2-3 months, if it is not done until then I will make myself a target like "-x86-asm-syntax=intel-nasm". Unfortunately for this I will need to learn the llvm TableGen system and possibly other things so it will take me probably some few weeks. For this amount of work I am not yet prepared to release the patch for free. Anyway, for smaller things I will keep myself contributing to the community.

Razvan