[lldb-dev] SBValue::GetName returns wrong result?

[Alexander Polyakov via lldb-dev]

Yes, seems that it is what I needed.

Thank you for the tip!

вт, 2 апр. 2019 г. в 1:45, Jim Ingham <jingham at apple.com>:

> 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 <polyakov.alx at gmail.com>
> 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 <jingham at apple.com> 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 <polyakov.alx at gmail.com>
> 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 <jingham at apple.com> 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 at 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 at lists.llvm.org
> > > > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> > >
> > >
> > >
> > > --
> > > Alexander
> >
> >
> >
> > --
> > Alexander
>
> --
Alexander
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20190402/97e3caa8/attachment.html>