> On Oct 7, 2020, at 5:29 PM, Greg Clayton <clayb...@gmail.com> wrote: > > > >> On Oct 7, 2020, at 12:16 PM, Jim Ingham via lldb-dev >> <lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>> wrote: >> >> >> >>> On Oct 7, 2020, at 12:11 PM, Pavel Labath <pa...@labath.sk >>> <mailto:pa...@labath.sk>> wrote: >>> >>> On 07/10/2020 21:01, Jim Ingham wrote: >>>>> On Oct 7, 2020, at 11:44 AM, Pavel Labath <pa...@labath.sk >>>>> <mailto:pa...@labath.sk> <mailto:pa...@labath.sk >>>>> <mailto:pa...@labath.sk>>> wrote: >>>>> >>>>> On 07/10/2020 20:42, Jim Ingham via lldb-dev wrote: >>>>>> There isn’t a built-in summary formatter for two dimensional arrays of >>>>>> chars, but the type is matching the regex for the one-dimensional >>>>>> StringSummaryFormat, but that doesn’t actually know how to format two >>>>>> dimensional arrays of chars. The type regex for StringSummaryFormat: >>>>>> char [[0-9]+] >>>>>> We should refine this regex so it doesn’t catch up two dimensional >>>>>> strings. We could also write a formatter for two-dimensional strings. >>>>> >>>>> Do we need a special formatter for two-dimensional strings? What about 3D? >>>>> >>>>> I'd hope that this could be handled by a combination of the simple string >>>>> formatter and the generic array dumping code... >>>> That works as expected, for instance if you do: >>>> (lldb) frame var z.i >>>> (char [2][4]) z.i = { >>>> [0] = "FOO" >>>> [1] = "BAR" >>>> } >>>> The thing that isn’t working is when the array doesn’t get auto-expanded >>>> by lldb, then you see the summary instead, >>> >>> Ah, interesting. I didn't realize that. >>> >>>> which is what you are seeing with: >>>> (lldb) frame var z >>>> (b) z = (i = char [2][4] @ 0x00007ffeefbff5f0) >>>> You can fix this either by having a summary string for char [][] or by >>>> telling lldb to expand more pointer like children for you: >>>> (lldb) frame var -P2 z >>>> (b) z = { >>>> i = { >>>> [0] = "FOO" >>>> [1] = "BAR" >>>> } >>>> } >>>> I’m hesitant to up the default pointer depth, I have gotten lots of >>>> complaints already about lldb disclosing too many subfields when printing >>>> structures. >>> >>> Yeah, I don't think we'd want to increase that. >>> >>>> We could also try to be smarter about what constitutes a “pointer” so the >>>> arrays don’t count against the pointer depth? Not sure how workable that >>>> would be. >>> >>> This sounds workable. I mean, an array struct member is not really a >>> pointer (it only decays to a pointer) and does not suffer from the issues >>> that pointers do -- infinite recursion with recursive data structures, etc. >> >> In any case we should not have the simple string formatter trying to format >> these arrays, which it clearly doesn’t know how to do. > > Should be easy to modify the regex to: > > ^char \[[0-9]+\]$
I don’t think you want the ^ or this wouldn’t match “const char [5]”. I wasn’t sure there were any post-decorators we might care about, but I can’t think of any. Jim
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
