[lldb-dev] synthetic for std::wstring

[Enrico Granata]

> 
> Hi Enrico,
> 
> thank you for your help.
> 

You're welcome :)

>> Since you're only really producing one child value, it looks like you may want to provide a summary for the wstring instead of synthetic children.
> Cool, thats exactly what I'm searching for, but I found only the synthetic children examples in the docu.
>> 

I think summaries are described here: http://lldb.llvm.org/varformats.html (there is an example about computing the area of a rectangle via Python and use that as a summary)

>> You are trying to bind a synthetic children provider to *every* std::basic_string<T>? Why?
> I am dealing with utf-8 utf-16 and utf-32 strings in my application and it would be great to be able to view all strings. Currently only the int version is implemented :-(

Are you going to have a way to distinguish the several encodings once you bind every std::basic_string<T> to your summary function? If so, great :)
A nice thing to be told about regexp, is that an exact match always wins over them, so you can make this binding and still get std::string (which is std::basic_string<char>) for free with the default summary provider

>> Again, I think a summary for std::wstring (and std::basic_string<wchar_t>) would be enough for the purpose.
> Yes
>> 
>> What version of LLDB are you using? (LLDB has a "version" command you can use) This looks like an issue with the built-in synthetic children provider for class std::vector.
> LLDB-112

You may want to try on TOT

>> In order to test *your* wstring provider, you should have a single variable of type std::wstring and try to "frame variable" that one variable. Here, your entry point is the synthetic children provider for std::vector.
> Thats what I've allready done with:
> 
> (lldb) type synthetic add "std::wstring" --python-class wstring.StdWStringSynthProvider
> (lldb) frame variable aWideString
> (std::wstring) aWideString = {
>  HELLO WORLD!!! = 0x0000004500000048
> }
> 
> But when I have a vector of std::wstring the type of each element is std::basic_string<int, ...> and the synth. children provider gets not invoked (thats why I tried to use  "^(std::)?basic_string<.+>", without success)
> 
> (lldb) frame variable aWideStringVector
> (vector<std::basic_string<wchar_t>, std::allocator<std::basic_string<wchar_t> > >) aWideStringVector = {
>  [0] = {
>    _M_dataplus = {
>      _M_p = 0x0000000107300aa8
>    }
>  }
>  [1] = {
>    _M_dataplus = {
>      _M_p = 0x0000000107300bc8
>    }
>  }

This is promising, it looks like LLDB is displaying your vector items

>> again, what you're doing here is asking the std::vector synthetic children provider (built into LLDB) to provide you with child at index 0 - your wstring provider is not being invoked at this moment.
> The std::vector synthetic children provider returns the child at index 0. When lldb prints this child, the summary provider for wstring gets invoked, right?

Yes, right
>> 1) Probably not - if you're using a recent version of LLDB then this issue might need further testing. Otherwise, it seems a good idea to retry this with TOT
>> 2) Again, I would just use a summary string provider. On LLDB TOT, the attached Python file (which is a very slightly modified version of what you sent) works well in providing a summary for std::wstring
> Okay, the summary solution is obviously the better one. What is TOT? The latest lldb trunk version?

Yes, TOT is the latest trunk of LLDB that you download from svn and build yourself

>> (lldb) command script import wstring.py
>> (lldb) type summary add --python-function wstring.wstring_summary std::wstring
>> (lldb) frame variable
>> (std::wstring) foo = hello world
> Unfortunately, this does not work for me. LLDB seems not to invoke the summary provider:
> 
> (lldb) command script import /Users/nino.kettlitz/wstring.py
> (lldb) type summary clear
> (lldb) type summary add --python-function wstring.wstring_summary "std::wstring"
> (lldb) frame variable aWideString
> (std::wstring) aWideString = {
>  _M_dataplus = {
>    _M_p = 0x0000000107300b68
>  }
> }
> 
> 

Weird. But again, please use TOT before we explore other potential issues.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20120228/0b8b53e9/attachment.html>