Greg Clayton wrote:
> Not really. If you can send me a concrete example of something that isn't
> working, it might help.
Reporting progress.
1. `im loo -t` only ever finds one "best match", and the plist seems
to have no effect on it.
2. The plist parsing code does get executed. I checked with
Greg Clayton wrote:
> Be sure to use "frame variable" more as it will never run into these type
> importation problems when you need to view a variable or members of a
> variable.
>
> It would be interesting to see the output of "frame variable" from frame 0
> and frame 4 and see if they differ
Hi,
I never do --no-stdin, because the program I'm debugging often takes
input. If I debug in one of the normal sessions for an extended period
of time, 'continue' returns the (lldb) prompt immediately, which
claims that the program is running (it's actually waiting for input).
At this point, I ha
Hi,
Basic things are failing.
(lldb) p lhs
(CG::VarExpr *) $0 = 0x00010d445ca0
(lldb) p lhs->rootStmt()
(CG::ExprStmt *) $1 = 0x00010d446290
(lldb) p cg_pp_see_it(lhs->rootStmt())
(const char *) $2 = 0x00010d448020 "%A = $3;"
(lldb) p cg_pp_see_it(def->rootStmt())
error: no member nam
On Mon, Nov 30, 2015 at 12:41 PM, Greg Clayton wrote:
> class A : public B
> {
> };
>
> where class "B" has all sorts of interesting methods, the debug info will
> often look like:
>
> class B; // Forward declaration for class B
>
> class A : public B
> {
> };
What? Didn't we just fix this (for
On Mon, Nov 30, 2015 at 5:42 PM, Greg Clayton wrote:
> When we debug "a.out" again, we might have recompiled "liba.so", but not
> "libb.so" and when we debug again, we don't need to reload the debug info for
> "libb.so" if it hasn't changed, we just reload "liba.so" and its debug info.
> When w
Hi,
gdb has a `layout asm` which is very useful while debugging assembly.
Do we have something like that in lldb?
Thanks.
Ram
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Hi,
This has been the source of much frustration, but I can't quite figure out
why my toString() member function is not present in the target, according
to lldb. The other functions in the compile unit are used and present, so
the linker couldn't have eliminated the compile unit. Nor could the
fun
Hi,
Pavel Labath wrote:
>
> a have couple of question to better understand the situation:
> - what is the system you are trying this out on (OS, arch, ...)?
>
macOS, x86_64.
> - are you using any funny compiler options that you think we should
> know about ? (e.g. if you're using -ffunction-se
I got around the problem using attribute used.
Ram
On Fri, Feb 10, 2017 at 9:02 AM Ramkumar Ramachandra
wrote:
> Hi,
>
> Pavel Labath wrote:
>
> a have couple of question to better understand the situation:
> - what is the system you are trying this out on (OS, arch, ...)?
>
>
> macOS, x86_64.
Hi,
My script is simple enough:
import lldb
def pp(debugger, command, result, internal_dict):
target = debugger.GetSelectedTarget()
process = target.GetProcess()
thread = process.GetSelectedThread()
frame = thread.GetSelectedFrame()
res = frame.EvaluateExpression("%s->dump()"
t; % command)
>print >>result, 'typename = "%s"' % (res.GetType().GetName())
>print >>result, res
>
> See if the double quote is on the next line.
>
>> On Aug 22, 2015, at 11:58 AM, Ramkumar Ramachandra via lldb-dev
>> wrote:
>&g
Hi,
I believe there's now a:
(gdb) info vtbl ...
and I'm unable to find the equivalent of this in lldb. I usually do:
(lldb) im look -r -v -s ...
and look for the vtable info in the output, but it doesn't always seem
to be there.
What am I missing?
Thanks.
Ram
__
Ha, turns out it's
(lldb) im look -r -v -s "vtable for ..."
We should document this in http://lldb.llvm.org/lldb-gdb.html
On Tue, Sep 15, 2015 at 9:53 AM, Ramkumar Ramachandra
wrote:
> Hi,
>
> I believe there's now a:
>
> (gdb) info vtbl ...
>
> and I'm unable to find the equivalent of this
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::allocator >::__rep,
std::__1::allocator >' vs.
'std::__1::__compressed_pair, s
mpilers 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 for
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 im
Greg Clayton wrote:
> 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 actu
Hi,
This does not happen with lldb-330.0.48, which ships with OS X, but
happens with HEAD:
frame #0: 0x000101c3ce8c libmwcgir_vm_rt.dylib`(anonymous
namespace)::CgJITMemManager::endFunctionBody(this=0x00010a715610,
F=0x00010a6da200, FunctionStart="�?^\n\x01",
FunctionEnd="
[Quoting entire email for the benefit of everyone else]
On Tue, Oct 20, 2015 at 7:39 PM, Greg Clayton wrote:
> Ok, so try this on all of your dSYM files:
>
> 1 - load the dsym file into lldb:
>
> % xcrun lldb
> libmwcgir_vm_rt.dylib.dSYM/Contents/Resources/DWARF/libmwcgir_vm_rt.dylib
> (lldb) im
On Tue, Oct 20, 2015 at 8:22 PM, Greg Clayton wrote:
> Then try running and let me know what your results are!
Hm, there seems to be something seriously wrong. I triple-checked
everything, but Declaration::Compare is not even called when the error
is triggered! How should we proceed now?
So first, an addendum: I found a way to make the project build without
using a symlink, and use a direct reference instead. The problem still
persists. It may be that symlink is one of the problems, but it is
certainly not the only problem.
On Tue, Oct 20, 2015 at 8:22 PM, Greg Clayton wrote:
> i
Hi,
On Wed, Oct 21, 2015 at 2:27 PM, Greg Clayton wrote:
>
Atleast, can we have lldb report a nicer error?
There is conflicting DWARF information for type ilist...:
/sandbox/rramacha/3p/derived/List.h
/sandbox/rramacha/3p/install/List.h
/sandbox/rramacha/idivide/bin/libmwcgir_vm.so is to
Okay, I'm stuck again. Let's back up and see what's happening:
~/src$ git clone llvm/
~/src$ mkdir llvm-build/
~/src/llvm-build$ cmake -GNinja -DCMAKE_BUILD_TYPE=Debug ../llvm
~/src/llvm-build$ ninja
Now, ~/src/llvm-build/lib/libLLVMCore.a contains DWARF information
that points to files ~/src/llv
Greg,
Greg Clayton wrote:
> Note that for C++ we get the fully qualified name and we pass in an empty
> Declaration() so they all will compare to the same thing. This would solve
> our current issue. We would also need to add the items to this map in the
> same way: for C++ get the fully quali
Hi,
I'm using lldb to debug lldb, and I notice that I get this message in
the inner lldb:
(lldb) p F
error: Process is running. Use 'process interrupt' to pause execution.
If I 'process interrupt', I go to the outer lldb (presumably), and if
I try to 'continue', the same message is displayed ov
26 matches
Mail list logo
