Created attachment 10041 [details] dump of DWARF generated by clang (passes test) TestNamespace.py is failing with GCC. The DWARF output by GCC looks correct in that it contains a DW_TAG_namespace node, although it is not identical to what Clang outputs. Attaching dumps both clang and gcc emitted dwarf for comparison. To reproduce this failure, run: python dotest.py -C gcc lang/cpp/namespace
Created attachment 10042 [details] dump of DWARF generated by gcc (fails test)
The test variant 'data_formatter_commands_after_steps' exposes a loss of every second "next" command. This variant sets a breakpoint before a list is populated, and steps 4 times to populate the list with 4 items. When this script is run using dotest, dosep or manually at the lldb command prompt, 2 "next" commands are required to populate a single list item. Note that this does not occur if the std::list contains integers rather than elements of type std::string. Note that a single line of code constructs an std::string and adds an element to the list. Also, this specific failure cannot be reproduced with clang r182733, whereas it reproduces reliably with gcc 4.6.3 (Ubuntu 12.04) gcc 4.6.2 (Debian buildbot) and icc 13.1 (Ubuntu 12.04).
Related issue on FreeBSD: runCmd: frame variable --show-declaration --show-globals i output: main.cpp:12: (int) _GLOBAL__N_1::i = 3 Expecting start string: main.cpp:12: (int) (anonymous namespace)::i = 3 Not matched FAILURE
The FreeBSD issue is just a bug in FreeBSD's __cxa_demangle in libcxxrt. For example, using one of the testcases from libcxxabi: % ./demangle-cxxrt _ZN12_GLOBAL__N_113ASTTypeWriter15VisitVectorTypeEPKN5clang10VectorTypeE _GLOBAL__N_1::ASTTypeWriter::VisitVectorType(clang::VectorType const*) % c++filt _ZN12_GLOBAL__N_113ASTTypeWriter15VisitVectorTypeEPKN5clang10VectorTypeE (anonymous namespace)::ASTTypeWriter::VisitVectorType(clang::VectorType const*)
The FreeBSD issue is now fixed in two ways - the in-tree __cxa_demangle has been updated to address this case, and FreeBSD now uses the built-in demangler recently re-added to lldb (because the in-tree __cxa_demangle still has some other limitations).
Looks like the test passes now.