[lldb-dev] [Bug 25205] New: std::string has no value
https://llvm.org/bugs/show_bug.cgi?id=25205
Bug ID: 25205
Summary: std::string has no value
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: beryku...@gmail.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified
Created attachment 15088
--> https://llvm.org/bugs/attachment.cgi?id=15088&action=edit
C++ source with test program
std::string variables have value "None" when I access them using the Python
scripting API. They only have one child, which also has a value of None. Is
there another way to get the string value, or am I doing something wrong? I
could probably print the string into the terminal and get the result from the
command interpreter, but it would be nice to access the string directly.
I've attached a simple C++ program that demonstrates this.
I'm using LLDB 3.8 compiled from trunk. The program was compiled using clang++
with libc++ (I also tried g++ and -fstandalone-debug switch with similar
results).
import lldb
import os
debugger = lldb.SBDebugger.Create()
debugger.SetAsync(False)
target = debugger.CreateTarget("./test")
target.BreakpointCreateByLocation("test.cpp", 7)
process = target.LaunchSimple([], [], os.getcwd())
thread = process.GetSelectedThread()
frame = thread.GetSelectedFrame()
for var in frame.vars:
if var.name == "a":
print(var.value) # None
debugger.Terminate()
--
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 25205] std::string has no value
https://llvm.org/bugs/show_bug.cgi?id=25205 Jim Ingham changed: What|Removed |Added Status|NEW |RESOLVED CC||jing...@apple.com Resolution|--- |INVALID --- Comment #1 from Jim Ingham --- std::string is a structure. Structures don't have a value. They have children - the structure fields - and perhaps a summary and/or synthetic children. Note that for a std::string the actual children are the fields of the internal implementation, which isn't all that helpful. What you probably want to show is the summary of the string, which is the user-friendly presentation that the lldb "data formatters" cook up for you. -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [BUG?] Confusion between translation units?
Alright, let's try to fix the bug.
Let's work backward from the leaves: clang's ASTImporter.cpp:2979 and
AstImporter.cpp:3044. In the backtrace, what seems to be most relevant
is a call inside layoutRecordType, namely ClangASTSource.cpp:1709. The
codebase clearly shows efforts to emit "Please retry with
-fno-limit-debug-info", so I can infer that we intend to catch every
non-IsStructurallyEquivalent before it goes to clang, and emit a good
error message if best-effort fails. ClangASTContext.cpp is littered
with `omit_empty_base_classes`, so some machinery to handle forward
declarations properly is already in place.
Back to where we were debugging. GetCompleteDecl seems relevant, and
we aren't using its return value, so we have no way of telling if it's
a complete definition, right? Why am I guessing instead of
interactively debugging? Because the debugger is useless at this
stage, thanks to the same bug :)
I think the bug is just a matter of missing a corner case, but I could
be wrong. Let me know your thoughts.
Ram
On Wed, Oct 14, 2015 at 11:06 AM, Ramkumar Ramachandra
wrote:
> Thanks for an excellent explanation.
>
> Unfortunately, -fno-limit-debug-info did not fix the problem; and that
> I don't see the problem with a gcc/gdb setup.
>
> So what I'm doing is forward-declaring LLVM IR entities (like `Value',
> `Type', `Function'), so that multiple downstream modules don't include
> those LLVM headers potentially double-including global statics. I'm
> trying to look inside an llvm::Function * in the debugger now, and it
> fails.
>
> I'm going to try building LLVM itself with -fno-limit-debug-info now.
> Let me know if there are other things I can try.
>
> Thanks.
>
> Ram
>
> On Tue, Oct 13, 2015 at 6:26 PM, Greg Clayton wrote:
>> In LLDB we create clang::ASTContext objects for the modules (executable and
>> shared libraries), one for the target to contain the expression results, and
>> one for each expression.
>>
>> When we evaluate an expression we might do something like:
>>
>> (lldb) expr a + b
>>
>> where "a" is from liba.so and "b" is from libb.so. We must copy types from
>> the clang::ASTContext for each module, so we will copy the type of "a" into
>> the expression clang::ASTContext and we will also copy type "b" from the
>> clang::ASTContext from libb.so into the expression clang::ASTContext. Many
>> times we the same types, but one has more information in it. Like lets say
>> both "a" and "b" are type "foo". We can often end up with different
>> definitions of "foo" in liba.so and libb.so and when we try to copy the
>> types, we first copy "foo" from liba.so into the expression AST, and
>> then we do the same with "b" from libb.so, but it notices that the types are
>> the same level, so it tries to verify the types are the same. This often
>> fails due to debug info being more complete in one of the shared libraries.
>> One example is the compiler might omit the complete definition for a base
>> class in libb.so where it has a complete definition for the base class in
>> liba.so. When parsing types we must always give clang something it is happy
>> with, so if we run into debug info that has a complete definition for
>> "foo", but it inherits from class "C". So the definition for "C" in
>> liba.so is:
>>
>> class C
>> {
>> public:
>> C();
>> ~C();
>> int callme();
>> };
>>
>> and "C" in "libb.so" is just a forward declaration:
>>
>> class C;
>>
>> But then int libb.so we must create a type for foo but we can't since C
>> isn't complete, but we do anyway by just saying C looks like:
>>
>> class C
>> {
>> };
>>
>> So now we have two types that differ, and importing both foo types into
>> the expression clang::ASTContext will fail. This happens a lot for C++
>> template classes because of the haphazard way that compilers generate debug
>> info for templates. It could be a bug in the type importer where the two
>> types are actually the same, but the type importer thinks they are
>> different, but often it is because the types actually do differ.
>>
>> One way to get around the compiler emitting forward declarations to base
>> classes is to specify: -fno-limit-debug-info
>>
>> This will disable the debug info minimizing feature and make the compiler
>> emit more complete debug info and it might fix your problem.
>>
>> Greg Clayton
>>
>>> On Oct 13, 2015, at 10:44 AM, Ramkumar Ramachandra via lldb-dev
>>> wrote:
>>>
>>> Hi,
>>>
>>> At one point in the debugging session, I get this when I try to print
>>> a particular value:
>>>
>>> error: field '__r_' declared with incompatible types in different
>>> translation units
>>> ('std::__1::__compressed_pair>> std::__1::char_traits, std::__1::allocator >::__rep,
>>> std::__1::allocator >' vs.
>>> 'std::__1::__compressed_pair>> std::__1::char_traits, std::__1::allocator >::__rep,
>>> std::__1::allocator >')
>>> error: field '__r_' declared with incompatible types in different
>>> translation units
>>> ('std::__1::
Re: [lldb-dev] [BUG?] Confusion between translation units?
> On Oct 16, 2015, at 3:01 PM, Ramkumar Ramachandra wrote:
>
> Alright, let's try to fix the bug.
>
> Let's work backward from the leaves: clang's ASTImporter.cpp:2979 and
> AstImporter.cpp:3044. In the backtrace, what seems to be most relevant
> is a call inside layoutRecordType, namely ClangASTSource.cpp:1709. The
> codebase clearly shows efforts to emit "Please retry with
> -fno-limit-debug-info", so I can infer that we intend to catch every
> non-IsStructurallyEquivalent before it goes to clang, and emit a good
> error message if best-effort fails. ClangASTContext.cpp is littered
> with `omit_empty_base_classes`, so some machinery to handle forward
> declarations properly is already in place.
No this is just so you don't see a mess in the variable view. If you have empty
base classes A, B, and C, and you have class D:
class D : public A, public B, public C
{
int m_a;
};
You don't want to have your variable view look like:
d-.
|- A
|- B
|- C
\- m_a
You would rather see:
d-.
\- m_a
So this is what imit_empty_base_classes aims to fix: showing tons of class
structure that doesn't contribute to efficient variable viewing in the
debugger. C++ classes in the "std" namespace have a ton of useless stuff that
shows up if you don't do this:
my_str-.
|-
|-
|-
\- m_data
>
> Back to where we were debugging. GetCompleteDecl seems relevant, and
> we aren't using its return value, so we have no way of telling if it's
> a complete definition, right? Why am I guessing instead of
> interactively debugging? Because the debugger is useless at this
> stage, thanks to the same bug :)
Yes I have seen a bunch of problems like this on linux due to types being
incomplete in the debug info (my guess). But I would like to verify that the
manual DWARF indexing isn't to blame for this. We have great accelerator tables
that the clang makes for us that actually have all of the info we need to find
types and functions quickly, whereas all other platforms must run
SymbolFileDWARF::Index() to manually index the DWARF.
>
> I think the bug is just a matter of missing a corner case, but I could
> be wrong. Let me know your thoughts.
I should be able to tell if you can send me an ELF file and say where you were
and wait wasn't showing up correctly (which variables) in an exact code context
(which file + line or exact line in a function). Then I can verify that
SymbolFileDWARF::Index() is correctly indexing things so that we can find types
and functions when we need them.
Greg
>
> Ram
>
> On Wed, Oct 14, 2015 at 11:06 AM, Ramkumar Ramachandra
> wrote:
>> Thanks for an excellent explanation.
>>
>> Unfortunately, -fno-limit-debug-info did not fix the problem; and that
>> I don't see the problem with a gcc/gdb setup.
>>
>> So what I'm doing is forward-declaring LLVM IR entities (like `Value',
>> `Type', `Function'), so that multiple downstream modules don't include
>> those LLVM headers potentially double-including global statics. I'm
>> trying to look inside an llvm::Function * in the debugger now, and it
>> fails.
>>
>> I'm going to try building LLVM itself with -fno-limit-debug-info now.
>> Let me know if there are other things I can try.
>>
>> Thanks.
>>
>> Ram
>>
>> On Tue, Oct 13, 2015 at 6:26 PM, Greg Clayton wrote:
>>> In LLDB we create clang::ASTContext objects for the modules (executable and
>>> shared libraries), one for the target to contain the expression results,
>>> and one for each expression.
>>>
>>> When we evaluate an expression we might do something like:
>>>
>>> (lldb) expr a + b
>>>
>>> where "a" is from liba.so and "b" is from libb.so. We must copy types from
>>> the clang::ASTContext for each module, so we will copy the type of "a" into
>>> the expression clang::ASTContext and we will also copy type "b" from the
>>> clang::ASTContext from libb.so into the expression clang::ASTContext. Many
>>> times we the same types, but one has more information in it. Like lets say
>>> both "a" and "b" are type "foo". We can often end up with different
>>> definitions of "foo" in liba.so and libb.so and when we try to copy
>>> the types, we first copy "foo" from liba.so into the expression AST,
>>> and then we do the same with "b" from libb.so, but it notices that the
>>> types are the same level, so it tries to verify the types are the same.
>>> This often fails due to debug info being more complete in one of the shared
>>> libraries. One example is the compiler might omit the complete definition
>>> for a base class in libb.so where it has a complete definition for the base
>>> class in liba.so. When parsing types we must always give clang something it
>>> is happy with, so if we run into debug info that has a complete definition
>>> for "foo", but it inherits from class "C". So the definition for "C"
>>> in liba.so is:
>>>
>>> class C
>>> {
>>> public:
>>>C();
>>>~C();
>>>int callme();
>>> };
>>>
>>> and "C" in "l
