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

[Greg Clayton via lldb-dev]

> On Oct 7, 2020, at 12:16 PM, Jim Ingham via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> 
> 
> 
>> On Oct 7, 2020, at 12:11 PM, Pavel Labath <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>> 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]+\]$


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