Re: [lldb-dev] SBValue::GetName returns wrong result?
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, CreateValueFromAddress just
> reads some memory and presents it as the given type, rather than having to
> parse and evaluate an expression just to figure out the type and address,
> and then go read the memory and present it as the given type..
>
> As a side note, if you only wanted the dereferenced values, and needed to
> use the expression, you could also just make the expression be:
>
> *((uint32_t *) ADDR)
>
> The resultant SBValue would have the name you wanted. But again, for
> "typed addresses" CreateValueFromAddress is a more robust & efficient API.
>
> Jim
>
>
> > On Apr 1, 2019, at 3:36 PM, Alexander Polyakov
> wrote:
> >
> > 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.GetName() will return "*rbx".
> >
> > Maybe it'd be better to use SBTarget::CreateValueFromAddress() instead
> of CreateValueFromExpression. The Value created this way will be
> dereferenced initially, so its name will not contain *, I guess.
> >
> > On Tue, Apr 2, 2019 at 1:23 AM Jim Ingham wrote:
> > 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
> better or worse, except it would be confusing to dereference an SBValue and
> get back another value with the same name, so we have to choose something
> else.
> >
> > Jim
> >
> > > On Apr 1, 2019, at 3:16 PM, Alexander Polyakov
> wrote:
> > >
> > > 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 see is to check the first symbol of
> name and erase it if it's equal to *.
> > >
> > > I'm facing with that situation when creating an object from a pointer
> via SBTarget::CreateValueFromExpression.
> > >
> > >
> > >
> > > On Mon, Apr 1, 2019 at 9:35 PM Jim Ingham wrote:
> > > 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 problem?
> > >
> > > Jim
> > >
> > >
> > > > On Mar 30, 2019, at 11:18 AM, Alexander Polyakov via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> > > >
> > > > Hi lldb-dev,
> > > >
> > > > I have a SBValue created via
> SBTarget.CreateValueFromExpression('some_name', expr).
> > > > If the expression looks like '(some_type *) addr', then GetName
> returns 'some_name' as expected, but when I do Dereference this value,
> GetName returns '*some_name'.
> > > >
> > > > So, is it a conventional behavior of the GetName method applied to
> dereferenced SBValue?
> > > >
> > > > --
> > > > Alexander
> > > > ___
> > > > lldb-dev mailing list
> > > > lldb-dev@lists.llvm.org
> > > > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> > >
> > >
> > >
> > > --
> > > Alexander
> >
> >
> >
> > --
> > Alexander
>
> --
Alexander
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] SBValue::GetName returns wrong result?
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 parse and
evaluate an expression just to figure out the type and address, and then go
read the memory and present it as the given type..
As a side note, if you only wanted the dereferenced values, and needed to use
the expression, you could also just make the expression be:
*((uint32_t *) ADDR)
The resultant SBValue would have the name you wanted. But again, for "typed
addresses" CreateValueFromAddress is a more robust & efficient API.
Jim
> On Apr 1, 2019, at 3:36 PM, Alexander Polyakov wrote:
>
> 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.GetName() will return "*rbx".
>
> Maybe it'd be better to use SBTarget::CreateValueFromAddress() instead of
> CreateValueFromExpression. The Value created this way will be dereferenced
> initially, so its name will not contain *, I guess.
>
> On Tue, Apr 2, 2019 at 1:23 AM Jim Ingham wrote:
> 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 better or
> worse, except it would be confusing to dereference an SBValue and get back
> another value with the same name, so we have to choose something else.
>
> Jim
>
> > On Apr 1, 2019, at 3:16 PM, Alexander Polyakov
> > wrote:
> >
> > 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 see is to check the first symbol of name
> > and erase it if it's equal to *.
> >
> > I'm facing with that situation when creating an object from a pointer via
> > SBTarget::CreateValueFromExpression.
> >
> >
> >
> > On Mon, Apr 1, 2019 at 9:35 PM Jim Ingham wrote:
> > 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 problem?
> >
> > Jim
> >
> >
> > > On Mar 30, 2019, at 11:18 AM, Alexander Polyakov via lldb-dev
> > > wrote:
> > >
> > > Hi lldb-dev,
> > >
> > > I have a SBValue created via
> > > SBTarget.CreateValueFromExpression('some_name', expr).
> > > If the expression looks like '(some_type *) addr', then GetName returns
> > > 'some_name' as expected, but when I do Dereference this value, GetName
> > > returns '*some_name'.
> > >
> > > So, is it a conventional behavior of the GetName method applied to
> > > dereferenced SBValue?
> > >
> > > --
> > > Alexander
> > > ___
> > > lldb-dev mailing list
> > > lldb-dev@lists.llvm.org
> > > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >
> >
> >
> > --
> > Alexander
>
>
>
> --
> Alexander
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] SBValue::GetName returns wrong result?
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.GetName() will return "*rbx".
Maybe it'd be better to use SBTarget::CreateValueFromAddress() instead of
CreateValueFromExpression. The Value created this way will be dereferenced
initially, so its name will not contain *, I guess.
On Tue, Apr 2, 2019 at 1:23 AM Jim Ingham wrote:
> 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 better
> or worse, except it would be confusing to dereference an SBValue and get
> back another value with the same name, so we have to choose something else.
>
> Jim
>
> > On Apr 1, 2019, at 3:16 PM, Alexander Polyakov
> wrote:
> >
> > 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 see is to check the first symbol of name
> and erase it if it's equal to *.
> >
> > I'm facing with that situation when creating an object from a pointer
> via SBTarget::CreateValueFromExpression.
> >
> >
> >
> > On Mon, Apr 1, 2019 at 9:35 PM Jim Ingham wrote:
> > 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 problem?
> >
> > Jim
> >
> >
> > > On Mar 30, 2019, at 11:18 AM, Alexander Polyakov via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> > >
> > > Hi lldb-dev,
> > >
> > > I have a SBValue created via
> SBTarget.CreateValueFromExpression('some_name', expr).
> > > If the expression looks like '(some_type *) addr', then GetName
> returns 'some_name' as expected, but when I do Dereference this value,
> GetName returns '*some_name'.
> > >
> > > So, is it a conventional behavior of the GetName method applied to
> dereferenced SBValue?
> > >
> > > --
> > > Alexander
> > > ___
> > > lldb-dev mailing list
> > > lldb-dev@lists.llvm.org
> > > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >
> >
> >
> > --
> > Alexander
>
>
--
Alexander
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] SBValue::GetName returns wrong result?
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 better or worse,
except it would be confusing to dereference an SBValue and get back another
value with the same name, so we have to choose something else.
Jim
> On Apr 1, 2019, at 3:16 PM, Alexander Polyakov wrote:
>
> 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 see is to check the first symbol of name and erase it
> if it's equal to *.
>
> I'm facing with that situation when creating an object from a pointer via
> SBTarget::CreateValueFromExpression.
>
>
>
> On Mon, Apr 1, 2019 at 9:35 PM Jim Ingham wrote:
> 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 problem?
>
> Jim
>
>
> > On Mar 30, 2019, at 11:18 AM, Alexander Polyakov via lldb-dev
> > wrote:
> >
> > Hi lldb-dev,
> >
> > I have a SBValue created via
> > SBTarget.CreateValueFromExpression('some_name', expr).
> > If the expression looks like '(some_type *) addr', then GetName returns
> > 'some_name' as expected, but when I do Dereference this value, GetName
> > returns '*some_name'.
> >
> > So, is it a conventional behavior of the GetName method applied to
> > dereferenced SBValue?
> >
> > --
> > Alexander
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
>
> --
> Alexander
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] SBValue::GetName returns wrong result?
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 see is to check the first symbol of name
and erase it if it's equal to *.
I'm facing with that situation when creating an object from a pointer via
SBTarget::CreateValueFromExpression.
On Mon, Apr 1, 2019 at 9:35 PM Jim Ingham wrote:
> 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 problem?
>
> Jim
>
>
> > On Mar 30, 2019, at 11:18 AM, Alexander Polyakov via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Hi lldb-dev,
> >
> > I have a SBValue created via
> SBTarget.CreateValueFromExpression('some_name', expr).
> > If the expression looks like '(some_type *) addr', then GetName returns
> 'some_name' as expected, but when I do Dereference this value, GetName
> returns '*some_name'.
> >
> > So, is it a conventional behavior of the GetName method applied to
> dereferenced SBValue?
> >
> > --
> > Alexander
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
--
Alexander
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] SBValue::GetName returns wrong result?
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 problem?
Jim
> On Mar 30, 2019, at 11:18 AM, Alexander Polyakov via lldb-dev
> wrote:
>
> Hi lldb-dev,
>
> I have a SBValue created via SBTarget.CreateValueFromExpression('some_name',
> expr).
> If the expression looks like '(some_type *) addr', then GetName returns
> 'some_name' as expected, but when I do Dereference this value, GetName
> returns '*some_name'.
>
> So, is it a conventional behavior of the GetName method applied to
> dereferenced SBValue?
>
> --
> Alexander
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] [Release-testers] Release 7.1.0 -rc1 has been tagged
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, Dimitry Andric via cfe-dev wrote: > > On 27 Mar 2019, at 22:27, Tom Stellard via Release-testers > wrote: > > > > I've just tagged 7.1.0-rc1. Testers, please begin testing and reporting > > results. > > Main test results on amd64-freebsd11: > > Expected Passes: 52441 > Expected Failures : 232 > Unsupported Tests : 3687 > Unexpected Passes : 1 > Unexpected Failures: 495 > > Test suite results on amd64-freebsd11: > > Expected Passes: 903 > Unexpected Failures: 3 > > Main test results on i386-freebsd11: > > Expected Passes: 50252 > Expected Failures : 226 > Unsupported Tests : 2502 > Unexpected Failures: 276 > > As before, the test suite fails to compile on i386, due to an SSE requirement. > > Uploaded: > > SHA256 (clang+llvm-7.1.0-rc1-amd64-unknown-freebsd11.tar.xz) = > f607f8b33838ba31684da09f7956d273e60dbd99e5d4a2066315efccb52556bb > SHA256 (clang+llvm-7.1.0-rc1-i386-unknown-freebsd11.tar.xz) = > 221c31b8dc19965271e47b422c30175fa70446a05fbb6f4dff9ba3f8020e8437 > > -Dimitry > > ___ > cfe-dev mailing list > cfe-...@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 39958] TestRegisters.py fails on Linux (failed to write register 'mxcsr')
https://bugs.llvm.org/show_bug.cgi?id=39958 lab...@google.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||lab...@google.com --- Comment #2 from lab...@google.com --- Fixed by r357376. -- You are receiving this mail because: You are the assignee for the bug.___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 41330] New: Please cherry-pick r357376 into the 8.0.1 branch
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 Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: lab...@google.com CC: llvm-b...@lists.llvm.org Blocks: 41221 Without this fix it's not possible to modify non-GPR registers via lldb on x86/linux. Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=41221 [Bug 41221] [meta] 8.0.1 Release Blockers -- You are receiving this mail because: You are the assignee for the bug.___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
