llgo produces debug data incompatible with LLVM 3.2

[axw]

#78 reintroduces and expands debug data. The format has been updated, and is now incompatible with LLVM 3.2. The drone.io config has been updated, but we should either disable generating debug data pre-3.3, or otherwise generate debug-data differently for different versions (I opt for sticking to the latest released version).

[quarnster]

Unfortunately although there is capability to specify a debug format version via LLVMDebugVersion, from what I can tell llvm does not actually handle the different versions:

09:54 ~/code/3rdparty/llvm-3.3.src $ find . -type f -exec grep -H LLVMDebugVersion {} \;
./docs/SourceLevelDebugging.rst:<a name="LLVMDebugVersion">The first field of a descriptor is always an
./docs/SourceLevelDebugging.rst:current debug version (``LLVMDebugVersion = 8 << 16`` or 0x80000 or
./docs/SourceLevelDebugging.rst:    i32,       ;; Tag = 17 + LLVMDebugVersion (DW_TAG_compile_unit)
./docs/SourceLevelDebugging.rst:    i32,       ;; Tag = 41 + LLVMDebugVersion (DW_TAG_file_type)
./docs/SourceLevelDebugging.rst:    i32,      ;; Tag = 52 + LLVMDebugVersion (DW_TAG_variable)
./docs/SourceLevelDebugging.rst:    i32,      ;; Tag = 46 + LLVMDebugVersion (DW_TAG_subprogram)
./docs/SourceLevelDebugging.rst:    i32,     ;; Tag = 11 + LLVMDebugVersion (DW_TAG_lexical_block)
./docs/SourceLevelDebugging.rst:    i32,     ;; Tag = 11 + LLVMDebugVersion (DW_TAG_lexical_block)
./docs/SourceLevelDebugging.rst:    i32,      ;; Tag = 36 + LLVMDebugVersion (DW_TAG_base_type)
./docs/SourceLevelDebugging.rst:    i32,    ;; Tag = 33 + LLVMDebugVersion (DW_TAG_subrange_type)
./docs/SourceLevelDebugging.rst:    i32,      ;; Tag = 40 + LLVMDebugVersion (DW_TAG_enumerator)
./include/llvm/DebugInfo.h:      return getUnsignedField(0) & ~LLVMDebugVersionMask;
./include/llvm/Support/Dwarf.h:  LLVMDebugVersion = (12 << 16),        // Current version of debug information.
./include/llvm/Support/Dwarf.h:  LLVMDebugVersion11 = (11 << 16),      // Constant for version 11.
./include/llvm/Support/Dwarf.h:  LLVMDebugVersion10 = (10 << 16),      // Constant for version 10.
./include/llvm/Support/Dwarf.h:  LLVMDebugVersion9 = (9 << 16),        // Constant for version 9.
./include/llvm/Support/Dwarf.h:  LLVMDebugVersion8 = (8 << 16),        // Constant for version 8.
./include/llvm/Support/Dwarf.h:  LLVMDebugVersion7 = (7 << 16),        // Constant for version 7.
./include/llvm/Support/Dwarf.h:  LLVMDebugVersion6 = (6 << 16),        // Constant for version 6.
./include/llvm/Support/Dwarf.h:  LLVMDebugVersion5 = (5 << 16),        // Constant for version 5.
./include/llvm/Support/Dwarf.h:  LLVMDebugVersion4 = (4 << 16),        // Constant for version 4.
./include/llvm/Support/Dwarf.h:  LLVMDebugVersionMask = 0xffff0000     // Mask for version number.
./lib/IR/DIBuilder.cpp:  assert((Tag & LLVMDebugVersionMask) == 0 &&
./lib/IR/DIBuilder.cpp:  return ConstantInt::get(Type::getInt32Ty(VMContext), Tag | LLVMDebugVersion);
09:55 ~/code/3rdparty/llvm-3.3.src $

In other words, there's no backwards compatibility and thus two (or more) versions of the debug code would have to be maintained if the code is going to be functional for different llvm releases.

IMO any branch should just have to deal with a single LLVM/Go/go.types/etc version and any other version is "use at your own risk". It's too early to talk about different release branches, so for now that means master is whatever the current LLVM/Go/go.types release is (which currently wouldn't actually work as current Go is 1.1, there's no go.types "release" and go.types tip is incompatible with Go1.1 #59).

Even better would be if all dependencies are added as git submodules or some other tagged/versioned approach to ensure everyone is using the exact same versions of everything. That would be a bit broader perspective tying in #59 and #18 here too which I think is the preferred long term approach.

[axw]

Fair points.

BTW, #59 was fixed upstream by rsc. While we should probably pin revisions at some point, I'd rather not until things are settled right down in go/types. That may sound counter-intuitive, but I don't want llgo to fall so far behind go/types that updating becomes difficult to manage.

[quarnster]

Yeah, IMO the "development" branch should be tip-ish for all dependencies and for now it doesn't make sense to maintain any release branches.