Compiler requirements for compiling lldb?

Is there a goal of keeping lldb compatible with building with gcc? I’ve been building successfully with gcc 4.8.2, but compiling at r212507 just broke with that gcc on a source line that was recently (today) changed. Full log below; key excerpts here:

/usr/local/google/home/rdsmith/Sandboxen/llvm/tools/lldb/source/Interpreter/Args.cpp:693:115: error: no matching function for call to ‘lldb_private::OptionValidator::IsValid(lldb_private::Platform&, lldb_private::ExecutionContext)’
if (validator && !validator->IsValid(*interpreter.GetPlatform(true), interpreter.GetExecutionContext()))

/usr/local/google/home/rdsmith/Sandboxen/llvm/tools/lldb/include/lldb/lldb-private-types.h:61:22: note: no known conversion for argument 2 from ‘lldb_private::ExecutionContext’ to ‘lldb_private::ExecutionContext&’

I’m happy to upgrade to compiling with clang if that’s needed; I’m just wanting to confirm policy and call out that the web page instructions may need to be changed.

(If this is pilot error on my part, sincere apologies for the spam. But at the moment I don’t see how it could be pilot error.)

– Randy

FAILED: /usr/local/google/home/rdsmith/toolchains/bin/g++ -DGTEST_HAS_RTTI=0 -DHAVE_ROUND -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wno-missing-field-initializers -pedantic -Wno-lo\

ng-long -Wno-maybe-uninitialized -Wnon-virtual-dtor -Wno-comment -std=c++11 -ffunction-sections -fdata-sections -Wno-deprecated-declarations -Wno-unknown-pragmas -Wno-deprecated-register -fno-exceptions -fno-rtti -fPIC -g -Itools/lldb/source/Interpreter -I/usr/local/google/home/rdsmith/Sandboxen/llvm/tools/lldb/s\

ource/Interpreter -I/usr/local/google/home/rdsmith/Sandboxen/llvm/tools/lldb/include -Itools/lldb/include -Iinclude -I/usr/local/google/home/rdsmith/Sandboxen/llvm/include -I/usr/include/python2.7 -I/usr/local/google/home/rdsmith/Sandboxen/llvm/tools/lldb/…/clang/include -Itools/lldb/…/clang/include -I/usr/local\

/google/home/rdsmith/Sandboxen/llvm/tools/lldb/source/. -I/usr/local/google/home/rdsmith/Sandboxen/llvm/tools/lldb/source/Plugins/Process/Linux -I/usr/local/google/home/rdsmith/Sandboxen/llvm/tools/lldb/source/Plugins/Process/POSIX -fno-exceptions -fno-rtti -MMD -MT tools/lldb/source/Interpreter/CMakeFiles/lldb\

Interpreter.dir/Args.cpp.o -MF tools/lldb/source/Interpreter/CMakeFiles/lldbInterpreter.dir/Args.cpp.o.d -o tools/lldb/source/Interpreter/CMakeFiles/lldbInterpreter.dir/Args.cpp.o -c /usr/local/google/home/rdsmith/Sandboxen/llvm/tools/lldb/source/Interpreter/Args.cpp

/usr/local/google/home/rdsmith/Sandboxen/llvm/tools/lldb/source/Interpreter/Args.cpp: In member function ‘lldb_private::Error lldb_private::Args::ParseOptions(lldb_private::Options&)’:

/usr/local/google/home/rdsmith/Sandboxen/llvm/tools/lldb/source/Interpreter/Args.cpp:693:115: error: no matching function for call to ‘lldb_private::OptionValidator::IsValid(lldb_private::Platform&, lldb_private::ExecutionContext)’

if (validator && !validator->IsValid(*interpreter.GetPlatform(true), interpreter.GetExecutionContext()))

^

/usr/local/google/home/rdsmith/Sandboxen/llvm/tools/lldb/source/Interpreter/Args.cpp:693:115: note: candidate is:

In file included from /usr/local/google/home/rdsmith/Sandboxen/llvm/tools/lldb/include/lldb/Interpreter/Args.h:22:0,

from /usr/local/google/home/rdsmith/Sandboxen/llvm/tools/lldb/source/Interpreter/Args.cpp:17:

/usr/local/google/home/rdsmith/Sandboxen/llvm/tools/lldb/include/lldb/lldb-private-types.h:61:22: note: virtual bool lldb_private::OptionValidator::IsValid(lldb_private::Platform&, lldb_private::ExecutionContext&) const

virtual bool IsValid(Platform &platform, ExecutionContext &target) const = 0;

^

/usr/local/google/home/rdsmith/Sandboxen/llvm/tools/lldb/include/lldb/lldb-private-types.h:61:22: note: no known conversion for argument 2 from ‘lldb_private::ExecutionContext’ to ‘lldb_private::ExecutionContext&’

This is my fault, and unfortunately I can’t fix it until tomorrow morning. You can either revert the change or fix it by changing the second argument of IsValid() to be a const reference instead of a reference. I had the patch applied on two branches locally, had the correct fix in one branch, and accidentally committed from the other branch.

If you do choose to fix it locally, please go ahead and just push the fix up for others as well.

Yes, gcc is important. The build was broken by r212500:
http://llvm-amd64.freebsd.your.org/b/builders/lldb-amd64-freebsd/builds/2276

I just grabbed that link because it was in #llvm IRC.

IsValid needs to take a const ref in order to lifetime extend the temporary parameter. Or, maybe the code is broken some other way.

Alternatively you could make the second argument passed on the stack instead of by reference. It returns by value anyway, so it’s not like there’s no precedent for it.

Historically, my understanding is that LLDB has required much more recent
GCCs to build than the rest of LLVM, even LLD (which has always used
C++11). Personally, now that the baseline for LLVM's compiler support is
more reasonably modern (GCC 4.7, MSVC 2012, Clang 3.1) I wonder if it would
be acceptable to the LLDB developers to have a common baseline of host
toolchain support with the rest of the LLVM project[1]? If not, I wonder
what the LLVM baseline would need to be before they could be the same? Not
a big deal, but would simplify one point of "getting started" for folks
trying to hack on LLDB.

-Chandler

[1] The details are here:
http://llvm.org/docs/CodingStandards.html#supported-c-11-language-and-library-features

Managed to get this fixed, so if you sync you should be good to go now. Sorry for the trouble.

Regarding Chandler’s comment on GCC version, I suppose it wouldn’t be too difficult of an experiment to just try older versions of GCC and see if the errors that arise are trivially fixable.

I believe we currently assume gcc 4.8.2, MSVC 2012 and a recent clang (I don't know what clang 3.1 maps to as we have different builds at Apple).

If GCC 4.7 can handle all of the C++11 that we have in LLDB, I am all for trying to support it. It there are major changes required, we might need to bump the requirement to gcc 4.8.2. If someone can find out how the LLDB build goes with gcc 4.7 that would be great.

Greg Clayton

Hey btw I just got a gcc 4.7.2 setup running last night for Sylvestre at Debian. (They’re stuck on 4.7.2 on one of their releases).

I had to change a few things, nothing major. See this revision (r212681) for details.
http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20140707/011717.html