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

[Pavel Labath via lldb-dev]

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

pl