Yes, seems that it is what I needed.
Thank you for the tip!
вт, 2 апр. 2019 г. в 1:45, Jim Ingham :
> Independent of the naming issue, if you have an address and want to view
> its pointee as a given type, CreateValueFromAddress is much more efficient
> than CreateValueFromExpression. After all
Independent of the naming issue, if you have an address and want to view its
pointee as a given type, CreateValueFromAddress is much more efficient than
CreateValueFromExpression. After all, CreateValueFromAddress just reads some
memory and presents it as the given type, rather than having to p
I have an address of memory where the value of some register is. I do
following:
addr = 0x1234 (just for example)
rbx = target.CreateValueFromExpression('(uint32_t *) ' + str(addr), 'rbx')
rbx = rbx.Dereference()
Then I want to create a map:
rbx.GetName() => rbx.GetValue()
In this case rbx.GetNa
What are you using the name for? If the name of an SBValue is the name of a
variable, then it makes sense (at least in C languages) for the name of the
dereference Value to be "*VARNAME". After all that's what it is. If the name
is some other random string, I'm not sure anything would be bett
I can't say that it's a problem, I just want to know what is the actual
reason of such a behavior to find good workaround.
I have a SBValue with a pointer to some object, e.g. "(uint32_t *) sp",
when I do dereference it, I get another SBValue - "(uint32_t) *sp". The
only way to deal with it that I
Dereference returns another SBValue distinct from the initial one, so it needs
to make up a name for it. I think it would be confusing for it to return the
same name, and putting a * at the beginning of the initial SBValue seems as
good a choice as any.
Is this causing you some concrete proble
ARM & AArch64 all green:
fa208f1d15ae8d4babc93cd421af6d23868f8bb6a16f64fa89f18920c133d982
clang+llvm-7.1.0-rc1-aarch64-linux-gnu.tar.xz
760a06933b45cffcf7340c15e1a04a4dce122677c9132291a9da4d64dd84edca
clang+llvm-7.1.0-rc1-armv7a-linux-gnueabihf.tar.xz
Cheers,
Diana
On Fri, 29 Mar 2019 at 17:51, D
https://bugs.llvm.org/show_bug.cgi?id=39958
lab...@google.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.llvm.org/show_bug.cgi?id=41330
Bug ID: 41330
Summary: Please cherry-pick r357376 into the 8.0.1 branch
Product: lldb
Version: 8.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
