Re: [lldb-dev] [Release-testers] [6.0.0 Release] Release Candidate 2 tagged

[Hans Wennborg via lldb-dev]

Thanks! I've added the binaries to http://prereleases.llvm.org/6.0.0/

On Tue, Feb 13, 2018 at 10:57 PM, Simon Dardis  wrote:
> Hi Hans,
>
> I'm seeing one unexpected failure:
>
> libc++ :: 
> std/input.output/stream.buffers/streambuf/streambuf.protected/streambuf.put.area/pbump2gig.pass.cpp
>
> Test logs show:
>
> Standard Error:
> --
> terminating with uncaught exception of type std::length_error: basic_string
> --
>
> but only on my big endian MIPS machine. I have filed PR36373 for the above 
> failure.
>
> I've looked at the failures from Msan from the previous rc candidate, and 
> have been unable to reproduce them. What
> I have seen is that the observed test failures from rc1, rc1 investigations 
> and rc2 are transient.
>
> Binaries uploaded.
>
> SHA256(clang+llvm-6.0.0-rc2-mipsel-linux-gnu.tar.xz)= 
> 0e446f60a1649680a49b048ad1429d4e327d1839dbbc8b34f1bd81e3277a98ee
> SHA256(clang+llvm-6.0.0-rc2-mips-linux-gnu.tar.xz)= 
> bdec9b0fe00cfdeefe53b8e471b9266ad9a99dfd10eded5e078026f67a38650a
> SHA256(clang+llvm-6.0.0-rc2-x86_64-linux-gnu-debian8.tar.xz)= 
> e6a281885d2f0fbc4e00bdc34803f67bb756f19badef3f24ed3738b2244c57cc
>
> Thanks,
> Simon
> 
> From: Release-testers [release-testers-boun...@lists.llvm.org] on behalf of 
> Hans Wennborg via Release-testers [release-test...@lists.llvm.org]
> Sent: Wednesday, February 7, 2018 8:51 PM
> To: Release-testers
> Cc: llvm-dev; cfe-dev; openmp-dev (openmp-...@lists.llvm.org); LLDB Dev
> Subject: [Release-testers] [6.0.0 Release] Release Candidate 2 tagged
>
> Dear testers,
>
> There's been a lot of merges since rc1, and hopefully the tests are in
> a better state now.
>
> 6.0.0-rc2 was just tagged, after r324506.
>
> Please test, let me know how it goes, and upload binaries.
>
> Thanks,
> Hans
> ___
> Release-testers mailing list
> release-test...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Querying build configuration of (lib)lldb from tests.

[Jim Ingham via lldb-dev]

The idea of having a static function in SBDebugger that returns lldb 
configuration information seems good to me.

Having the API return an SBStructuredData with the full configuration 
information seems like a pretty future-proof way to do this.  I can't see that 
this data will get sufficiently large that consing up the whole set of config 
options to answer a single question is going to be a problem, and the info is 
constant for the run of lldb, so you can cache the result.

Jim


> On Feb 5, 2018, at 4:01 AM, Pavel Labath via lldb-dev 
>  wrote:
> 
> Hello all,
> 
> In  we have a feature that only works
> when lldb was built with xml support. To  test this, we need the test
> to know whether we were build with xml support.
> 
> The typical llvm solution would be to generate some dotest equivalent
> of lit.site.cfg at build time, which we could then load from the test
> and query for build settings.
> 
> However, it has occurred to me that the information about various
> build properties (xml suport, libedit support, list of llvm targets we
> support) is something that could be useful to other liblldb clients as
> well. So, another way of exposing this would be to have a function
> (maybe a static function on SBDebugger ?) that the test can call and
> get the required information that way.
> 
> Do you have any thoughts on how this should be handled? Or maybe know
> of an existing way that we could check this information already?
> 
> regards,
> pavel
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

Re: [lldb-dev] Querying build configuration of (lib)lldb from tests.

[Greg Clayton via lldb-dev]

I second Jim's idea for a static function on SBDebugger that returns a 
SBStructuredData

> On Feb 14, 2018, at 10:31 AM, Jim Ingham via lldb-dev 
>  wrote:
> 
> The idea of having a static function in SBDebugger that returns lldb 
> configuration information seems good to me.
> 
> Having the API return an SBStructuredData with the full configuration 
> information seems like a pretty future-proof way to do this.  I can't see 
> that this data will get sufficiently large that consing up the whole set of 
> config options to answer a single question is going to be a problem, and the 
> info is constant for the run of lldb, so you can cache the result.
> 
> Jim
> 
> 
>> On Feb 5, 2018, at 4:01 AM, Pavel Labath via lldb-dev 
>>  wrote:
>> 
>> Hello all,
>> 
>> In  we have a feature that only works
>> when lldb was built with xml support. To  test this, we need the test
>> to know whether we were build with xml support.
>> 
>> The typical llvm solution would be to generate some dotest equivalent
>> of lit.site.cfg at build time, which we could then load from the test
>> and query for build settings.
>> 
>> However, it has occurred to me that the information about various
>> build properties (xml suport, libedit support, list of llvm targets we
>> support) is something that could be useful to other liblldb clients as
>> well. So, another way of exposing this would be to have a function
>> (maybe a static function on SBDebugger ?) that the test can call and
>> get the required information that way.
>> 
>> Do you have any thoughts on how this should be handled? Or maybe know
>> of an existing way that we could check this information already?
>> 
>> regards,
>> pavel
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[lldb-dev] How to test lldb-vscode?

[Greg Clayton via lldb-dev]

I have a patch I will be submitting soon that adds a tool called "lldb-vscode" 
that is much like "lldb-mi" where it sits on top of LLDB.framework on Darwin 
and liblldb.so on all other platforms, and it speaks the Visual Studio Code 
Debug adaptor language and can be used to create a VSCode extension that does 
native LLDB debugging. The plug-in works really well to debug native apps and 
is very responsive and quick. 

One issue I am thinking about is how to test this. Some VS Code tests out there 
use Javascript + npm to run a mock VSCode IDE and send/receive packets. I am 
not sure we can require people to have this on all build bots. So I am writing 
to get everyone's opinion on this so I can test this and get a patch submitted.

Any ideas would be appreciated.

Greg Clayton

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

Re: [lldb-dev] How to test lldb-vscode?

[Vadim Chugunov via lldb-dev]

FYI - I've been maintaining a similar VSCode extension
,
which does it all through LLDB's Python interface.

As for testing, the protocol is JSON with HTTP-like headers for framing, so
you could have a Python script emulating the VSCode side.


On Wed, Feb 14, 2018 at 2:28 PM, Greg Clayton via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> I have a patch I will be submitting soon that adds a tool called
> "lldb-vscode" that is much like "lldb-mi" where it sits on top of
> LLDB.framework on Darwin and liblldb.so on all other platforms, and it
> speaks the Visual Studio Code Debug adaptor language and can be used to
> create a VSCode extension that does native LLDB debugging. The plug-in
> works really well to debug native apps and is very responsive and quick.
>
> One issue I am thinking about is how to test this. Some VS Code tests out
> there use Javascript + npm to run a mock VSCode IDE and send/receive
> packets. I am not sure we can require people to have this on all build
> bots. So I am writing to get everyone's opinion on this so I can test this
> and get a patch submitted.
>
> Any ideas would be appreciated.
>
> Greg Clayton
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] How to test lldb-vscode?

[Greg Clayton via lldb-dev]

> On Feb 14, 2018, at 3:45 PM, Vadim Chugunov  wrote:
> 
> FYI - I've been maintaining a similar VSCode extension 
> , 
> which does it all through LLDB's Python interface. 

Indeed, I saw you plug-in and since it worked so well I wanted to make a native 
version of this plug-in to avoid taking over the python interpreter and get 
native performance. Very nice work on that plug-in as it inspired this one! I 
adopted many similar settings that you allow in the launch.json file and added 
some new ones.

> 
> As for testing, the protocol is JSON with HTTP-like headers for framing, so 
> you could have a Python script emulating the VSCode side.

That is what I was planning to do. Might be nice to work together on this and 
get the testing working as it could test both of our plug-ins. Would be great 
to have a debug session with a simple program that sets a breakpoint by name, 
by file and line and exception and run, hit the breakpoints, view variables, 
etc.

Greg

> 
> 
> On Wed, Feb 14, 2018 at 2:28 PM, Greg Clayton via lldb-dev 
> mailto:lldb-dev@lists.llvm.org>> wrote:
> I have a patch I will be submitting soon that adds a tool called 
> "lldb-vscode" that is much like "lldb-mi" where it sits on top of 
> LLDB.framework on Darwin and liblldb.so on all other platforms, and it speaks 
> the Visual Studio Code Debug adaptor language and can be used to create a 
> VSCode extension that does native LLDB debugging. The plug-in works really 
> well to debug native apps and is very responsive and quick.
> 
> One issue I am thinking about is how to test this. Some VS Code tests out 
> there use Javascript + npm to run a mock VSCode IDE and send/receive packets. 
> I am not sure we can require people to have this on all build bots. So I am 
> writing to get everyone's opinion on this so I can test this and get a patch 
> submitted.
> 
> Any ideas would be appreciated.
> 
> Greg Clayton
> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org 
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
> 
> 

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

Re: [lldb-dev] How to test lldb-vscode?

[Vadim Chugunov via lldb-dev]

My tests are here
.
I probably wouldn't move all that to Python for my extension, but feel free
to draw ideas on things to test from it.

What's going to be your deployment story?   The nice thing about
Python-based adapter is that it will run on a wide range on LLDB versions.
For a native adapter you'll need to somehow make sure that you have the
right liblldb installed, won't you?


On Wed, Feb 14, 2018 at 3:54 PM, Greg Clayton  wrote:

>
>
> On Feb 14, 2018, at 3:45 PM, Vadim Chugunov  wrote:
>
> FYI - I've been maintaining a similar VSCode extension
> ,
> which does it all through LLDB's Python interface.
>
>
> Indeed, I saw you plug-in and since it worked so well I wanted to make a
> native version of this plug-in to avoid taking over the python interpreter
> and get native performance. Very nice work on that plug-in as it inspired
> this one! I adopted many similar settings that you allow in the launch.json
> file and added some new ones.
>
>
> As for testing, the protocol is JSON with HTTP-like headers for framing,
> so you could have a Python script emulating the VSCode side.
>
>
> That is what I was planning to do. Might be nice to work together on this
> and get the testing working as it could test both of our plug-ins. Would be
> great to have a debug session with a simple program that sets a breakpoint
> by name, by file and line and exception and run, hit the breakpoints, view
> variables, etc.
>
> Greg
>
>
>
> On Wed, Feb 14, 2018 at 2:28 PM, Greg Clayton via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> I have a patch I will be submitting soon that adds a tool called
>> "lldb-vscode" that is much like "lldb-mi" where it sits on top of
>> LLDB.framework on Darwin and liblldb.so on all other platforms, and it
>> speaks the Visual Studio Code Debug adaptor language and can be used to
>> create a VSCode extension that does native LLDB debugging. The plug-in
>> works really well to debug native apps and is very responsive and quick.
>>
>> One issue I am thinking about is how to test this. Some VS Code tests out
>> there use Javascript + npm to run a mock VSCode IDE and send/receive
>> packets. I am not sure we can require people to have this on all build
>> bots. So I am writing to get everyone's opinion on this so I can test this
>> and get a patch submitted.
>>
>> Any ideas would be appreciated.
>>
>> Greg Clayton
>>
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] How to test lldb-vscode?

[Jim Ingham via lldb-dev]

The SB API's were designed to be binary stable API's when used either from C++ 
or Python (the latter are just a SWIG-ified version of the former.)  So just 
like the Python wrapper, with the exception that you might call an API that 
some older version of liblldb doesn't provide, Greg's adaptor wouldn't be 
sensitive to lldb library version.

Jim


> On Feb 14, 2018, at 4:43 PM, Vadim Chugunov via lldb-dev 
>  wrote:
> 
> My tests are here.   I probably wouldn't move all that to Python for my 
> extension, but feel free to draw ideas on things to test from it.
> 
> What's going to be your deployment story?   The nice thing about Python-based 
> adapter is that it will run on a wide range on LLDB versions.  For a native 
> adapter you'll need to somehow make sure that you have the right liblldb 
> installed, won't you?
> 
> 
> On Wed, Feb 14, 2018 at 3:54 PM, Greg Clayton  wrote:
> 
> 
>> On Feb 14, 2018, at 3:45 PM, Vadim Chugunov  wrote:
>> 
>> FYI - I've been maintaining a similar VSCode extension, which does it all 
>> through LLDB's Python interface. 
> 
> Indeed, I saw you plug-in and since it worked so well I wanted to make a 
> native version of this plug-in to avoid taking over the python interpreter 
> and get native performance. Very nice work on that plug-in as it inspired 
> this one! I adopted many similar settings that you allow in the launch.json 
> file and added some new ones.
> 
>> 
>> As for testing, the protocol is JSON with HTTP-like headers for framing, so 
>> you could have a Python script emulating the VSCode side.
> 
> That is what I was planning to do. Might be nice to work together on this and 
> get the testing working as it could test both of our plug-ins. Would be great 
> to have a debug session with a simple program that sets a breakpoint by name, 
> by file and line and exception and run, hit the breakpoints, view variables, 
> etc.
> 
> Greg
> 
>> 
>> 
>> On Wed, Feb 14, 2018 at 2:28 PM, Greg Clayton via lldb-dev 
>>  wrote:
>> I have a patch I will be submitting soon that adds a tool called 
>> "lldb-vscode" that is much like "lldb-mi" where it sits on top of 
>> LLDB.framework on Darwin and liblldb.so on all other platforms, and it 
>> speaks the Visual Studio Code Debug adaptor language and can be used to 
>> create a VSCode extension that does native LLDB debugging. The plug-in works 
>> really well to debug native apps and is very responsive and quick.
>> 
>> One issue I am thinking about is how to test this. Some VS Code tests out 
>> there use Javascript + npm to run a mock VSCode IDE and send/receive 
>> packets. I am not sure we can require people to have this on all build bots. 
>> So I am writing to get everyone's opinion on this so I can test this and get 
>> a patch submitted.
>> 
>> Any ideas would be appreciated.
>> 
>> Greg Clayton
>> 
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>> 
> 
> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[lldb-dev] Pending breakpoints to dlsym()ed functions

[Dmitry Antipov via lldb-dev]

I'm trying to setup a pending breakpoint for sin() and cos() which are 
dlsym()ed from libm.so
(sample attached), and an attempt to continue execution seems just hangs the 
debugger. For example:

(lldb) attach 17043
Process 17043 stopped
* thread #1, name = 't-dlopen', stop reason = signal SIGSTOP
frame #0: 0x00400728 t-dlopen`main(argc=1, argv=0x7ffd2b0a00c8) 
at t-dlopen.c:21
   18 for (a = 0; a < DELAY + argc; a++)
   19   for (b = 0; b < DELAY + argc; b++)
   20 for (c = 0; c < DELAY + argc; c++)
-> 21z += a + b + c;
   22 while (1)
   23   {
   24 void *handle = dlopen (LIBM_SO, RTLD_LAZY);

Executable module set to "/home/dantipov/tmp/t-dlopen".
Architecture set to: x86_64--linux.
(lldb) breakpoint set -n sin
Breakpoint 1: no locations (pending).
WARNING:  Unable to resolve breakpoint to any actual locations.
(lldb) breakpoint set -n cos
Breakpoint 2: no locations (pending).
WARNING:  Unable to resolve breakpoint to any actual locations.
(lldb) process continue  ;; After this, nothing 
happens for a long time
Process 17043 resuming
(lldb) process status;; After this, lldb hangs 
and have to be killed

I've tried 6.0.0-rc2 as well as 7.0.0 svn trunk 325127, with the same 
disappointing results.

Dmitry

---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
#include 
#include 
#include 
#include 
#ifdef __ANDROID__
#define LIBM_SO "libm.so"
#define DELAY 1500
#else
#include 
#define DELAY 2000
#endif

int
main (int argc, char *argv[])
{
  /* Busy loop long enough to attach the debugger before dlopen happens.  */
  int a, b, c, z = 0;
  for (a = 0; a < DELAY + argc; a++)
for (b = 0; b < DELAY + argc; b++)
  for (c = 0; c < DELAY + argc; c++)
z += a + b + c;
  while (1)
{
  void *handle = dlopen (LIBM_SO, RTLD_LAZY);
  if (handle)
	{
	  int i;
	  double sum = 0.0;
	  double (*sinptr) (double) = dlsym (handle, "sin");
	  double (*cosptr) (double) = dlsym (handle, "cos");
	  for (i = 0; i < 10; i++)
	sum += sinptr (drand48 ()) + cosptr (drand48 ());
	  printf ("%lf\n", sum);
	  dlclose (handle);
	}
  sleep (1);
}
  return z;
}
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev