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,
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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?
[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
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="
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
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
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
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
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,
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
__
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,
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()"
26 matches
Mail list logo
