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

[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

Re: [lldb-dev] Force format for frame variable using type summary is not working as expected.

[Chirag Patel via lldb-dev]

Thanks for clarification.

>> It would make sense to pass the summary provider the requested format.  
>> SBValue has a GetFormat option, so if the format was properly set on the 
>> SBValue before it's passed to the summary provider, that would work already. 
>>  Then it's up to the summary providers to do whatever seems appropriate with 
>> that format.  
- Is it useful to pass forced format to summary provider?, as the different 
format is of no use to summary provider(I may be wrong.). E.g. array of char -> 
string, array of hex/dec values -> ?.

>> We could also just suppress the summary and go back to the raw view if the 
>> format has been set by the user.  Though in that case you would see:
- Currently on my local repo I do just that, I just skip the summary provider 
call if the target format is different than the ValueObject default format, In 
ValueObject itself.

Regards,

Chirag Patel
Software Engineer | Raincode Labs India 
Tel: (+91) 080 41159811
Mob: (+91) 9049336744
www.raincodelabs.com


-Original Message-
From: jing...@apple.com  
Sent: 09 January 2020 00:12
To: Chirag Patel 
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Force format for frame variable using type summary is 
not working as expected.

The way lldb works, char[] has a type summary that does two things, 1) presents 
the contents as a C-string, and 2) suppresses the actual printing of the 
elements.  If it hadn't done (2) then you would have seen the elements 
formatted as a vector of char's with the format you specified.  OTOH (2) is 
very desirable when you have a char[100].  You don't want to see the string 
then many individual char elements below it.

If you want to print the raw values of something that has a child suppressing 
summary, currently you "--raw -format x".

It would make sense to pass the summary provider the requested format.  SBValue 
has a GetFormat option, so if the format was properly set on the SBValue before 
it's passed to the summary provider, that would work already.  Then it's up to 
the summary providers to do whatever seems appropriate with that format.  

We could also just suppress the summary and go back to the raw view if the 
format has been set by the user.  Though in that case you would see:

(lldb) fr v -f x arr
(char [13]) arr = {
  [0] = 0x48
  [1] = 0x65
  [2] = 0x6c
  [3] = 0x6c
  [4] = 0x6f
  [5] = 0x20
  [6] = 0x57
  [7] = 0x6f
  [8] = 0x72
  [9] = 0x6c
  [10] = 0x64
  [11] = 0x21
  [12] = 0x00
}

since that's how arrays get printed in lldb.

Jim


> On Jan 8, 2020, at 12:09 AM, Chirag Patel via lldb-dev 
>  wrote:
> 
> Hello,
>  
> I am trying to debug a simple c program, int main() {
> char arr[] = "Hello World!";
> }
>  
> On gdb, while printing variable content with force formatting,
> (gdb) l
> 1   int main() {
> 2   char arr[] = "Hello World!";
> 3   }
> (gdb) b 3
> Breakpoint 2 at 0x40050a: file string.c, line 3.
> (gdb) r
> Starting program: /home/chirag/Desktop/test/./a.out
>  
> Breakpoint 2, main () at string.c:3
> 3   }
> (gdb) p arr
> $4 = "Hello World!"
> (gdb) p /d arr
> $5 = {72, 101, 108, 108, 111, 32, 87, 111, 114, 108, 100, 33, 0}
> (gdb) p /x arr
> $6 = {0x48, 0x65, 0x6c, 0x6c, 0x6f, 0x20, 0x57, 0x6f, 0x72, 0x6c, 
> 0x64, 0x21, 0x0}
> (gdb)
>  
>  
> While on lldb,
> (lldb) l
>1int main() {
>2char arr[] = "Hello World!";
>   3}
> (lldb) b 3
> Breakpoint 1: where = a.out`main + 29 at string.c:3, address = 
> 0x0040050a
> (lldb) r
> Process 59671 launched: '/home/chirag/Desktop/test/a.out' (x86_64) 
> Process 59671 stopped
> * thread #1, name = 'a.out', stop reason = breakpoint 1.1
> frame #0: 0x0040050a a.out`main at string.c:3
>1int main() {
>2char arr[] = "Hello World!";
> -> 3}
> (lldb) fr v arr
> (char [13]) arr = "Hello World!"
> (lldb) fr v arr -f d
> (char [13]) arr = "Hello World!"
> (lldb) fr v arr -f x
> (char [13]) arr = "Hello World!"
> (lldb)
>  
> It seems like lldb type summary is completely ignoring the force format 
> option, is it a bug or it is intended?
>  
> Regards,
>  
> Chirag Patel
> Software Engineer | Raincode Labs India
> Tel: (+91) 080 41159811
> Mob: (+91) 9049336744
> www.raincodelabs.com
> 
>  
> ___
> 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] Force format for frame variable using type summary is not working as expected.

[Chirag Patel via lldb-dev]

Hello,

I am trying to debug a simple c program,
int main() {
char arr[] = "Hello World!";
}

On gdb, while printing variable content with force formatting,
(gdb) l
1   int main() {
2   char arr[] = "Hello World!";
3   }
(gdb) b 3
Breakpoint 2 at 0x40050a: file string.c, line 3.
(gdb) r
Starting program: /home/chirag/Desktop/test/./a.out

Breakpoint 2, main () at string.c:3
3   }
(gdb) p arr
$4 = "Hello World!"
(gdb) p /d arr
$5 = {72, 101, 108, 108, 111, 32, 87, 111, 114, 108, 100, 33, 0}
(gdb) p /x arr
$6 = {0x48, 0x65, 0x6c, 0x6c, 0x6f, 0x20, 0x57, 0x6f, 0x72, 0x6c, 0x64, 0x21, 
0x0}
(gdb)


While on lldb,
(lldb) l
   1int main() {
   2char arr[] = "Hello World!";
  3}
(lldb) b 3
Breakpoint 1: where = a.out`main + 29 at string.c:3, address = 
0x0040050a
(lldb) r
Process 59671 launched: '/home/chirag/Desktop/test/a.out' (x86_64)
Process 59671 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x0040050a a.out`main at string.c:3
   1int main() {
   2char arr[] = "Hello World!";
-> 3}
(lldb) fr v arr
(char [13]) arr = "Hello World!"
(lldb) fr v arr -f d
(char [13]) arr = "Hello World!"
(lldb) fr v arr -f x
(char [13]) arr = "Hello World!"
(lldb)

It seems like lldb type summary is completely ignoring the force format option, 
is it a bug or it is intended?

Regards,

Chirag Patel
Software Engineer | Raincode Labs India
Tel: (+91) 080 41159811
Mob: (+91) 9049336744
www.raincodelabs.com
[linkedin-button]

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

[lldb-dev] LLDB target charset, libicu vs libiconv.

[Chirag Patel via lldb-dev]

Hello,


I am trying to read ebcdic(specially 1142) encoded string using lldb, but at 
the moment AFAIK lldb only support UTF8/16/32 and ASCII. (Please correct me if 
i am wrong).

i started looking into adding support for "target-charset", which is present on 
gdb and uses libiconv. There is one more, which can be used is libicu.


As both of them does the job and libicu is available for windows and on the 
other hand libicu is available packed with most of the linux distribution (or  
easily available on repo anyway.

I would appreciate which choice would be better for lldb. (in terms of lldb 
future support)


Thanks and regards,


Chirag Patel| Software Engineer
RAINCODE Mainframe to .NET

Tel : +91 080 41159811 | Mob : +91 90493 36744
www.raincodelabs.com
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] EBCDIC charset in lldb

[Chirag Patel via lldb-dev]

Hello,

I was looking to read ebcdic encoded string in lldb (cp1252), but did not able 
to find option as gdb has $set target-charset EBCDIC-US
Can anybody help me how to accomplice that?

Thanks and regards,

Chirag Patel| Software Engineer
RAINCODE Mainframe to .NET
Tel : +91 080 41159811 | Mob : +91 90493 36744
www.raincodelabs.com

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

Re: [lldb-dev] [LLDB]{Proposal} Adding new typesystem to support language like PLI/COBOL to lldb

[Chirag Patel via lldb-dev]

Ping.




Chirag Patel| Software Engineer
RAINCODE Mainframe to .NET

Tel : +91 080 41159811 | Mob : +91 90493 36744
www.raincodelabs.com<http://www.raincodelabs.com/>


From: paul.robin...@sony.com 
Sent: 11 October 2018 00:02:06
To: Chirag Patel
Cc: lldb-dev@lists.llvm.org; john.rea...@vmssoftware.com
Subject: RE: [LLDB]{Proposal} Adding new typesystem to support language like 
PLI/COBOL to lldb


John Reagan at VMS Software has made noises about adopting LLDB, in which case 
it would need to support PLI and COBOL types.  Looping him in directly.

--paulr



From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Chirag 
Patel via lldb-dev
Sent: Tuesday, October 09, 2018 6:56 AM
To: lldb-dev@lists.llvm.org
Subject: [lldb-dev] [LLDB]{Proposal} Adding new typesystem to support language 
like PLI/COBOL to lldb



Hello all,



I am looking into adding the new typesystem support for languages like 
PLI/COBOL.

Is anybody actively working/looking on this?



Regards,



Chirag Patel| Software Engineer
RAINCODE Mainframe to .NET

Tel : +91 080 41159811 | Mob : +91 90493 36744
www.raincodelabs.com<http://www.raincodelabs.com/>


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

[lldb-dev] [LLDB]{Proposal} Adding new typesystem to support language like PLI/COBOL to lldb

[Chirag Patel via lldb-dev]

Hello all,

I am looking into adding the new typesystem support for languages like 
PLI/COBOL.
Is anybody actively working/looking on this?

Regards,

Chirag Patel| Software Engineer
RAINCODE Mainframe to .NET
Tel : +91 080 41159811 | Mob : +91 90493 36744
www.raincodelabs.com

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

Re: [lldb-dev] Proposal for bi-endian code debugging support for lldb.

[Chirag Patel via lldb-dev]

Ping!

Chirag Patel| Software Engineer
RAINCODE Mainframe to .NET
Tel : +91 080 41159811 | Mob : +91 90493 36744
www.raincodelabs.com<http://www.raincodelabs.com/>

From: lldb-dev  On Behalf Of Chirag Patel via 
lldb-dev
Sent: 04 October 2018 11:34
To: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Proposal for bi-endian code debugging support for lldb.

For the moment I am planning to add it for clang typesystem.


Chirag Patel| Software Engineer
RAINCODE Mainframe to .NET
Tel : +91 080 41159811 | Mob : +91 90493 36744
www.raincodelabs.com<http://www.raincodelabs.com/>

From: lldb-dev 
mailto:lldb-dev-boun...@lists.llvm.org>> On 
Behalf Of Chirag Patel via lldb-dev
Sent: 04 October 2018 11:15
To: lldb-dev@lists.llvm.org<mailto:lldb-dev@lists.llvm.org>
Subject: [lldb-dev] Proposal for bi-endian code debugging support for lldb.

Hello,

Kindly correct me if I am wrong.

Now llvm has the interface to set endianity on base_types, I am looking into 
the support for lldb to debug bi-endian code (with attribute DW_AT_endianity).
Currently I am planning to record the endianity/byte-order in CompilerType 
object with context and type(inclue/lldb/Symbol/ConpilerType.h) and pass it 
along to the parent(struct/union) and while reading/wrinting data using 
data-extractor setting the byte order on that.
Any suggestions are welcomed.

Regards,

Chirag Patel| Software Engineer
RAINCODE Mainframe to .NET
Tel : +91 080 41159811 | Mob : +91 90493 36744
www.raincodelabs.com<http://www.raincodelabs.com/>

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

[lldb-dev] Proposal for bi-endian code debugging support for lldb.

[Chirag Patel via lldb-dev]

Hello,

Kindly correct me if I am wrong.

Now llvm has the interface to set endianity on base_types, I am looking into 
the support for lldb to debug bi-endian code (with attribute DW_AT_endianity).
Currently I am planning to record the endianity/byte-order in CompilerType 
object with context and type(inclue/lldb/Symbol/ConpilerType.h) and pass it 
along to the parent(struct/union) and while reading/wrinting data using 
data-extractor setting the byte order on that.
Any suggestions are welcomed.

Regards,

Chirag Patel| Software Engineer
RAINCODE Mainframe to .NET
Tel : +91 080 41159811 | Mob : +91 90493 36744
www.raincodelabs.com

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

[lldb-dev] Scaler_Storage_order support in lldb.

[Chirag Patel via lldb-dev]

Hello,


I am currently looking into supporting the scaler_storage_order attribute 
support in lldb clang type system, namely DW_AT_endianity attribute on 
DW_TAG_base_type.(for the time being i will add on DW_TAG_variable support 
later)


I am planning to encode that attribute in heap-allocated Extended qualifier 
same used in clang front-end and decode it in clang expression parser decl map 
to set the byte order in data extractor.


currently the ExtQuals is missing from lldb.


Is above design seems sane enough?


i have chose ExtQual because it will be rarely used and QualType is full, it 
will also go hand in hand with frontend for sso attribute.


Thanks and Regards,


Chirag Patel| Software Engineer
RAINCODE Mainframe to .NET

Tel : +91 080 41159811 | Mob : +91 90493 36744
www.raincodelabs.com
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev