Hi Erik,
thanks for sending out this email. It is appreciated and valuable that you took
the time to write this list of problems you encountered.
> On Sep 20, 2014, at 3:42 PM, Erik Olofsson <erik.olofs...@hansoft.com> wrote:
>
> Hi,
>
> These are some of the issues I have run into when trying to add synthetic
> children and summary providers with the python API.
>
> Access to nested classes and typedefs
> The first problem I ran into was accessing member typedefs of a SBType, for
> which I have found no API. The workaround for this was to create static
> variables with types I needed. This practice however would not be advisable
> in Release builds as it bloats the executable. This brings us to the second
> problem.
You are probably correct about this. On the other hand, I don’t think I ever
needed this ability. When exactly would this be useful?
I am of course not implying that we would not care to have this ability, just
that I expect workarounds to exist.
>
> Access to class member static variables
> There is no way to access static member variables directly from a SBValue or
> SBType. The current method I use works for some cases but not all:
>
> SBValue.CreateValueFromExpression(SBValue.get_expr_path() + ("." or "->") +
> StaticVarName)
> This works for normal SBValues, but not synthetic SBValues
>
Indeed. Known problem, but most likely very hard to solve, and not even
desirable in all cases. See below, but this has been discussed already
somewhere in greater detail.
> SBValue.CreateValueFromExpression(SBType.GetName() + "::" + StaticVarName)
> This fails for template types as it fails to parse the template
>
> SBValue.GetFrame().GetVariables(False, False, True, False);
> This fails for statics not in the current compilation unit
>
> SBValue.GetTarget().FindGlobalVariables(StaticVarName, 1024);
> This fails because not nearly all statics are returned. Also if you
> specify the class, it is just ignored and you need to compare
> SBValue.GetName() against the SBType.GetName() + StaticVarName. But that also
> fails sometimes because the name in SBType and SBValue is not always
> formatted the same way for template (non-type) params.
Worth filing a bugzilla for. Or maybe Greg has some magical insight on how to
find all the things.
>
> Expressions on synthetic SBValues
> You cannot access synthetic SBValues in an expression in any way as far as I
> can tell. I have found no way to get an arbitrary type and pointer into an
> expression for evaluation. For simple types it works to just use the address
> and cast it to the correct type: "(Type *)0xXXXXXXXX". But this does not
> work for template types as parsing them invariably fails (error: no type
> named 'X' in namespace 'X::X’).
You can’t. That is entirely by design. Imagine having an std::map<string,int>
In code, you write myMap[“key”], but synthetic children are exposed as
myMap[0], as a pair<keyType,valueType>
If synthetic children were allowed, now you could write myMap[0] = 12, or
myMap[0] = {“1”,2} or other horrible things that you should not be allowed to
write, with dubious semantics at best.
There are a few more caveats, but long story short, it’s a tricky business, and
we just don’t have enough of a compelling use case/right answers to want to
delve into it
>
> Non Type Template Params
> For some types I need to get non type template param values. I have found no
> API for this, although this can be worked around by adding static variables
> with the values in them.
This sounds like a bug. Maybe a DWARF problem. Do you have a reproduction case
handy?
>
> Access to posix thread locals
> I have found no way to access pthread thread locals, or reading through the
> GS segment of a thread from the python API, so I have to resort to calling
> into the target. But I guess that is no problem as long as I don't need to
> debug a core dump (if or when this is supported).
>
> Suggestions
> To get everything working:
> * Add API for saving a SBValue as a persistent variable. This would allow a
> workaround for doing expressions on synthetic SBValues
This might be interesting. Worth filing a bugzilla ER for.
> or
> * You should be able to access the SBValue in the expression when calling:
> SBValue.CreateValueFromExpression. For example: $var, or the context of the
> evaluation should be as if inside a class function of the type of the
> SBValue, which would allow you to access the member vars directly.
I don’t think we’d want to go for language extensions. Doesn’t this->whatever
work, if you are currently stopped in a class context?
>
> To not have to add helpers in target executable:
> * Add API to access nested types and typedefs in a SBType
> * Add API to get static class members: SBValue.GetChildStaticMemberWithName,
> and SBType.GetChildStaticMemberWithName
> * Add API to read the from the GS segment of a thread, or support for reading
> pthread thread locals.
These seem all worth of bug/ER reports, although Greg might know more about
thread local access
>
>
> Any ideas for workarounds for these issue would be appreciated. Currently I
> would be happy to just get it to work reliably, for which all I need is to be
> able to get an arbitrary SBValue into an expression.
Why do you need to use an expression? For 99% of formatters, that is usually
not desirable nor necessary.
Not desirable for performance and stability reasons. Not necessary because most
often all the expression does is memory access and basic manipulations that are
doable via Python anyway
>
> If I were to try to patch this myself, what do you think would be the easiest:
> * Fix the template parsing in expressions.
If you have cases of expressions that we should parse and aren’t, please file
bugs
> * Save SBValue as persistent variable.
Not a bad idea, but probably not necessary either
> * Access SBValue directly in expression through $var
There are good reasons to not do that
> * Access the SBValue directly in expression by being evaluated in the context
> of type of the SBValue
Depending on where you’re stopped this should either work already or hardly be
meaningful (if I understand what you mean)
>
> Regards,
> Erik
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
Thanks,
- Enrico
📩 egranata@.com ☎️ 27683
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
