[lldb-dev] "print 0" produces "error: expected unqualified-id"

[Michael Witten via lldb-dev]

Firstly, here are the characters in our story:

  * lldb

      $ lldb --version
      lldb version 5.0.1

  * clang

      $ p=/path/to/clang
      $ file -L "$p"
      /path/to/clang: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=3a2da750e90367b294e4219896738fa9b0a285ad, with debug_info, not stripped
      $ "$p" --version
      clang version 7.0.0 (trunk 324807)
      Target: x86_64-unknown-linux-gnu
      Thread model: posix
      InstalledDir: /path/to

Launch "lldb" with the above "clang":

  $ lldb "$p"
  (lldb) target create "/path/to/clang"
  Current executable set to '/path/to/clang' (x86_64).
  (lldb) 

Set a breakpoint:

  (lldb) breakpoint set --name clang::driver::Compilation::ExecuteCommand
  Breakpoint 1: where = clang`clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&) const + 50 at Compilation.cpp:142, address = 0x00000000034a9a9c

Launch the executable:

  (lldb) process launch -- /dev/null
  Process 18950 launched: '/path/to/clang' (x86_64)
  Process 18950 stopped
  * thread #1, name = 'clang', stop reason = breakpoint 1.1
      frame #0: 0x00005555589fda9c clang`clang::driver::Compilation::ExecuteCommand(this=0x000055555fdd5ec0, C=0x000055555fdae930, FailingCommand=0x00007fffffffcd38) const at Compilation.cpp:142
     139
     140  int Compilation::ExecuteCommand(const Command &C,
     141                                  const Command *&FailingCommand) const {
  -> 142    if ((getDriver().CCPrintOptions ||
     143         getArgs().hasArg(options::OPT_v)) && !getDriver().CCGenDiagnostics) {
     144      raw_ostream *OS = &llvm::errs();
     145

Now, try to print an expression, even a simple constant expression:

  (lldb) print 0
  error: expected unqualified-id

Note that the initial attempt to run the command "print 0" causes an enormous
amount of computing to occur before the error is produced; subsequent attempts
to issue the command produce the error message much more quickly.

Sincerely,
Michael Witten