[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] [10.0.0 Release] One week to the branch

[Hans Wennborg via lldb-dev]

Hi everyone,

This is just a quick reminder that the upcoming release branch is
scheduled for one week from today: Wednesday, 15 January 2020.

When the branch is created, the trunk version will become 11.0.0.

The full release schedule can be found under "Upcoming Releases" in
the column to the right at https://llvm.org

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

Re: [lldb-dev] [cfe-dev] LLVM 9.0.1-final has been tagged

[Brian Cain via lldb-dev]

Tom, the 9.0.1 final binaries didn't (yet?) make it to the github release
page https://github.com/llvm/llvm-project/releases/tag/llvmorg-9.0.1

I also checked https://releases.llvm.org/ because I recall some debate or
back-and-forth about where the releases should go and/or redirects or links
from one to the other.  But they're not there either.

On Thu, Dec 19, 2019 at 10:07 PM Tom Stellard via cfe-dev <
cfe-...@lists.llvm.org> wrote:

> Hi,
>
> I've just tagged the 9.0.1-final release.  Testers can begin uploading
> binaries.
>
> -Tom
>
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>


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

[Jim Ingham via lldb-dev]

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] External API available from within debugged process

[Ilya Kulakov via lldb-dev]

Hi,

I was recently working on a debugging utility code in my app that ultimately 
needed to access some of the non-exported symbols from a linked shared library.

This code would only be run under DEBUG builds and is only useful when 
debugger's CLI is present. With that constraint I hoped to somehow utilize 
debugger
in recovering an address of the non-exported-but-in-symbols-table function.

A straightforward solution is to pause the debugger, run the necessary image 
lookup command and then store the result into some global variable.
This unfortunately requires manual user interaction.

Less straightforward solution is to have an LLDB script run automatically after 
the shared library gets loaded (hook or some for-sure-loaded breakpoint).
This is not ideal since I seldom script the debugger (learning curve is 
daunting) and would still require user interaction to set up the script (maybe 
a major obstacle for the end user).

A "Simple" solution that popped in my mind  was to talk to the debugger 
directly from within the app. Via the C API or remote access (XPC, D-Bus etc).
But I couldn't find anything even remotely similar neither for lldb nor gdb.

Did I overlook it? Is there a solid reason to not to have such API exposed?

I understand that many debugger's capabilities are outright dangerous to 
provide from within the app, but it would be nice to have an access to readonly 
lookups.

Best Regards,
Ilya Kulakov

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

Re: [lldb-dev] Optional Dependencies in LLDB

[Jonas Devlieghere via lldb-dev]

Yes, that's correct. This was added in edadb818e5b.

On Tue, Jan 7, 2020 at 11:19 PM Martin Storsjö  wrote:
>
> On Tue, 7 Jan 2020, Jonas Devlieghere wrote:
>
> > After trying it out I concluded that it should be easy enough to check
> > for the static bindings flag in FindPythonInterpAndLibs.cmake so I've
> > implemented your suggestion in fc6f15d4d2c. Thanks again for bringing
> > this up.
>
> Awesome, thanks!
>
> Do I understand this correctly that something similar still would be
> needed for Lua though?
>
> // Martin
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Optional Dependencies in LLDB

[Adrian Prantl via lldb-dev]

> On Jan 6, 2020, at 11:17 AM, Jonas Devlieghere via lldb-dev 
>  wrote:
> 
> Hey everyone,
> 
> I just wanted to let you know that most of the work is complete for
> auto-detecting optional dependencies in LLDB. Unless explicitly
> specified, optional dependencies like editline will be enabled when
> available and disabled otherwise. 

This "explicitly specified" mode makes it possible to declare that I want it to 
be hard error if an optional dependency is missing (e.g., to avoid silently 
dropping editline support by accident)?

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

Re: [lldb-dev] Optional Dependencies in LLDB

[Jonas Devlieghere via lldb-dev]

On Wed, Jan 8, 2020 at 2:46 PM Adrian Prantl  wrote:
>
>
>
> > On Jan 6, 2020, at 11:17 AM, Jonas Devlieghere via lldb-dev 
> >  wrote:
> >
> > Hey everyone,
> >
> > I just wanted to let you know that most of the work is complete for
> > auto-detecting optional dependencies in LLDB. Unless explicitly
> > specified, optional dependencies like editline will be enabled when
> > available and disabled otherwise.
>
> This "explicitly specified" mode makes it possible to declare that I want it 
> to be hard error if an optional dependency is missing (e.g., to avoid 
> silently dropping editline support by accident)?

Correct, setting any of the LLDB_ENABLE_* to ON and the dependency not
being found will cause a CMake configuration error.

>
> -- adrian
___
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

Re: [lldb-dev] [cfe-dev] LLVM 9.0.1-final has been tagged

[Tom Stellard via lldb-dev]

On 01/08/2020 09:24 AM, Brian Cain wrote:
> Tom, the 9.0.1 final binaries didn't (yet?) make it to the github release 
> page https://github.com/llvm/llvm-project/releases/tag/llvmorg-9.0.1 
> 

The binaries have been posted now.

> I also checked https://releases.llvm.org/ because I recall some debate or 
> back-and-forth about where the releases should go and/or redirects or links 
> from one to the other.  But they're not there either.
> 

I'm working on fixing the releases.llvm.org page.

-Tom

> On Thu, Dec 19, 2019 at 10:07 PM Tom Stellard via cfe-dev 
> mailto:cfe-...@lists.llvm.org>> wrote:
> 
> Hi,
> 
> I've just tagged the 9.0.1-final release.  Testers can begin uploading 
> binaries.
> 
> -Tom
> 
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org 
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> 
> 
> 
> -- 
> -Brian

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

Re: [lldb-dev] Optional Dependencies in LLDB

[Martin Storsjö via lldb-dev]

On Wed, 8 Jan 2020, Jonas Devlieghere wrote:


Yes, that's correct. This was added in edadb818e5b.


Thanks!

// Martin

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