Open llvmbot opened 10 years ago
Yes, lldb's integration with the STL is hampered by the fact that the STL inlines much of its implementation, leaving nothing for lldb to call. That's true here, and it is true for things like std::vector
We need to find a way to teach lldb how to reconstruct these inlined functions from the STL headers. By our current lights, we'll get that ability from clang learning to compose fully function STL modules, and then teaching lldb to ingest same.
Note, this isn't a problem with the expression parser understanding == operators, as you can show with simple examples like:
cat compare_strings.cpp
include
class Foo { public: int a; bool operator==(const std::string &rhs) { if (rhs.size() == a) return true; return false; } };
int main() { Foo my_foo = {5}; std::string my_str("asdfs"); bool equals = my_foo == my_str; if (equals) return 0; return 1; }
clang++ -g -O0 -o compare_strings compare_strings.cpp lldb compare_strings (lldb) target create "compare_strings" Current executable set to 'compare_strings' (x86_64). (lldb) b s -l 21 Breakpoint 1: where = compare_strings`main + 204 at compare_strings.cpp:21, address = 0x0000000100000cec (lldb) run Process 25890 launched: '/private/tmp/compare_strings' (x86_64) Process 25890 stopped
- thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 frame #0: 0x0000000100000cec compare_strings`main at compare_strings.cpp:21 18 Foo my_foo = {5}; 19 std::string my_str("asdfs"); 20 bool equals = my_foo == my_str; -> 21 if (equals) ^ 22 return 0; 23 return 1; 24 } Target 0: (compare_strings) stopped. (lldb) expr my_foo == my_str (bool) $0 = true
From looking at the headers, it seems that the expression:
(abc == "def")
is being expanded via templates to:
std::basic_string<>::operator==(abc, "def")
which is then being inlined to:
abc.compare("def")
... which is supported by fact that the binary links against the basic_string<>::compare(char const*) method from libc++.
So it looks like there isn't any actual implementation of operator==() available for lldb to use, though I'm not familiar with the details of how it's expression evaluator might differ.
I've reproduced the behavior described.
(lldb) target create "a.out" Current executable set to 'a.out' (x86_64). (lldb) br s -l 8 Breakpoint 1: where = a.out`main + 532 at test2.cc:8, address = 0x0000000100000b94 (lldb) r Process 80442 launched: '/Users/penryu/tmp/test2/a.out' (x86_64) Process 80442 stopped
I wonder if this isn't a case where lldb's expression evaluator doesn't match clang's.
Extended Description
If you try and execute C++ code comparing a std::string with a string literal using "expr", you get a warning and and error:
(lldb) expr abc == "abc" error: warning: result of comparison against a string literal is unspecified (use strncmp instead) error: invalid operands to binary expression ('string' (aka 'std::basic_string<char, std::char_traits, std::allocator >') and 'const char *')
error: 1 errors parsing expression
(lldb)
That comparison works fine when compiled by clang++, despite the fact that the first warning comes from the clang library (tools/clang/lib/Sema/SemaExpr.cpp:7960 at r215285). I poked around in that function, and it seems like it's designed to warn against string literal comparison in the large majority of cases (including this one). So the confusing thing here may be that clang++ doesn't warn about the comparison when compiling (though I think that is the proper behavior, since std::string explicitly defines a binary comparison operator of std::string vs. char*).
I did not explore the function where the second error comes from (tools/clang/lib/Sema/SemaExpr.cpp:6798, same revision).
Reproduction: Compile the attached file with clang++ -g test2.cc (note the lack of error or warning), and
lldb a.out break set -f test2.cc -l 8 run expr abc == "abc"