Hello,
SBValue::Cast marked as deprecated in LLDB headers:
// Deprecated - use the expression evaluator to perform type casting
lldb::SBValue Cast(lldb::SBType type);
But I can't understand how to replace it with expression evaluation.
Suppose I have:
auto casted_val = my_value.Cast(my_type);
Hello,
I'm observing very strange LLDB behavior: it does not always shows a
correct dynamic type when I ask for.
Originally I was working with LLDB 3.9, but it looks like trunk version
behaves the same strange way.
I was able to capture this behavior in a small code snippet:
#include
#include
X.
>
> Greg Clayton
>
> On Feb 5, 2017, at 1:19 PM, Roman Popov via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Hello,
> I'm observing very strange LLDB behavior: it does not always shows a
> correct dynamic type when I ask for.
>
> Originally I was
looking at this now. I will let you know what I find.
>
>
>
> Greg
>
>
>
> On Feb 6, 2017, at 10:00 AM, Roman Popov wrote:
>
>
>
> Yes, that was my thought.
>
>
>
> FYI, checked in GDB: it's working correctly on this testcase showing
>
Hello,
I just found out that sometimes I don't get correct dynamic type in LLDB
even if I compile with g++. How can I get typeinfo/vtable dump from LLDB
to check if it is still the same name matching issue?
2017-02-06 17:04 GMT-08:00 Robinson, Paul via lldb-dev <
lldb-dev@lists.llvm.org>:
> Yes,
Thanks Greg,
So here is another case when LLDB fails to resolve dynamic type. Compiled
with G++5.4 on Ubuntu 16.04.
Here I want to get dynamic type for some variable apb_memories
(lldb) expr -d no-run -- apb_memories
(sc_core::sc_object *) $3 = 0x00cb6aa8
(lldb) memory read --format a
Yes, you're right. When I replaced unsigned with signed int it works
properly.
2017-02-10 19:46 GMT+03:00 Greg Clayton :
>
> On Feb 10, 2017, at 12:55 AM, Roman Popov wrote:
>
> Thanks Greg,
>
> So here is another case when LLDB fails to resolve dynamic type. Compiled
> with G++5.4 on Ubuntu 16
I'm testing example from https://lldb.llvm.org/python-reference.html (USING
THE LLDB.PY MODULE IN PYTHON) on Ubuntu 16.04
For some reason it works only with LLDB 3.9, is it because LLDB 4.0/5.0 are
not stable yet?
#5.0 -- Does not work
deb http://apt.llvm.org/xenial/ llvm-toolchain-xenial mai
Hello Benjamin , all
>>I recently started using lldb to write a basic instrumentation tool for
>>tracking the values of variables at various code-points in a program.
I have the same problem of tracing some variables and debugging
application post-mortem. Without knowing about your experience I'v
hing that would automatically intercept some function to execute
> your code while the process is running (some kind of dynamic
> instrumentation), then the answer is no. (But I don't see any mention
> of that on the gdb page you quoted either).
>
> cheers,
> pavel
>
t; including declaring variables/types:
> >> (lldb) expr -- char s[]="qwerty"; for(int i=0; i < sizeof s; ++i)
> >> printf("%d: %c\n", i, s[i]);
> >> 0: q
> >> 1: w
> >> 2: e
> >> 3: r
> >> 4: t
> >> 5:
>> >>str[2] = 0;
> >> >>msg = str;
> >> >>end
> >> > (gdb) c
> >> > Continuing.
> >> > T
> >> >
> >> > T
> >> >
> >> > T
> >> >
> >> > T
>
ve a symbol, print some info for the
> symbol
> print symbol
>
>
> We set the async mode to false, so target.LaunchSimple() should not return
> until the process is stopped or exited. Note in your example it is
> returning with "state = launchin
we have a symbol in the symbol table for
>> where we stopped
>> symbol = frame.GetSymbol();
>> if symbol:
>> # We do have a symbol, print some info for the
>> symbol
>>
;>> # Now get all instructions for this function and
>>> print them
>>> insts = function.GetInstructions(target)
>>> disassemble_instructions (insts)
>>> else:
>
27; will persist beyond
> that expression and be available for future expressions.
> - Any type returned as the result type of an expression will have its type
> available
>
> Greg
>
> On Feb 13, 2017, at 6:00 AM, Roman Popov via lldb-dev <
> lldb-dev@lists.llvm.org> wro
16 matches
Mail list logo
