[lldb-dev] lldb 11.0.0-rc2 different behavior then gdb.

[Jim Ingham via lldb-dev]

> On Oct 7, 2020, at 5:29 PM, Greg Clayton <clayborg at gmail.com> wrote:
> 
> 
> 
>> On Oct 7, 2020, at 12:16 PM, Jim Ingham via lldb-dev <lldb-dev at lists.llvm.org <mailto:lldb-dev at lists.llvm.org>> wrote:
>> 
>> 
>> 
>>> On Oct 7, 2020, at 12:11 PM, Pavel Labath <pavel at labath.sk <mailto:pavel at labath.sk>> wrote:
>>> 
>>> On 07/10/2020 21:01, Jim Ingham wrote:
>>>>> On Oct 7, 2020, at 11:44 AM, Pavel Labath <pavel at labath.sk <mailto:pavel at labath.sk> <mailto:pavel at labath.sk <mailto:pavel at 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20201007/5b678aaa/attachment.html>