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

[Jim Ingham via lldb-dev]

> On Oct 7, 2020, at 11:44 AM, Pavel Labath <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, 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.

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.

Jim


> 
> pl

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