[lldb-dev] Issues found writing synthetic children providers for template library

Erik Olofsson erik.olofsson at hansoft.com
Sat Sep 20 15:42:46 PDT 2014


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.

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

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.

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').

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.

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
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.

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.


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. 

If I were to try to patch this myself, what do you think would be the easiest:
* Fix the template parsing in expressions.
* Save SBValue as persistent variable.
* Access SBValue directly in expression through $var
* Access the SBValue directly in expression by being evaluated in the context of type of the SBValue

Regards,
Erik

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140921/62d9598b/attachment.html>


More information about the lldb-dev mailing list