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

2020-10-07 Thread Jim Ingham via lldb-dev 


> On Oct 7, 2020, at 5:29 PM, Greg Clayton  wrote:
> 
> 
> 
>> On Oct 7, 2020, at 12:16 PM, Jim Ingham via lldb-dev 
>> mailto:lldb-dev@lists.llvm.org>> wrote:
>> 
>> 
>> 
>>> On Oct 7, 2020, at 12:11 PM, Pavel Labath >> > wrote:
>>> 
>>> On 07/10/2020 21:01, Jim Ingham wrote:
> On Oct 7, 2020, at 11:44 AM, Pavel Labath    >> 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] @ 0x7ffeefbff5f0)
 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

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

2020-10-07 Thread Greg Clayton via lldb-dev 


> On Oct 7, 2020, at 12:16 PM, Jim Ingham via lldb-dev 
>  wrote:
> 
> 
> 
>> On Oct 7, 2020, at 12:11 PM, Pavel Labath  wrote:
>> 
>> On 07/10/2020 21:01, Jim Ingham wrote:
 On Oct 7, 2020, at 11:44 AM, Pavel Labath >>> > 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] @ 0x7ffeefbff5f0)
>>> 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]+\]$


___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

2020-10-07 Thread Jim Ingham via lldb-dev 


> On Oct 7, 2020, at 12:11 PM, Pavel Labath  wrote:
> 
> On 07/10/2020 21:01, Jim Ingham wrote:
>>> On Oct 7, 2020, at 11:44 AM, Pavel Labath >> > 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] @ 0x7ffeefbff5f0)
>> 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.

Jim


> 
> pl

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

2020-10-07 Thread Pavel Labath via lldb-dev 

On 07/10/2020 21:01, Jim Ingham wrote:



On Oct 7, 2020, at 11:44 AM, Pavel Labath > 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] @ 0x7ffeefbff5f0)

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
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

2020-10-07 Thread Jim Ingham via lldb-dev 


> On Oct 7, 2020, at 11:44 AM, Pavel Labath  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] @ 0x7ffeefbff5f0)

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

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

2020-10-07 Thread Pavel Labath via lldb-dev 

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


pl
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

2020-10-07 Thread Jim Ingham via lldb-dev 
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.  

Would you file bugs about those two issues with http://bugs.llvm.org? 
  Thanks.

Note that user added formatters are scanned first and the match is granted to 
the first hit, so if you need this yourself, in the meantime you could write 
your own formatter and it should fire.

Jim


> On Oct 7, 2020, at 5:26 AM, Chirag Patel via lldb-dev 
>  wrote:
> 
> Hello all,
>  
> While debugging and printing struct with multi-dimensional char array, gdb 
> successfully prints string while lldb bails out with only printing address.
> For simple C testcase,
>  
> struct b {
> char i[2][4];
> };
>  
> int main() {
> struct b z;
> z.i[0][0] = 'F';
> z.i[0][1] = 'O';
> z.i[0][2] = 'O';
> z.i[0][3] = 0;
> z.i[1][0] = 'B';
> z.i[1][1] = 'A';
> z.i[1][2] = 'R';
> z.i[1][3] = 0;
> return 0;
> }
>  
> On gdb,
> Reading symbols from /home/chirag/a.out...done.
> (gdb) l
> 1   struct b {
> 2   char i[2][4];
> 3   };
> 4
> 5   int main() {
> 6   struct b z;
> 7   z.i[0][0] = 'F';
> 8   z.i[0][1] = 'O';
> 9   z.i[0][2] = 'O';
> 10  z.i[0][3] = 0;
> (gdb) l
> 11  z.i[1][0] = 'B';
> 12  z.i[1][1] = 'A';
> 13  z.i[1][2] = 'R';
> 14  z.i[1][3] = 0;
> 15  return 0;
> 16  }
> (gdb) b 15
> Breakpoint 1 at 0x400511: file Desktop/test/struct.c, line 15.
> (gdb) r
> Starting program: /home/chirag/./a.out
>  
> Breakpoint 1, main () at Desktop/test/struct.c:15
> 15  return 0;
> Missing separate debuginfos, use: debuginfo-install 
> glibc-2.17-307.el7.1.x86_64
> (gdb) p z
> $1 = {i = {"FOO", "BAR"}}
> (gdb) q
> A debugging session is active.
>  
> While on lldb 11.0.0-rc2, (lldb) target create "/home/chirag/a.out"
> Current executable set to '/home/chirag/a.out' (x86_64).
> (lldb) b 15
> Breakpoint 1: where = a.out`main + 36 at struct.c:15, address = 
> 0x00400511
> (lldb) r
> Process 57100 launched: '/home/chirag/a.out' (x86_64)
> Process 57100 stopped
> * thread #1, name = 'a.out', stop reason = breakpoint 1.1
> frame #0: 0x00400511 a.out`main at struct.c:15
>12   z.i[1][1] = 'A';
>13   z.i[1][2] = 'R';
>14   z.i[1][3] = 0;
> -> 15   return 0;
>16   }
> (lldb) p z
> (b) $0 = (i = char [2][4] @ 0x01fe3ca0)
> (lldb) q
>  
> It seems like the type summary formatter is failing? Or is it the intended 
> behaviour?.
>  
> Thanks and Regards,
> Chirag Patel.
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org 
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
> 
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 47743] LLDB displays wrong values for packed bitfields

2020-10-07 Thread via lldb-dev 
https://bugs.llvm.org/show_bug.cgi?id=47743

lab...@google.com changed:

   What|Removed |Added

   Assignee|lldb-dev@lists.llvm.org |lab...@google.com

--- Comment #3 from lab...@google.com ---
I have a fix up at https://reviews.llvm.org/D88992. Could you please check
whether that fixes your problem? (The problem I ran into triggers in only very
specific circumstances, but judging by your description, you may have run into
something more generic.)

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] n00b error running lldb tests on windows?

2020-10-07 Thread Joseph Tremoulet via lldb-dev 
Hi,

I'm trying to run the lldb tests on Windows (fresh installs of VS2019 16.7.5, 
Python 3.8.5, and Swig 4.0.2).  The API tests crash immediately in python 
initialization code:

Windows fatal exception: access violation

Current thread 0x693c (most recent call first):
  File "", line 219 in _call_with_frames_removed
  File "", line 1101 in create_module
  File "", line 556 in module_from_spec
  File "", line 657 in _load_unlocked
  File "", line 975 in _find_and_load_unlocked
  File "", line 991 in _find_and_load
  File "", line 219 in _call_with_frames_removed
  File "", line 1042 in _handle_fromlist
  File "D:\Obj\lldb\Debug\Lib\site-packages\lldb\__init__.py", line 41 in 

  File "", line 219 in _call_with_frames_removed
  File "", line 783 in exec_module
  File "", line 671 in _load_unlocked
  File "", line 975 in _find_and_load_unlocked
  File "", line 991 in _find_and_load
  File "D:\Source\llvm-project\lldb\packages\Python\lldbsuite\test\dotest.py", 
line 898 in run_suite
  File "D:/Source/llvm-project/lldb\test\API\dotest.py", line 7 in 

Running in the debugger, I see "_PyRuntime.gc.generation0 was nullptr".

I presume I have something set up incorrectly in my environment, but I haven't 
had much luck figuring out what.  Is this by any chance an error/stack that 
somebody recognizes as a common/known issue?

Thanks,
-Joseph

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [11.0.0 Release] Release Candidate 6 is here

2020-10-07 Thread Hans Wennborg via lldb-dev 
Hello once again,

A few more issues appeared, so here is yet another release candidate:
llvmorg-11.0.0-rc6 was just tagged.

Source code and docs are available at
https://prereleases.llvm.org/11.0.0/#rc6
and
https://github.com/llvm/llvm-project/releases/tag/llvmorg-11.0.0-rc6

Pre-built binaries will be added as they become ready.

Please file reports for any bugs you find as blockers of
https://llvm.org/pr46725

Release testers, if you still have cycles, please take this for a
quick spin. The changes from rc5 are minimal, and hopefully we can tag
this as the final version very soon now.

Thanks,
Hans
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

2020-10-07 Thread Chirag Patel via lldb-dev 
Hello all,

While debugging and printing struct with multi-dimensional char array, gdb 
successfully prints string while lldb bails out with only printing address.
For simple C testcase,

struct b {
char i[2][4];
};

int main() {
struct b z;
z.i[0][0] = 'F';
z.i[0][1] = 'O';
z.i[0][2] = 'O';
z.i[0][3] = 0;
z.i[1][0] = 'B';
z.i[1][1] = 'A';
z.i[1][2] = 'R';
z.i[1][3] = 0;
return 0;
}

On gdb,
Reading symbols from /home/chirag/a.out...done.
(gdb) l
1   struct b {
2   char i[2][4];
3   };
4
5   int main() {
6   struct b z;
7   z.i[0][0] = 'F';
8   z.i[0][1] = 'O';
9   z.i[0][2] = 'O';
10  z.i[0][3] = 0;
(gdb) l
11  z.i[1][0] = 'B';
12  z.i[1][1] = 'A';
13  z.i[1][2] = 'R';
14  z.i[1][3] = 0;
15  return 0;
16  }
(gdb) b 15
Breakpoint 1 at 0x400511: file Desktop/test/struct.c, line 15.
(gdb) r
Starting program: /home/chirag/./a.out

Breakpoint 1, main () at Desktop/test/struct.c:15
15  return 0;
Missing separate debuginfos, use: debuginfo-install glibc-2.17-307.el7.1.x86_64
(gdb) p z
$1 = {i = {"FOO", "BAR"}}
(gdb) q
A debugging session is active.

While on lldb 11.0.0-rc2, (lldb) target create "/home/chirag/a.out"
Current executable set to '/home/chirag/a.out' (x86_64).
(lldb) b 15
Breakpoint 1: where = a.out`main + 36 at struct.c:15, address = 
0x00400511
(lldb) r
Process 57100 launched: '/home/chirag/a.out' (x86_64)
Process 57100 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x00400511 a.out`main at struct.c:15
   12   z.i[1][1] = 'A';
   13   z.i[1][2] = 'R';
   14   z.i[1][3] = 0;
-> 15   return 0;
   16   }
(lldb) p z
(b) $0 = (i = char [2][4] @ 0x01fe3ca0)
(lldb) q

It seems like the type summary formatter is failing? Or is it the intended 
behaviour?.

Thanks and Regards,
Chirag Patel.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev