Re: [lldb-dev] test results look typical?

[Pavel Labath via lldb-dev]

There is no separate option, it should just work. :)

I'm betting you are still missing some package there (we should
document the prerequisites better). Could you send the error message
you are getting so we can have a look.

cheers,
pl


On 25 August 2015 at 16:20, Todd Fiala via lldb-dev
 wrote:
>
>
> On Mon, Aug 24, 2015 at 4:11 PM, Todd Fiala  wrote:
>>
>>
>>
>> On Mon, Aug 24, 2015 at 4:01 PM, Chaoren Lin  wrote:
>>>
>>> The TestDataFormatterLibcc* tests require libc++-dev:
>>>
>>> $ sudo apt-get install libc++-dev
>>>
>>
>> Ah okay, so we are working with libc++ on Ubuntu, that's good to hear.
>> Pre-14.04 I gave up on it.
>>
>> Will cmake automatically choose libc++ if it is present?  Or do I need to
>> pass something to cmake to use libc++?
>
>
> Hmm it appears I need to do more than just install libc++-dev.  I did a
> clean build with that installed, then ran the tests, and I still have the
> Libcxc/Libcxx tests failing.  Is there some flag expected, either to pass
> along for the compile options to dotest.py to override/specify which c++ lib
> it is using?
>
>>
>>
>> Thanks, Chaoren!
>>
>> -Todd
>>
>>>
>>> On Mon, Aug 24, 2015 at 3:42 PM, Todd Fiala via lldb-dev
>>>  wrote:


 On Mon, Aug 24, 2015 at 3:39 PM, Zachary Turner 
 wrote:
>
> Can't comment on the failures for Linux, but I don't think we have a
> good handle on the unexpected successes.  I only added that information to
> the output about a week ago, before that unexpected successes were 
> actually
> going unnoticed.


 Okay, thanks Zachary.   A while back we had some flapping tests that
 would oscillate between unexpected success and failure on Linux.  Some of
 those might still be in that state but maybe (!) are fixed.

 Anyone on the Linux end who happens to know if the fails in particular
 look normal, that'd be good to know.

 Thanks!

>
>
> It's likely that someone could just go in there and remove the XFAIL
> from those tests.
>
> On Mon, Aug 24, 2015 at 3:37 PM Todd Fiala via lldb-dev
>  wrote:
>>
>> Hi all,
>>
>> I'm just trying to get a handle on current lldb test failures across
>> different platforms.
>>
>> On Linux on non-virtualized hardware, I currently see the failures
>> below on Ubuntu 14.04.2 using a setup like this:
>> * stock linker (ld.bfd),
>> * g++ 4.9.2
>> * cmake
>> * ninja
>> * libstdc++
>>
>> ninja check-lldb output:
>>
>> Ran 394 test suites (15 failed) (3.807107%)
>> Ran 474 test cases (17 failed) (3.586498%)
>> Failing Tests (15)
>> FAIL: LLDB (suite) :: TestCPPThis.py (Linux rad 3.13.0-57-generic
>> #95-Ubuntu SMP Fri Jun 19 09:28:15 UTC 2015 x86_64 x86_64)
>> FAIL: LLDB (suite) :: TestDataFormatterLibccIterator.py (Linux rad
>> 3.13.0-57-generic #95-Ubuntu SMP Fri Jun 19 09:28:15 UTC 2015 x86_64 
>> x86_64)
>> FAIL: LLDB (suite) :: TestDataFormatterLibccMap.py (Linux rad
>> 3.13.0-57-generic #95-Ubuntu SMP Fri Jun 19 09:28:15 UTC 2015 x86_64 
>> x86_64)
>> FAIL: LLDB (suite) :: TestDataFormatterLibccMultiMap.py (Linux rad
>> 3.13.0-57-generic #95-Ubuntu SMP Fri Jun 19 09:28:15 UTC 2015 x86_64 
>> x86_64)
>> FAIL: LLDB (suite) :: TestDataFormatterLibcxxMultiSet.py (Linux rad
>> 3.13.0-57-generic #95-Ubuntu SMP Fri Jun 19 09:28:15 UTC 2015 x86_64 
>> x86_64)
>> FAIL: LLDB (suite) :: TestDataFormatterLibcxxSet.py (Linux rad
>> 3.13.0-57-generic #95-Ubuntu SMP Fri Jun 19 09:28:15 UTC 2015 x86_64 
>> x86_64)
>> FAIL: LLDB (suite) :: TestDataFormatterLibcxxString.py (Linux rad
>> 3.13.0-57-generic #95-Ubuntu SMP Fri Jun 19 09:28:15 UTC 2015 x86_64 
>> x86_64)
>> FAIL: LLDB (suite) :: TestDataFormatterSkipSummary.py (Linux rad
>> 3.13.0-57-generic #95-Ubuntu SMP Fri Jun 19 09:28:15 UTC 2015 x86_64 
>> x86_64)
>> FAIL: LLDB (suite) :: TestDataFormatterUnordered.py (Linux rad
>> 3.13.0-57-generic #95-Ubuntu SMP Fri Jun 19 09:28:15 UTC 2015 x86_64 
>> x86_64)
>> FAIL: LLDB (suite) :: TestMiGdbSetShowPrint.py (Linux rad
>> 3.13.0-57-generic #95-Ubuntu SMP Fri Jun 19 09:28:15 UTC 2015 x86_64 
>> x86_64)
>> FAIL: LLDB (suite) :: TestRegisterVariables.py (Linux rad
>> 3.13.0-57-generic #95-Ubuntu SMP Fri Jun 19 09:28:15 UTC 2015 x86_64 
>> x86_64)
>> FAIL: LLDB (suite) :: TestStaticVariables.py (Linux rad
>> 3.13.0-57-generic #95-Ubuntu SMP Fri Jun 19 09:28:15 UTC 2015 x86_64 
>> x86_64)
>> FAIL: LLDB (suite) :: TestStepNoDebug.py (Linux rad 3.13.0-57-generic
>> #95-Ubuntu SMP Fri Jun 19 09:28:15 UTC 2015 x86_64 x86_64)
>> FAIL: LLDB (suite) :: TestTypedefArray.py (Linux rad 3.13.0-57-generic
>> #95-Ubuntu SMP Fri Jun 19 09:28:15 UTC 2015 x86_64 x86_64)
>> FAIL: LLDB (suite) :: TestVectorTypesFormatting.py (Linux rad
>> 3.13.0-57-generic #95-Ubuntu SMP Fri Jun 19 09:28:1

Re: [lldb-dev] test results look typical?

[Pavel Labath via lldb-dev]

There's no need to do anything fancy (yet :) ). For initial diagnosis
the output of `./dotest.py $your_usual_options -p SomeLibcxxTest.py
-t` should suffice.

pl

On 25 August 2015 at 16:45, Todd Fiala  wrote:
> Thanks, Pavel!  I'll dig that up and get back.
>
> On Tue, Aug 25, 2015 at 8:30 AM, Pavel Labath  wrote:
>>
>> There is no separate option, it should just work. :)
>>
>> I'm betting you are still missing some package there (we should
>> document the prerequisites better). Could you send the error message
>> you are getting so we can have a look.
>>
>> cheers,
>> pl
>>
>>
>> On 25 August 2015 at 16:20, Todd Fiala via lldb-dev
>>  wrote:
>> >
>> >
>> > On Mon, Aug 24, 2015 at 4:11 PM, Todd Fiala 
>> > wrote:
>> >>
>> >>
>> >>
>> >> On Mon, Aug 24, 2015 at 4:01 PM, Chaoren Lin 
>> >> wrote:
>> >>>
>> >>> The TestDataFormatterLibcc* tests require libc++-dev:
>> >>>
>> >>> $ sudo apt-get install libc++-dev
>> >>>
>> >>
>> >> Ah okay, so we are working with libc++ on Ubuntu, that's good to hear.
>> >> Pre-14.04 I gave up on it.
>> >>
>> >> Will cmake automatically choose libc++ if it is present?  Or do I need
>> >> to
>> >> pass something to cmake to use libc++?
>> >
>> >
>> > Hmm it appears I need to do more than just install libc++-dev.  I did a
>> > clean build with that installed, then ran the tests, and I still have
>> > the
>> > Libcxc/Libcxx tests failing.  Is there some flag expected, either to
>> > pass
>> > along for the compile options to dotest.py to override/specify which c++
>> > lib
>> > it is using?
>> >
>> >>
>> >>
>> >> Thanks, Chaoren!
>> >>
>> >> -Todd
>> >>
>> >>>
>> >>> On Mon, Aug 24, 2015 at 3:42 PM, Todd Fiala via lldb-dev
>> >>>  wrote:
>> 
>> 
>>  On Mon, Aug 24, 2015 at 3:39 PM, Zachary Turner 
>>  wrote:
>> >
>> > Can't comment on the failures for Linux, but I don't think we have a
>> > good handle on the unexpected successes.  I only added that
>> > information to
>> > the output about a week ago, before that unexpected successes were
>> > actually
>> > going unnoticed.
>> 
>> 
>>  Okay, thanks Zachary.   A while back we had some flapping tests that
>>  would oscillate between unexpected success and failure on Linux.
>>  Some of
>>  those might still be in that state but maybe (!) are fixed.
>> 
>>  Anyone on the Linux end who happens to know if the fails in
>>  particular
>>  look normal, that'd be good to know.
>> 
>>  Thanks!
>> 
>> >
>> >
>> > It's likely that someone could just go in there and remove the XFAIL
>> > from those tests.
>> >
>> > On Mon, Aug 24, 2015 at 3:37 PM Todd Fiala via lldb-dev
>> >  wrote:
>> >>
>> >> Hi all,
>> >>
>> >> I'm just trying to get a handle on current lldb test failures
>> >> across
>> >> different platforms.
>> >>
>> >> On Linux on non-virtualized hardware, I currently see the failures
>> >> below on Ubuntu 14.04.2 using a setup like this:
>> >> * stock linker (ld.bfd),
>> >> * g++ 4.9.2
>> >> * cmake
>> >> * ninja
>> >> * libstdc++
>> >>
>> >> ninja check-lldb output:
>> >>
>> >> Ran 394 test suites (15 failed) (3.807107%)
>> >> Ran 474 test cases (17 failed) (3.586498%)
>> >> Failing Tests (15)
>> >> FAIL: LLDB (suite) :: TestCPPThis.py (Linux rad 3.13.0-57-generic
>> >> #95-Ubuntu SMP Fri Jun 19 09:28:15 UTC 2015 x86_64 x86_64)
>> >> FAIL: LLDB (suite) :: TestDataFormatterLibccIterator.py (Linux rad
>> >> 3.13.0-57-generic #95-Ubuntu SMP Fri Jun 19 09:28:15 UTC 2015
>> >> x86_64 x86_64)
>> >> FAIL: LLDB (suite) :: TestDataFormatterLibccMap.py (Linux rad
>> >> 3.13.0-57-generic #95-Ubuntu SMP Fri Jun 19 09:28:15 UTC 2015
>> >> x86_64 x86_64)
>> >> FAIL: LLDB (suite) :: TestDataFormatterLibccMultiMap.py (Linux rad
>> >> 3.13.0-57-generic #95-Ubuntu SMP Fri Jun 19 09:28:15 UTC 2015
>> >> x86_64 x86_64)
>> >> FAIL: LLDB (suite) :: TestDataFormatterLibcxxMultiSet.py (Linux rad
>> >> 3.13.0-57-generic #95-Ubuntu SMP Fri Jun 19 09:28:15 UTC 2015
>> >> x86_64 x86_64)
>> >> FAIL: LLDB (suite) :: TestDataFormatterLibcxxSet.py (Linux rad
>> >> 3.13.0-57-generic #95-Ubuntu SMP Fri Jun 19 09:28:15 UTC 2015
>> >> x86_64 x86_64)
>> >> FAIL: LLDB (suite) :: TestDataFormatterLibcxxString.py (Linux rad
>> >> 3.13.0-57-generic #95-Ubuntu SMP Fri Jun 19 09:28:15 UTC 2015
>> >> x86_64 x86_64)
>> >> FAIL: LLDB (suite) :: TestDataFormatterSkipSummary.py (Linux rad
>> >> 3.13.0-57-generic #95-Ubuntu SMP Fri Jun 19 09:28:15 UTC 2015
>> >> x86_64 x86_64)
>> >> FAIL: LLDB (suite) :: TestDataFormatterUnordered.py (Linux rad
>> >> 3.13.0-57-generic #95-Ubuntu SMP Fri Jun 19 09:28:15 UTC 2015
>> >> x86_64 x86_64)
>> >> FAIL: LLDB (suite) :: TestMiGdbSetShowPrint.py (Linux rad
>> >> 3.13.0-57-generic #95-Ubuntu SMP Fri Jun 19 09:28:15 UTC 2015
>> >> 

Re: [lldb-dev] Test suite rebuilding test executables many times

[Pavel Labath via lldb-dev]

On 26 August 2015 at 06:14, Zachary Turner via lldb-dev
 wrote:
>
> I'll wait and see if anyone can remember which tests rebuild binaries on
> purpose.  Otherwise I will try to look through them and see if I can figure
> it out.

TestInferiorChanged is one that I remember.

I think this is a good thing to do, but it will need to be done with a
steady hand.



I was also thinking about the dsym/dwo tests.. Instead of basically
having a copy of each test for dwarf and dsym (and soon also dwo), how
about having just one test, and have some higher level logic (the test
runner) know that it needs to execute each test multiple times. The
tests would then just do a buildDefault() (or something) and on the
first run it would build normal dwarf, on the second one dsym, etc. If
we need to run a test only for some combination of debug infos, we
could have @skipIfDsym annotations, like we do for the rest of stuff.
I think this will make what Zachary is proposing easier to do, and it
will make the test writing less awkard.


What do you think? I'm ready to chip in on this if we agree to go down
this way...

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

Re: [lldb-dev] How does attach work on non-Windows?

[Pavel Labath via lldb-dev]

The main issue I see with all these APIs is that they are
non-blocking. That is, the test executable cannot simply say "wait
until a debugger attaches", but it will have to do something like:
while (! attached) {
  sleep(X);
  attached = figure_out_if_i_am_attached_using_architecture_specific_methods();
}

This does not sound to me like it will be significantly more stable
then the currently used method:
while (! attached) sleep(X);
where the debugger flips the variable after it attaches.

However, I would definitely welcome providing a default implementation
of wait_for_debugger_attach() (regardless of how it is implemented),
which all tests can use, instead of each one rolling out its own.


Another possible implementation would be to use some standard IPC
mechanism (pipes, signals, sockets, ...) for waking up the inferior
once the debugger is ready. The test inferior could e.g., wait on a
pipe and the debugger will write a single byte there once it attaches.
Since we control both the test runner and the test inferior, this is
enough and you don't need any fancy APIs. The tricky part here would
be to make sure this works during remote debugging.


That said, I don't think the current issues with the attach tests are
caused by this problem. The current protocol, however awkard it may
be, should still work IMO, but we are still seeing flakyness in all
tests that do attaches. I think we have some other issues here and I
am suspecting races in other parts of the system. I was planning to
take a look at these soon...


> LLDB picks this up, and the result is that LLDB stops and waits for the user
> to continue the inferior just as it would with any other breakpoint, and if
> you were to get a backtrace you might see something like this:
>
> looking at: Stack traces for SBProcess: pid = 12588, state = stopped,
> threads = 2, executable = test_with_dwarf_and_attach_to_process_with_id_api
> Stack trace for thread id=0x3428 name=None queue=None stop reason=none
>   frame #0: 0x ntdll.dll`DbgBreakPoint + 1

This sounds like a pretty strange way to stop the inferior (I was
quite surprised that ^C also injects a thread into a program), however
it is fundamentally equivalent to what the other platforms do. When we
attach on Linux, the inferior also comes out stopped. The difference
is that we get a SIGSTOP as a stop reason, while on windows you get a
breakpoint in a different thread. It sounds to me like the tests
should not rely on a specific thread being selected after the attach.
Most tests don't do backtraces right after attach since you're likely
to get very unpredictable results on any platform. Those that do
should be fixed to set a breakpoint on the place that interests them,
resume and do a backtrace once they hit that breakpoint. I vaguelly
recall some tests that actually do try to backtrace on attach on
purpose (for example, to see if you can backtrace out of a syscall).
If they exist, we should fix them to first select the right thread for
the backtracing, so they don't try to use the DbgBreakPoint thread.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] How does attach work on non-Windows?

[Pavel Labath via lldb-dev]

Ah yes, our old friend TestHelloWorld. This guy definitely needs to be
fixed. I haven't actually looked at the code before to see why it was
so flaky, but now it all makes sense

I would just use the "usual" protocol of "expr release_child = 1"
here, but if you wanna go crazy, then go ahead... :)



On 27 August 2015 at 16:12, Zachary Turner  wrote:
> It's not that it relies on a specific thread being selected, because as you
> can see there are 2 threads in that trace.  The problem is that the second
> frame is not even yet in the main function, it's in the startup code because
> of how early the attach process happens (which itsels is probably actually
> racy, since attach is user-initiated and might happen before or after main
> function has entered.  But the test checks for main.c as the source file of
> the second frame, so this si where the probelm lies.
>
> On Thu, Aug 27, 2015 at 1:41 AM Pavel Labath  wrote:
>>
>> The main issue I see with all these APIs is that they are
>> non-blocking. That is, the test executable cannot simply say "wait
>> until a debugger attaches", but it will have to do something like:
>> while (! attached) {
>>   sleep(X);
>>   attached =
>> figure_out_if_i_am_attached_using_architecture_specific_methods();
>> }
>>
>> This does not sound to me like it will be significantly more stable
>> then the currently used method:
>> while (! attached) sleep(X);
>> where the debugger flips the variable after it attaches.
>>
>> However, I would definitely welcome providing a default implementation
>> of wait_for_debugger_attach() (regardless of how it is implemented),
>> which all tests can use, instead of each one rolling out its own.
>>
>>
>> Another possible implementation would be to use some standard IPC
>> mechanism (pipes, signals, sockets, ...) for waking up the inferior
>> once the debugger is ready. The test inferior could e.g., wait on a
>> pipe and the debugger will write a single byte there once it attaches.
>> Since we control both the test runner and the test inferior, this is
>> enough and you don't need any fancy APIs. The tricky part here would
>> be to make sure this works during remote debugging.
>>
>>
>> That said, I don't think the current issues with the attach tests are
>> caused by this problem. The current protocol, however awkard it may
>> be, should still work IMO, but we are still seeing flakyness in all
>> tests that do attaches. I think we have some other issues here and I
>> am suspecting races in other parts of the system. I was planning to
>> take a look at these soon...
>>
>>
>> > LLDB picks this up, and the result is that LLDB stops and waits for the
>> > user
>> > to continue the inferior just as it would with any other breakpoint, and
>> > if
>> > you were to get a backtrace you might see something like this:
>> >
>> > looking at: Stack traces for SBProcess: pid = 12588, state = stopped,
>> > threads = 2, executable =
>> > test_with_dwarf_and_attach_to_process_with_id_api
>> > Stack trace for thread id=0x3428 name=None queue=None stop reason=none
>> >   frame #0: 0x ntdll.dll`DbgBreakPoint + 1
>>
>> This sounds like a pretty strange way to stop the inferior (I was
>> quite surprised that ^C also injects a thread into a program), however
>> it is fundamentally equivalent to what the other platforms do. When we
>> attach on Linux, the inferior also comes out stopped. The difference
>> is that we get a SIGSTOP as a stop reason, while on windows you get a
>> breakpoint in a different thread. It sounds to me like the tests
>> should not rely on a specific thread being selected after the attach.
>> Most tests don't do backtraces right after attach since you're likely
>> to get very unpredictable results on any platform. Those that do
>> should be fixed to set a breakpoint on the place that interests them,
>> resume and do a backtrace once they hit that breakpoint. I vaguelly
>> recall some tests that actually do try to backtrace on attach on
>> purpose (for example, to see if you can backtrace out of a syscall).
>> If they exist, we should fix them to first select the right thread for
>> the backtracing, so they don't try to use the DbgBreakPoint thread.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

lldb-dev@lists.llvm.org

[Pavel Labath via lldb-dev]

I think it should be a weak_ptr if anything. Target already holds a
shared_ptr of the process, and you will get pointer loops otherwise.

Couldn't you make sure the debug thread exits (and processes all
events) before the Target gets deleted (e.g. shut it down in
Process::Finalize() or somewhere...)? If there is currently an
invariant that Process should never outlive its Target (which would
seem to be implied by the fact it holds a Target&), I would prefer if
it can be preserved.

pl

On 28 August 2015 at 19:34, Zachary Turner via lldb-dev
 wrote:
> We've been seeing races during shutdown of inferiors for months, and I
> finally tracked it down to the fact that Process holds a Target&.  When an
> inferior is exiting on Windows, we will get a notification of this and we
> try to do various cleanup related with the target.  But there are times
> where the Target gets deleted even when the Process is still around, due to
> some interactions between our debug loop and the timing of when certain
> debug events that get sent by the operating system.
>
> As a result, the race leads to us getting one of the notifications from the
> OS and us trying to access the target, which is stored by reference leading
> to a crash.
>
> It seems like a purely mechanical change to make Process hold a TargetSP
> instead of a Target&.  I've already started down this patch locally, but I
> want to make sure there are no objections or concerns before I continue down
> this path, since it's kind of mundane work.
>
> ___
> 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] Portable tests that create threads

[Pavel Labath via lldb-dev]

+1 for the naming idea. It sounds like the a more reliable solution
than crawling backtraces to me.

pl

On 3 September 2015 at 06:32, Todd Fiala via lldb-dev
 wrote:
> I think the thread naming is a reasonable way to go.
>
>> 1) Linux and MacOSX inferiors can use pthread_setname_np
>> 2) FreeBSD inferiors can use pthread_set_name_np
>
> IIRC Linux and FreeBSD both are limited to a very short thread name, much
> shorter than OS X and, if I'm not mistaken, Windows as well.  So we need to
> not go crazy on thread naming conventions.  The code has it, but I think the
> limit on Linux and FreeBSD was something like 16 characters.
>
> On Wed, Sep 2, 2015 at 2:48 PM, Jim Ingham via lldb-dev
>  wrote:
>>
>>
>> > On Sep 2, 2015, at 1:06 PM, Greg Clayton via lldb-dev
>> >  wrote:
>> >
>> > One idea is add the ability to discover which of any of the current
>> > threads are or are not user created. This might help us.
>> >
>> > On MacOSX, the main thread would always be considered user created, and
>> > any other thread, it is quite easy to tell. User created threads could be
>> > ones whose bottom stack frame is "thread_start"
>> >
>> >
>> >frame #8: 0x7fff9b47c41d libsystem_pthread.dylib thread_start +
>> > 13
>> >
>> > Where OS created threads have their last frames in "start_wqthread" or
>> > "_dispatch_mgr_thread":
>> >
>> >...
>> >frame #2: 0x7fff9b47c40d libsystem_pthread.dylib start_wqthread +
>> > 13
>> >
>> > or:
>> >
>> >...
>> >frame #2: 0x7fff9c298a6a libdispatch.dylib _dispatch_mgr_thread +
>> > 52
>> >
>> >
>> > So it might be easy to add API to SBThread like:
>> >
>> > bool
>> > SBThread::IsUserCreated();
>> >
>> > Then we could teach the tests to filter out any threads that are not
>> > user created?
>>
>> I'm not sure on OS X this is a terribly useful distinction.  There are
>> lots of threads that are created to run user code through the dispatch
>> library.  They won't start with "thread_start" but I don't think most users
>> would think of them as "not user threads..."
>>
>> Jim
>>
>>
>> >
>> > Greg
>> >
>> >
>> >> On Sep 2, 2015, at 12:31 PM, Zachary Turner via lldb-dev
>> >>  wrote:
>> >>
>> >> Historically the pattern for tests that need to test situations
>> >> involving threads has been to write the tests using pthreads, and then a
>> >> common pattern on the python side of the test is to assert that the actual
>> >> number of threads equals the expected number of threads.
>> >>
>> >> To deal with the pthread portability issue, I ported most of these
>> >> tests over to std::threads, but there is still another issue with them.
>> >>
>> >> On Windows we can't assume anything about the number of threads in a
>> >> program.  For example, a single-threaded hello world program actually has 
>> >> 3
>> >> threads, 2 of which are reserved for use by the operating system.  And the
>> >> fact that there's 2 is just arbitrary, that might not remain the same
>> >> between compiler versions, operating system versions, etc.  And to make
>> >> matters worse it might not even remain constant through the life of the
>> >> program (the assumption just being that we cannot make any assumptions,
>> >> since we don't control the threads).
>> >>
>> >> So I need to find a way to write these tests portably.
>> >>
>> >> Do all platforms have a way to assign a thread a name?  Looking in
>> >> Host/*/ThisThread.cpp, it seems:
>> >>
>> >> 1) Linux and MacOSX inferiors can use pthread_setname_np
>> >> 2) FreeBSD inferiors can use pthread_set_name_np
>> >> 3) Windows inferiors can raise a magic exception which the debugger is
>> >> expected to recognize
>> >>
>> >> Based on this, it seems that one possible way to write these tests
>> >> portably is to have the test inferiors assign names to the threads, and 
>> >> have
>> >> the tests index the threads by name instead of by ordinal.
>> >>
>> >> Does anyone have any thoughts on this or other possible approaches?
>> >>
>> >> I really would like to avoid having different inferiors or different
>> >> tests for all of this functionality, as it will be very easy to get out of
>> >> sync.
>> >> ___
>> >> 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
>
>
>
>
> --
> -Todd
>
> ___
> 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] Difference of behaviour of process.Continue() between MacOSX and Linux

[Pavel Labath via lldb-dev]

Hi,

thanks for your report.

Let me first ask you a question. Which version of lldb are you using?

If it's anything less than 3.7, then I strongly recommend to upgrade,
since linux support was not in a very good state there. If you are
using 3.7 or svn, then the thing you are describing should work. If it
does not please send your script along with your test app (or better
yet, file a bug at  and I will take a look.

cheers,
pl


On 8 September 2015 at 13:29, Louis Granboulan via lldb-dev
 wrote:
> Dear all,
>
> I am new to lldb-dev and I hope that this issue has not already been
> reported. I did not find any reference of it.
>
> I started with the example from section "Using the lldb.py module in python"
> of
> http://lldb.llvm.org/python-reference.html
> and decided to have the process continue after having printed some
> information about the breakpoint context. It allows to have multiple
> breakpoints and display information about every breakpoint, or to have a
> breakpoint at a function that is called many times and to display
> information for every call.
>
> On a MacOSX machine (any recent version) it works well, but on a Linux
> machine (Ubuntu 14.04 64 bits) it looks like process.Continue() makes the
> program continue at the breakpoint instead of at the instruction following
> the breakpoint. Therefore, it enters an infinite loop.
>
> I can attach the python script, but this script is just made by taking the
> example of the webpage, putting in a "while True" loop everything after
> "state = process.GetState()" and adding at the end of the loop the
> instruction "process.Continue()".
>
> Regards,
> Louis
>
> ___
> 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] Looking for info on two rdars: 18684124, 15367233

[Pavel Labath via lldb-dev]

On 9 September 2015 at 14:21, Ed Maste via lldb-dev
 wrote:
> Also, are these tests passing on Linux?

The tests seem to be passing for linux as well.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] lldb::SBDebugger::Terminate() hangs in deadlock

[Pavel Labath via lldb-dev]

Hi,

Thanks for the report. Since you are suspecting a deadlock, could you
post a backtrace of all the threads (thread apply all backtrace). It
would be best to move this discussion to a bug in llvm.org/bugs.

> I am currently using svn revision 247535 of llvm and lldb, and I know that my 
> code was working with svn revision 229496
This sounds like a pretty big revision range. It would help if you
could narrow it down a bit.

pl


On 28 September 2015 at 09:12, Stefan Kratochwil via lldb-dev
 wrote:
> Hi,
>
> I've got a problem with lldb deadlocking upon a call to
> lldb::SBDebugger::Terminate().
>
> I am currently using svn revision 247535 of llvm and lldb, and I know that
> my code was working with svn revision 229496.
>
> In short, I am doing the following steps:
>
>   lldb_debugger = lldb::SBDebugger::Create()
>   lldb_debugger.SetAsync(true)
>   lldb_target = lldb_debugger.CreateTarget()
>   lldb_process = lldb_target.AttachToProcessWithID()
>   ... (doing stuff with modules)
>   lldb::SBDebugger::Terminate()
>
> The last call results in a deadlock.
>
> I enabled the DEBUG_LOG and ENABLE_MUTEX_ERROR_CHECKING macros within
> Mutex.cpp and found out that a mutex is getting locked whose ID never came
> up in the log before. This mutex has no owner, so it should be lockable -
> but it isn't...
>
> A gdb backtrace with the last few debug messages can be found here:
> http://pastebin.com/Kv4EidHx
>
>
> Does anyone have an idea what is going on here? Am I missing something?
>
> Thanks in advance!
>
>
> Cheers,
> Stefan Kratochwil
> ___
> 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] possible test runner speedup

[Pavel Labath via lldb-dev]

Hi,

Interesting results. We were discussing the same thing last week. I
was somewhat skeptical to the ideal as I am afraid of increased
flakyness -- LLDB has hardcoded timeout values in a lot of places, and
with increased cpu contention, we might start to see this code failing
because the other side was slower than expected.

I have now tried running the test suite with a higher number of
threads and it seems it working quite alright, so I think we can try
that. I'll watch the buildbots for signs of increased flakyness. FWIW,
it did not speed up the tests for me at all, but I guess that's
expected, as it ran in 90 seconds even before that, and the limiting
factor there probably is the longest test.

As for the timeout, I have set the value to 4 minutes, based on the
formula: 2 * (number of seconds when I first started noticing flaky
tests in the slowest configuration). The slowest configuration here
was running the test suite on a debug build of lldb and using debug
ToT clang to compile the inferiors (believe it or not, this makes a
big difference). So there is still some leeway here, but if you're
gonna reduce the default, please make sure it is enough for the
slowest test configuration also. For faster configurations you can
always override the timeout manually.

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

[lldb-dev] correct event sequence on process detach

[Pavel Labath via lldb-dev]

Hello all,

The following question came up while fixing up handling of process detach.

when detaching from a running process, on some platforms LLDB needs to
stop it first. Is this stop something that should be hidden from the
public view or not?

I.e. if the process state is Running, and I do a process.Detach(),
what is the correct sequence of public state transitions one should
observe:
a) Running -> Detached ?

b) (Running -> Stopped -> Detached) or (Running -> Detached),
depending on whether the platform performs the maintenance stop?

My feeling is it should be a), but I wanted to double check first.

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

Re: [lldb-dev] Thread resumes with stale signal after executing InferiorCallMmap

[Pavel Labath via lldb-dev]

Hi,

I believe the SIGILL problem you are referring to is the problem
described in bug . This
was fixed in r244875, but unfortunately, this was after 3.7 branch so
this patch did not make it there. I recommend to try the master
branch, I think this should work for you now (and do let me know if
the problem persists).

pl

On 8 October 2015 at 00:20, Jim Ingham via lldb-dev
 wrote:
>
>> On Oct 7, 2015, at 4:06 PM, Eugene Birukov  wrote:
>>
>> Even on Linux call to InferiorCallMmap does not fail consistently. In many 
>> cases it survives. I just happened to have 100% repro on this specific 
>> breakpoint in my specific problem. I.e. the burden of investigation is on 
>> me, since I cannot share my program.
>>
>> But I am not looking at this SIG_ILL yet. Whatever the problem is with mmap 
>> - the client must not carry this signal past expression evaluation. I.e. I 
>> believe that we can construct any arbitrary function that causes signal, 
>> call it from evaluate expression, and then continue would fail. I suspect 
>> that this problem might be applicable to any POSIX platform.
>
> It doesn't happen on OS X, though when it comes to signal handling in the 
> debugger OS X is an odd fish...
>
>>
>> As it turned out, my initial analysis was incorrect. m_resume_signal is 
>> calculated from StopInfo::m_value (now I wonder why do we need two fields 
>> for that?).
>
> The signal that you stop with is not necessarily the one you are going to 
> resume with.  For instance, if you use "process handle SIG_SOMESIG -p 0" to 
> tell lldb not to propagate the signal, then the resume signal will be 
> nothing, even though the stop signal is SIG_SOMESIG.
>
>> And after mmap call, m_stop_info on the thread is null. So, my current 
>> theory is that there is an event with SIG_ILL that is stuck in the 
>> broadcaster and is picked up and processed much later.
>
> When the expression evaluation completes, the StopInfo from the last 
> "natural" stop should be put back in place in the thread.  After all, if you 
> hit a breakpoint, run an expression, then ask why that thread stopped, you 
> want to see "hit a breakpoint" not "ran a function call".  Sounds like that 
> is failing somehow.
>
> Jim
>
>
>>
>> > Subject: Re: [lldb-dev] Thread resumes with stale signal after executing 
>> > InferiorCallMmap
>> > From: jing...@apple.com
>> > Date: Wed, 7 Oct 2015 15:08:18 -0700
>> > CC: lldb-dev@lists.llvm.org
>> > To: eugen...@hotmail.com
>> >
>> > Does it only happen for InferiorCallMmap, or does an expression evaluation 
>> > that crashes in general set a bad signal on resume? I don't see this 
>> > behavior in either case on OS X, so it may be something in the Linux 
>> > support. Be interesting to figure out why it behaves this way on Linux, so 
>> > whatever we do we're implementing it consistently.
>> >
>> > Jim
>> >
>> >
>> >
>> > > On Oct 7, 2015, at 12:03 PM, Eugene Birukov via lldb-dev 
>> > >  wrote:
>> > >
>> > > Hi,
>> > >
>> > > I am using LLDB 3.7.0 C++ API. My program stops at a certain breakpoint 
>> > > and if I call SBFrame::EvaluateExpression() there, when I let it go it 
>> > > terminates with SIG_ILL on an innocent thread. I dug up into this, and 
>> > > there seems to be two independent problems there, this mail is about the 
>> > > second one.
>> > >
>> > > • EvaluateExpression() calls Process::CanJIT() which in turn executes 
>> > > mmap() on the inferior. This mmap gets SIG_ILL because execution starts 
>> > > at address which is 2 bytes before the very first mmap instruction. I am 
>> > > still looking why LLDB server decided to do that - I am pretty sure that 
>> > > the client asked to set the program counter to correct value.
>> > > • So, the thread execution terminates and the signal is recorded on 
>> > > Thread::m_resume_signal. This field is not cleared during 
>> > > Thread::RestoreThreadStateFromCheckpoint() and fires when I resume the 
>> > > program after breakpoint.
>> > >
>> > > So, what would be the best way to deal with the situation? Should I add 
>> > > "resume signal" field to ThreadStateCheckpoint? Or would StopInfo be a 
>> > > better place for that? Or something else?
>> > >
>> > > Thanks,
>> > > Eugene
>> > > ___
>> > > 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

Re: [lldb-dev] Thread resumes with stale signal after executing InferiorCallMmap

[Pavel Labath via lldb-dev]

On 8 October 2015 at 17:08, Eugene Birukov  wrote:
> Yes, that's exactly what I see, thanks a lot!
You're wellcome.

>
> Does it explain why I see SIGILL reappear when I let process continue after
> mmap execution? I.e. do I need to look into this more?
No. That could still be a bug somewhere. Feel free to look into it..

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

Re: [lldb-dev] Thread resumes with stale signal after executing InferiorCallMmap

[Pavel Labath via lldb-dev]

Sure, fair enough.

If you have made a small repro case already though, it would be great
if you could file a bug about it, so we don't forget it.

pl

On 12 October 2015 at 23:23, Eugene Birukov  wrote:
> I tried to repro it using standard LLDB client on a simple program that I
> could share. Well, the problem does not exactly repro as in my case - i.e.
> the signal is not re-delivered to the thread. But LLDB does get confused
> state: the program continues but at the same time lldb shows its prompt as
> if the program were stopped. I.e. the recovery from signal during expression
> evaluation is buggy. Sorry, I am not sure that I will have time to look into
> it deeper - it is not a blocker for me at this time.
>
>> From: lab...@google.com
>> Date: Mon, 12 Oct 2015 13:25:45 +0100
>> Subject: Re: [lldb-dev] Thread resumes with stale signal after executing
>> InferiorCallMmap
>> To: eugen...@hotmail.com
>> CC: lldb-dev@lists.llvm.org; jing...@apple.com
>>
>> On 8 October 2015 at 17:08, Eugene Birukov  wrote:
>> > Yes, that's exactly what I see, thanks a lot!
>> You're wellcome.
>>
>> >
>> > Does it explain why I see SIGILL reappear when I let process continue
>> > after
>> > mmap execution? I.e. do I need to look into this more?
>> No. That could still be a bug somewhere. Feel free to look into it..
>>
>> pl
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] TestRaise.py test_restart_bug flakey stats

[Pavel Labath via lldb-dev]

I have created this test to reproduce a race condition in
ProcessGDBRemote. Given that it tests a race condition, it cannot be
failing 100% of the time, but I agree with Tamas that we should keep
it as XFAIL to avoid noise in the buildbots.

pl

On 19 October 2015 at 12:30, Tamas Berghammer via lldb-dev
 wrote:
> The expected flakey works a bit differently then you are described:
> * Run the tests
> * If it passes, it goes as a successful test and we are done
> * Run the test again
> * If it is passes the 2nd time then record it as expected failure (IMO
> expected falkey would be a better result, but we don't have that category)
> * If it fails 2 times in a row then record it as a failure because a flakey
> test should pass at least once in every 2 run (it means we need ~95% success
> rate to keep the build bot green in most of the time). If it isn't passing
> often enough for that then it should be marked as expected failure. This is
> done this way to detect the case when a flakey test get broken completely by
> a new change.
>
> I checked some states for TestRaise on the build bot and in the current
> definition of expected flakey we shouldn't mark it as flakey because it will
> often fail 2 times in a row (it passing rate is ~50%) what will be reported
> as a failure making the build bot red.
>
> I will send you the full stats from the lass 100 build in a separate off
> list mail as it is a too big for the mailing list. If somebody else is
> interested in it then let me know.
>
> Tamas
>
> On Sun, Oct 18, 2015 at 2:18 AM Todd Fiala  wrote:
>>
>> Nope, no good either when I limit the flakey to DWO.
>>
>> So perhaps I don't understand how the flakey marking works.  I thought it
>> meant:
>> * run the test.
>> * If it passes, it goes as a successful test.  Then we're done.
>> * run the test again.
>> * If it passes, then we're done and mark it a successful test.  If it
>> fails, then mark it an expected failure.
>>
>> But that's definitely not the behavior I'm seeing, as a flakey marking in
>> the above scheme should never produce a failing test.
>>
>> I'll have to revisit the flakey test marking to see what it's really doing
>> since my understanding is clearly flawed!
>>
>> On Sat, Oct 17, 2015 at 5:57 PM, Todd Fiala  wrote:
>>>
>>> Hmm, the flakey behavior may be specific to dwo.  Testing it locally as
>>> unconditionally flaky on Linux is failing on dwarf.  All the ones I see
>>> succeed are dwo.  I wouldn't expect a diff there but that seems to be the
>>> case.
>>>
>>> So, the request still stands but I won't be surprised if we find that dwo
>>> sometimes passes while dwarf doesn't (or at least not enough to get through
>>> the flakey setting).
>>>
>>> On Sat, Oct 17, 2015 at 4:57 PM, Todd Fiala  wrote:

 Hi Tamas,

 I think you grabbed me stats on failing tests in the past.  Can you dig
 up the failure rate for TestRaise.py's test_restart_bug() variants on 
 Ubuntu
 14.04 x86_64?  I'd like to mark it as flaky on Linux, since it is passing
 most of the time over here.  But I want to see if that's valid across all
 Ubuntu 14.04 x86_64.  (If it is passing some of the time, I'd prefer 
 marking
 it flakey so that we don't see unexpected successes).

 Thanks!

 --
 -Todd
>>>
>>>
>>>
>>>
>>> --
>>> -Todd
>>
>>
>>
>>
>> --
>> -Todd
>
>
> ___
> 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] lldb tests and tear down hooks

[Pavel Labath via lldb-dev]

I think we can remove these, provided there is a way to mimic the
functionality they are used for now, which I think shouldn't be hard.
Anything which was set up in the setUp() method should be undone in
tearDown(). Anything which was set up in the test method, can be
undone using a try-finally block. Is there a use case not covered by
this?

pl

On 21 October 2015 at 04:47, Zachary Turner via lldb-dev
 wrote:
> There's a subtle bug that is pervasive throughout the test suite.  Consider
> the following seemingly innocent test class.
>
> class MyTest(TestBase);
> def setUp():
> TestBase.setUp()#1
>
> # Do some stuff  #2
> self.addTearDownHook(lambda: self.foo())   #3
>
> def test_interesting_stuff():
> pass
>
> Here's the problem.  As a general principle, cleanup needs to happen in
> reverse order from initialization.  That's why, if we had a tearDown()
> method, it would probably look something like this:
>
> def tearDown():
> # Clean up some stuff  #2
>
> TestBase.tearDown()#1
>
> This follows the pattern in other languages like C++, for example, where
> construction goes from base -> derived, but destruction goes from derived ->
> base.
>
> But if you add these tear down hooks into the mix, it violates that.  tear
> down hooks get invoked as part of TestBase.tearDown(), so in the above
> example the initialization order is 1 -> 2 -> 3 but the teardown order is 2
> -> 1 -> 3  (or 2 -> 3 -> 1, or none of the above depending on where inside
> of TestBase.tearDown() hook the hooks get invoked).
>
> To make matters worse, tear down hooks can be added from arbitrary points in
> a test's run, not just during setup.
>
> The only way I can see to fix this is to delete this tearDownHook mechanism
> entirely.  Anyone who wants it can easily reimplement this in the individual
> test by just keeping their own list of lambdas in the derived class,
> overriding tearDown(), and running through their own list in reverse order
> before calling TestBase.tearDown().
>
> I don't intend to do this work right now, but I would like to do it in the
> future, so I want to throw this out there and see if anyone has thoughts on
> it.
>
> ___
> 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] [Lldb-commits] [lldb] r248028 - Make libc++ tests skip themselves if libc++ is not actually loaded in the target

[Pavel Labath via lldb-dev]

[moving this to lldb-dev for more visibility.]

Sorry, I was in a hurry yesterday, so I did not explain myself fully. Let
me try to elaborate.

> What I am trying to avoid here is getting useless noise in build
automation where test cases proclaim their failure, which however tells us
nothing of value as the issue is simply “libc++ not available” vs. “data
formatters broken” That is an ability I would strongly like to preserve

I agree that we should have an ability to skip libc++ tests if the library
is not available (similarly for go, etc.). However, I believe there should
be as little "magic" in that as possible. Otherwise you run into the
opposite problem where a test passing could mean "everything is ok" or "our
auto-skipping magic has gone wrong", which I would argue is a worse
situation than the first one.

Currently, we have a lot of magic in here:
- self.build() silently builds an executable with a different library even
though libc++ was requested. (otherwise you wouldn't even be able to list
the modules of the executable)
- the test decides to skip itself without giving any indication about
(sure, it shows up in the "skipped tests" list, but a lot of other stuff
appears there as well. and I would argue that this is a different
situation: usually we do skips based on the OS, architecture, or other
"immutable" characteristics. Presence of libc++ is something that can be
usually changed by simply installing a package.)

I'd like to propose a few alternative solutions to achieve both of these
objectives:

a) Use the existing category system for this: libc++ tests get tagged as
such and the user has to explicitly disable this category to avoid running
the tests. Potentially, add some code to detect when the user is running
the test suite without libc++ installed and abort the run with some message
like "No libc++ detected on your system. Please install libc++ or disable
libc++ tests with `--disable-category libc++`".

I like this solution because it is easily achievable and has no magic
involved. However, it requires an action from the user (which I think is a
good thing, but I see how others may disagree). That's what I meant for
asking about your "use case". Would you be able to fit it inside this
framework?

b) Use category tagging as in (a), but auto-disable this category when
libc++ is missing and print a big fat warning "No libc++ detected, libc++
tests will not run". What is different from the current state is that this
libc++ detection would work centrally, which would give us the possibility
to print the warning (e.g. right before the "Ran XXX test suites" message")
I like this a bit less, as it is still automatic, but I am fine with it, as
it would give a clear visual indication of what is happening.


What do you think? Do you have another proposal?

I can implement either of those, but I was to get some feedback first..

pl



On 20 October 2015 at 19:05, Enrico Granata  wrote:

>
> On Oct 20, 2015, at 10:43 AM, Pavel Labath  wrote:
>
> Hi Enrico,
>
> Could you explain what was the motivation behind this change?
>
>
> As per title of the commit, in a process that is using a standard c++
> library other than libc++, these tests are noise - of course the libc++
> tests aren’t gonna pass if you don’t have libc++
>
> I am asking because, I have just learned that this commit has caused
> all libc++ tests to be skipped on linux*, silently decreasing test
> coverage on linux. I would like to replace this with some other
> mechanism, which is not prone to accidental silent skips, like a
> dotest flag to skip libc++ or something, but I'd like to understand
> the original motivation first.
>
> pl
>
> * the problem seems to be that on linux, we do not have the list of
> modules until we actually start the process, so this code will not
> find the library, as it runs before that.
>
>
> The solution might then be to run the process, and then
> skip_if_library_missing
> I think we avoid trying to compile the test inferior entirely if we can’t
> find libc++ however, so you might first want to check if a.out exists at
> all, and only then proceed all the way to the first breakpoint being hit
>
> If is considered a bug then
> we can look into that separately, but I'd still like to avoid these
> kinds of skips.
>
>
> What I am trying to avoid here is getting useless noise in build
> automation where test cases proclaim their failure, which however tells us
> nothing of value as the issue is simply “libc++ not available” vs. “data
> formatters broken”
> That is an ability I would strongly like to preserve
>
>
> On 18 September 2015 at 21:12, Enrico Granata via lldb-commits
>  wrote:
>
> Author: enrico
> Date: Fri Sep 18 15:12:52 2015
> New Revision: 248028
>
> URL: http://llvm.org/viewvc/llvm-project?rev=248028&view=rev
> Log:
> Make libc++ tests skip themselves if libc++ is not actually loaded in the
> target
>
>
> Modified:
>
>
> lldb/trunk/test/functionalities/data-formatter/data-formatter-stl/libcxx

Re: [lldb-dev] Inquiry for performance monitors

[Pavel Labath via lldb-dev]

[ Moving this discussion back to the list. I pressed the wrong button
when replying.]

Thanks for the explanation Ravi. It sounds like a very useful feature
indeed. I've found a reference to the debugserver profile data in
GDBRemoteCommunicationClient.cpp:1276, so maybe that will help with
your investigation. Maybe also someone more knowledgeable can explain
what those A packets are used for (?).


On 21 October 2015 at 15:48, Ravitheja Addepally
 wrote:
> Hi,
>Thanx for your reply, some of the future processors to be released by
> Intel have this hardware support for recording the instructions that were
> executed by the processor and this recording process is also quite fast and
> does not add too much computational load. Now this hardware is made
> accessible via the perf_event_interface where one could map a region of
> memory for this purpose by passing it as an argument to this
> perf_event_interface. The recorded instructions are then written to the
> memory region assigned. Now this is basically the raw information, which can
> be obtained from the hardware. It can be interpreted and presented to the
> user in the following ways ->
>
> 1) Instruction history - where the user gets basically a list of all
> instructions that were executed
> 2) Function Call History - It is also possible to get a list of all the
> functions called in the inferior
> 3) Reverse Debugging with limited information - In GDB this is only the
> functions executed.
>
> This raw information also needs to decoded (even before you can disassemble
> it ), there is already a library released by Intel called libipt which can
> do that. At the moment we plan to work with Instruction History.
> I will look into the debugserver infrastructure and get back to you. I guess
> for the server client communication we would rely on packets only. In case
> of concerns about too much data being transferred, we can limit the number
> of entries we report because anyway the amount of data recorded is too big
> to present all at once so we would have to resort to something like a
> viewport.
>
> Since a lot of instructions can be recorded this way, the function call
> history can be quite useful for debugging and especially since it is a lot
> faster to collect function traces this way.
>
> -ravi
>
> On Wed, Oct 21, 2015 at 3:14 PM, Pavel Labath  wrote:
>>
>> Hi,
>>
>> I am not really familiar with the perf_event interface (and I suspect
>> others aren't also), so it might help if you explain what kind of
>> information do you plan to collect from there.
>>
>> As for the PtraceWrapper question, I think that really depends on
>> bigger design decisions. My two main questions for a feature like this
>> would be:
>> - How are you going to present this information to the user? (I know
>> debugserver can report some performance data... Have you looked into
>> how that works? Do you plan to reuse some parts of that
>> infrastructure?)
>> - How will you get the information from the server to the client?
>>
>> pl
>>
>>
>> On 21 October 2015 at 13:41, Ravitheja Addepally via lldb-dev
>>  wrote:
>> > Hello,
>> >I want to implement support for reading Performance measurement
>> > information using the perf_event_open system calls. The motive is to add
>> > support for Intel PT hardware feature, which is available through the
>> > perf_event interface. I was thinking of implementing a new Wrapper like
>> > PtraceWrapper in NativeProcessLinux files. My query is that, is this a
>> > correct place to start or not ? in case not, could someone suggest me
>> > another place to begin with ?
>> >
>> > BR,
>> > A Ravi Theja
>> >
>> >
>> > ___
>> > 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] Attaching to a stopped (cored) process hangs lldb-server

[Pavel Labath via lldb-dev]

I'm following this discussion, but I don't yet understand what is
going on here completely. What I am sure is that the problem here is
not the S+ state, as that just means "interruptible sleep, foreground
process", and a lot of processes have that state and we attach to them
just fine. I would need to investigate what are the exact properties
or this cored state. I'll try to take a look when I get some spare
cycles, but that might not happen very soon.

Mark, have you investigated what is the next thing to fail after you
remove the waitpid call?

pl

On 3 November 2015 at 16:48, Greg Clayton via lldb-dev
 wrote:
> Can someone with linux experience chime in here? It shouldn't be too hard to 
> figure out which flag 'S' is in. On MacOS we can get a process info structure 
> from a pid and that will have bits set that indicate 'S'...
>
> If you want to checkin this tool into the LLDB source tree at 
> trunk/tools/core_tool then we can get more people to work on it and improve 
> it. It would be nice to have this available for all linux users. I would love 
> to see an JSON output mode that is parseable by automated tools instead of 
> people saving text formats that must be text scraped.
>
> If you can get this into a tool, others can help get this working. Any 
> interest in this?
>
> Greg
>
>> On Nov 3, 2015, at 4:41 PM, Mark Chandler  wrote:
>>
>> The biggest tell is that the process state is already 'S' or stopped. I 
>> don’t know lldb at all to make a change to fix this though.
>>
>>
>> Mark Chandler
>> Battle.Net Engineering Systems | Blizzard Entertainment
>> (P) 949-955-1380 x15353
>>
>> -Original Message-
>> From: Greg Clayton [mailto:gclay...@apple.com]
>> Sent: Tuesday, November 03, 2015 4:39 PM
>> To: Mark Chandler 
>> Cc: lldb-dev@lists.llvm.org
>> Subject: Re: [lldb-dev] Attaching to a stopped (cored) process hangs 
>> lldb-server
>>
>> Makes sense about not writing the core file to disk.
>>
>> Is there a way you can detect this "core" mode where we don't have to 
>> waitpid? Seems like that www.sourceware.org message had ideas on how to 
>> detect this case?
>>
>> Greg
>>
>>> On Nov 3, 2015, at 4:36 PM, Mark Chandler  wrote:
>>>
>>> Not able to do that as the servers have no hard drives (use ram disk and 
>>> net boot) and the tool is trying to avoid a core storm that takes down the 
>>> network file share. I found out what is causing it to hang, there is a call 
>>> to waitpid in NativeLinuxProcess.cpp that waits forever. As the process is 
>>> already stopped, I disabled that and it looks to be working
>>>
>>> Mark Chandler
>>> Battle.Net Engineering Systems | Blizzard Entertainment
>>> (P) 949-955-1380 x15353
>>>
>>> -Original Message-
>>> From: Greg Clayton [mailto:gclay...@apple.com]
>>> Sent: Tuesday, November 03, 2015 4:34 PM
>>> To: Mark Chandler 
>>> Cc: lldb-dev@lists.llvm.org
>>> Subject: Re: [lldb-dev] Attaching to a stopped (cored) process hangs 
>>> lldb-server
>>>
>>> One different approach is to have your tool write all STDIN to a file (the 
>>> core file comes into the tool as STDIN bytes) and then hand LLDB the core 
>>> file and do any needed backtracing and data gathering from the core file 
>>> instead of actually attaching to the process for real. All executable and 
>>> shared library object files (ELF files) from the core file are still on 
>>> disk so you can get symbols and use the debug info, so LLDB should be able 
>>> to load all frames up and symbolicate up the crash location. It should be 
>>> just as good as having the process around without any bad side affects. 
>>> Core files are less useful if they must be archived and symbolicated later 
>>> because the executable files might not be around anymore since things like 
>>> test suites might produce binaries for testing and remove them after the 
>>> test is run or crashed.
>>>
>>> What do you think about this approach?
>>>
>>> Greg Clayton
>>>
>>>
 On Nov 2, 2015, at 5:54 PM, Mark Chandler via lldb-dev 
  wrote:

 So im trying to write a core handler program and use lldb to attach and 
 dump important information about it. This works if a use my tool to attach 
 to an existing one but I found that lldb-server will hang in a waitpid 
 call if the kernel has invoked the tool after another process has cored.

 Example:
 · /proc/sys/kernel/core_pattern is set to |/opt/core_tool
 · Run a.out and it segfaults
 · Kernel invokes core_tool that uses lldb AttachToProcess and 
 a.out is in state “S+”
 · lldb-server hangs in 
 source\Plugins\Process\Linux\NativeProcessLinux.cpp:867
 · if I remove the waitpid it doesn’t hang but fails to attach

 Looks like gdb had a similar problem as well: 
 http://www.sourceware.org/ml/gdb-patches/2008-04/msg00224.html
 Any ideas on how to fix this?

 Mark Chandler
 Battle.Net Engineering Systems | Blizzard Entertainment
 (P) 949-955-138

Re: [lldb-dev] Is it possible to set a python script handler for a signal stop in lldb?

[Pavel Labath via lldb-dev]

I believe there is no such thing at the moment. It might be
interesting to add one though, to enable "conditional" signal
handling. E.g., when an application handles it's own SIGSEGVs, and you
want to pass those quietly, but you want to stop for real problems
(for some definition of "real").

pl

On 16 November 2015 at 04:07, Jay Wang via lldb-dev
 wrote:
> LLDB tutorial tells the way to set a python script handler for a breakpoint.
> see http://lldb.llvm.org/scripting.html
>
> But is there a way to set one for a signal stop?
>
>
> ___
> 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] Is there a way to inspect signaled stack?

[Pavel Labath via lldb-dev]

Hi Eugene,

the libc signal trampoline should have .eh_frame unwind info (I am
assuming this is x86_64 btw), and last time I looked at it, it seemed
that it should be able to handle sigaltstack(). However, I have never
tested this, so it's quite possible there is still some bug hidden
there. Could you file a bug with a small repro case and attach the
output of (thread backtrace) with logging enabled (log enable lldb
unwind). We'll try to look at it.

thanks,
pl


On 13 November 2015 at 19:22, Eugene Birukov via lldb-dev
 wrote:
> Hi,
>
> I am running on Ubuntu Linux. I am using a custom debugger built upon LLDB
> C++ API using version 3.7.
>
> The target program issues a lot of "legitimate" SIGSEGV signals that it
> handles itself. Its signal handler runs on a separate stack (it uses
> sigaltstack() and SA_ONSTACK). Now, sometimes a bug in the program causes
> SIGSEGV that the handler cannot deal with and it crashes. Now, when I load
> the core, I see stack frames for the signal handler stack, but what I really
> need are frames for the signaled stack.
>
> Of course, I have access to siginfo_t and ucontext_t, so I can try to use
> some unwind library, but that approach is far from ideal - the LLDB already
> has the unwinder. So, what should I do to get the set of SBFrame's that I
> can query about local variables, etc.? I mean, something like .cxr command
> in Windbg would be really handy...
>
> Thanks,
> Eugene
>
> ___
> 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] Invalid iterator dereference in TypeMap::ForEach when it's invoked with TypeMaptoList callback

[Pavel Labath via lldb-dev]

Thanks for the heads-up Mikhail.

Ravi,

this looks like your code. Could you take a look at this?

pl


On 16 November 2015 at 16:24, Mikhail Filimonov via lldb-dev
 wrote:
> Hi guys and thank you for the excellent community project!
>
>
>
> Recently I’ve stumbled on a pesky, but trivial Invalid iterator dereference
> bug in SymbolContext and TypeMap implementations at revisions
>
> https://github.com/llvm-mirror/lldb/blob/e528da256d14ecac7df858462b44dca931879509/source/Symbol/SymbolContext.cpp#L823
>
> and
>
> https://github.com/llvm-mirror/lldb/blob/5ac1fc5bc961688505334395598a2bb174eabd3b/source/Symbol/TypeMap.cpp#L172
>
>
>
> From the code below it is obvious that TypeMap::ForEach calls the
> pre-increment operator on m_types iterator right after it has been
> invalidated by m_types.erase
>
>
>
> SymbolContext::SortTypeList(TypeMap &type_map, TypeList &type_list ) const
>
> {
>
> TypeMaptoList callbackM2L (type_map, type_list);
>
> type_map.ForEach(callbackM2L);
>
> return ;
>
> }
>
>
>
> void
>
> TypeMap::ForEach (std::function  const
> &callback)
>
> {
>
> for (auto pos = m_types.begin(), end = m_types.end(); pos != end; ++pos)
>
> {
>
> if (!callback(pos->second))
>
> break;
>
> }
>
> }
>
>
>
> bool
>
> TypeMap::RemoveTypeWithUID (user_id_t uid)
>
> {
>
> iterator pos = m_types.find(uid);
>
>
>
> if (pos != m_types.end())
>
> {
>
> m_types.erase(pos);
>
> return true;
>
> }
>
> return false;
>
> }
>
>
>
> class TypeMaptoList
>
> {
>
> public:
>
> TypeMaptoList(TypeMap &typem, TypeList &typel) :
>
> type_map(typem),type_list(typel)
>
> {
>
> }
>
>
>
> bool
>
> operator() (const lldb::TypeSP& type)
>
> {
>
> if(type)
>
> {
>
> type_list.Insert(type);
>
> type_map.RemoveTypeWithUID(type->GetID());
>
> if (type_map.Empty())
>
> return false;
>
> }
>
> return true;
>
> }
>
>
>
> private:
>
> TypeMap &type_map;
>
> TypeList &type_list;
>
> };
>
>
>
> Regards,
>
> Mikhail Filimonov
>
>
>
>
>
>
>
> 
> 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.
> 
>
> ___
> 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] [Lldb-commits] [lldb] r253317 - Add Pythonic language binding wrapper generation script.

[Pavel Labath via lldb-dev]

On 18 November 2015 at 09:02, Zachary Turner via lldb-dev
 wrote:
> On Tue, Nov 17, 2015 at 8:03 PM Todd Fiala  wrote:
>>
>> Nothing concrete at the moment; however, it could be interesting to look
>> at the clang community and see what could be done for llvm-based language
>> implementations.  The angle that I think would be interesting would be if we
>> can generate bindings more effectively based on the in-depth understanding
>> of the language that is afforded by languages built on top of LLVM.  This is
>> probably less interesting for Python (particularly since we have a
>> functioning solution) and more interesting for languages built on LLVM or
>> clang.
>>
>> Honestly, though, I haven't spent much time on that.
>>
>> For the time being, I am going to not change the path for everyone on
>> swig, and only use a static binding if swig cannot be found.  This will be
>> minimal impact for everyone and doesn't interfere with anyone using a
>> specific version of swig.  We can revisit larger questions about
>> who/what/when on static bindings after we gain some experience with enabling
>> them for those who don't have swig.  We can review and adjust based on our
>> collective experience.  The two files this seems like it will be are the
>> LLDBWrapPython.cpp and the lldb.py file that comes out of python.  I hope to
>> have this working in the next day or so.
>
> To try this another way, I really would like to voice my opinion very very
> strongly for moving away from having different ways of doing things for
> different platforms / build configurations / etc unless it is *required* to
> support a hard requirement of someone's environment.
>
> Here's our current configuration matrix.
>
> Platforms: Windows, Linux, FreeBSD, Darwin, NetBSD, Other(?)
> Build Systems: CMake, Xcode
> SWIG version: 1.3x, latest
> Python version: None, 2.7, 3.x (in progress)
> SWIG Binding Generation: on-the-fly, static (proposed)
>
> In all of these cases (except the proposed), the matrix choices are
> justifiable because they are there to support a hard requirement of
> someone's environment, and I do not think we should grow for anything that
> is not also a hard requirement of someone's environment.  We definitely
> should not grow it out of convenience, and *especially* not if it's only a
> minor convenience.  So I still am looking for a clear answer regarding what
> problem this is solving.  Is not having a swig binary on every machine a
> hard requirement?

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

Re: [lldb-dev] Exclusively build and install LLDB?

[Pavel Labath via lldb-dev]

I believe that for purposes of building distribution packages you
should use the out-of-tree mode of building lldb. This means, you
build llvm and clang separately, and then point your LLDB build to
their installation path with LLDB_PATH_TO_LLVM_BUILD and
LLDB_PATH_TO_CLANG_BUILD variables. This way you can avoid building
llvm/clang twice, you can have a separate package for each logical
component of llvm and you can make lldb optional for your users (e.g.
have only clang installed normally, if user chooses to install lldb,
it will automatically pull in clang if needed). In this mode "make
install" should install only the lldb components, which should be
correctly linked to the already-installed llvm libraries.

That said, I can't guarantee that this mode will work for you
out-of-the-box. We occasionally get patches to fix it up, but I don't
know anyone who is using it extensively. However, I think this would
be the best way forward for you and I'm prepared yo help you out if
you choose to go that way.

What do you think about that?

pl


On 23 November 2015 at 05:12, Kamil Rytarowski via lldb-dev
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 23.11.2015 05:19, Zachary Turner wrote:
>> LLDB links against clang and llvm.  How would an lldb-only target
>> work? i.e. how would you build lldb without first building clang
>> and llvm? Unless I'm misunderstanding the purpose of your
>> question:
>>
>
> I don't want to build the following executables (among others):
> bin/clang
> bin/clang++
> bin/clang-3.8
> bin/clang-check
> bin/clang-cl
> bin/clang-format
> bin/git-clang-format
>
> I've found that to some extend I can emulate it with:
> ninja/make lldb lldb-mi
>
> I would like to have a target lldb-only, building all LLDB targets
> needed to install the full distribution and to perform builtin tests.
>
>> As for the install, are you saying that running "ninja install"
>> does not install lldb?  If so that's a bug and shoudl be fixed in
>> the CMake.
>>
>
> ninja/make install does its job installing LLDB properly.
>
> My complain is that it's not possible (to my knowledge) to stop
> installing Clang and LLVM sets.
>
> I don't want to populate my system with the following example files:
> bin/clang*
> bin/llvm*
> include/clang-c/
> include/clang/
> include/llvm/
>
> Another good reason, besides time and space optimization is that among
> others pkgsrc isn't designed to produce multiple packages from a
> single meta-file (in a format of BSD Makefile in pkgsrc) with rules
> specified to build a piece of software.
>
> It's convenient to users to ship with separated prebuilt packages with
> Clang, LLVM, LLDB etc. For now users who installed Clang from pkgsrc
> won't be able to install LLDB from pkgsrc-wip (containing prebuilt
> package with LLDB from HEAD/master/trunk of the debugger).
>
> For now there seems to be need to go for walk-around similar to
> ArchLinux [1]:
> https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=lldb-svn
>
>
> Additionally I've optimized my build with
> - -DLLVM_TARGETS_TO_BUILD="X86" and it significantly reduced the
> resource usage! I will happily accept more suggestions how to tune it
> further.
>
> My current Makefile is here:
> http://wip.pkgsrc.org/cgi-bin/gitweb.cgi?p=pkgsrc-wip.git;a=blob_plain;f
> =lldb-git/Makefile
> GH mirror:
> https://github.com/NetBSD/pkgsrc-wip/blob/master/lldb-git/Makefile
>
>
> Thanks!
>
>> On Sun, Nov 22, 2015 at 5:44 PM Kamil Rytarowski via lldb-dev
>> mailto:lldb-dev@lists.llvm.org>> wrote:
>>
>> Are there plans to add new target: lldb-only and lldb-install?
>> There are already similar targets for Clang.
>>
>> I'm debugging LLDB on NetBSD and I'm having very bad time building
>> everything with debug symbols. There is also popular request from
>> NetBSD users to just install lldb without conflicting with Clang
>> and LLV M.
>>
>> I was looking at Open Source distributions with a LLDB package,
>> for example ArchLinux is manually copying files from the build...
>>
>> I would like to skip building unnecessary parts and then focus on
>> installing only the LLDB package... otherwise I need 64GB of
>> RAM+storage and a lot of time to produce new package.
>> ___ lldb-dev mailing
>> list lldb-dev@lists.llvm.org 
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQIcBAEBCAAGBQJWUqBCAAoJEEuzCOmwLnZsywcP/iasACfyXiyRVE04J6HXmPxV
> tvnnZp5WafPMmE2cp61oiivBO0PWBrG8aMeZelRZMPZPRhlvGIUYtwCe1W1CeeFq
> QurYR7JwDcMA5fiVCmaqqToDQ3ki9J3fCmjvAnAKIHcq4+baXNDQOm2O3NvBBPNL
> YHn2ZsKBWdZgIRvVYKx6o35zQYBOSgKqfPycvg7h+Nqvvb82MJIBmpb21SAHlbEz
> hwBC/A2GxI399zxxb1vxicS8Fo7OUHx7pont6Er9mcPjLWvkRbahIWiPwysNR1is
> I6HcRgyGSbbEMfuAbhZ16yHvq3Si79Si/O1DteJYF7+lrRdHqmStrQexPnx1E0zl
> u1BrHWUiEkZq5dFHDID/30DQULF1baNq9/qmrVacChJluJlVMIyQwZz8GCXU0RXZ
> cDwnmYSOxstUKWSeL7IvQ3aFMe0WCGXoeSQ0dH/JM0n8CKyVm2XWCAeYuGek7gor
> BIzqIv

Re: [lldb-dev] Fwd: lldb doesn't work on centos7

[Pavel Labath via lldb-dev]

HI,

a couple of random shots in the dark:

- could you paste the output of "frame variable --raw-output s"? (This
disables lldb's type formatters. The goal is to see if the problem is
in the formatter, or in lldb not finding the variable in the first
place).

- could you compile your test executable with -fno-limit-debug-info
and see if that helps?

pl


On 23 November 2015 at 02:15, 陶征霖 via lldb-dev  wrote:
>
> -- Forwarded message --
> From: 陶征霖 
> Date: 2015-11-20 23:10 GMT+08:00
> Subject: lldb doesn't work on centos7
> To: llvm-...@lists.llvm.org
>
>
> Hi,
>
> I build llvm+clang+lldb 3.7.0 from source code on centos7, the build command
> is "cmake -DCMAKE_BUILD_TYPE=Release
> -DCMAKE_INSTALL_PREFIX=${INSTALL_PREFIX} -DLLVM_LIBDIR_SUFFIX=64", there is
> no error during building process.
>
> And then I compile following c++ code using command "clang++ -std=c++11
> -stdlib=libc++ -lc++abi -g t.cpp":
> // t.cpp
> #include 
> using namespace std;
> int main() {
>string s = "aa";
>cout << s;
> }
> Try lldb to debug a.out, found that I can't print string s which shows
> empty:
> lldb a.out
> (lldb) target create "a.out"
> Current executable set to 'a.out' (x86_64).
> (lldb) l
>4int main() {
>5   string s = "aa";
>6   cout << s;
>7}
> (lldb) b 6
> Breakpoint 1: where = a.out`main + 94 at t.cpp:6, address =
> 0x00400e5e
> (lldb) r
> Process 150 launched: '/root/a.out' (x86_64)
> Process 150 stopped
> * thread #1: tid = 150, 0x00400e5e a.out`main + 94 at t.cpp:6, name
> = 'a.out', stop reason = breakpoint 1.1
> frame #0: 0x00400e5e a.out`main + 94 at t.cpp:6
>3using namespace std;
>4int main() {
>5   string s = "aa";
> -> 6   cout << s;
>7}
> (lldb) p s
> (std::__1::string) $0 = {}
>
> Could you please help point out what's wrong in my env? Thanks.
>
> Thanks,
> Zhenglin
>
> ___
> 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] --no-stdin mode kicks in without warning (?)

[Pavel Labath via lldb-dev]

It more likely has something to do with LLDB being multi-threaded and
failing to push the process IO handler on stack. It sounds like a bug,
but it's hard to diagnose without more info. Could you try enabling
logging (log enable -f some_file.txt lldb process) and send that over
when this problem hits. Maybe we can dig something up from that.

cheers,
pl

On 24 November 2015 at 00:08, Ramkumar Ramachandra via lldb-dev
 wrote:
> Hi,
>
> I never do --no-stdin, because the program I'm debugging often takes
> input. If I debug in one of the normal sessions for an extended period
> of time, 'continue' returns the (lldb) prompt immediately, which
> claims that the program is running (it's actually waiting for input).
> At this point, I have no choice but to start over, because there's no
> way to go from the --no-stdin mode to the normal mode (?).
>
> I'm not able to give reproduction steps, but I think it has to do with
> the program being multi-threaded?
>
> Ram
> ___
> 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] Linux core dump doesn't show listing when loaded

[Pavel Labath via lldb-dev]

There has been some discussion in , as
to what get's printed when, but I don't think any changes went in yet.
I wouldn't be opposed to bringing back the old behavior (or keeping
the current one, for that matter), but I feel that any change here
should consistent with whatever is the outcome of the mentioned
discussion.

pl

On 24 November 2015 at 21:09, Ted Woodward via lldb-dev
 wrote:
> I’ve been working on an old rev that we’d released on; now I’m much closer
> to ToT as we move towards our next major Hexagon release.
>
>
>
> Core dumps on the old rev would print out a listing/disassembly for each
> thread in the core dump. Now it doesn’t.
>
>
>
> ToT does this, on x86 Linux:
>
>
>
>>bin/lldb ~/lldb_test/coredump/lincrash -c ~/lldb_test/coredump/lincore
>
> (lldb) target create "/usr2/tedwood/lldb_test/coredump/lincrash" --core
> "/usr2/tedwood/lldb_test/coredump/lincore"
>
> Core file '/usr2/tedwood/lldb_test/coredump/lincore' (x86_64) was loaded.
>
> (lldb) thread list
>
> Process 0 stopped
>
> * thread #1: tid = 0, 0x00401190 lincrash`main + 16 at lincrash.c:5,
> name = 'lincrash', stop reason = signal SIGSEGV
>
> (lldb)
>
>
>
> I can see the listing by going up and down the stack, but I’d like to see
> the listing on load. Is the no listing intended?
>
>
>
> Ted
>
>
>
> --
>
> Qualcomm Innovation Center, Inc.
>
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>
>
>
> ___
> 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] serialized, low-load test pass in parallel test runner

[Pavel Labath via lldb-dev]

I think it sounds like something that would be useful in general. I'd
even go a step further and say that we can replace the current flakey
test mechanism with your proposed solution. If we do that (remove the
current flakey mechanism when this is in place), then I think it would
be super-great as we don't increase the number of moving parts and we
can think of this as just an upgrade of an inferior solution (the
current flakey mechanism has always felt like a hack to me) with a
better one.

If you want to automatically re-run tests, then we can have a mode
that does that, but I'd like to have it off by default. I have several
reasons for this:
- you get to feel bad for having to add flakey decorators, which may
encourage you to fix things
- if you make a change (hopefully only locally :) ) which breaks a lot
of tests, you want this to fail quickly instead of waiting for reruns
- if you make a change that makes things flakey (!), you may not
actually notice it because of the reruns

cheers,
pl






On 27 November 2015 at 18:58, Todd Fiala via lldb-dev
 wrote:
> Note this is similar to the flakey test mechanism, with the primary
> difference being that the re-run is done in a minimal CPU load environment
> rather than wherever the failure first occurred.  The existing flakey test
> rerun logic is not helpful for the high-load-induced failures that I'm
> looking to handle.
>
> On Fri, Nov 27, 2015 at 10:56 AM, Todd Fiala  wrote:
>>
>> Hi all,
>>
>> On OS X (and frankly on Linux sometimes as well, but predominently OS X),
>> we have tests that will sometimes fail when under significant load (e.g.
>> running the concurrent test suite, exacerbated if we crank up the number of
>> threads, but bad enough if we run at "number of concurrent workers == number
>> of logical cores").
>>
>> I'm planning on adding a serialized, one-worker-only phase to the end of
>> the concurrent test run, where the load is much lighter since only one
>> worker will be processing at that phase.  Then, for tests that fail in the
>> first run, I'd re-run them in the serialized, single worker test run phase.
>> On the OS X side, this would eliminate a significant number of test failures
>> that are both hard to diagnose and hard to justify spending significant
>> amounts of time on in the short run.  (There's a whole other conversation to
>> have about fixing them for real, i.e. working through all the race and/or
>> faulty test logic assumptions that are stressed to the max under heavier
>> load, but practically speaking, there are so many of them that this is going
>> to be impractical to address in the short/mid term.).
>>
>> My question to all of you is if we'd want this functionality in top of
>> tree llvm.org lldb.  If not, I'll do it in one of our branches.  If so, we
>> can talk about possibly having a category or some other mechanism if we want
>> to mark those tests that are eligible to be run in the follow-up serialized,
>> low-load pass.  Up front I was just going to allow any test to fall into
>> that bucket.  The one benefit to having it in top of tree llvm.org is that,
>> once I enable test reporting on the green dragon public llvm.org OS X LLDB
>> builder, that builder will be able to take advantage of this, and will most
>> certainly tag fewer changes as breaking a test (in the case where the test
>> is just one of the many that fail under high load).
>>
>> Let me know your thoughts either way.
>>
>> Thanks!
>> --
>> -Todd
>
>
>
>
> --
> -Todd
>
> ___
> 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] Exclusively build and install LLDB?

[Pavel Labath via lldb-dev]

On 2 December 2015 at 16:19, Todd Fiala  wrote:
> Sorry for being late the the party here.
>
> Sean Callanan and some of the other members can comment more on this, but
> LLDB's expression parser for C/C++ is going to need access to the clang
> include headers, so somehow lldb has to be able to find them.  Out of tree
> llvm/clang usage is certainly possible as others have pointed out.  Using
> that as the one way it is done, though, is likely to lead to pain.  Parts of
> lldb's source will adjust as needed when the API surface area of LLVM or
> clang changes.  It may not be happening quite as frequently as it had say 2
> or 3 years ago, but it definitely happens.  So my expectation would be that
> if you decouple lldb from llvm/clang (i.e. let them drift), sooner or later
> you will get bitten by that.  Particularly when things like clang modules
> and whatnot come along and actually require different logic on the lldb side
> to deal with content generated on the clang/llvm side.  Once expression
> evaluation is potentially compromised (due to the drift), I suspect the lldb
> experience will degrade significantly.

I think you have misunderstood our intentions here.

Kamil, correct me if I am wrong, but I don't think we are talking
about building lldb against a different version of clang. What we want
is just to be able to build and link lldb against an already-built
clang (of the same version). This is quite useful when you (as a
distribution maintainer) want to provide prebuilt packages. So, for
example you can have a "clang" and an "lldb" package. Users wishing to
install clang, just get the first one, while someone installing lldb
will get the correct clang package pulled automatically. I believe the
easiest way to build these packages is to use the standalone mode of
lldb (which already exists, and some people use that).

hope that makes sense,
pl
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] New test summary results formatter

[Pavel Labath via lldb-dev]

There is already code that enforces unique names (see dotest.py:1255).
I added this a while back because we were getting test flakyness
because of that. I don't remember the exact reason but I think it had
something to do with the log file names clashes, as all logs are
placed in the same folder.

I agree that it is possible to have multiple test files with the same
name, and still have the names meaningful, but then we need to make
sure that the it actually works reliably.


As for the results formatter, I like the new output a lot. For me, the
inability to recognize crashes is a blocker for using it, but once
that works, I would definitely be in favor of making the default.


I would welcome shortening of the test names, but that is of secondary
significance for me.

great job,
pl


On 3 December 2015 at 06:20, Todd Fiala via lldb-dev
 wrote:
>
>
> On Wed, Dec 2, 2015 at 9:48 PM, Zachary Turner  wrote:
>>
>>
>>
>> On Wed, Dec 2, 2015 at 9:44 PM Todd Fiala  wrote:
>>>
>>>

 and the classname could be dropped (there's only one class per file
 anyway, so the classname is just wasted space)
>>>
>>>
>>> Part of the reason I included that is I've hit several times where copy
>>> and paste errors lead to the same class name, method name or even file name
>>> being used for a test.  I think, though, that most of those are addressed by
>>> having the path (relative is fine) to the python test file.  I think we can
>>> probably get by with classname.methodname (relative test path).  (From your
>>> other email, I think you nuke the classname and keep the module name, but
>>> I'd probably do the reverse, keeping the class name and getting rid of the
>>> module name since it can be derived from the filename).
>>
>> I don't think the filename can be the same anymore, as things will break
>> if two filenames are the same.
>
>
> Maybe, but that wasn't my experience as of fairly recently.  When tracking
> failures sometime within the last month, I tracked something down in a
> downstream branch with two same-named files that (with the legacy output)
> made it hard to track down what was actually failing given the limited info
> of the legacy test summary output.  Maybe that has changed since then, but
> I'm not aware of anything that would have prohibited that.
>
>>
>>   We could go one step further and enforce this in the part where it scans
>> for all the tests.
>
>
> I think I can come up with a valid counterargument to doing that.  I could
> imagine some python .py files being organized hierarchically, where some of
> the context of what is being tested clearly comes from the directory
> structure.
>
> Something like (I'm making this up):
>
> lang/c/const/TestConst.py
> lang/c++/const/TestConst.py
>
> where it seems totally reasonable to me to have things testing const support
> (in this example) but being very different things for C and C++, being
> totally uniqued by path rather than the .py file.  I'd prefer not to require
> something like this to say:
> lang/c/const/TestConstC.py
> lang/c++/const/TestConstC++.py
>
> as it is redundant (at least via the path hierarchy).
>
> The other reason I could see avoiding that
> unique-test-basenames-across-test-suite restriction is that it can become
> somewhat of an unnecessary burden on downstream branches.  Imagine somebody
> has a branch and has a test that happens to be running fine, then somebody
> in llvm.org lldb adds a test with the same name.  Downstream breaks.  We
> could choose to not care about that, but given that a lot of our tests will
> revolve around language features accessed/provided by the debugger, and a
> number of language features pull out of a limited set of feature names (e.g.
> const above), I could see us sometimes hitting this.
>
> Just one take on it.  I'm not particularly wedded to it (I probably would
> avoid the confusion by doing something exactly like what I said above with
> regards to tacking on the language to the test name), but I have hit this in
> similar form across different language tests.
>
>>
>>   If it finds two test files with the same name we could just generate an
>> error.  I think that's a good idea anyway, because if two test files have
>> the same name, then the tests inside must be similar enough to warrant
>> merging them into the same file.
>
>
> Maybe, but not in the real cases I saw across different languages.  I think
> for other areas of the debugger, this isn't an issue.  So maybe language
> feature tests just have to know to append their language (whether it be C,
> C++, ObjC, etc.)
>
>>
>>
>> If no two filenames are the same, and if there's only 1 class per file,
>> then filename + method name should uniquely identify a single test, and so
>> you could omit the class name and show a relative path to the filename.
>
>
> I think we currently have some tests that have multiple test classes in the
> test file.  We could certainly verify that in TOT, and we could certainly
> undo that which seems reaso

Re: [lldb-dev] BasicResultsFormatter - new test results summary

[Pavel Labath via lldb-dev]

If it's not too much work, I think the extra bit of noise will not be
a problem. But I don't think it is really necessary either.

I assume the actual flip will be a small change that we can back out
easily if we notice troubles... After a sufficient grace period we can
remove the old formatter altogether and hopefully simplify the code
somewhat.

pl

On 9 December 2015 at 17:08, Todd Fiala  wrote:
> Here's what I can do.
>
> Put in the change (setting the default to use the new format).
>
> Separately, put in a trial balloon commit with one failing test, one
> exceptional exit test, and one timeout test, and watch the ubuntu 14.04
> buildbot catch it and fail.  Then reverse this out.  That should show beyond
> a reasonable doubt whether the buildbot catches new failures and errors.  (I
> think this is a noisy way to accomplish this, but it certainly would
> validate if its working).
>
> -Todd
>
> On Wed, Dec 9, 2015 at 8:06 AM, Todd Fiala  wrote:
>>
>> Specifically, the markers for issue details are:
>>
>> FAIL
>> ERROR
>> UNEXPECTED SUCCESS
>> TIMEOUT
>>
>> (These are the fourth field in the array entries (lines 275 - 290) of
>> packages/Python/lldbsuite/test/basic_results_formatter.py).
>>
>> -Todd
>>
>> On Wed, Dec 9, 2015 at 8:04 AM, Todd Fiala  wrote:
>>>
>>> That's a good point, Tamas.
>>>
>>> I use (so I claim) the same all upper-case markers for the test result
>>> details.  Including, not using XPASS but rather UNEXPECTED SUCCESS for
>>> unexpected successes.  (The former would trigger the lit script IIRC to
>>> parse that as a failing-style result).
>>>
>>> The intent is this is a no-op on the test runner.
>>>
>>> On Wed, Dec 9, 2015 at 8:02 AM, Tamas Berghammer 
>>> wrote:

 +Ying Chen

 Ying, what do we have to do on the build bot side to support a change in
 the default test result summary formatter?

 On Wed, Dec 9, 2015 at 4:00 PM Todd Fiala via lldb-dev
  wrote:
>
> Hi all,
>
> Per a previous thread on this, I've made all the changes I intended to
> make last night to get the intended replacement of test run results meet 
> or
> exceed current requirements.
>
> I'd like to switch over to that by default.  I'm depending on the test
> event system to be able to handle test method reruns in test results
> accounting.
>
> The primary thing missing before was that timeouts were not routed
> through the test events system, nor were exception process exits (i.e. 
> test
> inferiors exiting with a signal on POSIX systems).  Those were added last
> night so that test events are generated for those, and the
> BasicResultsFormatter presents that information properly.
>
> I will switch it over to being the default output in a bit here.
> Please let me know if you have any concerns once I flip it on by default.
>
> Thanks!
> --
> -Todd
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>
>>>
>>>
>>>
>>> --
>>> -Todd
>>
>>
>>
>>
>> --
>> -Todd
>
>
>
>
> --
> -Todd
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Separating test runner and tests

[Pavel Labath via lldb-dev]

Sounds like a reasonable thing to do. A couple of tiny remarks:
- when you do the move, you might as well rename dotest into something
else, just to avoid the "which dotest should I run" type of
questions...
- there is nothing that makes it obvious that "engine" is actually a
"test running engine", as it sits in a sibling folder. OTOH,
"test_engine" might be too verbose, and messes up tab completion, so
that might not be a good idea either...

pl


On 10 December 2015 at 23:30, Zachary Turner via lldb-dev
 wrote:
> Currently our folder structure looks like this:
>
> lldbsuite
> |-- test
> |-- dotest.py
> |-- dosep.py
> |-- lldbtest.py
> |-- ...
> |-- functionalities
> |-- lang
> |-- expression_command
> |-- ...
> etc
>
> I've been thinking about organizing it like this instead:
>
> lldbsuite
> |-- test
> |-- functionalities
> |-- lang
> |-- expression_command
> |-- ...
> |-- engine
> |-- dotest.py
> |-- dosep.py
> |-- lldbtest.py
> |-- ...
>
> Anybody have any thoughts on this?  Good idea or bad idea?  The main reason
> I want to do this is because as we start breaking up some of the code, it
> makes sense to start having some subpackages under the `engine` folder (or
> the `test` folder in our current world).  For example, Todd and I have
> discussed the idea of putting formatter related stuff under a `formatters`
> subpackage.  In the current world, there's no way to differentiate between
> folders which contain tests and folders which contain test infrastructure,
> so when we walk the directory tree looking for tests we end up walking a
> bunch of directories that are used for test infrastructure code and not
> actual tests.  So I like the logical separation this provides -- having the
> tests themselves all under a single subpackage.
>
> Thoughts?
>
> ___
> 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] BasicResultsFormatter - new test results summary

[Pavel Labath via lldb-dev]

Todd, I've had to disable the new result formatter as it was not
working with the expected timeout logic we have for the old one. The
old XTIMEOUT code is a massive hack and I will be extremely glad when
we get rid of it, but we can't keep our buildbot red until then, so
I've switched it off.

I am ready to start working on this, but I wanted to run this idea
here first. I thought we could have a test annotation like:
@expectedTimeout(oslist=["linux"], ...)

Then, when the child runner would encounter this annotation, it would
set a flag in the "test is starting" message indicating that this test
may time out. Then if the test really times out, the parent would know
about this, and it could avoid flagging the test as error.

Alternatively, if we want to avoid the proliferation test result
states, we could key this off the standard @expectedFailure
annotation, then a "time out" would become just another way it which a
test can fail, and XTIMEOUT would become XFAIL.

What do you think ?

pl

PS: I am pretty new to this part of code, so any pointers you have
towards implementing this would be extremely helpful.



On 10 December 2015 at 23:20, Todd Fiala  wrote:
> Checked this in as r255310.  Let me know if you find any issues with that,
> Tamas.
>
> You will need '-v' to enable it.  Otherwise, it will just print the method
> name.
>
> -Todd
>
> On Thu, Dec 10, 2015 at 2:39 PM, Todd Fiala  wrote:
>>
>> Sure, I can do that.
>>
>> Tamas, okay to give more detail on -v?  I'll give it a shot to see what
>> else comes out if we do that.
>>
>> -Todd
>>
>> On Thu, Dec 10, 2015 at 12:58 PM, Zachary Turner 
>> wrote:
>>>
>>>
>>>
>>> On Thu, Dec 10, 2015 at 12:54 PM Todd Fiala  wrote:

 Hi Tamas,



 On Thu, Dec 10, 2015 at 2:52 AM, Tamas Berghammer
  wrote:
>
> HI Todd,
>
> You changed the way the test failure list is printed in a way that now
> we only print the name of the test function failing with the name of the
> test file in parenthesis. Can we add back the name of the test class to 
> this
> list?


 Sure.  I originally planned to have that in there but there was some
 discussion about it being too much info.  I'm happy to add that back.
>>>
>>> Can we have it tied to verbosity level?  We have -t and -v, maybe one of
>>> those could trigger more detail in the summary view.
>>
>>
>>
>>
>> --
>> -Todd
>
>
>
>
> --
> -Todd
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] marking new summary output for expected timeouts

[Pavel Labath via lldb-dev]

Hi,

we've had an unrelated breaking change, so the buildbots were red over
the weekend. I've fixed it now, and it seems to be turning green.
We've also had power outage during the weekend and not all of the
buildbots are back up yet, as we need to wait for MTV to wake up. I'd
like to give this at least one more day, to give them a chance to
stabilize. Is this blocking you from making further changes to the
test event system?

pl

On 12 December 2015 at 00:20, Todd Fiala  wrote:
> Hey Pavel and/or Tamas,
>
> Let me know when we're definitely all clear on the expected timeout support
> I added to the (now once again) newer default test results.
>
> As soon as we don't need the legacy summary results anymore, I'm going to
> strip out the code that manages it.  It is quite messy and duplicates the
> content that is better handled by the test event system.
>
> Thanks!
>
> -Todd
>
> On Fri, Dec 11, 2015 at 2:03 PM, Todd Fiala  wrote:
>>
>> I went ahead and added the expected timeout support in r255363.
>>
>> I'm going to turn back on the new BasicResultsFormatter as the default.
>> We can flip this back off if it is still not doing everything we need, but I
>> *think* we cover the issue you saw now.
>>
>> -Todd
>>
>> On Fri, Dec 11, 2015 at 10:14 AM, Todd Fiala  wrote:
>>>
>>> Hi Pavel,
>>>
>>> I'm going to adjust the new summary output for expected timeouts.  I hope
>>> to do that in the next hour or less.  I'll put that in and flip the default
>>> back on for using the new summary output.
>>>
>>> I'll do those two changes separately, so you can revert the flip back on
>>> to flip it back off if we still have an issue.
>>>
>>> Sound good?
>>>
>>> (This can be orthogonal to the new work to mark up expected timeouts).
>>> --
>>> -Todd
>>
>>
>>
>>
>> --
>> -Todd
>
>
>
>
> --
> -Todd
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] BasicResultsFormatter - new test results summary

[Pavel Labath via lldb-dev]

Hi,

thanks a lot for fixing the timeout issue on such a short notice. I
didn't think I'd find myself defending them, as I remember being quite
upset when they went in, but they have proven useful in stabilising
the build bots, and I think it's likely you may need them as well.
I'll try to now add a nicer way to expect timeouts so that we don't
have the hack in the new runner as well. I'll add a new message, like
you did for the flakey decorator.

I'm a bit uneasy about adding another kind of a decorator though. What
would you (and anyone else reading this) think about adding this
behavior to the existing XFAIL decorators?
This way, "timeout" would become just another way in which a test can
"fail", and any test marked with an XFAIL decorator would be eligible
for this treatment.

We would lose the ability to individually expect "failures" and
"timeouts", but I don't think that is really necessary, and I think it
will be worth the extra maintainability we get from the fact of having
fewer test decorators.

What do you think?

pl


On 11 December 2015 at 17:54, Todd Fiala  wrote:
> Merging threads.
>
>> The concept is not there to protect against timeouts, which are caused
> by processes being too slow, for these we have been increasing
> timeouts where necessary.
>
> Okay, I see.  If that's the intent, then expected timeout sounds reasonable.
> (My abhorrence was against the idea of using that as a replacement for
> increasing a timeout that was too short under load).
>
> I would go with your original approach (the marking as expected timeout).
> We can either have that generate a new event (much like a change I'm about
> to put in that has flakey tests send and event indicating that they are
> eligible for rerun) or annotate the start message.  FWIW, the startTest()
> call on the LLDBTestResults gets called before decorators have a chance to
> execute, which is why I'm going with the 'send an enabling event' approach.
> (I'll be checking that in shortly here, like when I'm done writing this
> email, so you'll see what I did there).
>
> On Fri, Dec 11, 2015 at 9:41 AM, Todd Fiala  wrote:
>>
>>
>>
>> On Fri, Dec 11, 2015 at 3:26 AM, Pavel Labath  wrote:
>>>
>>> Todd, I've had to disable the new result formatter as it was not
>>> working with the expected timeout logic we have for the old one. The
>>> old XTIMEOUT code is a massive hack and I will be extremely glad when
>>> we get rid of it, but we can't keep our buildbot red until then, so
>>> I've switched it off.
>>>
>>
>> Ah, sorry my comments on the check-in precede me reading this.  Glad you
>> see this as a hack :-)
>>
>> No worries on shutting it off.  I can get the expected timeout as
>> currently written working with the updated summary results.
>>
>>>
>>> I am ready to start working on this, but I wanted to run this idea
>>> here first. I thought we could have a test annotation like:
>>> @expectedTimeout(oslist=["linux"], ...)
>>>
>>> Then, when the child runner would encounter this annotation, it would
>>> set a flag in the "test is starting" message indicating that this test
>>> may time out. Then if the test really times out, the parent would know
>>> about this, and it could avoid flagging the test as error.
>>>
>>
>> Yes, the idea seems reasonable.  The actual implementation will end up
>> being slightly different as the ResultsFormatter will receive the test start
>> event (where the timeout is expected comes from), whereas the reporter of
>> the timeout (the test worker) will not know anything about that data.  It
>> will still generate the timeout, but then the ResultsFormatter can deal with
>> transforming this into the right event when a timeout is "okay".
>>
>>>
>>> Alternatively, if we want to avoid the proliferation test result
>>> states, we could key this off the standard @expectedFailure
>>> annotation, then a "time out" would become just another way it which a
>>> test can fail, and XTIMEOUT would become XFAIL.
>>>
>>> What do you think ?
>>>
>>
>> Even though the above would work, if the issue here ultimately is that a
>> larger timeout is needed, we can avoid all this by increasing the timeout.
>> Probably more effective, though, is going to be running it in the follow-up,
>> low-load, single worker pass, where presumably we would not hit the timeout.
>> If you think that would work, I'd say:
>>
>> (1) short term (like in the next hour or so), I get the expected timeout
>> working in the summary results.
>>
>> (2) longer term (like by end of weekend or maybe Monday at worst), we have
>> the second pass test run at lower load (i.e. single worker thread), which
>> should prevent these things from timing out in the first place.
>>
>> If the analysis of the cause of the timeout is incorrect, then really
>> we'll want to do your initial proposal in the earlier paragraphs, though.
>>
>> What do you think about any of that?
>>
>>
>>
>>>
>>> pl
>>>
>>> PS: I am pretty new to this part of code, so any pointers you have
>>> towards implem

Re: [lldb-dev] BasicResultsFormatter - new test results summary

[Pavel Labath via lldb-dev]

On 14 December 2015 at 16:19, Todd Fiala  wrote:
>> We would lose the ability to individually expect "failures" and
>> "timeouts", but I don't think that is really necessary, and I think it
>> will be worth the extra maintainability we get from the fact of having
>> fewer test decorators.
>>
>
> OTOH, the piece we then lose is the ability to have an XFAIL mean "Hey this
> test really should fail, we haven't implemented feature XYZ (correctly or
> otherwise), so this better fail."  In that semantic meaning, an unexpected
> success would truly be an actionable signal --- either the test is now
> passing because the feature now works (actionable signal option A: the XFAIL
> should come off after verifying), or or the test is passing because it is
> not testing what it thought it was, and the test needs to be modified to
> more tightly bound the expected fail condition (actionable item option B).
>
> So it eliminates the definiteness of an XFAIL ideally meaning "this really
> should fail," turning it into "it is permissible for this to fail."
>
> All that said, our Python test suite is so far away from that ideal right
> now.  The highest level output of our test suite that I care about is "if
> tests run green, this is a good build", and if "tests run red, this is a bad
> build."  I don't see the timeout being rolled into XFAIL as hurting that.
> It seems reasonable to roll them together at this time.  And the test output
> will list and count the timeouts.

I'd say that the root cause here is something different, namely the
fact that our tests do not behave deterministically. If they were
always ending with the same result, then all you said is above would
be true, regardless of whether that result was "failure" or "timeout"
- having a test consistently failing would give the same kind of
signal as a test consistently timing out (although I hope we never
have the latter kind). I am really only interested in hanging tests
here, using this to handle tests that were just slightly too slow is
quite a bad idea. In fact, I think using a uniform decorator would
discourage this, as then you will not have the option of saying "I
want this test to succeed, but if it takes too long, then don't worry
about that" (which is actually what we do right now, and we needed to
do that as we had a lot of tests hanging in the past, but I think
that's gotten better now).

>
> So I'd be okay with that at this time in the sake of simplifying markup for
> tests.

Ok, I'll get on it then.

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

Re: [lldb-dev] Patch for addressing format warnings on 32-bit

[Pavel Labath via lldb-dev]

I believe %z will not work on MSVC 2013, which we are still using on windows.

pl

On 28 December 2015 at 18:32, William Dillon via lldb-dev
 wrote:
> Hi Todd,
>
> The example I put in my last email is one of a few (maybe one more)
> instances where the existing code casts to 64-bit and uses PRIu64.  When I’m
> dabbling in existing code I try to copy the conventions that are already in
> place, so that’s why I went this way.  I’m happy to change it to %zu.  I was
> just checking about that.
>
> - Will
>
> On Dec 28, 2015, at 10:24 AM, Todd Fiala  wrote:
>
> Hi William,
>
> It looks like just the PRIx64/PRIu64 bits are needed from a visual
> inspection.  The source variables that are printed from already are 64-bit
> always, aren't they?  If they're not but they should be, that seems like the
> real underlying problem rather than needing to cast.
>
> What kind of warning are you seeing if you just replace the % format
> specifier?
>
> Thanks!
>
> -Todd
>
> On Sun, Dec 27, 2015 at 12:32 PM, William Dillon via lldb-dev
>  wrote:
>>
>> > Message: 1
>> > Date: Sat, 26 Dec 2015 21:15:53 +0100
>> > From: Joerg Sonnenberger via lldb-dev 
>> > To: lldb-dev@lists.llvm.org
>> > Subject: Re: [lldb-dev] Patch for addressing format warnings on 32-bit
>> > Message-ID: <20151226201553.gb14...@britannica.bec.de>
>> > Content-Type: text/plain; charset=utf-8
>> >
>> > On Fri, Dec 25, 2015 at 06:34:09PM -0800, William Dillon via lldb-dev
>> > wrote:
>> >> There are a handful of -Wformat warnings on 32-bit platforms.
>> >> I addressed all those that I’ve seen while working on Swift.
>> >> Let me know if the git diff format is inappropriate for this.
>> >
>> > Don't cast size_t to uint64_t, format it with %zu directly.
>> >
>> > Joerg
>> >
>>
>> I can go ahead and do that, but I wonder whether there should be two
>> different ways of handling this, even on the same line.  For example:
>>
>> -error.SetErrorStringWithFormat ("SoftwareBreakpointr::%s
>> addr=0x%" PRIx64 ": tried to read %lu bytes but only read %" PRIu64,
>> __FUNCTION__, m_addr, m_opcode_size, (uint64_t)bytes_read);
>> +error.SetErrorStringWithFormat ("SoftwareBreakpointr::%s
>> addr=0x%" PRIx64 ": tried to read %" PRIu64 " bytes but only read %" PRIu64,
>> __FUNCTION__, m_addr, (uint64_t)m_opcode_size, (uint64_t)bytes_read);
>>
>> - Will
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
>
>
> --
> -Todd
>
>
>
> ___
> 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] Hang during attach

[Pavel Labath via lldb-dev]

Also including the list...


On 11 January 2016 at 09:30, Pavel Labath  wrote:
> Hi,
>
> there was a race condition in 3.7, which sometimes caused a hang
> during process attach. This should be fixed in r246756, but this fix
> is not available in the 3.7 branch. I think if you try this with the
> current trunk, you should not experience this problem anymore. If you
> still notice the problem with the trunk lldb, then please let me know.
>
>> Has anything changed in the API over the past year? It looks like LLDB is 
>> creating a server internally; it is terminating quickly for some reason, and 
>> the LLDB parent is waiting forever for its server.
> LLDB now spawns a server which performs the actual debugging work
> (which means you can now debug remotely as well), but that should not
> affect the API in any noticeable way.
>
> cheers,
> pl
>
>
> On 9 January 2016 at 01:42, David Jones via lldb-dev
>  wrote:
>> I have some code which worked under LLVM+LLDB 3.6.0 which runs as follows:
>> its purpose is to run some code, and print a backtrace if the code
>> segfaults. My approach was:
>> - fork
>> - the child runs the main part of the program.
>> - the parent creates a debugger and attaches to the child. The child is
>> continued and allowed to run until either it terminates or faults.
>>
>> This code worked in 3.6.0:
>>
>> switch (pid = fork()) {
>> case -1:
>> return; // no trace
>>
>> case 0:
>> // child
>> fprintf(stderr, "child 1\n");
>> //pause();
>> fprintf(stderr, "child 2\n");
>> signal(SIGUSR1, SIG_DFL);
>> fprintf(stderr, "child 3\n");
>> return;
>>
>> default:
>> // parent: create debugger
>> {
>> StateType   state;
>> //SBAttachInfoai(pid);
>>
>> SBDebugger::Initialize();
>> m_Debugger = SBDebugger::Create(false);
>> if (!m_Debugger.IsValid())
>> fprintf (stderr, "error: failed to create a debugger
>> object\n");
>> m_Debugger.SetAsync(false);
>> m_Listener = m_Debugger.GetListener();
>> m_Target = m_Debugger.CreateTarget(exec_name);
>> fprintf(stderr, "parent 1\n");
>> //m_Target.Attach(ai, m_Error);
>> m_Target.AttachToProcessWithID(m_Listener, pid, m_Error);
>> fprintf(stderr, "parent 2\n");
>>
>>
>> Under LLVM+LLDB 3.7.1, I see the following instead:
>> - the child runs to completion (child 1/2/3 messages print out).
>> - the parent hangs in attach (parent 1 prints out but parent 2 does not)
>>
>> Debugging the whole thing under GDB (unsure how reliable this is, but the
>> hang happens w/o GDB as well) shows:
>>
>> child 1
>> child 2
>> child 3
>> [ child prints out other stuff and runs happily ]
>> parent 1
>> [ child terminates ]
>> [New Thread 0x7fffed043700 (LWP 470)]
>> [New Thread 0x7fffec842700 (LWP 472)]
>> [Thread 0x7fffec842700 (LWP 472) exited]
>> ^C
>> Program received signal SIGINT, Interrupt.
>> 0x72bd566b in pthread_join (threadid=140737169864448,
>> thread_return=0x0)
>> at pthread_join.c:92
>> 92  pthread_join.c: No such file or directory.
>> (gdb) bt
>> #0  0x72bd566b in pthread_join (threadid=140737169864448,
>> thread_return=0x0) at pthread_join.c:92
>> #1  0x75f8247c in lldb_private::HostThreadPosix::Join(void**) ()
>>from /tools/llvm/3.7.1dbg/lib/liblldb.so
>> #2  0x75f7034d in lldb_private::HostThread::Join(void**) ()
>>from /tools/llvm/3.7.1dbg/lib/liblldb.so
>> #3  0x7610802e in
>> lldb_private::process_gdb_remote::GDBRemoteCommunication::StartDebugserverProcess(char
>> const*, unsigned short, lldb_private::ProcessLaunchInfo&, unsigned short&)
>> () from /tools/llvm/3.7.1dbg/lib/liblldb.so
>> #4  0x7612f5c0 in
>> lldb_private::process_gdb_remote::ProcessGDBRemote::LaunchAndConnectToDebugserver(lldb_private::ProcessInfo
>> const&) ()
>>from /tools/llvm/3.7.1dbg/lib/liblldb.so
>> #5  0x7612fbde in
>> lldb_private::process_gdb_remote::ProcessGDBRemote::DoAttachToProcessWithID(unsigned
>> long, lldb_private::ProcessAttachInfo const&) ()
>>from /tools/llvm/3.7.1dbg/lib/liblldb.so
>> #6  0x7623efa5 in
>> lldb_private::Process::Attach(lldb_private::ProcessAttachInfo&) () from
>> /tools/llvm/3.7.1dbg/lib/liblldb.so
>> #7  0x77025cc4 in
>> PlatformPOSIX::Attach(lldb_private::ProcessAttachInfo&,
>> lldb_private::Debugger&, lldb_private::Target*, lldb_private::Error&) ()
>>from /tools/llvm/3.7.1dbg/lib/liblldb.so
>> #8  0x7626ef52 in
>> lldb_private::Target::Attach(lldb_private::ProcessAttachInfo&,
>> lldb_private::Stream*) () from /tools/llvm/3.7.1dbg/lib/liblldb.so
>> #9  0x75d4a4d7 in (anonymous
>> namespace)::AttachToProcess(lldb_private::ProcessAttachInfo&,
>> lldb_private::Target&) ()
>>from /tools/llvm/3.7.1dbg/lib/liblldb.so
>> #10 0x75d4a149 in

Re: [lldb-dev] Using control+left/right arrow to jump between words in the prompt

[Pavel Labath via lldb-dev]

LLDB's command line editing leaves a lot to be desired. The thing
which annoys me the most is that you get bogus characters inserted if
you press the wrong character (e.g. left arrow) in the incremental
search (^R) mode.

> Is it a feature that would be welcome?
Is this an offer to implement the feature? ;)
If so, I know a couple of people, who would be very pleased by that. :)

cheers,
pl

On 9 January 2016 at 20:06, Ori Avtalion via lldb-dev
 wrote:
> Hi,
>
> I tried using lldb (and the Swift repl, which uses it), and found it
> very annoying that the CTRL+left/right arrow key sequence isn't
> handled correctly, spewing ;5D and ;5C instead.
>
> I'm used to be able to hit Ctrl+left/right to jump between words in
> almost any editing software.
>
> Is it a feature that would be welcome?
>
> Thanks,
> Ori
> ___
> 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] lldb tests and tear down hooks

[Pavel Labath via lldb-dev]

On 14 January 2016 at 21:52, Zachary Turner via lldb-dev
 wrote:
> So what if tests could be *either* a method *or* a nested class.  If it's a
> nested class, it could provide setUp, tearDown, and run methods.  These
> setup and teardown methods can do whatever they want specific to the
> individual test, and it also provides the exception safe way to clean up.

I don't think this is supported by unittest, which is what determines
what constitutes a "test". Nothing that couldn't be hacked around, but
I don't see the added value over just using a finally block.

Was there any reason we couldn't use that? I don't think it prevents
code reuse, and it's a standard way of doing things that everyone
should be familiar with.

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

Re: [lldb-dev] Does LLDB work on Ubuntu 14.04 x86_64?

[Pavel Labath via lldb-dev]

Hi,

thanks for the report. Lldb does indeed work on linux x86_64 (and
plenty more), but I think noone tests it with your given combination
of cmake flags. I've managed to reproduce your problem and fix it with
, but please give it a go to make sure
it works for you. If all goes well, we'll get this backported to the
3.8 branch.

cheers,
pl


On 18 January 2016 at 01:54, David Jones via lldb-dev
 wrote:
> I'm trying out the release candidate(?) as follows:
>
> svn co http://llvm.org/svn/llvm-project/llvm/branches/release_38 llvm
> svn co http://llvm.org/svn/llvm-project/cfe/branches/release_38 cfe
> svn co http://llvm.org/svn/llvm-project/lldb/branches/release_38 lldb
>
> cd llvm/tools
> ln -s ../../cfe clang
> ln -s ../../lldb lldb
> cd ..
> mkdir build
> cd build
>
> cmake -DLLVM_BUILD_LLVM_DYLIB=ON -DLLVM_LINK_LLVM_DYLIB=ON
> -DCMAKE_INSTALL_PREFIX=/tools/llvm/rel_38
> -DLLVM_TARGETS_TO_BUILD="X86;CppBackend" -DCMAKE_BUILD_TYPE=Release
> -DLLVM_ENABLE_ASSERTIONS=ON ..
> cmake --build . -- -j4
> sudo cmake --build . --target install
>
>
> LLVM fundamentally works: I am able to link the LLVM libraries with my
> application, and my application passes its regression tests.
>
> clang fundamentally works: it is able to compile a program.
>
> But lldb:
>
> dej@slam:~$ export LD_LIBRARY_PATH=/tools/llvm/rel_38/lib
> dej@slam:~$ export PATH=/tools/llvm/rel_38/bin:$PATH
> dej@slam:~$ lldb /bin/ls
> (lldb) target create "/bin/ls"
> Current executable set to '/bin/ls' (x86_64).
> (lldb) r
> Process 13656 launched: '/bin/ls' (x86_64)
> Segmentation fault (core dumped)
>
> dej@slam:~$ gdb lldb core
> ...
> (gdb) bt
> #0  0x7fd9971b5671 in LLVMDisasmInstruction ()
>from /tools/llvm/rel_38/bin/../lib/../lib/libLLVM-3.8.so
> #1  0x7fd999e350c2 in
> AssemblyParse_x86::instruction_length(lldb_private::Address, int&) () from
> /tools/llvm/rel_38/bin/../lib/liblldb.so.3.8.0
> #2  0x7fd999e37d08 in
> AssemblyParse_x86::get_non_call_site_unwind_plan(lldb_private::UnwindPlan&)
> () from /tools/llvm/rel_38/bin/../lib/liblldb.so.3.8.0
> #3  0x7fd999e38e95 in
> UnwindAssembly_x86::GetNonCallSiteUnwindPlanFromAssembly(lldb_private::AddressRange&,
> lldb_private::Thread&, lldb_private::UnwindPlan&) () from
> /tools/llvm/rel_38/bin/../lib/liblldb.so.3.8.0
> #4  0x7fd999c8693b in
> lldb_private::FuncUnwinders::GetAssemblyUnwindPlan(lldb_private::Target&,
> lldb_private::Thread&, int) ()
>from /tools/llvm/rel_38/bin/../lib/liblldb.so.3.8.0
> #5  0x7fd999c88594 in
> lldb_private::FuncUnwinders::GetUnwindPlanAtNonCallSite(lldb_private::Target&,
> lldb_private::Thread&, int) ()
>from /tools/llvm/rel_38/bin/../lib/liblldb.so.3.8.0
> #6  0x7fd999dfb16d in
> lldb_private::RegisterContextLLDB::GetFullUnwindPlanForFrame() () from
> /tools/llvm/rel_38/bin/../lib/liblldb.so.3.8.0
> #7  0x7fd999dfff90 in
> lldb_private::RegisterContextLLDB::InitializeZerothFrame() () from
> /tools/llvm/rel_38/bin/../lib/liblldb.so.3.8.0
> #8  0x7fd999e01e83 in
> lldb_private::RegisterContextLLDB::RegisterContextLLDB(lldb_private::Thread&,
> std::shared_ptr const&,
> lldb_private::SymbolContext&, unsigned int, lldb_private::UnwindLLDB&) ()
>from /tools/llvm/rel_38/bin/../lib/liblldb.so.3.8.0
> #9  0x7fd999df5d43 in lldb_private::UnwindLLDB::AddFirstFrame() ()
>from /tools/llvm/rel_38/bin/../lib/liblldb.so.3.8.0
> #10 0x7fd999df63d0 in
> lldb_private::UnwindLLDB::DoGetFrameInfoAtIndex(unsigned int, unsigned
> long&, unsigned long&) ()
>from /tools/llvm/rel_38/bin/../lib/liblldb.so.3.8.0
> #11 0x7fd999d1049b in
> lldb_private::StackFrameList::GetFramesUpTo(unsigned int) () from
> /tools/llvm/rel_38/bin/../lib/liblldb.so.3.8.0
> #12 0x7fd999d11a23 in
> lldb_private::StackFrameList::GetFrameAtIndex(unsigned int) () from
> /tools/llvm/rel_38/bin/../lib/liblldb.so.3.8.0
> #13 0x7fd999ce4ae1 in
> lldb_private::Thread::GetStackFrameAtIndex(unsigned int) () from
> /tools/llvm/rel_38/bin/../lib/liblldb.so.3.8.0
> #14 0x7fd999cc839a in
> lldb_private::StopInfoBreakpoint::ShouldStopSynchronous(lldb_private::Event*)
> () from /tools/llvm/rel_38/bin/../lib/liblldb.so.3.8.0
> #15 0x7fd999ce75b3 in
> lldb_private::Thread::ShouldStop(lldb_private::Event*) () from
> /tools/llvm/rel_38/bin/../lib/liblldb.so.3.8.0
> #16 0x7fd999cee452 in
> lldb_private::ThreadList::ShouldStop(lldb_private::Event*) () from
> /tools/llvm/rel_38/bin/../lib/liblldb.so.3.8.0
> #17 0x7fd999cb505b in
> lldb_private::Process::ShouldBroadcastEvent(lldb_private::Event*) () from
> /tools/llvm/rel_38/bin/../lib/liblldb.so.3.8.0
> #18 0x7fd999cb5111 in
> lldb_private::Process::HandlePrivateEvent(std::shared_ptr&)
> ()
>from /tools/llvm/rel_38/bin/../lib/liblldb.so.3.8.0
> #19 0x7fd999cb5f73 in lldb_private::Process::RunPrivateStateThread(bool)
> ()
>from /tools/llvm/rel_38/bin/../lib/liblldb.so.3.8.0
> #20 0x7fd999b45d67 in
> lldb_private::HostNativeThreadBase::Threa

Re: [lldb-dev] Spurious process state change events

[Pavel Labath via lldb-dev]

Hello,

thanks for confirming my suspicions. Sending the extra running event
seems quite annoying to me as well, but it is how things work at the
moment. And the problem does not seem to be linux-specific. This is
the sequence of events I get on a Mac, when running over a conditional
breakpoint that does not stop:

Got event: running , restarted:  False
Got event: stopped , restarted:  True
Got event: running , restarted:  False
Got event: stopped , restarted:  False

Shall I file a bug about this?

pl

On 19 January 2016 at 19:03, Jim Ingham  wrote:
>
>> On Jan 15, 2016, at 1:49 PM, Vadim Chugunov via lldb-dev 
>>  wrote:
>>
>> +lldb-dev
>>
>> On Fri, Jan 15, 2016 at 1:47 PM, Vadim Chugunov  wrote:
>> Thanks, that was it!
>>
>> On Fri, Jan 15, 2016 at 1:00 PM, Pavel Labath  wrote:
>> Hi,
>>
>> The stopped event should have the "restarted" flag set. You can use
>> the GetRestartedFromEvent function to check for that. (Let me know if
>> they don't). I think you can get this (under varying circumstances) on
>> other platforms as well, so you need to handle this everywhere.
>>
>> Somebody correct me if I'm wrong, but I believe that every restarted
>> should be then followed by a running event.
>
> No, if you get a stop event with the restarted bit set, the next event will 
> be another stop event.  It just seemed annoying, if you already know the 
> process restarted, to have to turn around and wait for the running event.
>
> Jim
>
>
>>
>> cheers,
>> pl
>>
>>
>> On 15 January 2016 at 19:35, Vadim Chugunov via lldb-dev
>>  wrote:
>> > Hi,
>> > I have a Python script that drives LLDB (in async mode), with a
>> > listener attached to the process.
>> > On OSX, upon the launch, LLDB emits a eStateRunning process state
>> > event, and then eventually eStateStopped - when a breakpoint is hit.
>> > On Linux, however, the initial eStateRunning is immediately followed
>> > by eStateStopped and another eStateRunning, without any intervention
>> > on my part.  This messes things up for me somewhat, because my script
>> > thinks that a breakpoint has been hit and tries examine state of the
>> > process.
>> > So I have 2 questions:
>> > - Is it supposed to happen?
>> > - What would be the best way to filter out these spurious stop events?
>> >   if is_linux and is_first_stop_event: ...  feels a bit hacky.
>> >
>> > thanks!
>> > ___
>> > 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

Re: [lldb-dev] marking new summary output for expected timeouts

[Pavel Labath via lldb-dev]

Hi,

I have removed all of our expected timeouts from dosep.py (there are
still some freebsd and darwin ones left, but I don't know If anyone is
looking at those), so I think we're not using any part of the old test
runner at the moment. All clear for removal on our part.

pl


On 14 December 2015 at 16:06, Todd Fiala  wrote:
> Oh yeah, that's fine.  I won't take that code out.
>
> Hmm at least some of the builds went through this weekend, I made a number
> of changes Saturday morning (US Pacific time) that I saw go through the
> Ubuntu 14.04 cmake bot.
>
> On Mon, Dec 14, 2015 at 6:29 AM, Pavel Labath  wrote:
>>
>> Hi,
>>
>> we've had an unrelated breaking change, so the buildbots were red over
>> the weekend. I've fixed it now, and it seems to be turning green.
>> We've also had power outage during the weekend and not all of the
>> buildbots are back up yet, as we need to wait for MTV to wake up. I'd
>> like to give this at least one more day, to give them a chance to
>> stabilize. Is this blocking you from making further changes to the
>> test event system?
>>
>> pl
>>
>> On 12 December 2015 at 00:20, Todd Fiala  wrote:
>> > Hey Pavel and/or Tamas,
>> >
>> > Let me know when we're definitely all clear on the expected timeout
>> > support
>> > I added to the (now once again) newer default test results.
>> >
>> > As soon as we don't need the legacy summary results anymore, I'm going
>> > to
>> > strip out the code that manages it.  It is quite messy and duplicates
>> > the
>> > content that is better handled by the test event system.
>> >
>> > Thanks!
>> >
>> > -Todd
>> >
>> > On Fri, Dec 11, 2015 at 2:03 PM, Todd Fiala 
>> > wrote:
>> >>
>> >> I went ahead and added the expected timeout support in r255363.
>> >>
>> >> I'm going to turn back on the new BasicResultsFormatter as the default.
>> >> We can flip this back off if it is still not doing everything we need,
>> >> but I
>> >> *think* we cover the issue you saw now.
>> >>
>> >> -Todd
>> >>
>> >> On Fri, Dec 11, 2015 at 10:14 AM, Todd Fiala 
>> >> wrote:
>> >>>
>> >>> Hi Pavel,
>> >>>
>> >>> I'm going to adjust the new summary output for expected timeouts.  I
>> >>> hope
>> >>> to do that in the next hour or less.  I'll put that in and flip the
>> >>> default
>> >>> back on for using the new summary output.
>> >>>
>> >>> I'll do those two changes separately, so you can revert the flip back
>> >>> on
>> >>> to flip it back off if we still have an issue.
>> >>>
>> >>> Sound good?
>> >>>
>> >>> (This can be orthogonal to the new work to mark up expected timeouts).
>> >>> --
>> >>> -Todd
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> -Todd
>> >
>> >
>> >
>> >
>> > --
>> > -Todd
>
>
>
>
> --
> -Todd
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Getting lldb tests working on Hexagon

[Pavel Labath via lldb-dev]

What is the sequence of lldb commands you use to innitiate a hexagon
debug session normally? Do you need to set a custom platform (platform
select XXX)? If so, then you need to look into --platform-name (and
possibly --platform-url, --platform-working-dir) parameter, and
possibly add some support there?

On 20 January 2016 at 17:48, Ted Woodward via lldb-dev
 wrote:
> I’m trying to get the lldb tests running using lldb built with Hexagon
> support. Some tests are running correctly, but others are failing/skipped
> etc.
>
>
>
> First, I’d like to get it to skip tests that shouldn’t be run. For example,
> I see output that looks like this:
>
> Configuration: arch=x86_64
> compiler=/prj/dsp/qdsp6/release/internal/branch-8.0/linux64/latest/Tools/bin/hexagon-clang
>
>
>
> Or
>
>
>
> Config=x86_64-/prj/dsp/qdsp6/release/internal/branch-8.0/linux64/latest/Tools/bin/hexagon-clang
>
>
>
> Those are clearly incorrect.
>
>
>
> My dotest line is:
>
> python dotest.py -C
> /prj/dsp/qdsp6/release/internal/branch-8.0/linux64/latest/Tools/bin/hexagon-clang
> --executable /local/mnt/workspace/ted/8.0/build/bin/lldb
>
>
>
> How does the –A flag affect the Configuration/Config outputs above?
>
>
>
> Ted
>
>
>
> --
>
> Qualcomm Innovation Center, Inc.
>
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>
>
>
> ___
> 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] clang-format now supports return type on separate line

[Pavel Labath via lldb-dev]

Apparently, you can also disable the formatting of a piece of code by
a magic comment. Could be quite useful for those tables. From the
docs:
-
Clang-format understands also special comments that switch formatting
in a delimited range. The code between a comment // clang-format off
or /* clang-format off */ up to a comment // clang-format on or /*
clang-format on */ will not be formatted. The comments themselves will
be formatted (aligned) normally.
-


On 22 January 2016 at 17:09, Todd Fiala via lldb-dev
 wrote:
> Okay, thanks for the tip!
>
> On Fri, Jan 22, 2016 at 8:32 AM, Zachary Turner  wrote:
>>
>> By the way, one place where you are guaranteed to get undesirable results
>> is where you have a large array formatted so that the columns line up.  Like
>> in our options tables in the CommandObjects.  If you're using git, one way
>> to avoid having clang-format touch these files is to commit that file by
>> itself, then run git clang-format (since it only looks at staged files),
>> then git commit --amend.  But of course that will gloss over any other
>> changes you made to the file as well.  But in any case, it's another trick
>> I've found useful occasionally.
>>
>> On Fri, Jan 22, 2016 at 7:09 AM Kate Stone 
>> wrote:
>>>
>>> Agreed.  My guidance has been that we go ahead and require submitters to
>>> use clang-format for patches, but to acknowledge that there may be cases
>>> where this produces undesirable results.  Manual formatting to correct these
>>> issues is acceptable and should lead to discussions about concrete examples
>>> where the automated approach is imperfect.
>>>
>>> Kate Stone k8st...@apple.com
>>>  Xcode Runtime Analysis Tools
>>>
>>> On Jan 21, 2016, at 9:46 PM, Todd Fiala via lldb-dev
>>>  wrote:
>>>
>>> Okay, sounds like a reasonable thing to try.  We can always review it if
>>> it causes any real issues.
>>>
>>> On Thu, Jan 21, 2016 at 11:34 AM, Zachary Turner 
>>> wrote:



 On Thu, Jan 21, 2016 at 11:18 AM Sean Callanan 
 wrote:
>
> I tend to agree with Zachary on the overall principle – and I would be
> willing to clang-format functions when I modify them.  I’m concerned 
> about a
> specific class of functions, though.  Let’s say I have a function that has
> had lots of activity (I’m thinking of, for example, ParseType off in the
> DWARF parser).  Unfortunately, such functions tend to be the ones that
> benefit most from clang-format.
>
> In such a function, there’s a lot of useful history available via svn
> blame that helps when fixing bugs.  My concern is that if someone
> clang-formats this function after applying the kth fix, suddenly I've lost
> convenient access to that history.  It’s only available with a fair amount
> of pain, and this pain increases as more fixes are applied because now I
> need to interleave the info before and after reformatting.
>
> Would it be reasonable to mark such functions as “Don’t clang-format”?
> That could be also interpreted as a “// TODO add comments so what this 
> does
> is more understandable”


 Well again by default it's only going to format the code you touch in
 yoru diff plus 1 or 2 surrounding lines.  So having it format an entire
 function is something you would have to explicitly go out of your way to 
 do.
 So it's a judgement call.  If you think the function would be better off
 clang-formatting the entire thing, do that.  If you just want to format the
 lines you're touching because you were in there anyway, that's the default
 behavior.
>>>
>>>
>>>
>>>
>>> --
>>> -Todd
>>>
>>> ___
>>>
>>>
>>> lldb-dev mailing list
>>> lldb-dev@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
>
>
> --
> -Todd
>
> ___
> 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] Bad state of release 3.7.1?

[Pavel Labath via lldb-dev]

Hello Jeffrey,

we did test 3.7 before letting it out, bug this bug was fixed only
after the release date, so the fix is not present in 3.7. I think you
have a couple of options now:
- backport the patch to 3.7: should be pretty easy and I expect it to
"just work"
- llvm 3.7 + lldb 3.8: this won't work out of the box as llvm
interfaces have changed. I don't think it would be too hard to make it
work, but you would be in totally unsupported waters there..
- switch to lldb 3.8: probably the easiest solution. Note that you can
still use llvm 3.7 in other parts of your toolchain, if you need it.
The only requirement is that you build lldb with the matching version
of llvm.

regards,
pl




On 26 January 2016 at 01:36, David Jones via lldb-dev
 wrote:
> r246756 has a fix, if you are comfortable applying it. It's a large patch.
> In theory it should back-port but I have not tried it.
>
> The API gap from 3.7.1 to 3.8 is quite minimal, so you should be able to get
> your applications running with 3.8 rather easily if they are running on
> 3.7.1 already.
>
>
> On Mon, Jan 25, 2016 at 7:40 PM, Jeffrey Tan 
> wrote:
>>
>> Btw: is there a fix that we can cherry pick? Or is it safe for us to build
>> lldb 3.8rc1 with llvm3.7.1?
>>
>> On Mon, Jan 25, 2016 at 4:34 PM, Jeffrey Tan 
>> wrote:
>>>
>>> Thanks David.
>>> I am new to lldb group but it's kind of surprise to me that the lldb on
>>> the official release page(http://llvm.org/releases/download.html#3.7.1) can
>>> have such big problems(can't attach/launch). Don't we fully test lldb before
>>> we post on the official website?
>>>
>>>
>>>
>>> On Mon, Jan 25, 2016 at 4:12 PM, David Jones 
>>> wrote:

 This is a known problem with 3.7.1.

 It should be fixed for 3.8. You should be able to try out 3.8rc1 right
 now.



 On Mon, Jan 25, 2016 at 5:37 PM, Jeffrey Tan via lldb-dev
  wrote:
>
> Hi,
>
> My colleague downloaded and built 3.7.1 version of lldb on Linux. When
> we used it to attach to a normal process(like sleep), it just hangs 
> forever:
>
> bin/lldb -n sleep
> (lldb) process attach --name "sleep"
>
> And my private built 3.8.0 version works fine.
>
> Just to confirm, is 3.7.1 a bad version? Is there any known issue about
> it?
>
> Thanks
>
> ___
> 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

Re: [lldb-dev] Patch to fix REPL for ARMv7 & ARMv6 on linux

[Pavel Labath via lldb-dev]

+ Omair

I don't really understand arm (sub)-architectures or REPL. The patch
seems mostly harmless, but it also feels like a hack to me. A couple
of questions:
- why does this only pose a problem for REPL?
- If I understand correctly, the problem is that someone is looking at
the architecture string contained in the Triple, and not finding what
it expects. Is that so? Could you point me to (some of) the places
that do that.

Omair, any thoughts on this?

cheers,
pl


On 25 January 2016 at 18:55, Hans Wennborg  wrote:
> This patch looks reasonable to me, but I don't know enough about LLDB
> to actually review it.
>
> +Renato or Pavel maybe?
>
> On Thu, Jan 14, 2016 at 11:32 AM, William Dillon via lldb-dev
>  wrote:
>> Hi again, everyone
>>
>> I’d like to ping on this patch now that the 3.8 branch is fairly new, and 
>> merging it over is fairly straight-forward.
>>
>> Thanks in advance for your comments!
>> - Will
>>
>>> There is a small change that enables correct calculation of arm sub 
>>> architectures while using the REPL on arm-linux.  As you may of may or may 
>>> not know, linux appends ‘l’ to arm architecture versions to denote little 
>>> endian.  This sometimes interferes with the determination of the 
>>> architecture in the triple.  I experimented with adding sub architecture 
>>> entries for these within lldb, but I discovered a simpler (and less 
>>> invasive) method.  Because LLVM already knows how to handle some of these 
>>> cases (I have a patch submitted for review that enables v6l; v7l already 
>>> works), I am relying on llvm to clean it up.  The gist of it is that the 
>>> llvm constructor (when given a triple string) retains the provided string 
>>> unless an accessor mutates it.  Meanwhile, the accessors for the components 
>>> go through the aliasing and parsing logic.  This code detects whether the 
>>> sub-architecture that armv6l or armv7l aliases to is detected, and re-sets 
>>> the architecture in the triple.  This overwrites the architecture that 
>>> comes from linux, thus sanitizing it.
>>>
>>> Some kind of solution is required for the REPL to work on arm-linux.  
>>> Without it, the REPL crashes.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Module Cache improvements - RFC

[Pavel Labath via lldb-dev]

Hello all,

we are running into limitations of the current module download/caching
system. A simple android application can link to about 46 megabytes
worth of modules, and downloading that with our current transfer rates
takes about 25 seconds. Much of the data we download this way is never
actually accessed, and yet we download everything immediately upon
starting the debug session, which makes the first session extremely
laggy.

We could speed up a lot by only downloading the portions of the module
that we really need (in my case this turns out to be about 8
megabytes). Also, further speedups could be made by increasing the
throughput of the gdb-remote protocol used for downloading these files
by using pipelining.

I made a proof-of-concept hack  of these things, put it into lldb and
I was able to get the time for the startup-attach-detach-exit cycle
down to 5.4 seconds (for comparison, the current time for the cycle is
about 3.6 seconds with a hot module cache, and 28(!) seconds with an
empty cache).

Now, I would like to properly implement these things in lldb properly,
so this is a request for comments on my plan. What I would like to do
is:
- Replace ModuleCache with a SectionCache (actually, more like a cache
of arbitrary file chunks). When a the cache gets a request for a file
and the file is not in the cache already, it returns a special kind of
a Module, whose fragments will be downloaded as we are trying to
access them. These fragments will be cached on disk, so that
subsequent requests for the file do not need to re-download them. We
can also have the option to short-circuit this logic and download the
whole file immediately (e.g., when the file is small, or we have a
super-fast way of obtaining the whole file via rsync, etc...)
- Add pipelining support to GDBRemoteCommunicationClient for
communicating with the platform. This actually does not require any
changes to the wire protocol. The only change is in adding the ability
to send an additional request to the server while waiting for the
response to the previous one. Since the protocol is request-response
based and we are communication over a reliable transport stream, each
response can be correctly matched to a request even though we have
multiple packets in flight. Any packets which need to maintain more
complex state (like downloading a single entity using continuation
packets) can still lock the stream to get exclusive access, but I am
not sure if we actually even have any such packets in the platform
flavour of the protocol.
- Paralelize downloading of multiple files in parallel, utilizing
request pipelining. Currently we get the biggest delay when first
attaching to a process (we download file headers and some basic
informative sections) and when we try to set the first symbol-level
breakpoint (we download symbol tables and string sections). Both of
these actions operate on all modules in bulk, which makes them easy
paralelization targets. This will provide a big speed boost, as we
will be eliminating communication latency. Furthermore, in case of
lots of files, we will be overlapping file download  (io) with parsing
(cpu), for an even bigger boost.

What do you think?

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

Re: [lldb-dev] Understanding debugger launch events sequence

[Pavel Labath via lldb-dev]

Hi Jeffrey,

I see a couple of problems with the way you are using the lldb's API.
The main problem is you are launching the target via the command-line
API, which does not allow you to specify the listener upon creation.
When you start it this way all events go to the default debugger
listener (debugger.GetListener()), and by the time you connect your
own listener, some of these events have already been broadcast, and
that is why you get nondeterministic behavior. You should use the
SBTarget.Launch function to specify the listener from the start.

The second problem is the handling of the Stopped events. Sometimes
LLDB needs to stop the inferior do to some internal work, but this the
program is immediately resumed. This event is broadcast as a "stopped"
event with a special "restarted" bit set (see
SBProcess.GetRestartedFromEvent, and
)

hope that helps,
pl



On 29 January 2016 at 03:53, Jeffrey Tan via lldb-dev
 wrote:
> Hi,
>
> On mac OS, I am having difficulty understanding the launch debugger events
> sequence of lldb. I used the following code to play around LLDB. I found,
> for some binaries, debugger will enter stopped/paused mode, waiting for my
> further input, print stack shows:
> dbg> bt
> * thread #1: tid = 0x15153e, 0x7fff5fc0d2af
> dyld`gdb_image_notifier(dyld_image_mode, unsigned int, dyld_image_info
> const*) + 1
>   * frame #0: 0x7fff5fc0d2af dyld`gdb_image_notifier(dyld_image_mode,
> unsigned int, dyld_image_info const*) + 1
> frame #1: 0x401d
>
> But some other binaries, it just print "Process event: stopped, reason: 1"
> and inferior just exits immediately without waiting for debugger's further
> input.
>
> Questions:
> 1. When I launch a binary, is there supposed to be a loader breakpoint
> waiting for debugger continue? Any other debug events do I expect to get and
> continue?
> 2. What about attach?
> 3. What is the dyld`gdb_image_notifier() debugger break above? Why does it
> happen for some binary but not others?
>
> Thanks for any information!
>
> # Should be first for LLDB package to be added to search path.
> from find_lldb import lldb
> from lldb import eStateStepping, eStateRunning, eStateExited, SBBreakpoint,
> SBEvent, SBListener, SBProcess, SBTarget
> import sys
> import os
> import subprocess
> from sys import stdin, stdout
> from threading import Thread
>
> class LLDBListenerThread(Thread):
> should_quit = False
>
> def __init__(self, process):
>   Thread.__init__(self)
>   self.listener = SBListener('Chrome Dev Tools Listener')
>   self._add_listener_to_process(process)
>   self._broadcast_process_state(process)
>   self._add_listener_to_target(process.target)
>
> def _add_listener_to_target(self, target):
> # Listen for breakpoint/watchpoint events
> (Added/Removed/Disabled/etc).
> broadcaster = target.GetBroadcaster()
> mask = SBTarget.eBroadcastBitBreakpointChanged |
> SBTarget.eBroadcastBitWatchpointChanged |
> SBTarget.eBroadcastBitModulesLoaded
> broadcaster.AddListener(self.listener, mask)
>
> def _add_listener_to_process(self, process):
> # Listen for process events (Start/Stop/Interrupt/etc).
> broadcaster = process.GetBroadcaster()
> mask = SBProcess.eBroadcastBitStateChanged
> broadcaster.AddListener(self.listener, mask)
>
> def _broadcast_process_state(self, process):
> state = 'stopped'
> if process.state == eStateStepping or process.state ==
> eStateRunning:
> state = 'running'
> elif process.state == eStateExited:
> state = 'exited'
> self.should_quit = True
> thread = process.selected_thread
> print 'Process event: %s, reason: %d' % (state,
> thread.GetStopReason())
>
> def _breakpoint_event(self, event):
> breakpoint = SBBreakpoint.GetBreakpointFromEvent(event)
> print 'Breakpoint event: %s' % str(breakpoint)
>
> def run(self):
> while not self.should_quit:
> event = SBEvent()
> if self.listener.WaitForEvent(1, event):
> if event.GetType() == SBTarget.eBroadcastBitModulesLoaded:
> print 'Module load: %s' % str(event)
> elif SBProcess.EventIsProcessEvent(event):
>
> self._broadcast_process_state(SBProcess.GetProcessFromEvent(event))
> elif SBBreakpoint.EventIsBreakpointEvent(event):
> self._breakpoint_event(event)
>
> def _interctive_loop(debugger):
> process = debugger.GetSelectedTarget().process
> event_thread = LLDBListenerThread(process)
> event_thread.start()
>
> while (True):
> stdout.write('dbg> ')
> command = stdin.readline().rstrip()
> if len(command) == 0:
> continue
> debugger.HandleCommand(command)
>
>
> def main():
> debugger = lldb.SBDebugger.Create()
>
> print('Wor

Re: [lldb-dev] Understanding debugger launch events sequence

[Pavel Labath via lldb-dev]

On 29 January 2016 at 18:43, Jeffrey Tan  wrote:
> Thanks Jim. Is this true for other platforms? Our IDE is going to support
> Mac and Linux and may extend to Windows some time later.

AFAIK, windows spawns a separate thread to do the actual debugging,
but this is hidden from you, and you can carry on debugging normally.
On Linux/OSX we even spawn a separate process.

In short, there should be no noticeable user-facing differences
between the platforms. If you find any, then we'd like to know about
them.

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

Re: [lldb-dev] Patch to fix REPL for ARMv7 & ARMv6 on linux

[Pavel Labath via lldb-dev]

On 30 January 2016 at 00:13, William Dillon  wrote:
> In a very real sense, no information is lost here.
That is exactly the reason why it looks very hackish. :)

It looks to me like you are trying to work around some other bug,
probably in the code that consumes the triple.

Could you point me to the code that consumes that triple? Couldn't
that be fixed to look at triple.getSubArch() instead of it's string
representation?


> Would it make you more comfortable is this patch was rewritten within 
> HostInfoLinux::ComputeHostArchitectureSupport alongside the massaging of the 
> vendor name for linux?

If this is Linux-specific, then HostInfoLinux is definitely a better
place for it. However, I would like to understand this a bit deeper
first...

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

Re: [lldb-dev] How to get SBTarget before AttachToProcessWithID?

[Pavel Labath via lldb-dev]

Hi,

it's a bit un-intuitive, but you should be able to create a target
with a null pointer for the executable, and use that to attach (see
CommandObjectProcessAttach::DoExecute).

BTW, if you find the existing API documentation too vague, we'd be
happy to accept any improvements.

cheers,
pl


On 30 January 2016 at 05:42, Jeffrey Tan via lldb-dev
 wrote:
> Hi,
>
> Normally if you want to attach to a process you only have the pid/name of
> the process. How do you get SBTarget? Am I supposed to call
> SBDebugger.CreateTargetWithFileAndArch() against a dummy executable? Why do
> we require a dummy SBTarget before attaching? This seems to be a wrong
> design to me... Thanks.
>
>
>
> ___
> 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] Inquiry for performance monitors

[Pavel Labath via lldb-dev]

_event_open system call, plus I think the
>> > perf_wrapper could be reused to
>> > get CoreSight information as well (see https://lwn.net/Articles/664236/
>> > )
>> >
>> >
>> > On Wed, Oct 21, 2015 at 8:57 PM, Greg Clayton 
>> > wrote:
>> > one main benefit to doing this externally is allow this to be done
>> > remotely over any debugger connection. If you can run expressions to
>> > enable/disable/setup the memory buffer/access the buffer contents, then you
>> > don't need to add code into the debugger to actually do this.
>> >
>> > Greg
>> >
>> > > On Oct 21, 2015, at 11:54 AM, Greg Clayton  wrote:
>> > >
>> > > IMHO the best way to provide this information is to implement reverse
>> > > debugging packets in a GDB server (lldb-server). If you enable this 
>> > > feature
>> > > via some packet to lldb-server, and that enables the gathering of data 
>> > > that
>> > > keeps the last N instructions run by all threads in some buffer that gets
>> > > overwritten. The lldb-server enables it and gives a buffer to the
>> > > perf_event_interface(). Then clients can ask the lldb-server to step 
>> > > back in
>> > > any thread. Only when the data is requested do we actually use the data 
>> > > to
>> > > implement the reverse stepping.
>> > >
>> > > Another way to do this would be to use a python based command that can
>> > > be added to any target that supports this. The plug-in could install a 
>> > > set
>> > > of LLDB commands. To see how to create new lldb command line commands in
>> > > python, see the section named "CREATE A NEW LLDB COMMAND USING A PYTHON
>> > > FUNCTION" on the http://lldb.llvm.org/python-reference.html web page.
>> > >
>> > > Then you can have some commands like:
>> > >
>> > > intel-pt-start
>> > > intel-pt-dump
>> > > intel-pt-stop
>> > >
>> > > Each command could have options and arguments as desired. The
>> > > "intel-pt-start" command could make an expression call to enable the 
>> > > feature
>> > > in the target by running and expression that runs the some
>> > > perf_event_interface calls that would allocate some memory and hand it to
>> > > the Intel PT stuff. The "intel-pt-dump" could just give a raw dump all of
>> > > history for one or more threads (again, add options and arguments as 
>> > > needed
>> > > to this command). The python code could bridge to C and use the intel
>> > > libraries that know how to process the data.
>> > >
>> > > If this all goes well we can think about building it into LLDB as a
>> > > built in command.
>> > >
>> > >
>> > >> On Oct 21, 2015, at 9:50 AM, Zachary Turner via lldb-dev
>> > >>  wrote:
>> > >>
>> > >> There are two different kinds of performance counters: OS performance
>> > >> counters and CPU performance counters.  It sounds like you're talking 
>> > >> about
>> > >> the latter, but it's worth considering whether this could be designed 
>> > >> in a
>> > >> way to support both (i.e. even if you don't do both yourself, at least 
>> > >> make
>> > >> the machinery reusable and apply to both for when someone else wanted to
>> > >> come through and add OS perf counters).
>> > >>
>> > >> There is also the question of this third party library.  Do we take a
>> > >> hard dependency on libipt (probably a non-starter), or only use it if 
>> > >> it's
>> > >> available (much better)?
>> > >>
>> > >> As Pavel said, how are you planning to present the information to the
>> > >> user?  Through some sort of top level command like "perfcount
>> > >> instructions_retired"?
>> > >>
>> > >> On Wed, Oct 21, 2015 at 8:16 AM Pavel Labath via lldb-dev
>> > >>  wrote:
>> > >> [ Moving this discussion back to the list. I pressed the wrong button
>> > >> when replying.]
>> > >>
>> > >> Thanks for the explanation Ravi. It sounds like a very useful feature
>> > >> indeed. I've found a reference to the debugserver profile data in
>&g

Re: [lldb-dev] Inquiry for performance monitors

[Pavel Labath via lldb-dev]

vel, the already present infrastructure
>> >> > is
>> >> > a little bit lacking in terms of the needs of the
>> >> > project, but I plan to follow a similar approach, i.e to extract the
>> >> > raw
>> >> > trace data by querying the server (which can use the
>> >> > perf_event_open to get the raw trace data from the kernel) and
>> >> > transport
>> >> > it through gdb packets ( qXfer packets
>> >> >
>> >> >
>> >> > https://sourceware.org/gdb/onlinedocs/gdb/Branch-Trace-Format.html#Branch-Trace-Format).
>> >> > At the client side the raw trace data
>> >> > could be passed on to python based command that could decode the
>> >> > data.
>> >> > This also eliminates the dependency of libipt since LLDB
>> >> > would not decode the data itself.
>> >> >
>> >> > There is also the question of this third party library.  Do we take a
>> >> > hard dependency on libipt (probably a non-starter), or only use it if
>> >> > it's
>> >> > available (much better)?
>> >> >
>> >> > With the above mentioned way LLDB would not need the library, who
>> >> > ever
>> >> > wants to use the python command would have to install it separately
>> >> > but LLDB
>> >> > wont need it
>> >> >
>> >> > With the performance counters, the interface would still be
>> >> > perf_event_open, so if there was a perf_wrapper in LLDB server then
>> >> > it could
>> >> > be reused to configure and use the
>> >> > software performance counters as well, you would just need to pass
>> >> > different attributes in the perf_event_open system call, plus I think
>> >> > the
>> >> > perf_wrapper could be reused to
>> >> > get CoreSight information as well (see
>> >> > https://lwn.net/Articles/664236/
>> >> > )
>> >> >
>> >> >
>> >> > On Wed, Oct 21, 2015 at 8:57 PM, Greg Clayton 
>> >> > wrote:
>> >> > one main benefit to doing this externally is allow this to be done
>> >> > remotely over any debugger connection. If you can run expressions to
>> >> > enable/disable/setup the memory buffer/access the buffer contents,
>> >> > then you
>> >> > don't need to add code into the debugger to actually do this.
>> >> >
>> >> > Greg
>> >> >
>> >> > > On Oct 21, 2015, at 11:54 AM, Greg Clayton 
>> >> > > wrote:
>> >> > >
>> >> > > IMHO the best way to provide this information is to implement
>> >> > > reverse
>> >> > > debugging packets in a GDB server (lldb-server). If you enable this
>> >> > > feature
>> >> > > via some packet to lldb-server, and that enables the gathering of
>> >> > > data that
>> >> > > keeps the last N instructions run by all threads in some buffer
>> >> > > that gets
>> >> > > overwritten. The lldb-server enables it and gives a buffer to the
>> >> > > perf_event_interface(). Then clients can ask the lldb-server to
>> >> > > step back in
>> >> > > any thread. Only when the data is requested do we actually use the
>> >> > > data to
>> >> > > implement the reverse stepping.
>> >> > >
>> >> > > Another way to do this would be to use a python based command that
>> >> > > can
>> >> > > be added to any target that supports this. The plug-in could
>> >> > > install a set
>> >> > > of LLDB commands. To see how to create new lldb command line
>> >> > > commands in
>> >> > > python, see the section named "CREATE A NEW LLDB COMMAND USING A
>> >> > > PYTHON
>> >> > > FUNCTION" on the http://lldb.llvm.org/python-reference.html web
>> >> > > page.
>> >> > >
>> >> > > Then you can have some commands like:
>> >> > >
>> >> > > intel-pt-start
>> >> > > intel-pt-dump
>> >> > > intel-pt-stop
>> >> > >
>> >> > > Each command could have options and argumen

Re: [lldb-dev] Sending input to the process being debugged

[Pavel Labath via lldb-dev]

Hi,

I think you will have to provide a bit more context to get help. I.e.,
what is the full sequence of debugger commands you are issuing, and
what is the inferior process doing?

cheers,
pl

On 3 February 2016 at 22:03, John Lindal via lldb-dev
 wrote:
> When I use SBDebugger::SetAsync(true), the process is not stopped at scanf,
> so it does not wait for input.  The process does stop and wait for input
> when SetAsync(false).  Unfortunately, when building a GUI on top of the C++
> API, I have to SetAsync(true).
>
> Is there some way to resolve this?
>
> Thanks,
> John
>
>
> ___
> 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] Debug events in synchronous mode?

[Pavel Labath via lldb-dev]

Hi,

I am not sure what are the "official" rules, but the general idea is
that you need not concern yourself too much with events when you are
in synchronous mode. In synchronous mode, you can be sure that by the
time target.Launch() returns, the process will be stopped (or dead, or
something else, you can check process.GetState() to find that out). No
need to play around with listeners...

cheers,
pl

On 4 February 2016 at 06:41, Jeffrey Tan via lldb-dev
 wrote:
> Hi,
>
> I found that if I am using synchronous mode, some times there are no debug
> events generated during launch. For example, for the code below,
> LLDBListenerThread will receive no debug events.
>
> Is this expected? What is the rule of debug events in synchronous mode?
>
> def main():
> debugger = lldb.SBDebugger.Create()
> debugger.SetAsync(False)
> target = debugger.CreateTargetWithFileAndArch(executable_path,
> lldb.LLDB_ARCH_DEFAULT)
> target.BreakpointCreateByName('main')
>
> listener = lldb.SBListener('Event Listener')
> error = lldb.SBError()
> process = target.Launch (listener,
>  None,  # argv
>  None,  # envp
>  None,  # stdin_path
>  None,  # stdout_path
>  None,  # stderr_path
>  None,  # working directory
>  0, # launch flags
>  False, # Stop at entry
>  error) # error
> print 'Launch result: %s' % str(error)
> event_thread = LLDBListenerThread(debugger)
> event_thread.start()
>
> ___
> 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] Inquiry for performance monitors

[Pavel Labath via lldb-dev]

On 4 February 2016 at 10:04, Ravitheja Addepally
 wrote:
> Hello Pavel,
> In the case of expression evaluation approach you mentioned
> that:
> 1. The data could be accessible only when the target is stopped. why is that
> ?
If I understand the approach correctly, the idea is the run all perf
calls as expressions in the debugger. Something like
lldb> expr perf_event_open(...)
We need to stop the target to be able to do something like that, as we
need to fiddle with its registers. I don't see any way around that...

> 2. What sort of noise were you referring to ?
Since now all the perf calls will be expressions executed within the
context of the process being traced, they themselves will show up in
the trace. I am sure we could filter that out somehow, but it feels
like an added complication..

Does that make it any clearer?

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

Re: [lldb-dev] Problem running the test suite on Linux.

[Pavel Labath via lldb-dev]

In addition to flaky tests, I think some of these are just decorated
too broadly (e.g. it's marked expectedFailureLinux, but fails only on
i386 with gcc). I occasionally enable tests that I see are passing
consistently, but I am currently more worried about tests failing
unexpectedly than succeeding.

The 30 minutes for running the test seems very long, something must
have gone wrong there. If you do a "ps" after 5 minutes, which
processes do you still see running? What about after 15? What are the
specs of the machine you are running this on? What is the exact
command line you launching the tests with?

I wouldn't be too worried about the timeouts, these are the two of our
longest-running tests, so I think they are just getting killed for
running too slow. We need to figure out what is causing the whole
suite to run so slowly. (Unless you see them constantly timing out at
the exact same test, in which case it could be interesting.)

cheers,
pl


On 4 February 2016 at 04:11, Todd Fiala via lldb-dev
 wrote:
>>  I don't recall exactly what it was off the top of my head, but I wonder
>> if Zachary needs that?
>
> That is the lldb_enable_attach() call that I make in the beginning of the
> inferior test driver, defined in
> packages/Python/lldbsuite/test/make/test_common.h.  This is already called,
> so shouldn't be the issue.
>
> On Wed, Feb 3, 2016 at 8:07 PM, Todd Fiala  wrote:
>>
>> You also need to pass "hello, world" as a launch arg (in quotes).  That is
>> what will make it get echoed back.
>>
>> On Wed, Feb 3, 2016 at 8:05 PM, Todd Fiala  wrote:
>>>
>>> Hey Zachary,
>>>
>>> For the test listed above, it is failing trying to match output from the
>>> inferior process being debugged by lldb-server.  First, it is trying to get
>>> a hello, world string to be printed.  Then, it is expecting the process to
>>> exit without failure.
>>>
>>> If you go in that directory and make/run the a.out program, it should
>>> print hello world and exit with an exit value of 0.  You may find that it
>>> doesn't print, perhaps?  Or maybe your terminal is set differently, so that
>>> the text isn't matching as expected?  (I would expect to have heard others
>>> with this issue).
>>>
>>> Pavel just added some gdb remote logging that is easier to access than
>>> the way I had it rigged up before.  If you end up getting stuck, if you get
>>> the output log from either the lldb-server side, that would probably help
>>> figure out what's getting stuck.  But I wouldn't bother with that if you can
>>> rule out that something with the a.out is going wrong first.
>>>
>>> -Todd
>>>
>>> On Wed, Feb 3, 2016 at 3:16 PM, Siva Chandra 
>>> wrote:

 Yes, there is something like that but I am unable to recollect.
 However, I do not think Zach's problem is that. He is able to get all
 but 2 of the tests passing.

 Zach, is it possible for you to run with clang-3.5?

 On Wed, Feb 3, 2016 at 3:05 PM, Todd Fiala  wrote:
 > (Security around ptrace).
 >
 > On Wed, Feb 3, 2016 at 3:04 PM, Todd Fiala 
 > wrote:
 >>
 >> Hmm I wonder if your lldb-server is able to attach to processes?
 >> Siva, we
 >> used to have some kind of kernel flag or something that would allow
 >> attaching to a process that was launched by something else.  I don't
 >> recall
 >> exactly what it was off the top of my head, but I wonder if Zachary
 >> needs
 >> that?
 >>
 >> -Todd
 >>
 >> On Wed, Feb 3, 2016 at 3:02 PM, Zachary Turner via lldb-dev
 >>  wrote:
 >>>
 >>> In my logs I'm seeing this:
 >>>
 >>> UNSUPPORTED: LLDB
 >>>
 >>> (/usr/local/google_ssd/src/llvm/build/ninja_release/bin/clang-3.9-x86_64)
 >>>  ::
 >>> test_inferior_print_exit_debugserver_dwo
 >>> (TestLldbGdbServer.LldbGdbServerTestCase) (debugserver tests)
 >>>   File
 >>>
 >>> "/usr/local/google/home/zturner/ssd/src/llvm/tools/lldb/test/dotest.py",
 >>> line 7, in 
 >>> lldbsuite.test.run_suite()
 >>>   File
 >>>
 >>> "/usr/local/google_ssd/src/llvm/tools/lldb/packages/Python/lldbsuite/test/dotest.py",
 >>> line 1089, in run_suite
 >>> resultclass=test_result.LLDBTestResult).run(configuration.suite)
 >>>   File
 >>>
 >>> "/usr/local/google_ssd/src/llvm/tools/lldb/third_party/Python/module/unittest2/unittest2/runner.py",
 >>> line 162, in run
 >>> test(result)
 >>>   File
 >>>
 >>> "/usr/local/google_ssd/src/llvm/tools/lldb/third_party/Python/module/unittest2/unittest2/suite.py",
 >>> line 65, in __call__
 >>> return self.run(*args, **kwds)
 >>>   File
 >>>
 >>> "/usr/local/google_ssd/src/llvm/tools/lldb/third_party/Python/module/unittest2/unittest2/suite.py",
 >>> line 85, in run
 >>> self._wrapped_run(result)
 >>>   File
 >>>
 >>> "/usr/local/google_ssd/src/llvm/tools/lldb/third_party/Python/module/unittest2/unittest2/suite.py",
 >>> l

Re: [lldb-dev] Inquiry for performance monitors

[Pavel Labath via lldb-dev]

On 4 February 2016 at 12:49, Abhishek Aggarwal  wrote:
> Hello Pavel
>
> As per my understanding, instead of doing it by expression evaluation
> if the code (to enable pt and gathering the raw traces) is written on
> lldb-server side, then also lldb-server will have to wait for the
> inferior to stop in order to encapsulate all the traces in packets and
> send them to client for analysis.
>
> Is it possible that client can request the lldb-server to send it a
> part of the raw traces while the inferior is still running?
>

Hi,

This is certainly possible. The server already sends us the stdout
from the inferior this way. There is even some support for gathering
"profile data" in the client (see
GDBRemoteCommunicationClient.cpp:1286), presumably gathering data from
debugserver, as lldb-server does not send such packets. If needed, we
can send the same packets from lldb-server. Or, if these are not
suitable, we can add another kind of packets -- the protocol through
which they communicate is fully under our control.

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

Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported toolchain

[Pavel Labath via lldb-dev]

Hi all.

we (android lldb team) are starting to transition to VS2015 as well.
For now, the plan is to stick to python 2.7, but if we encounter
problems there, the backup plan is to go to python 3 as well. Until
then (I estimate that will take 1--2 weeks) our buildbot
 will
continue building 2.7+2013 and we will be making sure it works, so
please don't check in any VS2013 incompatible code (yet).

Ted: If you can't switch to the 3+2015 combination (which I *do*
recommend you try), maybe you can go half-way and switch to 2.7+2015
(I can show you how to build python 2.7 with VS2015). If you stick
with 2.7+2013 combo, it will soon be up to you to chase anyone who
adds 2013-breaking changes...

pl


On 2 February 2016 at 23:42, Ted Woodward via lldb-dev
 wrote:
> No, it turned red Friday night/Saturday morning.
>
>
>
> Last good build:
>
> http://lab.llvm.org:8011/builders/lldb-x86-win7-msvc/builds/15167
>
>
>
> First bad build:
>
> http://lab.llvm.org:8011/builders/lldb-x86-win7-msvc/builds/15168
>
>
>
> It went red because of the change to VS2015/Python 3.5.
>
>
>
> --
>
> Qualcomm Innovation Center, Inc.
>
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>
>
> From: Zachary Turner [mailto:ztur...@google.com]
> Sent: Tuesday, February 02, 2016 5:28 PM
>
>
> To: Ted Woodward; LLDB
> Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported
> toolchain
>
>
>
> BTW, I expect that your buildbot has been experiencing the problems with the
> x86 / x64 toolchain for quite some time, because it's not really relevant to
> how much memory your machine has, but just that it was using an x86
> toolchain at all.  Has it been red for a long time?
>
>
>
> On Tue, Feb 2, 2016 at 1:48 PM Zachary Turner  wrote:
>
> You may have to make some changes to the zorg scripts to keep that working.
> I didn't realize there were any other bots building LLDB, so I made some
> changes that will default everything to VS2015 and Py3.
>
>
>
> BTW, is your builder doing a debug build or a release build?  When doing a
> debug build clang now requires more memory than can fit in a 4GB address
> space to link, so using an x86 toolchain won't work anymore.  I forced a
> change to use the amd64_x86 toolchain, but this won't work unless the
> version of python used by buildbot is a 64-bit Python distro (because
> Python.exe is what ultimately calls vcvarsall and cmake and it inherits the
> environment of the parent).
>
>
>
> So I think you will need to do all this as well.
>
>
>
> On Tue, Feb 2, 2016 at 1:44 PM Ted Woodward 
> wrote:
>
> Then maybe we should keep it 2013/py2.7, until llvm requires 2015.
>
>
>
> --
>
> Qualcomm Innovation Center, Inc.
>
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>
>
> From: Zachary Turner [mailto:ztur...@google.com]
> Sent: Tuesday, February 02, 2016 3:43 PM
>
>
> To: Ted Woodward; LLDB
> Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported
> toolchain
>
>
>
> It's Server 2008 R2 technically, which is the server version of Win 7 (same
> API set, same OS features, etc).  So yea, I'm pretty confident that test
> coverage is going to be 100% the same across both.  It's just a matter of if
> you want to have something that you maintain / have control over, or if you
> want to test something in a different way than what we're testing.
>
>
>
> On Tue, Feb 2, 2016 at 1:29 PM Ted Woodward 
> wrote:
>
> Yours is Win Server 2008; ours is Win 7. I don’t know if that matters.
>
>
>
> --
>
> Qualcomm Innovation Center, Inc.
>
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>
>
> From: Zachary Turner [mailto:ztur...@google.com]
> Sent: Tuesday, February 02, 2016 2:48 PM
> To: Ted Woodward; LLDB
>
>
> Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported
> toolchain
>
>
>
> If I remember correctly your bot isn't actually doing anything differently
> than my bot [http://lab.llvm.org:8011/builders/lldb-x86-windows-msvc2015].
> If you want you could just remove your bot.  If you want to keep it, then
> yea getting it on VS2015 and Python 3 would be the best idea.
>
>
>
> On Tue, Feb 2, 2016 at 12:20 PM Ted Woodward via lldb-dev
>  wrote:
>
> It looks like our bot, http://lab.llvm.org:8011/builders/lldb-x86-win7-msvc
> , has tried to update to Python 3.5 and MSVC 2015, but it can’t find python
> or VC. I’ll talk to our buildmiester about it.
>
>
>
> Should we run this guy with 2013/py2.7 or 2015/py3.5?
>
>
>
> --
>
> Qualcomm Innovation Center, Inc.
>
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>
>
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Zachary
> Turner via lldb-dev
> Sent: Tuesday, February 02, 2016 1:

Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported toolchain

[Pavel Labath via lldb-dev]

The patch is in the attachment.

The timezone part seems pretty non-controversial. The _PyVerify_fd
thing seems more scary, but I basically copied that part out of
python3, so I assume they know what they are doing. With this I can
compile and run the python and it appears to be working. The real test
will be when I try to run the lldb test suite with it, but I didn't
set that up yet.

pl

On 4 February 2016 at 16:06, Zachary Turner  wrote:
> Out of curiosity, did you guys get Python 2.7 building with VS2015?  How did
> you solve the compiler error?  (I had a few ideas myself for how to fix it,
> but I wasn't sure of the implications)
>
> On Thu, Feb 4, 2016 at 8:01 AM Pavel Labath  wrote:
>>
>> Hi all.
>>
>> we (android lldb team) are starting to transition to VS2015 as well.
>> For now, the plan is to stick to python 2.7, but if we encounter
>> problems there, the backup plan is to go to python 3 as well. Until
>> then (I estimate that will take 1--2 weeks) our buildbot
>>  will
>> continue building 2.7+2013 and we will be making sure it works, so
>> please don't check in any VS2013 incompatible code (yet).
>>
>> Ted: If you can't switch to the 3+2015 combination (which I *do*
>> recommend you try), maybe you can go half-way and switch to 2.7+2015
>> (I can show you how to build python 2.7 with VS2015). If you stick
>> with 2.7+2013 combo, it will soon be up to you to chase anyone who
>> adds 2013-breaking changes...
>>
>> pl
>>
>>
>> On 2 February 2016 at 23:42, Ted Woodward via lldb-dev
>>  wrote:
>> > No, it turned red Friday night/Saturday morning.
>> >
>> >
>> >
>> > Last good build:
>> >
>> > http://lab.llvm.org:8011/builders/lldb-x86-win7-msvc/builds/15167
>> >
>> >
>> >
>> > First bad build:
>> >
>> > http://lab.llvm.org:8011/builders/lldb-x86-win7-msvc/builds/15168
>> >
>> >
>> >
>> > It went red because of the change to VS2015/Python 3.5.
>> >
>> >
>> >
>> > --
>> >
>> > Qualcomm Innovation Center, Inc.
>> >
>> > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
>> > Linux Foundation Collaborative Project
>> >
>> >
>> >
>> > From: Zachary Turner [mailto:ztur...@google.com]
>> > Sent: Tuesday, February 02, 2016 5:28 PM
>> >
>> >
>> > To: Ted Woodward; LLDB
>> > Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an
>> > unsupported
>> > toolchain
>> >
>> >
>> >
>> > BTW, I expect that your buildbot has been experiencing the problems with
>> > the
>> > x86 / x64 toolchain for quite some time, because it's not really
>> > relevant to
>> > how much memory your machine has, but just that it was using an x86
>> > toolchain at all.  Has it been red for a long time?
>> >
>> >
>> >
>> > On Tue, Feb 2, 2016 at 1:48 PM Zachary Turner 
>> > wrote:
>> >
>> > You may have to make some changes to the zorg scripts to keep that
>> > working.
>> > I didn't realize there were any other bots building LLDB, so I made some
>> > changes that will default everything to VS2015 and Py3.
>> >
>> >
>> >
>> > BTW, is your builder doing a debug build or a release build?  When doing
>> > a
>> > debug build clang now requires more memory than can fit in a 4GB address
>> > space to link, so using an x86 toolchain won't work anymore.  I forced a
>> > change to use the amd64_x86 toolchain, but this won't work unless the
>> > version of python used by buildbot is a 64-bit Python distro (because
>> > Python.exe is what ultimately calls vcvarsall and cmake and it inherits
>> > the
>> > environment of the parent).
>> >
>> >
>> >
>> > So I think you will need to do all this as well.
>> >
>> >
>> >
>> > On Tue, Feb 2, 2016 at 1:44 PM Ted Woodward
>> > 
>> > wrote:
>> >
>> > Then maybe we should keep it 2013/py2.7, until llvm requires 2015.
>> >
>> >
>> >
>> > --
>> >
>> > Qualcomm Innovation Center, Inc.
>> >
>> > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
>> > Linux Foundation Collaborative Project
>> >
>> >
>> >
>> > From: Zachary Turner [mailto:ztur...@google.com]
>> > Sent: Tuesday, February 02, 2016 3:43 PM
>> >
>> >
>> > To: Ted Woodward; LLDB
>> > Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an
>> > unsupported
>> > toolchain
>> >
>> >
>> >
>> > It's Server 2008 R2 technically, which is the server version of Win 7
>> > (same
>> > API set, same OS features, etc).  So yea, I'm pretty confident that test
>> > coverage is going to be 100% the same across both.  It's just a matter
>> > of if
>> > you want to have something that you maintain / have control over, or if
>> > you
>> > want to test something in a different way than what we're testing.
>> >
>> >
>> >
>> > On Tue, Feb 2, 2016 at 1:29 PM Ted Woodward
>> > 
>> > wrote:
>> >
>> > Yours is Win Server 2008; ours is Win 7. I don’t know if that matters.
>> >
>> >
>> >
>> > --
>> >
>> > Qualcomm Innovation Center, Inc.
>> >
>> > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
>> > Linux Foundation Collaborative Project
>> >

Re: [lldb-dev] Race condition crashes during launching LLDB

[Pavel Labath via lldb-dev]

On 5 February 2016 at 05:09, Jeffrey Tan via lldb-dev
 wrote:
> After adding some logging I figured out that the race condition is caused by
> process.Continue() did not guarantee process has been really resumed yet in
> async mode, so the second wait_for_process_stop() is skipped immediately to
> kill listener thread and destroying debugger. I know I have a race condition
> bug here because of polling for process state, but why is lldb crashing when
> listener thread has exited and SBDebugger.Destroy() is called? What is the
> situation that SBDebugger.Destroy() can be called safely?

My guess on the sequence of events here is this:
- call process.Continue(), which returns immediately
- you check process.is_stopped, which is still true
- set self.should_quit = true
- listener thread exits and you join in
- you call SBDebugger.Destroy()

all of this happens _before_ the process has had a chance to really
start. So now Destroy starts destroying the process while it is just
being started up and things go south. It could be argued that this is
a bug in LLDB (this is the reason our TestEvents is disabled). I've
been investigating this a bit, but it did not look easy.

In any case, what you can do now is to make sure you wait for the
eStateRunning event before you try to do anything to the process
(including killing it). These paths are more tested and they I believe
they should be stable.

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

Re: [lldb-dev] Details on rdar://18684408?

[Pavel Labath via lldb-dev]

Linux is ok as well. I've enabled the tests everywhere except windows.
Please add your arch back if you notice problems.

pl

On 18 February 2016 at 19:37, Zachary Turner via lldb-dev
 wrote:
> Does not work on Windows yet, so please leave it xfail'ed on windows for now
>
> On Thu, Feb 18, 2016 at 11:30 AM Sean Callanan via lldb-dev
>  wrote:
>>
>> I apologize for this confusion.  I recently fixed these as a side effect
>> of some major changes in IRForTarget.cpp.
>> These should be fixed on pretty much all platforms, and the
>> expectedFailure can be removed.
>> If they’re passing on Linux too, let’s remove the expectedFailure.
>>
>> Sean
>>
>> > On Feb 18, 2016, at 11:22 AM, Ed Maste via lldb-dev
>> >  wrote:
>> >
>> > The tests in lang/cpp/unicode-literals/TestUnicodeLiterals.py are
>> > marked with @unittest2.expectedFailure("rdar://18684408").
>> >
>> > These tests are passing on FreeBSD:
>> > UNEXPECTED SUCCESS: test_and_run_command_dwarf
>> > (lang/c/const_variables/TestConstVariables.py)
>> > UNEXPECTED SUCCESS: test_expr1_dwarf
>> > (lang/cpp/unicode-literals/TestUnicodeLiterals.py)
>> > UNEXPECTED SUCCESS: test_expr2_dwarf
>> > (lang/cpp/unicode-literals/TestUnicodeLiterals.py)
>> > UNEXPECTED SUCCESS: test_expr3_dwarf
>> > (lang/cpp/unicode-literals/TestUnicodeLiterals.py)
>> >
>> > The example in the test case works as expected:
>> >
>> > (lldb) expr L"Hello"
>> > (const wchar_t [6]) $0 = L"Hello"
>> >
>> > Are these passing on Linux as well?
>> > ___
>> > 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 mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] problem with quoted strings in setting target.run-args

[Pavel Labath via lldb-dev]

Hi Ted,

I did some improvements in this area a year ago, which (I hope) made
things better, but they are still not perfect (hint: try running:
settings set target.run-args '"') [that's
]. I tried to finish the
job, but it ended up being too complicated, for the reasons you
mention above...

I think the current method of "quoting" in
OptionValueString::SetValueFromString is wrong and I would welcome
anything that changes that. Also, if you can decrease the number of
times we need to quote and unquote stuff while passing the arguments
internally around, I would be super happy. :)

(I'm not sure if this helps you. I don't really have a good suggestion
on how to do what you want, but I wanted to encourage the idea.)

pl

On 19 February 2016 at 00:16, Ted Woodward via lldb-dev
 wrote:
> Quoted strings in target.run-args aren’t handled correctly.
>
>
>
> (lldb) settings set target.run-args "foo bar"
>
> (lldb) settings show target.run-args
>
> target.run-args (array of strings) =
>
>   [0]: "foo bar"
>
>
>
> This looks correct, but the Args in the ProcessLaunchInfo passed to the
> Platform doesn’t have m_args_quote_char set, so if the Args is later pulled
> out with GetQuotedCommandString() it won’t get “foo bar”, but will instead
> get foo and bar unquoted. This is masked when talking to debugserver or
> lldb_server because run-args are sent to the server using an RSP packet, but
> on systems like Windows or the Hexagon Simulator, where run-args are on the
> command line, you get 2 args, foo and bar, instead of 1 arg “foo bar”.
>
>
>
> The first problem is in OptionValueArray::SetArgs(), in the
> eVarSetOperationAppend case. It calls Args::GetArgumentAtIndex(), which
> doesn’t return a quoted argument. I added a function
> GetQuotedArgumentAtIndex() and called that, which revealed the second
> problem. The string is passed into
> OptionValue::CreateValueFromCStringForTypeMask(), which calls
> OptionValueString::SetValueFromString(). In that function it explicitly
> strips quotes. Changing it to not strip quotes leads to the third problem –
> when TargetProperties::RunArgsValueChangedCallback() pulls the data from the
> OptionValueArray to make a new Args, it calls OptionValueArray::GetArgs(),
> which doesn’t handle quoting like the Args ctor does.
>
>
>
> I think changing the OptionValue classes to handle quoting could lead to
> problems with other use cases. So that leaves me with the option of going
> through the Args before launch and adding quotes around anything with
> spaces, which seems hackish. Any thoughts on how to solve this issue?
>
>
>
> --
>
> Qualcomm Innovation Center, Inc.
>
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>
>
>
> ___
> 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] No stopping event during launch(stop_at_entry=True) on Linux?

[Pavel Labath via lldb-dev]

This is a known bug (bugzilla is slugish right now, so I can't look up
the number). The stopped event does not seem to get through most of
the times, although the stop is actually performed. I am afraid I
can't offer any workaround for the time being...

On 24 February 2016 at 07:36, Jeffrey.fudan via lldb-dev
 wrote:
> Makes sense, will file a bug for it.
>
> Sent from my iPad
>
>> On Feb 23, 2016, at 5:10 PM, Jim Ingham  wrote:
>>
>> That also is a bug.  If it is going to do a public stop, it has to send a 
>> stop event.
>>
>> Jim
>>
>>> On Feb 23, 2016, at 2:52 PM, Jeffrey Tan  wrote:
>>>
>>> I am not sure. From the output, it seems lldb does stop at the entry 
>>> point(because you can issue "bt" command to dump the stack) in both 
>>> platforms; the problem seems to be that it did not emit the stopped event 
>>> for its stop on linux.
>>>
>>> On Tue, Feb 23, 2016 at 2:03 PM, Jim Ingham  wrote:
>>> If the linux side is not obeying "stop_at_entry" then that is a bug.
>>>
>>> Jim
>>>
>>>
 On Feb 23, 2016, at 1:49 PM, Jeffrey Tan via lldb-dev 
  wrote:

 Hi,

 I have got lldb launch working fine on my macbook for sometime. But when I 
 try the same code on Linux, it failed to emit any stopping events during 
 initial launch.

 When I run the reproduce code(listed at the end), I got the following 
 different results:

 The key difference is that Macbook will emit a stopped event which caused 
 our IDE UI to enter break mode, while Linux violates this assumption. Is 
 this a bug?

 ==Mac==
 lldb_pythonpath: 
 /Applications/Xcode.app/Contents/Developer/../SharedFrameworks/LLDB.framework/Resources/Python
 Launch result: success
  Listening Thread ID: 4610625536
 dbg> Target event: ModulesLoaded
 Process event: StateChanged, Stopped
 Stop reason: 5
 dbg> bt
 * thread #1: tid = 0x101f01d, 0x7fff6401a000 dyld`_dyld_start, stop 
 reason = signal SIGSTOP
  * frame #0: 0x7fff6401a000 dyld`_dyld_start
 ==Mac==

 ==Linux==
 python linux_launch.py
 find_lldb: >>> '/home/jeffreytan/project/llvm-bin/Debug+Asserts/lib/python2.7/site-packages/lldb/__init__.pyc'>
 Launch result: success
  Listening Thread ID: 140316621375232
 dbg> bt
 * thread #1: tid = 2794520, 0x7f6165b7bb00, name = 'foo', stop reason 
 = signal SIGSTOP
  * frame #0: 0x7f6165b7bb00
 ==Linux==

 Repro main.py
 # Should be first for LLDB package to be added to search path.
 from find_lldb import lldb
 import sys
 import os
 import time
 from sys import stdin, stdout
 from event_thread import LLDBListenerThread
 import threading


 def interctive_loop(debugger):
while (True):
stdout.write('dbg> ')
command = stdin.readline().rstrip()
if len(command) == 0:
continue
if command == 'q':
return
debugger.HandleCommand(command)

 def do_test():
debugger = lldb.SBDebugger.Create()
debugger.SetAsync(True)
executable_path = 
 '~/Personal/compiler/CompilerConstruction/code/compiler'
target = debugger.CreateTargetWithFileAndArch(executable_path, 
 lldb.LLDB_ARCH_DEFAULT)

listener = lldb.SBListener('Event Listener')
error = lldb.SBError()
process = target.Launch (listener,
 None,  # argv
 None,  # envp
 None,  # stdin_path
 None,  # stdout_path
 None,  # stderr_path
 None,  # working directory
 0, # launch flags
 True, # Stop at entry
 error) # error
print 'Launch result: %s' % str(error)

running_signal = threading.Event()
stopped_signal = threading.Event()
event_thread = LLDBListenerThread(debugger, running_signal, 
 stopped_signal)
event_thread.start()

interctive_loop(debugger)

event_thread.should_quit = True
event_thread.join()

lldb.SBDebugger.Destroy(debugger)
return debugger

 def main():
debugger = do_test()

 if __name__ == '__main__':
main()

 Event_thread
 class LLDBListenerThread(Thread):
should_quit = False

def __init__(self, debugger, running_signal=None, stopped_sigal=None):
  Thread.__init__(self)

Re: [lldb-dev] Module Cache improvements - RFC

[Pavel Labath via lldb-dev]

Thanks for the feedback, and sorry about the slow response.

After some internal discussions, it looks like we are not going to go
forward with this approach at the moment.

cheers,
pl



On 24 February 2016 at 11:16, Tamas Berghammer via lldb-dev
 wrote:
> I completely agree with you that we shouldn't change LLDB too much just to
> speed up the startup time at the first use.
>
> For android we already have a host side disk cache in place similar to what
> you described for iOS and we already using ADB (an android specific
> interface) to download the files from the device but unfortunately its speed
> is only ~4-5MB/s on most device.
>
> On Tue, Feb 23, 2016 at 9:23 PM Greg Clayton  wrote:
>>
>> > On Feb 23, 2016, at 10:31 AM, Nico Weber  wrote:
>> >
>> > On Tue, Feb 23, 2016 at 1:21 PM, Tamas Berghammer via lldb-dev
>> >  wrote:
>> > Yes we already have a disk cache on the host. I agree with you that
>> > waiting 30s at the first startup shouldn't be an issue in general (Pavel
>> > isn't sharing my opinion). The only catch is that in case of iOS there are
>> > only a few different builds released so if you downloaded the modules once
>> > then I think you won't have to download them the next time when you try to
>> > use a different device. In case of Android we have to download the symbols
>> > from each device you are using and at that point 30s might be an issue (I
>> > still don't think it is).
>> >
>> > With my app developer hat on, if some program makes me wait 30s for
>> > something then I won't like that program.
>>
>> I agree, but if the first time you hook your phone up Android Studio pops
>> up a dialog box saying "This is the first time you have connected this
>> device, hold on while I cache the shared libraries for this device..." then
>> it wouldn't be too bad. It is primarily the fact that the 30 seconds is
>> happening without feedback during first launch or attach. Also, you can
>> probably use something faster than the lldb-platform to download all of the
>> files. In Xcode, we download all symbols into the users home directory in a
>> known location:
>>
>> ~/Library/Developer/Xcode/iOS DeviceSupport
>>
>> This folder contains the exact OS version and a build number:
>>
>> (lldb) platform select remote-ios
>>   Platform: remote-ios
>>  Connected: no
>>  SDK Roots: [ 0] "~/Library/Developer/Xcode/iOS DeviceSupport/9.0 (W)"
>>  SDK Roots: [ 1] "~/Library/Developer/Xcode/iOS DeviceSupport/9.1 (X)"
>>  SDK Roots: [ 2] "~/Library/Developer/Xcode/iOS DeviceSupport/9.2 (Y)"
>>
>> Where W, X, Y are build numbers. We know we can look in these
>> folders for any files that are from the device. They get populated and these
>> SDK directories get searched by LLDB's PlatformRemoteiOS so they get found
>> (we don't use the file cache that the PlatformAndroid currently uses).
>>
>> So with a little work, I would add some functionality to your Android
>> Studio, have something that knows how to copy files from device as quickly
>> as possible (using lldb-platform is slwww and that is the way it is
>> currently done I believe) into some such directory, all while showing a
>> progress dialog to the user on first device connect, and then debugging will
>> always be quick. And you can probably make it quicker than 30 seconds.
>>
>> 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] lldb-server stripped binary size: AArch64 ~16Mb vs ARM ~9 Mb

[Pavel Labath via lldb-dev]

Hi,

so the problem here is that we are currently relying on the linker to
remove code that we don't need, and it can't always do a good job in
figuring out which code is not used due to complex dependencies. So,
innocent-looking changes in the code can pull in lots of transitive
dependencies, even though they are not used. I suspect something like
that is going on here, although we should keep in mind that arm64 code
is less dense naturally. Any help on this front will be welcome,
although it probably won't be trivial, as we have probably picked off
the low-hanging fruit already.

That said, you may want to try adding LLVM_TARGETS_TO_BUILD=Aarch64 to
your cmake line. We use that, although I can't say how much it affects
the size of the resulting binary.

help that helps,
pl

On 29 February 2016 at 20:15, Mikhail Filimonov via lldb-dev
 wrote:
> Hello, fellow developers and congratulations with long awaited 3.8 Release.
>
> I wonder why AArch64 stripped binary of lldb-server built from [3.8 Release] 
> RC3 source is so much bigger than its ARM counterpart.
> See the numbers:
> 16318632 Feb 29 22:41 lldb-server-3.8.0-aarch64
>  9570916 Feb 29 22:23 lldb-server-3.8.0-arm
> lldb-server-3.8.0-aarch64: ELF 64-bit LSB  executable, ARM aarch64, version 1 
> (SYSV), statically linked, stripped
> lldb-server-3.8.0-arm: ELF 32-bit LSB  executable, ARM, EABI5 version 1 
> (SYSV), statically linked, stripped
>
> My build configuration is MinSizeRel in both cases:
> cmake -GNinja
> -DCMAKE_BUILD_TYPE=MinSizeRel $HOME/llvm_git
> -DCMAKE_TOOLCHAIN_FILE=tools/lldb/cmake/platforms/Android.cmake
> -DANDROID_TOOLCHAIN_DIR=$HOME/Toolchains/aarch64-21-android
> -DANDROID_ABI=aarch64
> -DCMAKE_CXX_COMPILER_VERSION=4.9
> -DLLVM_TARGET_ARCH=aarch64
> -DLLVM_HOST_TRIPLE=aarch64-unknown-linux-android
> -DLLVM_TABLEGEN=$HOME/llvm_host/bin/llvm-tblgen
> -DCLANG_TABLEGEN=$HOME/llvm_host/bin/clang-tblgen
>
> cmake -GNinja
> -DCMAKE_BUILD_TYPE=MinSizeRel $HOME/llvm_git
> -DCMAKE_TOOLCHAIN_FILE=tools/lldb/cmake/platforms/Android.cmake
> -DANDROID_TOOLCHAIN_DIR=$HOME/Toolchains/arm-21-android-toolchain
> -DANDROID_ABI=armeabi
> -DCMAKE_CXX_COMPILER_VERSION=4.9
> -DLLVM_TARGET_ARCH=arm
> -DLLVM_HOST_TRIPLE=arm-unknown-linux-android
> -DLLVM_TABLEGEN=$HOME/llvm_host/bin/llvm-tblgen
> -DCLANG_TABLEGEN=$HOME/llvm_host/bin/clang-tblgen
>
> Maybe I need some additional settings to be set for AArch64 case?
>
> Regards,
> Mikhail
>
> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Hans 
> Wennborg via lldb-dev
> Sent: Wednesday, February 24, 2016 12:51 AM
> To: release-test...@lists.llvm.org
> Cc: llvm-dev ; cfe-dev ; 
> openmp-dev (openmp-...@lists.llvm.org) ; LLDB Dev 
> 
> Subject: [lldb-dev] [3.8 Release] RC3 has been tagged
>
> Dear testers,
>
> Release Candidate 3 has just been tagged [1]. Please build, test, and upload 
> to the sftp.
>
> If there are no regressions from previous release candidates, this will be 
> the last release candidate before the final release.
>
> Release notes can still go into the branch.
>
> Thanks again for all your work!
> Hans
>
>  [1] 
> http://lists.llvm.org/pipermail/llvm-branch-commits/2016-February/009866.html
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
> ---
> 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.
> ---
> ___
> 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] Problems with core load on Linux and proposed solution

[Pavel Labath via lldb-dev]

Hi,

Thanks for the report. I've had my eye set on this for a while, but
unfortunately it hasn't gotten to the top of the list yet. The main
reasons i was slow to respond are:
- there is no test included.
- I am not entirely sure about the proposed solution. It looks a bit
hackish (the stop reason part) and I was hoping I could come up with a
cleaner solution...

So, for the thread id part, I'd be happy to commit that as soon as you
create a test (or you can wait until I create one at some point...).

For the stop reason, if you want to speed it up, you can try running
the patch by Jim Ingham, as he's the one who will have to approve that
anyway. (and please also add a test)

cheers,
pl


On 26 February 2016 at 16:58, Zachary Turner  wrote:
> Cced some people who work on Linux.
>
> Not sure how this slipped through the cracks, but sometimes you can have
> better results by just posting a patch to lldb-commits and ccing the right
> person (check owners file to find out who the right person is)
>
> On Thu, Feb 25, 2016 at 5:18 PM Eugene Birukov via lldb-dev
>  wrote:
>>
>> No response. I filed a bug, hopefully somebody will pay attention.
>>
>> https://llvm.org/bugs/show_bug.cgi?id=26322
>>
>>
>> 
>> From: mi...@microsoft.com
>> To: eugen...@hotmail.com; lldb-dev@lists.llvm.org
>> Subject: RE: Problems with core load on Linux and proposed solution
>> Date: Thu, 25 Feb 2016 22:37:45 +
>>
>>
>> Eugene, do you know if they have taken these changes? Have you heard from
>> anybody on lldb-dev?
>>
>>
>>
>> mikem
>>
>>
>>
>> From: Eugene Birukov [mailto:eugen...@hotmail.com]
>> Sent: Thursday, January 21, 2016 10:46 AM
>> To: LLDB 
>> Subject: Problems with core load on Linux and proposed solution
>>
>>
>>
>> Hi,
>>
>>
>>
>> LLDB 3.8 has much better support for core load on Linux than 3.7 - thanks
>> a lot! But there are still two problems.
>>
>>
>>
>> 1. The thread ID are lost and there is FIXME in the code
>>
>> 2. If core dump is obtained from live process (i.e. gdb attach, gcore,
>> detach) then there is no thread that has any reason to stop. LLDB hangs
>> forever on such a core.
>>
>>
>>
>> Here is the fix that works for me for both problems.
>>
>>
>>
>> Thanks,
>>
>> Eugene
>>
>>
>>
>> diff --git a/include/lldb/Target/Process.h b/include/lldb/Target/Process.h
>>
>> index 6bb7a3d..915ca15 100644
>>
>> --- a/include/lldb/Target/Process.h
>>
>> +++ b/include/lldb/Target/Process.h
>>
>> @@ -3401,6 +3401,7 @@ protected:
>>
>>  std::map m_resolved_indirect_addresses;
>>
>>  bool m_destroy_in_process;
>>
>>  bool m_can_interpret_function_calls; // Some targets, e.g the OSX
>> kernel, don't support the ability to modify the stack.
>>
>> +bool m_load_core; // True if we are looking at a core dump, not at a
>> running program
>>
>>  WarningsCollection  m_warnings_issued;  // A set of object
>> pointers which have already had warnings printed
>>
>>
>>
>>  enum {
>>
>> diff --git a/source/Plugins/Process/elf-core/ProcessElfCore.cpp
>> b/source/Plugins/Process/elf-core/ProcessElfCore.cpp
>>
>> index 5b5d98a..fa057f1 100644
>>
>> --- a/source/Plugins/Process/elf-core/ProcessElfCore.cpp
>>
>> +++ b/source/Plugins/Process/elf-core/ProcessElfCore.cpp
>>
>> @@ -559,11 +559,10 @@
>> ProcessElfCore::ParseThreadContextsFromNoteSegment(const
>> elf::ELFProgramHeader *
>>
>>  have_prstatus = true;
>>
>>  prstatus.Parse(note_data, arch);
>>
>>  thread_data->signo = prstatus.pr_cursig;
>>
>> +thread_data->tid = prstatus.pr_pid;
>>
>>  header_size = ELFLinuxPrStatus::GetSize(arch);
>>
>>  len = note_data.GetByteSize() - header_size;
>>
>>  thread_data->gpregset = DataExtractor(note_data,
>> header_size, len);
>>
>> -// FIXME: Obtain actual tid on Linux
>>
>> -thread_data->tid = m_thread_data.size();
>>
>>  break;
>>
>>  case NT_FPREGSET:
>>
>>  thread_data->fpregset = note_data;
>>
>> diff --git a/source/Target/Process.cpp b/source/Target/Process.cpp
>>
>> index e4fe419..489b307 100644
>>
>> --- a/source/Target/Process.cpp
>>
>> +++ b/source/Target/Process.cpp
>>
>> @@ -767,6 +767,7 @@ Process::Process(lldb::TargetSP target_sp, Listener
>> &listener, const UnixSignals
>>
>>  m_last_broadcast_state (eStateInvalid),
>>
>>  m_destroy_in_process (false),
>>
>>  m_can_interpret_function_calls(false),
>>
>> +m_load_core(false),
>>
>>  m_warnings_issued (),
>>
>>  m_can_jit(eCanJITDontKnow)
>>
>> {
>>
>> @@ -3088,6 +3089,7 @@ Process::LoadCore ()
>>
>>  // We successfully loaded a core file, now pretend we stopped so
>> we can
>>
>>  // show all of the threads in the core file and explore the
>> crashed
>>
>>  // state.
>>
>> +m_load_core = true;
>>
>>  SetPrivateState (eStateStop

Re: [lldb-dev] How to use the C++ API? No useful documentation?

[Pavel Labath via lldb-dev]

Hi Paul,

I haven't followed this discussion from the start, and I am now having
trouble understanding what is the issue at hand here. Could you just
briefly repeat what is the problem, and maybe send the code for
reproducing the problem again? Maybe I'll be able to help...

pl

On 3 March 2016 at 13:04, Paul Peet via lldb-dev
 wrote:
> Sorry to bring this up again, but I am not sure if this is really a
> linux kernel issue anymore, see the following code:
>
> if(event_type == SBProcess::eBroadcastBitStateChanged) {
>   const StateType state = SBProcess::GetStateFromEvent(event);
>
>   switch(state) {
> default:
>   continue;
> case eStateStopped: {
>   static bool runOnce = false;
>   if(runOnce == false) {
> sleep(1); // sleep a second
> runOnce = true;
>   }
>
>   SBThread thread = process.GetThreadAtIndex(0);
>   SBStream stream;
>
> As I said before that strangely it worked on the vm with kernel 4.4 so
> I tried using kernel 4.4 and it still didn't work.
>
> Next thing I did was enabling lldb's logging and what I noticed was
> that when the first thread plan is being made it had wrong instruction
> information that's probably because the thread was still running. So
> what I tried was this runOnce with a sleep(1) and the result was as I
> expected, the thread plan contained the correct instruction
> information and the following breakpoints and step-overs were
> correctly made.
>
> Any chance that this issue lies deep in lldb? Would the lldb log help
> to trace back the issue?
>
> 2016-02-29 19:58 GMT+01:00 Greg Clayton :
>>
>>> On Feb 28, 2016, at 2:17 PM, Paul Peet  wrote:
>>>
>>> Hey,
>>>
>>> Just to let you know that I think I made some progress in determine the 
>>> problem.
>>> I've basically setup an vm (archlinux, linux 4.4, lldb 3.7.1) and
>>> tried the code on it. To my surprise it gave me proper output without
>>> non-determinism. YEY.
>>> I still don't have any idea why it's not working on my host system. I
>>> might try testing linux 4.4 like I did on the vm.
>>>
>>> Do you have any idea/suspicion why it might not work on my system. (I
>>> can provide additional information if needed).
>>
>> I don't. Maybe some of the linux experts out there might be able to help 
>> you. Are are working with top of tree LLDB sources right? You might post the 
>> exact linux setup you have in case that might allow people to help you out...
>>
>> Greg
>>
>>
> ___
> 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 use the C++ API? No useful documentation?

[Pavel Labath via lldb-dev]

Thanks for the explanation. I'll look this over tomorrow.

cheers,
pl

On 3 March 2016 at 15:23, Paul Peet  wrote:
> Hi Pavel,
>
> This is the code:
>
> int main() {
>   using namespace lldb;
>
>   SBDebugger::Initialize();
>   SBDebugger debugger = SBDebugger::Create(true);
>
>   if(!debugger.IsValid()) {
> return 1;
>   }
>
>   SBTarget target = debugger.CreateTarget("/home/cynecx/dev/helloWorld/main");
>
>   if(!target.IsValid()) {
> return 1;
>   }
>
>   SBBreakpoint bp1 = target.BreakpointCreateByLocation(
> "/home/cynecx/dev/helloWorld/main.cpp", 7);
>
>   if(!bp1.IsValid()) {
> return 1;
>   }
>
>   bp1.SetEnabled(true);
>
>   const char* args[] = { "/home/cynecx/dev/helloWorld/main", 0 };
>   const char* env[] = { 0 };
>
>   SBLaunchInfo launch_info(args);
>   launch_info.SetEnvironmentEntries(env, true);
>   launch_info.SetWorkingDirectory("/home/cynecx/dev/helloWorld");
>   launch_info.SetLaunchFlags(eLaunchFlagStopAtEntry);
>
>   SBError error;
>   SBProcess process = target.Launch(launch_info, error);
>
>   if(!process.IsValid() || !error.Success()) {
> return 1;
>   }
>
>   error = process.Continue();
>   if(!error.Success()) {
> return 1;
>   }
>
>   while(true) {
> SBEvent event;
> SBListener listener = debugger.GetListener();
>
> if(listener.WaitForEvent(6, event)) {
>   if(!event.IsValid()) {
> break;
>   }
>
>   const uint32_t event_type = event.GetType();
>
>   if (!SBProcess::EventIsProcessEvent(event)) {
> continue;
>   }
>
>   if(event_type == SBProcess::eBroadcastBitStateChanged) {
> const StateType state = SBProcess::GetStateFromEvent(event);
>
> switch(state) {
>   default:
> continue;
>   case eStateStopped: {
> //static bool runOnce = false;
> //
> //if(runOnce == false) {
> //  sleep(1);
> //  runOnce = true;
> //}
>
> SBThread thread = process.GetThreadAtIndex(0);
> SBStream stream;
>
> thread.GetStatus(stream);
> event.GetDescription(stream);
>
> std::cout << stream.GetData() << std::endl;
>
> auto threadStopReason = thread.GetStopReason();
> if(threadStopReason == eStopReasonBreakpoint) {
>   uint64_t bpId = thread.GetStopReasonDataAtIndex(0);
>
>   if(bpId == static_cast(bp1.GetID())) {
> std::cout << "Stopped at breakpoint" << std::endl;
> thread.StepOver();
>   }
> } else if (threadStopReason == eStopReasonPlanComplete) {
>   std::cout << "Stopped at step" << std::endl;
> }
>
> break;
>   }
> }
>   } else if (SBProcess::eBroadcastBitSTDOUT) {
> char buffer[1024];
> size_t num_bytes = 0;
> do
> {
>   num_bytes = process.GetSTDOUT(buffer, sizeof(buffer));
>   if (num_bytes > 0)
> printf("%*s", (int)num_bytes, buffer);
> } while (num_bytes == sizeof(buffer));
>   }
>
>   std::cout << "--" << std::endl;
> } else {
>   break;
> }
>   }
>
>   SBDebugger::Terminate();
>
>   return 0;
> }
>
> main.cpp:
>
> #include 
> #include 
> #include 
>
> int main() {
>
>   std::cout << "Hello World" << std::endl;
>
>   int i = 0;
>   std::cin >> i;
>
>   if (i == 1) {
> return 1;
>   }
>
>   return 0;
> }
>
>
> So the problem is that I am not getting correct thread information
> when receiving an eStateStopped event. It kinda seems that when
> "thread.GetStatus(stream);", the thread hasn't stopped yet so I always
> getting non-determine thread information.
> I found out that on my linux vm, it works properly so I thought it
> might be an issue with the kernel and stuff but I kinda found a
> workaround by simply putting a sleep(1) before querying the thread
> information. As expected it gave me correct thread information, also
> the step-over worked properly because the thread plan used correct
> line information.
>
> To compare both outputs:
>
> Correct one (with sleep(1)):
>
> * thread #1: tid = 5862, 0x00400953 main`main + 35 at
> main.cpp:7, name = 'main', stop reason = breakpoint 1.1
> frame #0: 0x00400953 main`main + 35 at main.cpp:7
>4
>5   int main() {
>6
> -> 7std::cout << "Hello World" << std::endl;
>8
>9int i = 0;
>10std::cin >> i;
> 0x7f1dc4000930 Event: broadcaster = 0x55da93268068 (lldb.process),
> type = 0x0001 (state-changed), data = { process = 0x55da93268030
> (pid = 5862), state = stopped}
> --
> * thread #1: tid = 5862, 0x00400953 main`main + 35 at
> main.cpp:7, name = 'main', stop reason = breakpoint 1.1
> frame #0: 0x00400953 main`main + 35 at main.cpp:7
>4
>5   int main() {
>6
> -> 7std::cout << "Hello World" << std::endl;
>8
>9int i = 0;
>10std::cin >> i;
>

Re: [lldb-dev] How to use the C++ API? No useful documentation?

[Pavel Labath via lldb-dev]

Hi Paul,

I believe you are experiencing the same problem as a couple of other
people before you (see
,
).
Basically, you need to ignore the events with the "restarted" flag  by
checking the GetRestartedFromEvent value for Stopped events. Linux
broadcasts this event on initial start, but other targets don't. This
is not a particularly well documented feature, and we would welcome
any improvements to the documentation. :)

Let me know if you still have problems after adding the check for the
restarted flag.

cheers,
pl


On 3 March 2016 at 15:26, Pavel Labath  wrote:
> Thanks for the explanation. I'll look this over tomorrow.
>
> cheers,
> pl
>
> On 3 March 2016 at 15:23, Paul Peet  wrote:
>> Hi Pavel,
>>
>> This is the code:
>>
>> int main() {
>>   using namespace lldb;
>>
>>   SBDebugger::Initialize();
>>   SBDebugger debugger = SBDebugger::Create(true);
>>
>>   if(!debugger.IsValid()) {
>> return 1;
>>   }
>>
>>   SBTarget target = 
>> debugger.CreateTarget("/home/cynecx/dev/helloWorld/main");
>>
>>   if(!target.IsValid()) {
>> return 1;
>>   }
>>
>>   SBBreakpoint bp1 = target.BreakpointCreateByLocation(
>> "/home/cynecx/dev/helloWorld/main.cpp", 7);
>>
>>   if(!bp1.IsValid()) {
>> return 1;
>>   }
>>
>>   bp1.SetEnabled(true);
>>
>>   const char* args[] = { "/home/cynecx/dev/helloWorld/main", 0 };
>>   const char* env[] = { 0 };
>>
>>   SBLaunchInfo launch_info(args);
>>   launch_info.SetEnvironmentEntries(env, true);
>>   launch_info.SetWorkingDirectory("/home/cynecx/dev/helloWorld");
>>   launch_info.SetLaunchFlags(eLaunchFlagStopAtEntry);
>>
>>   SBError error;
>>   SBProcess process = target.Launch(launch_info, error);
>>
>>   if(!process.IsValid() || !error.Success()) {
>> return 1;
>>   }
>>
>>   error = process.Continue();
>>   if(!error.Success()) {
>> return 1;
>>   }
>>
>>   while(true) {
>> SBEvent event;
>> SBListener listener = debugger.GetListener();
>>
>> if(listener.WaitForEvent(6, event)) {
>>   if(!event.IsValid()) {
>> break;
>>   }
>>
>>   const uint32_t event_type = event.GetType();
>>
>>   if (!SBProcess::EventIsProcessEvent(event)) {
>> continue;
>>   }
>>
>>   if(event_type == SBProcess::eBroadcastBitStateChanged) {
>> const StateType state = SBProcess::GetStateFromEvent(event);
>>
>> switch(state) {
>>   default:
>> continue;
>>   case eStateStopped: {
>> //static bool runOnce = false;
>> //
>> //if(runOnce == false) {
>> //  sleep(1);
>> //  runOnce = true;
>> //}
>>
>> SBThread thread = process.GetThreadAtIndex(0);
>> SBStream stream;
>>
>> thread.GetStatus(stream);
>> event.GetDescription(stream);
>>
>> std::cout << stream.GetData() << std::endl;
>>
>> auto threadStopReason = thread.GetStopReason();
>> if(threadStopReason == eStopReasonBreakpoint) {
>>   uint64_t bpId = thread.GetStopReasonDataAtIndex(0);
>>
>>   if(bpId == static_cast(bp1.GetID())) {
>> std::cout << "Stopped at breakpoint" << std::endl;
>> thread.StepOver();
>>   }
>> } else if (threadStopReason == eStopReasonPlanComplete) {
>>   std::cout << "Stopped at step" << std::endl;
>> }
>>
>> break;
>>   }
>> }
>>   } else if (SBProcess::eBroadcastBitSTDOUT) {
>> char buffer[1024];
>> size_t num_bytes = 0;
>> do
>> {
>>   num_bytes = process.GetSTDOUT(buffer, sizeof(buffer));
>>   if (num_bytes > 0)
>> printf("%*s", (int)num_bytes, buffer);
>> } while (num_bytes == sizeof(buffer));
>>   }
>>
>>   std::cout << "--" << std::endl;
>> } else {
>>   break;
>> }
>>   }
>>
>>   SBDebugger::Terminate();
>>
>>   return 0;
>> }
>>
>> main.cpp:
>>
>> #include 
>> #include 
>> #include 
>>
>> int main() {
>>
>>   std::cout << "Hello World" << std::endl;
>>
>>   int i = 0;
>>   std::cin >> i;
>>
>>   if (i == 1) {
>> return 1;
>>   }
>>
>>   return 0;
>> }
>>
>>
>> So the problem is that I am not getting correct thread information
>> when receiving an eStateStopped event. It kinda seems that when
>> "thread.GetStatus(stream);", the thread hasn't stopped yet so I always
>> getting non-determine thread information.
>> I found out that on my linux vm, it works properly so I thought it
>> might be an issue with the kernel and stuff but I kinda found a
>> workaround by simply putting a sleep(1) before querying the thread
>> information. As expected it gave me correct thread information, also
>> the step-over worked properly because the thread plan used correct
>> line information.
>>
>> To compare both outputs:

Re: [lldb-dev] Inquiry about Load Address

[Pavel Labath via lldb-dev]

Hi,

could you give us a bit more background about what are you trying to
do? It's hard to answer the question without knowing a bit more...

On 8 March 2016 at 10:42, Ravitheja Addepally via lldb-dev
 wrote:
> Hello,
>   I wanted to know if there is any existing API or a set of API's that
> could be used to retrieve the load addresses of the Modules ?

There is a GetLoadAddress function on SBSection
.
I don't see one on SBModule though. What do you need this for?

> secondly Can
> we obtain the dumps of the loaded Elf 's like in the remote case
> transporting them from the target to the host ?
>

What kind of "dumps" are you looking for? Will
SBSection.GetSectionData() work? A lot of other data is available in
the other SB classes, but it's hard to answer this without knowing
what exactly you are looking for.

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

Re: [lldb-dev] LLDB + UE4 on Android

[Pavel Labath via lldb-dev]

Hi Mikhail,

Modifying the build tool to include the build ID would probably be the
easiest solution to your problem. Please not that both the stripped
AND unstripped versions of the module need to have the (same)
.note.gnu.build-id section. I am not familiar with the build tool, but
"fixing" this should be as simple as adding "-Wl,--build-id" to your
compiler arguments for building the full .so. The subsequent strip
step should not remove the build-id (unless the tool uses some very
aggressive strip arguments).

Other possible solution would be to fix lldb to work in a
build-id-less scenario. We have been discussing trying to support this
just yesterday, but it's not yet clear when/if will that happen. The
problem there is that currently LLDB (in the ObjectFileELF snippet you
posted) falls back to computing a CRC of the whole module as its
"identity" if it cannot find a build it, which is not really working
as the CRC changes during stripping. One possible solution would be to
just do a checksum of only the allocatable ELF sections of the module,
which should hopefully create a strip-resistible identifier. If you're
interested in making this work, I think this would be a nice
improvement to lldb in general, and it should fix your problem.

let me know if you have further questions,
pl

On 9 March 2016 at 21:33, Mikhail Filimonov  wrote:
> Hello, fellow developers!
>
> I’m trying to debug Unreal Engine 4 sample on Android with LLDB 3.8 build 
> from source - Win32 x86 liblldb.dll and Android ARM lldb-server : it can’t 
> match the stripped module libUE4.so running on the device with a full version 
> which is available on a host.
> Unreal Build Tool don’t add the .note.gnu.build-id or .gnu_debuglink sections 
> to ELF files – and it looks that only if the stripped ELF .so running on a 
> target does have one of these than it could be matched with a full ELF module 
> located on a host - is that true?
>
> My reasoning is based on examination of
> https://github.com/llvm-mirror/lldb/blob/release_38/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp#L4328
> and
> https://github.com/llvm-mirror/lldb/blob/release_38/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp#L790
>
> If so, I need to modify UBT to add the .build-id or .gnu_debuglink to a 
> stripped libUE4.so
> ---
> 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.
> ---
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] What's the purpose of the TestStarted-XXX and TestFinished-XXX files?

[Pavel Labath via lldb-dev]

I don't think anyone is relying on these. We should just stop creating
them altogether.

We are using the *.log files to track test results over time, but we
don't need these files there. You can detect crashing tests by the
fact that the log files don't have a "TestResult-" (Success, Failure,
Error, ...) prefix. We have a script for doing that here
,
but it's very specific to our buildbot setup, so it may not be very
useful to you...



On 9 March 2016 at 23:04, Greg Clayton via lldb-dev
 wrote:
> I would be happy to see these files go away if no one is using them...
>
>> On Mar 9, 2016, at 2:32 PM, Adrian McCarthy via lldb-dev 
>>  wrote:
>>
>> The test traces directory tends to accumulate thousands and thousands of 
>> TestStarted-XXX and TestFinished-XXX files.  What purpose do they serve?
>>
>> I assume it's for trying to figure out why something went wrong.  If you 
>> have a TestStarted-123 without a corresponding TestFinished-123, then you 
>> can know that a test crashes and by looking inside the file, you can see 
>> which test and what the command was.
>>
>> If that's the case, then wouldn't it be cleaner to delete the TestStarted 
>> file when the test finishes rather than writing a second file?  Then you can 
>> simply search for TestStarted files to see the ones that didn't finish 
>> successfully without the noise of thousands of others that did.
>>
>> I suppose it's also possible that some other process is looking at these 
>> files in order to collect statistics.  Is there such a beast and is it 
>> valuable?
>>
>> Adrian.
>> ___
>> 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

Re: [lldb-dev] LLDB + UE4 on Android

[Pavel Labath via lldb-dev]

So, from the error message it looks like lldb is getting confused by
the debug information inside the executable. I don't have any special
hints for debugging that, I think the usual process of attaching the
debugger, examining the backtrace, and seeing what data is triggering
the assert would work best.

Alternatively, if you can create a list of steps to reproduce this
bug, we may be able to look at it for you. We're interested in making
this use case work, so we'll try to fix it soon.

pl

On 10 March 2016 at 18:00, Mikhail Filimonov  wrote:
> Well, after I've added .gnu_debuglink section to stripped libUE4.so LLDB 
> managed to resolve the symbols.
> But sometimes it asserts with the following message:
> ---
> Microsoft Visual C++ Runtime Library
> ---
> Assertion failed!
> Program: ...ORPORATION\NSIGHT TEGRA\3.3.16035.4243\liblldb.dll
> File: C:\wrk\llvm_git\tools\clang\lib\AST\Recor...tBuilder.cpp
> Line: 82
> Expression: FieldOffsets.count(FD) && "Field does not have an external offset"
> For information on how your program can cause an assertion
> failure, see the Visual C++ documentation on asserts
> (Press Retry to debug the application - JIT must be enabled)
> ---
> Abort   Retry   Ignore
> ---
> Any suggestions how to debug that?
>
> Regards,
> Mikhail
>
> -Original Message-
> From: Mikhail Filimonov
> Sent: Thursday, March 10, 2016 12:33 AM
> To: lldb-dev@lists.llvm.org
> Cc: Tamas Berghammer ; Pavel Labath 
> 
> Subject: LLDB + UE4 on Android
>
> Hello, fellow developers!
>
> I’m trying to debug Unreal Engine 4 sample on Android with LLDB 3.8 build 
> from source - Win32 x86 liblldb.dll and Android ARM lldb-server : it can’t 
> match the stripped module libUE4.so running on the device with a full version 
> which is available on a host.
> Unreal Build Tool don’t add the .note.gnu.build-id or .gnu_debuglink sections 
> to ELF files – and it looks that only if the stripped ELF .so running on a 
> target does have one of these than it could be matched with a full ELF module 
> located on a host - is that true?
>
> My reasoning is based on examination of
> https://github.com/llvm-mirror/lldb/blob/release_38/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp#L4328
> and
> https://github.com/llvm-mirror/lldb/blob/release_38/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp#L790
>
> If so, I need to modify UBT to add the .build-id or .gnu_debuglink to a 
> stripped libUE4.so
>
> ---
> 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.
> ---
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] unable to build lldb 3.8

[Pavel Labath via lldb-dev]

Hi Peter,

thank you for the report, you are writing to the right list.

Unfortunately, I am not aware of anyone in LLDB, who actually uses the
"make install" functionality, so it's very well possible that it's
broken. I can take a look at it, but I won't be able to do that for a
couple of weeks now. If you have some cmake experience you can try
digging around the lldb install scripts. I don't think the fix should
be difficult.

Until then, as a workaround I can recommend the following:
- if you just want to try out lldb, don't do a "make install", it
should run just fine from the build directory
- if you must do an "install", I guess you'll have to avoid checking
out lldb for now... :/

BTW, could you also send me the "tree diagram" of your build directory
as well? It might help me track the problem down when I get around to
it.

cheers,
pl


On 16 March 2016 at 09:32, Peter Steinbach via lldb-dev
 wrote:
> Hi to all,
>
> quick disclaimer: if this is the wrong mailing list, please let me know and
> accept my apologies. But I am not sure, if this is a bug or just me taking
> the wrong steps to build lldb. Feel free to suggest redirection.
>
> I wanted to build the entire llvm 3.8 suite to explore some parallel goodies
> (OpenMP, CUDA). I downloaded a handful of llvm projects and packages:
> cfe-3.8.0.src.tar.xzcompiler-rt-3.8.0.src.tar.xz
> libcxxabi-3.8.0.src.tar.xz  lld-3.8.0.src.tar.xz   llvm-3.8.0.src.tar.xz
> polly-3.8.0.src.tar.xz
> clang-tools-extra-3.8.0.src.tar.xz  libcxx-3.8.0.src.tar.xz
> libunwind-3.8.0.src.tar.xz  lldb-3.8.0.src.tar.xz openmp-3.8.0.src.tar.xz
> test-suite-3.8.0.src.tar.xz
> and put them in the right place I hope (see tree output attached).
>
> I then went:
> $ cmake -DCMAKE_INSTALL_PREFIX=/foo/bar /path/to/llvm/source
> $ make -jXX
> #all goes well until here
> $ make -jXX install
> ...
> - Up-to-date:
> /home/steinbac/software/llvm/3.8/include/lldb/DataFormatters/FormattersContainer.h
> -- Up-to-date:
> /home/steinbac/software/llvm/3.8/include/lldb/DataFormatters/TypeCategory.h
> CMake Error at tools/lldb/scripts/cmake_install.cmake:36 (file):
>   file INSTALL cannot find
>   "/data/steinbac/llvm/llvm-3.8.0.build/lib/python2.7".
> Call Stack (most recent call first):
>   tools/lldb/cmake_install.cmake:42 (include)
>   tools/cmake_install.cmake:43 (include)
>   cmake_install.cmake:61 (include)
>
>
> make: *** [install] Error 1
>
> What am I missing?
>
> Best,
> Peter
>
> PS. My system details:
> $ lsb_release -a
> LSB Version:
> :core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch
> Distributor ID: CentOS
> Description:CentOS Linux release 7.1.1503 (Core)
> Release:7.1.1503
> Codename:   Core
> $ uname -a
> Linux islay.mpi-cbg.de 3.10.0-229.20.1.el7.x86_64 #1 SMP Tue Nov 3 19:10:07
> UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
> $ gcc --version
> gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-9)
> Copyright (C) 2013 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> ___
> 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] unable to build lldb 3.8

[Pavel Labath via lldb-dev]

This is just a wild guess, but could you try running cmake with
-DLLVM_LIBDIR_SUFFIX=64. I remember we've had a need for that in the
past for systems which store libraries in lib64. Some provisions were
put in place to autodetect it, but i'm not sure if they completely
work.

On 16 March 2016 at 10:02, Peter Steinbach  wrote:
> Hi Pavel,
>
> thank you for jumping on this thread and giving this honest answer. I had a
> look at the build tree and indeed all binaries appear to be where they
> should be, i.e. build/bin, build/lib* and build/lib64/python2.7 etc. I'll do
> as you suggest and copy them to their final destination for now. I attached
> a 3 level tree dump to this mail of the build directory for completeness.
>
> I am relying on "make install" as we do a homogeneous provisioning of custom
> packages on our cluster (through a parallel FS) and workstation
> infrastructure (through network mounts) for now.
>
> If "make install" is not supported for now, I'd appreciate it if that would
> be documented somewhere.
>
> Thanks -
> Peter
>
>
> On 03/16/2016 10:48 AM, Pavel Labath wrote:
>>
>> Hi Peter,
>>
>> thank you for the report, you are writing to the right list.
>>
>> Unfortunately, I am not aware of anyone in LLDB, who actually uses the
>> "make install" functionality, so it's very well possible that it's
>> broken. I can take a look at it, but I won't be able to do that for a
>> couple of weeks now. If you have some cmake experience you can try
>> digging around the lldb install scripts. I don't think the fix should
>> be difficult.
>>
>> Until then, as a workaround I can recommend the following:
>> - if you just want to try out lldb, don't do a "make install", it
>> should run just fine from the build directory
>> - if you must do an "install", I guess you'll have to avoid checking
>> out lldb for now... :/
>>
>> BTW, could you also send me the "tree diagram" of your build directory
>> as well? It might help me track the problem down when I get around to
>> it.
>>
>> cheers,
>> pl
>>
>>
>> On 16 March 2016 at 09:32, Peter Steinbach via lldb-dev
>>  wrote:
>>>
>>> Hi to all,
>>>
>>> quick disclaimer: if this is the wrong mailing list, please let me know
>>> and
>>> accept my apologies. But I am not sure, if this is a bug or just me
>>> taking
>>> the wrong steps to build lldb. Feel free to suggest redirection.
>>>
>>> I wanted to build the entire llvm 3.8 suite to explore some parallel
>>> goodies
>>> (OpenMP, CUDA). I downloaded a handful of llvm projects and packages:
>>> cfe-3.8.0.src.tar.xzcompiler-rt-3.8.0.src.tar.xz
>>> libcxxabi-3.8.0.src.tar.xz  lld-3.8.0.src.tar.xz   llvm-3.8.0.src.tar.xz
>>> polly-3.8.0.src.tar.xz
>>> clang-tools-extra-3.8.0.src.tar.xz  libcxx-3.8.0.src.tar.xz
>>> libunwind-3.8.0.src.tar.xz  lldb-3.8.0.src.tar.xz openmp-3.8.0.src.tar.xz
>>> test-suite-3.8.0.src.tar.xz
>>> and put them in the right place I hope (see tree output attached).
>>>
>>> I then went:
>>> $ cmake -DCMAKE_INSTALL_PREFIX=/foo/bar /path/to/llvm/source
>>> $ make -jXX
>>> #all goes well until here
>>> $ make -jXX install
>>> ...
>>> - Up-to-date:
>>>
>>> /home/steinbac/software/llvm/3.8/include/lldb/DataFormatters/FormattersContainer.h
>>> -- Up-to-date:
>>>
>>> /home/steinbac/software/llvm/3.8/include/lldb/DataFormatters/TypeCategory.h
>>> CMake Error at tools/lldb/scripts/cmake_install.cmake:36 (file):
>>>file INSTALL cannot find
>>>"/data/steinbac/llvm/llvm-3.8.0.build/lib/python2.7".
>>> Call Stack (most recent call first):
>>>tools/lldb/cmake_install.cmake:42 (include)
>>>tools/cmake_install.cmake:43 (include)
>>>cmake_install.cmake:61 (include)
>>>
>>>
>>> make: *** [install] Error 1
>>>
>>> What am I missing?
>>>
>>> Best,
>>> Peter
>>>
>>> PS. My system details:
>>> $ lsb_release -a
>>> LSB Version:
>>>
>>> :core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch
>>> Distributor ID: CentOS
>>> Description:CentOS Linux release 7.1.1503 (Core)
>>> Release:7.1.1503
>>> Codename:   Core
>>> $ uname -a
>>> Linux islay.mpi-cbg.de 3.10.0-229.20.1.el7.x86_64 #1 SMP Tue Nov 3
>>> 19:10:07
>>> UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>>> $ gcc --version
>>> gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-9)
>>> Copyright (C) 2013 Free Software Foundation, Inc.
>>> This is free software; see the source for copying conditions.  There is
>>> NO
>>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
>>> PURPOSE.
>>>
>>> ___
>>> 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] Is it ok to use lldb_private from the driver?

[Pavel Labath via lldb-dev]

Are using we using any other signal that SIGINT on windows currently?
I seem to remember all the fancy signals (SIGTSTP, SIGWINCH,...) being
ifdef-ed out on windows. If the only signal we are interested about if
SIGINT, then I think the API should be more higher-level than a
signal() wrapper (SBHostOS::SetInterruptionHandler ?), since you're
never going to get that to behave portably. If there are other signals
used, then I'd be interesting in what they are and how they work on
windows.

Another thing: our current signal-handling code is pretty far from
being signal-safe. I was actually considering replacing the current
signal triggering mechanism with something makes sure the execution
happens on a separate thread (on POSIX you can do this with pselect or
sigwait, on windows we have this semantics already IIUC). It would be
great if any API added here did not preclude this.




On 18 March 2016 at 17:44, Greg Clayton via lldb-dev
 wrote:
>
>> On Mar 18, 2016, at 10:20 AM, Zachary Turner via lldb-dev 
>>  wrote:
>>
>> Is it ok to add a public API that isn't interfaced to Python?  In this case 
>> the culprit is the signal() function.  Windows doesn't really support signal 
>> in the same way that other platforms do, so there's some code in each driver 
>> that basically defines a signal function, and then if you're unlucky when 
>> you build, or accidentally include the wrong header file (even indirectly), 
>> you'll get multiply defined symbol errors.
>>
>> So what I wanted to do was make a Host::Signal() that on Windows had our 
>> custom implementation, and on other platforms just called signal.  But it 
>> returns and accepts function pointers, and making this work through the 
>> python api is going to be a big deal, if not flat out impossible.
>
> Why is this an issue in Python? Doesn't python abstract this for you? Or is 
> it just a NOP on windows??
>>
>> The idea is that instead of writing signal() everywhere, we would write 
>> lldb_private::Host::Signal() everywhere instead.
>
> Is this just to get a callback when a certain signal is sent to a process, 
> like to handle SIGINT?
>
> Why this is hard to hook through SBHostOS if python doesn't provide an 
> abstraction?
>
>>
>> On Fri, Mar 18, 2016 at 10:16 AM Jim Ingham  wrote:
>> The driver used to have a bunch of lldb_private stuff in it, mostly to run 
>> the event loop, which Greg abstracted into SB API’s a while ago.  If it can 
>> be avoided, I’d rather not add it back in.  Our claim is folks should be 
>> able to write their own debugger interfaces (command line or gui) using the 
>> SB API’s, so it would be good if we stuck to that discipline as well.
>>
>> I thought that the lldm-mi was pure SB API’s.  That seemed a virtue to me.
>>
>> Jim
>>
>> > On Mar 18, 2016, at 9:54 AM, Zachary Turner via lldb-dev 
>> >  wrote:
>> >
>> > I notice everything uses SB classes only.  Is this a hard requirement?  We 
>> > have a bit of cruft in all of the top-level executables (lldb-server, 
>> > lldb-mi, lldb) that could be shared if we could move it into Host, but 
>> > then the 3 drivers would have to #include "lldb/Host/Host.h".  Note that 
>> > lldb-mi and lldb-server already do this, it's only lldb that doesn't.  Is 
>> > this ok?
>> >
>> > If not, I can always add a method to SBHostOS and just not add a 
>> > corresponding swig interface definition for it (so it wouldn't be 
>> > accessible from Python), which would achieve basically the same effect.
>> > ___
>> > 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 mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Weird stop stack while hitting breakpoint

[Pavel Labath via lldb-dev]

If you send me a small repro case, I can try to look at why is Linux
different here.

On 19 March 2016 at 00:46, Jim Ingham via lldb-dev
 wrote:
> All this logic is handled in Process::HandleProcessStateChangedEvent (see 
> around line 1215 in Process.cpp)  You shouldn’t have to reimplement the logic 
> for setting the selected thread unless you don’t like our heuristics.  Note, 
> that’s in generic code, so I don’t know why it wouldn’t be working right on 
> Linux.
>
> Jim
>
>> On Mar 18, 2016, at 5:38 PM, Greg Clayton  wrote:
>>
>> It is really up to the IDE to decide this so the logic belongs in your IDE. 
>> We do things as follows:
>>
>> If no thread was selected before, display the first thread that has a stop 
>> reason other than none. If no threads have stop reasons, select the first 
>> thread. If a thread was selected before, then see if that same thread is 
>> stopped with a reason the next time you stop and select that one, regardless 
>> if it is the first thread with a stop reason. The idea is, if you were 
>> stepping or doing something in a thread, and then stop again, you don't want 
>> the IDE changing away from your current thread if this thread has a stop 
>> reason. If this thread doesn't have a stop reason, then select the first one 
>> that does. If not threads have stop reasons, then display the same thread as 
>> before.
>>
>>> On Mar 18, 2016, at 5:23 PM, Jeffrey Tan via lldb-dev 
>>>  wrote:
>>>
>>> Thanks for the info. I understand the multiple threads stopping at the same 
>>> time issue. But I would think we should at least pick one stopped thread 
>>> and set it as selected thread instead of some random thread with stop 
>>> reason None. Also, in my repro case, there is only one thread that has stop 
>>> reason, so the heuristics should be pretty trivial to set selected thread 
>>> to that one.
>>> I have workaround this issue with the suggestion but I think there is a 
>>> bug(on Linux) here.
>>>
>>> On Fri, Mar 18, 2016 at 4:40 PM, Jim Ingham  wrote:
>>> On many platforms (OS X for sure) there’s no guarantee that when you stop 
>>> you will only have hit one breakpoint on one thread.  On OS X in 
>>> multithreaded programs, it is not at all uncommon to have many threads hit 
>>> breakpoint(s) by the the time the stop gets reported.  So you just have to 
>>> iterate over all the threads and see what their stop reasons are.  Note 
>>> that it isn’t just breakpoints, you might have been stepping on thread A, 
>>> and when you stop, thread A will have stopped with “plan complete” for the 
>>> step operation, and thread B for some other breakpoint.
>>>
>>> So when you get a stop event you have to iterate over the threads and see 
>>> why they have stopped.
>>>
>>> LLDB will set one of the threads as the selected thread, using some 
>>> heuristics (if you were stepping on thread A & threads A & B stopped with 
>>> breakpoints, thread A will be the selected thread, etc…)  So you could just 
>>> show the selected thread, but really you want to figure out what all the 
>>> threads are doing.
>>>
>>> Jim
>>>
 On Mar 18, 2016, at 4:25 PM, Jeffrey Tan  wrote:


 Hmm, interesting, I got the stop reason from the 
 lldb.SBProcess.GetProcessFromEvent(event).GetSelectedThread().GetStopReason().
  Is that thread not the one that stopped? But you are right, the 
 breakpoint hits in another thread:

 thread #87: tid = 1006769, 0x0042eacd 
 biggrep_master_server_async`facebook::biggrep::BigGrepMasterAsync::future_find(this=0x7f3ea2d74fd0,
  corpus=error: summary string parsing error, needle=error: summary string 
 parsing error, options=0x7f3e899fc7e0) + 51 at 
 BigGrepMasterAsync.cpp:171, name = 'BigGrep-pri3-32', stop reason = 
 breakpoint 1.1

 How do I know which thread hits the breakpoint?

 Jeffrey


 On Fri, Mar 18, 2016 at 4:12 PM, Jim Ingham  wrote:
 You only show one thread in your example.  Did another thread have a valid 
 stop reason?  lldb shouldn’t be stopping for no reason anywhere…

 Jim

> On Mar 18, 2016, at 4:08 PM, Jeffrey Tan via lldb-dev 
>  wrote:
>
> Btw: the breakpoint I set is:
> "b BigGrepMasterAsync.cpp:171" which is not in any of the stopped stack 
> frames.
>
> On Fri, Mar 18, 2016 at 3:47 PM, Jeffrey Tan  
> wrote:
> Hi,
>
> Our IDE(wrapping lldb using python) works fine on Linux for simple hello 
> world cases. While trying a real world case, I found whenever we set a 
> source line breakpoint, then trigger the code path, lldb will send a 
> stopped state process event, with thread.GetStopReason() being None and 
> with weird callstack. Any ideas why do I get this stop stack(code is 
> listed at the end)? I have verified that if I do not set breakpoint and 
> trigger the same code path does not cause this stop event to generate.
>
> bt
> * thread #1: tid = 9524

Re: [lldb-dev] Hang of LLDB 3.8.0 on Debian 8

[Pavel Labath via lldb-dev]

Hi,

I suspect this may be related to
. Could you try removing
the  -DLLVM_LINK_LLVM_DYLIB=ON option and trying again?

cheers,
pl

On 24 March 2016 at 14:52, David Jones via lldb-dev
 wrote:
> I am trying to run LLDB from the 3.8.0 release on a Debian 8 system.
> However, LLDB hangs during attach:
>
> $ lldb /bin/ls
> (lldb) target create "/bin/ls"
> Current executable set to '/bin/ls' (x86_64).
> (lldb) r
>
> At which point it hangs. From another window:
>
> $ ps -eLf|grep djones
> djones   32218  7418 32218  33 10:33 pts/18   00:00:00 lldb /bin/ls
> djones   32218  7418 32224  03 10:33 pts/18   00:00:00 lldb /bin/ls
> djones   32218  7418 32225  03 10:34 pts/18   00:00:00 lldb /bin/ls
>
> So three threads are created. I'm not sure how far LLDB got in creating its
> target.
>
> The 3.7 releases did this, on both Debian and Ubuntu 14.04LTS. However, the
> 3.8 release fixed this for Ubuntu. I had neglected to test this on Debian.
>
> I am also using LLDB as a library in my own application. Tracing through
> that, my app hangs in the call to SBTarget::AttachToProcessWithID.
>
> strace -f provides insight:
>
> [pid   532] write(2, ": CommandLine Error: Option '", 29) = 29
> [pid   532] write(2, "debug", 5)= 5
> [pid   532] write(2, "' registered more than once!\n", 29) = 29
> [pid   532] write(2, "LLVM ERROR: inconsistency in reg"..., 60) = 60
> [pid   532] exit_group(1)   = ?
> [pid   532] +++ exited with 1 +++
> [pid   524] <... futex resumed> )   = ? ERESTARTSYS (To be restarted if
> SA_RESTART is set)
> [pid   533] <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) == 1}],
> __WALL, NULL) = 532
> [pid   524] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=532,
> si_uid=1500, si_status=1, si_utime=0, si_stime=0} ---
> [pid   524] futex(0x7fed965909d0, FUTEX_WAIT, 531, NULL 
> [pid   533] madvise(0x7fed9558f000, 8368128, MADV_DONTNEED) = 0
> [pid   533] _exit(0)= ?
> [pid   533] +++ exited with 0 +++
>
> It looks like the error message to the effect that an option was registered
> more than once never makes it out, causes child death, and the parent hangs
> waiting for a child that will never signal.
>
> LLVM was built as follows:
>
> tar xJf Downloads/llvm-3.8.0.src.tar.xz
> tar xJf Downloads/cfe-3.8.0.src.tar.xz
> tar xJf Downloads/lldb-3.8.0.src.tar.xz
> cd llvm-3.8.0.src/tools
> ln -s ../../cfe-3.8.0.src/ clang
> ln -s ../../lldb-3.8.0.src/ lldb
> cmake -DLLVM_BUILD_LLVM_DYLIB=ON -DLLVM_LINK_LLVM_DYLIB=ON
> -DCMAKE_INSTALL_PREFIX=/tools/llvm/3.8.0dbg
> -DLLVM_TARGETS_TO_BUILD="X86;CppBackend" -DCMAKE_BUILD_TYPE=Release
> -DLLVM_ENABLE_ASSERTIONS=ON ..
> cmake --build . -- -j4
> sudo cmake --build . --target install
>
> Is this a known issue?
>
>
>
> ___
> 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] SBProcess::Detach kills target

[Pavel Labath via lldb-dev]

There is no system restriction which prevents you from doing this.
(Without any investigation) my guess would be that your inferior is
dying of SIGHUP, which it receives when we close the master end of its
pty. Could you check whether the behavior persists if your app blocks
SIGHUP and/or you launch it with "process launch --no-stdio").

pl

On 25 March 2016 at 23:33, Jim Ingham via lldb-dev
 wrote:
> I vaguely remember that not all Unixen support detaching from a process that 
> is a child of the debugger that is attached to it.  If you run the process 
> under gdb & detach, does the process survive?  This may not be an exact test, 
> since gdb may use procfs rather than ptrace, I don't know any more...  But if 
> it doesn't work for gdb, it's probably a system limitation.
>
> Anyway, launch then detach works as Greg described on OS X, so all the bits 
> down to the call into the Process plugin's Detach is working correctly.  So 
> either there's a bug in llgs or in the Process plugin for Linux's detach.
>
> Jim
>
>
>> On Mar 25, 2016, at 3:57 PM, Greg Clayton via lldb-dev 
>>  wrote:
>>
>> Calling SBProcess::Detach() on a process that is currently running should 
>> always detach and this seems like a bug. This might be this way because if 
>> you launch a process in LLDB and then quit:
>>
>> % lldb /bin/ls
>> (lldb) b malloc
>> (lldb) run
>> (lldb) quit
>>
>> This should kill the process if it was launched and detach if we attached. 
>> But only when we quit without telling it to do something. If we did:
>>
>> % lldb /bin/ls
>> (lldb) b malloc
>> (lldb) run
>> (lldb) detach
>>
>> Then this should always detach if the user explicitly requests it no matter 
>> how it was launched.
>>
>>> On Mar 25, 2016, at 3:35 PM, Eugene Birukov via lldb-dev 
>>>  wrote:
>>>
>>> Hi,
>>>
>>> Is this expected behavior or am I doing something wrong?
>>>
>>> I am running my C++ program that uses LLDB API on Linux Ubuntu 15.10.
>>>
>>> If I attach to already running process then SBProcess::Detach() behaves as 
>>> expected - my debugger quits and the target keeps running. But if the 
>>> target was launched by my debugger, then detach just kills it. Is there any 
>>> way to leave the target running?
>>>
>>> Thanks,
>>> Eugene
>>> ___
>>> 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 mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] How to detach from stop mode without causing signal in inferior on Linux?

[Pavel Labath via lldb-dev]

Hi,

are you doing a SBProcess.Detach() before you kill the debugger? If
that doesn't help could you send me the gdb-remote packet form
(execute command: log enable -f /some/file.log gdb-remote packets), so
I can get a better idea of what is going on.

cheers,
pl


On 29 March 2016 at 00:21, Jeffrey Tan via lldb-dev
 wrote:
> Hi,
>
> When user tries to stop debugging, we call SBDebugger.Destroy(), then
> SBDebugger.Terminate() and exit the python process. This works well on mac,
> but on linux in running mode. However, I found if the debugger hits
> breakpoint first, then user stops debugging, the inferior is killed with
> siginal:
> "Trace/breakpoint trap"
>
> I tried to call SBTarget.DeleteAllBreakpoints() first before killing
> debugger. Still the same result.
>
> Jeffrey
>
> ___
> 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] MSVC 2013 w/ Python 2.7 is moving to an unsupported toolchain

[Pavel Labath via lldb-dev]

Zachary, all,

after overcoming some problems, mostly unrelated to MSVC, we have
finally managed to switch to VS2015. I think that means there are no
more VS2013 users remaining. Given that, shall we start the process to
formally allow c++ features, which were blocked due to VS2013 until
now? I am mostly thinking about thread-safe function-static variable
initialization and alias templates here...

what do you think?
pl


On 4 February 2016 at 20:23, Ted Woodward  wrote:
> We can change to 3+2015; if you guys don't think 2+2013 is useful, we'll do 
> that.
>
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
> Linux Foundation Collaborative Project
>
> -Original Message-
> From: Pavel Labath [mailto:lab...@google.com]
> Sent: Thursday, February 04, 2016 10:01 AM
> To: Ted Woodward
> Cc: Zachary Turner; LLDB
> Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported 
> toolchain
>
> Hi all.
>
> we (android lldb team) are starting to transition to VS2015 as well.
> For now, the plan is to stick to python 2.7, but if we encounter problems 
> there, the backup plan is to go to python 3 as well. Until then (I estimate 
> that will take 1--2 weeks) our buildbot 
>  will continue 
> building 2.7+2013 and we will be making sure it works, so please don't check 
> in any VS2013 incompatible code (yet).
>
> Ted: If you can't switch to the 3+2015 combination (which I *do* recommend 
> you try), maybe you can go half-way and switch to 2.7+2015 (I can show you 
> how to build python 2.7 with VS2015). If you stick with 2.7+2013 combo, it 
> will soon be up to you to chase anyone who adds 2013-breaking changes...
>
> pl
>
>
> On 2 February 2016 at 23:42, Ted Woodward via lldb-dev 
>  wrote:
>> No, it turned red Friday night/Saturday morning.
>>
>>
>>
>> Last good build:
>>
>> http://lab.llvm.org:8011/builders/lldb-x86-win7-msvc/builds/15167
>>
>>
>>
>> First bad build:
>>
>> http://lab.llvm.org:8011/builders/lldb-x86-win7-msvc/builds/15168
>>
>>
>>
>> It went red because of the change to VS2015/Python 3.5.
>>
>>
>>
>> --
>>
>> Qualcomm Innovation Center, Inc.
>>
>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>> a Linux Foundation Collaborative Project
>>
>>
>>
>> From: Zachary Turner [mailto:ztur...@google.com]
>> Sent: Tuesday, February 02, 2016 5:28 PM
>>
>>
>> To: Ted Woodward; LLDB
>> Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an
>> unsupported toolchain
>>
>>
>>
>> BTW, I expect that your buildbot has been experiencing the problems
>> with the
>> x86 / x64 toolchain for quite some time, because it's not really
>> relevant to how much memory your machine has, but just that it was
>> using an x86 toolchain at all.  Has it been red for a long time?
>>
>>
>>
>> On Tue, Feb 2, 2016 at 1:48 PM Zachary Turner  wrote:
>>
>> You may have to make some changes to the zorg scripts to keep that working.
>> I didn't realize there were any other bots building LLDB, so I made
>> some changes that will default everything to VS2015 and Py3.
>>
>>
>>
>> BTW, is your builder doing a debug build or a release build?  When
>> doing a debug build clang now requires more memory than can fit in a
>> 4GB address space to link, so using an x86 toolchain won't work
>> anymore.  I forced a change to use the amd64_x86 toolchain, but this
>> won't work unless the version of python used by buildbot is a 64-bit
>> Python distro (because Python.exe is what ultimately calls vcvarsall
>> and cmake and it inherits the environment of the parent).
>>
>>
>>
>> So I think you will need to do all this as well.
>>
>>
>>
>> On Tue, Feb 2, 2016 at 1:44 PM Ted Woodward
>> 
>> wrote:
>>
>> Then maybe we should keep it 2013/py2.7, until llvm requires 2015.
>>
>>
>>
>> --
>>
>> Qualcomm Innovation Center, Inc.
>>
>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>> a Linux Foundation Collaborative Project
>>
>>
>>
>> From: Zachary Turner [mailto:ztur...@google.com]
>> Sent: Tuesday, February 02, 2016 3:43 PM
>>
>>
>> To: Ted Woodward; LLDB
>> Subject: Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an
>> unsupported toolchain
>>
>>
>>
>> It's Server 2008 R2 technically, which is the server version of Win 7
>> (same API set, same OS features, etc).  So yea, I'm pretty confident
>> that test coverage is going to be 100% the same across both.  It's
>> just a matter of if you want to have something that you maintain /
>> have control over, or if you want to test something in a different way than 
>> what we're testing.
>>
>>
>>
>> On Tue, Feb 2, 2016 at 1:29 PM Ted Woodward
>> 
>> wrote:
>>
>> Yours is Win Server 2008; ours is Win 7. I don’t know if that matters.
>>
>>
>>
>> --
>>
>> Qualcomm Innovation Center, Inc.
>>
>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>> a Linux Foundation Collaborative Project
>>
>>
>>
>> From:

Re: [lldb-dev] SBProcess::Detach kills target

[Pavel Labath via lldb-dev]

So I have made a small test program (which does nothing but spin in a
loop), and indeed it is the SIGHUP that kills it after detach. If the
test program blocks the signal, then it continues running even after
detach:
$ cat a.c
#include 
#include 

int main() {
signal(SIGHUP, SIG_IGN);
for (;;) sleep(1);
}
$ cc a.c -g
$ ps -A | grep a.out
$ ~/ll/build/dbg/bin/lldb ./a.out
(lldb) target create "./a.out"
Current executable set to './a.out' (x86_64).
(lldb) b 6
Breakpoint 1: where = a.out`main + 19 at a.c:6, address = 0x00400590
(lldb) r
Process 13416 launched: './a.out' (x86_64)
Process 13416 stopped
* thread #1: tid = 13416, 0x00400590 a.out`main + 19 at a.c:6,
name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x00400590 a.out`main + 19 at a.c:6
   3
   4   int main() {
   5  signal(SIGHUP, SIG_IGN);
-> 6  for (;;) sleep(1);
   7   }
(lldb) detach
Process 13416 detached
(lldb) q
$ ps -A | grep a.out
 13416 ?00:00:00 a.out


On 29 March 2016 at 18:38, Eugene Birukov  wrote:
> I believe this is not SIGHUP on debugger exit. I am using my own C++ program
> that calls into LLDB API. So, this program is still alive after calling
> SBProcess::Detach() but the target dies. Also, the target intercepts SIGHUP
> to do cleanup before exiting. I put printf there, it was not hit.
The fact whether your program is alive irrelevant. What matters is
that by cleaning up the process structure, we will also close the
master end of the pty used for inferior communication, and this is
what causes the SIGHUP. For that reason you also cannot use a printf
to do diagnostics as the output has nowhere to go. Note that lldb's
behavior here will be different from gdb as gdb does not do stdio
redirection, and has the inferior share the pty with the debugger (in
which case your program will die when you close the terminal window).

>
> I tried interactive LLDB, the target is not there:
>
> Process 49145 stopped
> * thread #1: tid = 49145, ..., stop reason = signal SIGSTOP
> frame #0: 0x76a5bbed libc.so.6 at syscall-template.S:81
> (lldb) detach
> Process 49145 detached
> (lldb) q
> eugene@EUGENEBI-L1:~/tmp$ ps
>   PID TTY  TIME CMD
> 30714 pts/17   00:00:00 bash
> 49259 pts/17   00:00:00 ps
Note that the inferior will not show up here even if it exists, as ps
will only list the processes with the same tty, but at this point the
inferior process has no tty.

Good luck with your investigations.

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

Re: [lldb-dev] SBProcess::Detach kills target

[Pavel Labath via lldb-dev]

We are not sending the SIGHUP, it is automatically getting sent by the
OS when the master end of the pty gets closed. The reason you are not
seeing this in the attach scenario is that we do not intercept
inferior stdio in this case (it's not possible, or desirable, since
the process is already running). This is also the reason
SBProcess.GetSTDOUT does not return anything in the attach scenario. I
am not familiar with the details of the Mac implementation and I
cannot tell you why is this not happening there.
I guess one way to fix this would be to have a special mode of
starting the inferior without a controlling terminal, but I am not
sure if this would be a generally useful feature. What is it that you
are trying to do anyway?

pl

On 30 March 2016 at 23:03, Eugene Birukov  wrote:
> Just a wild guess - is this SIGHUP because stdin/stdout are broken? I.e. the
> debugger closes its pty's on detach and that causes the signal?
> What is the behavior on MAC?
>
> 
> To: lab...@google.com
> Date: Wed, 30 Mar 2016 14:49:33 -0700
> CC: lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] SBProcess::Detach kills target
> From: lldb-dev@lists.llvm.org
>
>
> Right, my bad. The problem was that when debugger detaches the stdio does
> not go anywhere so I failed to see my printf.
>
> Still, is this how it is supposed to be? I naively assume that if we don't
> send SIGHUP in attach scenario we should not send it in launch scenario too.
>
> Thanks,
> Eugene
>
>> From: lab...@google.com
>> Date: Wed, 30 Mar 2016 10:22:33 +0100
>> Subject: Re: [lldb-dev] SBProcess::Detach kills target
>> To: eugen...@hotmail.com
>> CC: jing...@apple.com; lldb-dev@lists.llvm.org
>>
>> So I have made a small test program (which does nothing but spin in a
>> loop), and indeed it is the SIGHUP that kills it after detach. If the
>> test program blocks the signal, then it continues running even after
>> detach:
>> $ cat a.c
>> #include 
>> #include 
>>
>> int main() {
>> signal(SIGHUP, SIG_IGN);
>> for (;;) sleep(1);
>> }
>> $ cc a.c -g
>> $ ps -A | grep a.out
>> $ ~/ll/build/dbg/bin/lldb ./a.out
>> (lldb) target create "./a.out"
>> Current executable set to './a.out' (x86_64).
>> (lldb) b 6
>> Breakpoint 1: where = a.out`main + 19 at a.c:6, address =
>> 0x00400590
>> (lldb) r
>> Process 13416 launched: './a.out' (x86_64)
>> Process 13416 stopped
>> * thread #1: tid = 13416, 0x00400590 a.out`main + 19 at a.c:6,
>> name = 'a.out', stop reason = breakpoint 1.1
>> frame #0: 0x00400590 a.out`main + 19 at a.c:6
>> 3
>> 4 int main() {
>> 5 signal(SIGHUP, SIG_IGN);
>> -> 6 for (;;) sleep(1);
>> 7 }
>> (lldb) detach
>> Process 13416 detached
>> (lldb) q
>> $ ps -A | grep a.out
>> 13416 ? 00:00:00 a.out
>>
>>
>> On 29 March 2016 at 18:38, Eugene Birukov  wrote:
>> > I believe this is not SIGHUP on debugger exit. I am using my own C++
>> > program
>> > that calls into LLDB API. So, this program is still alive after calling
>> > SBProcess::Detach() but the target dies. Also, the target intercepts
>> > SIGHUP
>> > to do cleanup before exiting. I put printf there, it was not hit.
>> The fact whether your program is alive irrelevant. What matters is
>> that by cleaning up the process structure, we will also close the
>> master end of the pty used for inferior communication, and this is
>> what causes the SIGHUP. For that reason you also cannot use a printf
>> to do diagnostics as the output has nowhere to go. Note that lldb's
>> behavior here will be different from gdb as gdb does not do stdio
>> redirection, and has the inferior share the pty with the debugger (in
>> which case your program will die when you close the terminal window).
>>
>> >
>> > I tried interactive LLDB, the target is not there:
>> >
>> > Process 49145 stopped
>> > * thread #1: tid = 49145, ..., stop reason = signal SIGSTOP
>> > frame #0: 0x76a5bbed libc.so.6 at syscall-template.S:81
>> > (lldb) detach
>> > Process 49145 detached
>> > (lldb) q
>> > eugene@EUGENEBI-L1:~/tmp$ ps
>> > PID TTY TIME CMD
>> > 30714 pts/17 00:00:00 bash
>> > 49259 pts/17 00:00:00 ps
>> Note that the inferior will not show up here even if it exists, as ps
>> will only list the processes with the same tty, but at this point the
>> inferior process has no tty.
>>
>> Good luck with your investigations.
>>
>> pl
>
> ___ 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] Review of API and remote packets

[Pavel Labath via lldb-dev]

I second Greg's suggestions, and I have some thoughts of my own:

- with the proposed API, it is not possible to get a trace for newly
created threads - the process needs to be stopped first, so you can
enable trace collection. There certainly are cases where this could be
problematic, e.g. if you get a crash early during thread creation and
you want to figure out how you got there. For this to work, we might
need an API like
SBProcess::TraceNewThreads(...)
or
SBProcess::TraceAllThreads(...)
with the assumption that "all" also includes newly created threads in
the future.

I'm not saying this needs to be done in the first implementation, but
I think that we should at least design the API in a way that will not
make adding this unnecessarily hard in the future (e.g. the idea of
returning an SBTrace object might be problematic, since you don't know
if/how many threads will be created).



Also, thinking about new APIs, should we have a way to mark an API as
incubating/experimental? Maybe it would be good to mark these new APIs
as experimental for a while, so we have an option of changing them in
the future, if it turns out we have made the wrong decision. I was
thinking of either a naming convention
(SBThread::StartTraceExperimental) or some annotation/comment on the
methods. When we are confident this design is good, we can remove the
promote the api into the "stable" set.

pl




On 31 March 2016 at 18:59, Greg Clayton via lldb-dev
 wrote:
>
>> On Mar 31, 2016, at 5:10 AM, Ravitheja Addepally via lldb-dev 
>>  wrote:
>>
>> Hello all,
>>   I am currently working on enabling Intel (R) Processor Trace 
>> collection for lldb. I have done some previous discussions in this mailing 
>> list on this topic but just to summarize , the path we chose was to 
>> implement raw trace collection in lldb and the trace will be decoded outside 
>> LLDB. I wanted to expose this feature through the SB API's  and for trace 
>> data transfer I wish to develop new communication packets. Now I want to get 
>> the new API's and packet specifications reviewed by the dev list. Please 
>> find the specification below ->
>>
>> lldb::SBError SBProcess::StartTrace(lldb::tid_t threadId, const 
>> SBTraceConfig &config)
>> Start tracing for thread - threadId with trace configuration config.
>> SBTraceConfig would contain the following fields-
>> -> TraceType - ProcessorTrace, SoftwareTrace , any trace 
>> technology etc
>> -> size of trace buffer
>> -> size of meta data buffer
>> Returns error in case starting trace was unsuccessful, which could occur 
>> by reasons such as
>> picking non existent thread, target does not support TraceType selected 
>> etc.
>
> If you are going to trace on a thread, we should be putting this API on 
> SBThread. Also we have other config type classes in our public API and we 
> have suffixed them with Options so SBTraceConfig should actually be 
> SBTraceOptions. Also don't bother using "const" on any public APIs since the 
> mean nothing and only cause issues. Why? All public classes usually contain a 
> std::unique_ptr or a std::shared_ptr to a private class that exists only 
> within LLDB itself. The "const" is just saying don't change my shared 
> pointer, which doesn't actually do anything.
>
> lldb::SBError SBThread::StartTrace(SBTraceOptions &trace_options);
>
>>
>> lldb::SBError SBProcess::StopTrace(lldb::tid_t threadId)
>> Stop tracing for thread - threadId. Tracing should be enabled already 
>> for thread, else error is returned.
>
> This should be:
>
> lldb::SBError SBThread::StopTrace();
>
> One question: can there only be one kind of trace going on at the same time? 
> If we ever desire to support more than one at a time, we might need the above 
> two calls to be:
>
>
> lldb::user_id_t SBThread::StartTrace(SBTraceOptions &trace_options, 
> lldb::SBError &error);
> lldb::SBError SBThread::StopTrace(lldb::user_id_t trace_id);
>
> The StartTrace could return a unique trace token that would need to be 
> supplied back to any other trace calls like the ones below.
>
>> size_t SBProcess::DumpTraceData(lldb::tid_t threadId, void *buf, size_t 
>> size, SBError &sberror)
>> Dump the raw trace data for threadId in buffer described by pointer buf 
>> and size. Tracing should be enabled already for thread else error
>> is sent in sberror. The actual size of filled buffer is returned by API.
>>
>> size_t SBProcess::DumpTraceMetaData(lldb::tid_t threadId, void *buf, size_t 
>> size, SBError &sberror)
>> Dump the raw trace meta data for threadId in buffer described by pointer 
>> buf and size. Tracing should be enabled already for thread
>> else error is sent in sberror. The actual size of filled buffer is 
>> returned by API.
>
> These would be on lldb::SBThread and remove the lldb::tid_t parameter, 
> possibly adding "lldb::user_id_t trace_id" as the first parameter.
>
> The other way to do this is to create a lldb::SBTrace

Re: [lldb-dev] SBProcess::Detach kills target

[Pavel Labath via lldb-dev]

> It might be also possible to run an expression that will route 
> stdin/stdout/stderr to /dev/null before detaching if we know that we have a 
> master/slave pty hooked up the the inferior's in/out/err. We could run an 
> expression like:
(At least on linux) you would also need something like:
ioctl(open("/dev/tty", O_RDWR), TIOCNOTTY)
without it, the process will remain tied to the pty and will get a
HUP. Then redirection of file descriptors becomes optional: The
program will not get a SIGHUP, although it will get a SIGPIPE if it
tries to write some output to the slave end of the pty.


On 31 March 2016 at 22:44, Eugene Birukov  wrote:
> OK, I got the picture, thanks a lot!
>
>  > What is it that you are trying to do anyway?
>
> Well, target termination during detach is unexpected, so my customers might
> get confused.

In case of a console debugger, I don't think anybody would even try
detaching from a launched program. For a graphical debugger, yes, it
will be confusing. In case you don't need access to inferior stdio
running with "process launch --no-stdio" might be an option. Right
now, it redirects io to /dev/null, but it still sets up a controlling
pty, which means you get the SIGHUP. However, I don't think a pty is
needed in this case and it sounds like it could be a good idea to
avoid creating it. Patches welcome.

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

Re: [lldb-dev] Green Dragon LLDB Xcode build update: TSAN support

[Pavel Labath via lldb-dev]

We're not running them yet. I'd like to add that at some point, but I
haven't gotten around to that yet...

On 5 April 2016 at 09:39, Tamas Berghammer  wrote:
> I think we don't. If we consider them stable enough for enabling them on a
> buildbot AND we agree to revert changes breaking the unittests then I am
> happy with enabling them (doing it should take very little effort from our
> side). Otherwise I would prefer to wait until we can get them to a stable
> state.
>
> On Mon, Apr 4, 2016 at 10:53 PM Todd Fiala  wrote:
>>
>> One more update:
>>
>> The Green Dragon OS X LLDB builder now actually runs the gtests instead of
>> just building them.
>>
>> The gtests run as a phase right before the Python test suite.  A non-zero
>> value returning from the gtests will cause the OS X LLDB build to fail.
>> Right now, tracking down the cause of the failure will require looking at
>> the console log for the build and test job.  I'm excited to see our gtest
>> test count has gone from roughly 17  to over 100 now!
>>
>> Pavel or Tamas, are we running the gtests on the Linux buildbots?
>>
>> -Todd
>>
>> On Mon, Apr 4, 2016 at 10:49 AM, Todd Fiala  wrote:
>>>
>>> Hi all,
>>>
>>> I've made a minor change to the Green Dragon LLDB OS X Xcode build
>>> located here:
>>> http://lab.llvm.org:8080/green/job/LLDB/
>>>
>>> 1. Previously, the python test run used the default C/C++ compiler to
>>> build test inferiors.  Now it uses the just-built clang/clang++ to build
>>> test inferiors.  At some point in the future, we will change this to a
>>> matrix of important clang/clang++ versions (e.g. some number of official
>>> Xcode-released clangs).  For now, however, we'll continue to build with just
>>> one, and that one will be the one in the clang build tree.
>>>
>>> 2. The Xcode llvm/clang build step now includes compiler-rt and libcxx.
>>> This, together with the change above, will allow the newer LLDB TSAN tests
>>> to run.
>>>
>>> If you're ever curious how the Xcode build is run, it uses the build.py
>>> script in the zorg repo (http://llvm.org/svn/llvm-project/zorg/trunk) under
>>> zorg/jenkins/build.py.  The build constructs the build tree with a
>>> "derive-lldb" command, and does the Xcode build with the "lldb" command.
>>>
>>> Please let me know if you have any questions.
>>>
>>> I'll address any hiccups that may show up ASAP.
>>>
>>> Thanks!
>>> --
>>> -Todd
>>
>>
>>
>>
>> --
>> -Todd
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Green Dragon LLDB Xcode build update: TSAN support

[Pavel Labath via lldb-dev]

On 6 April 2016 at 06:23, Todd Fiala  wrote:
> Okay, thanks all.
>
> FWIW I am running them on the OS X side.  I haven't seen any stability
> problems yet.  I'd also expect them to be very stable, much more like a
> compiler test, since there are far fewer parts in a small-scoped C++ unit
> test (vs., say, our Python tests which are end-to-end and have many moving
> parts).
I've been running them locally, and I haven't noticed any flakyness.
It should be also be much easier to remove it, if we find any, because
of the smaller scope and number of tests.


>
> We've talked about it a bit over here, which I think you're alluding to,
> which is how do we handle them assuming they were treated like any other
> test (i.e. revert or fix fast if they break).  That implies we need to run
> them, which means we should make that easy.  (Particularly easy to not
> forget).  On the OS X side we currently have a target and scheme that will
> build and run them, but it's a separate target.  I haven't done anything on
> the Linux side to make that run, although plugging it into the test targets
> shouldn't be hard.
In cmake, you can run these tests with the check-lldb-unit target. I
like the idea of being able to run both, but I think we should also
keep the option of running them separately. How about:
check-lldb: runs unit and python tests
check-lldb-unit: runs unit tests only
check-lldb-XXX: runs only python tests (for some value of XXX)

>
> I don't think the gtests replace the purpose of our Python tests, but I
> think there's a wide-open place for them, particularly when initially
> testing new classes or hard-to-expose places that would be overly cumbersome
> to test (and therefore don't get tested).
+1
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Weird stop stack while hitting breakpoint

[Pavel Labath via lldb-dev]

Ok, so the reason for this behavior seems to be that the process hits
two breakpoints simultaneously:
- the breakpoint you have set and you are expecting to hit
- an internal shared library breakpoint we use to get notified of new
shared libraries

* thread #1: tid = 33390, 0x7ff7dcd9f970
ld-linux-x86-64.so.2`_dl_debug_state, name = 'a.out', stop reason =
shared-library-event
  * frame #0: 0x7ff7dcd9f970 ld-linux-x86-64.so.2`_dl_debug_state
frame #1: 0x7ff7dcda3b05
ld-linux-x86-64.so.2`___lldb_unnamed_symbol90$$ld-linux-x86-64.so.2 +
357
frame #2: 0x7ff7dcd9eff4
ld-linux-x86-64.so.2`___lldb_unnamed_symbol59$$ld-linux-x86-64.so.2 +
116
frame #3: 0x7ff7dcda33bb
ld-linux-x86-64.so.2`___lldb_unnamed_symbol88$$ld-linux-x86-64.so.2 +
171
frame #4: 0x7ff7dc5de0f2
libc.so.6`do_dlopen(ptr=0x7ffed953c6f0) + 66 at dl-libc.c:87
frame #5: 0x7ff7dcd9eff4
ld-linux-x86-64.so.2`___lldb_unnamed_symbol59$$ld-linux-x86-64.so.2 +
116
frame #6: 0x7ff7dc5de1b2 libc.so.6`__GI___libc_dlopen_mode +
47 at dl-libc.c:46
frame #7: 0x7ff7dc5de183
libc.so.6`__GI___libc_dlopen_mode(name=,
mode=) + 35 at dl-libc.c:163
frame #8: 0x7ff7dc87da43 libpthread.so.0`pthread_cancel_init +
35 at unwind-forcedunwind.c:52
frame #9: 0x7ff7dc87dc0c
libpthread.so.0`_Unwind_ForcedUnwind(exc=0x7ff7dcf8ddf0,
stop=(libpthread.so.0`unwind_stop at unwind.c:44),
stop_argument=0x7ffed953c7f0) + 60 at unwind-forcedunwind.c:129
frame #10: 0x7ff7dc87bd40
libpthread.so.0`__GI___pthread_unwind(buf=) + 64 at
unwind.c:129
frame #11: 0x7ff7dc876535 libpthread.so.0`__pthread_exit + 37
at pthreadP.h:280
frame #12: 0x7ff7dc87651d
libpthread.so.0`__pthread_exit(value=) + 13 at
pthread_exit.c:29
frame #13: 0x00400b00 a.out`main + 186
frame #14: 0x7ff7dc4c9ec5
libc.so.6`__libc_start_main(main=(a.out`main), argc=1,
argv=0x7ffed953c8a8, init=, fini=,
rtld_fini=, stack_end=0x7ffed953c898) + 245 at
libc-start.c:287
frame #15: 0x00400939 a.out`_start + 41

  thread #2: tid = 35166, 0x004009fd a.out`PrintHello(void*),
name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x004009fd a.out`PrintHello(void*)
frame #1: 0x7ff7dc875182
libpthread.so.0`start_thread(arg=0x7ff7dbf8b700) + 194 at
pthread_create.c:312
frame #2: 0x7ff7dc5a247d libc.so.6`__clone + 109 at clone.S:111


These internal breakpoints are normally ignored, but I can certainly
imagine that if you hit them concurrently with a regular breakpoint,
the thread-selecting machinery will get confused. I don't have time to
look into this more right now, but I'll get to it eventually if
someone doesn't beat me to it...


PS: Your inferior is quite strange. I am not sure you are allowed to
exit the main thread via pthread_exit(), especially when you still
have non-detached threads running...

pl


On 21 March 2016 at 05:03, Jeffrey Tan  wrote:
> Thanks guys. I tried our IDE against a sample multithreading program on Mac,
> it correctly switches selected thread to the worker thread that triggers
> breakpoint, while on Linux(CentOS release 6.7) it failed to do that. Repro
> code:
>
> =Output=
> Launch result: success
>  Listening Thread ID: 139749072582400
> running_signal wait
> stopped_signal wait
> Target event: ModulesLoaded
> Target event: ModulesLoaded
> Target event: ModulesLoaded
> Target event: ModulesLoaded
> Target event: ModulesLoaded
> Target event: ModulesLoaded
> Target event: ModulesLoaded
> Target event: ModulesLoaded
> Non stopping event:  'lldb::SBEvent *' at 0x7f19e0975990> >
> Process event: StateChanged, Running
> Stop reason: 1
> Process event: Stdout, Running
> Stop reason: 1
> Stdout:
> main() : creating thread, 0
> Process event: StateChanged, Stopped
> after wait_for_process_run_then_stop
> frame #0: 0x7fcb7259ceb0 ld-linux-x86-64.so.2`__GI__dl_debug_state
> frame #1: 0x7fcb725a0c53 ld-linux-x86-64.so.2`dl_open_worker + 499
> frame #2: 0x7fcb7259c286 ld-linux-x86-64.so.2`_dl_catch_error + 102
> frame #3: 0x7fcb725a063a ld-linux-x86-64.so.2`_dl_open + 186
> frame #4: 0x7fcb71963c60 libc.so.6`do_dlopen + 64
> frame #5: 0x7fcb7259c286 ld-linux-x86-64.so.2`_dl_catch_error + 102
> frame #6: 0x7fcb71963db7 libc.so.6`__GI___libc_dlopen_mode + 71
> frame #7: 0x7fcb71be0eec libpthread.so.0`pthread_cancel_init + 76
> frame #8: 0x7fcb71be104c libpthread.so.0`_Unwind_ForcedUnwind + 60
> frame #9: 0x7fcb71bdef60 libpthread.so.0`__GI___pthread_unwind + 64
> frame #10: 0x7fcb71bd9175 libpthread.so.0`__pthread_exit + 37
> frame #11: 0x00400ac0 threads`main + 195 at threads.cpp:31
> frame #12: 0x7fcb7185bd5d libc.so.6`__libc_start_main + 253
> frame #13: 0x004008f9 threads
>  Exiting listener thread
>
> =Inferior=
> #include 
> #include 
> #include 
>
> using namespace st

Re: [lldb-dev] Review of API and remote packets

[Pavel Labath via lldb-dev]

I think we should reuse packets from the gdb protocol whereever it
makes sense. So, if they fit your needs (and a quick glance seems to
confirm that), then I think you should use them.

On 11 April 2016 at 15:28, Ravitheja Addepally  wrote:
> Hello,
>Regarding the packet definitions for tracing, how about reusing the
> existing btrace packets ?
>
> https://sourceware.org/gdb/onlinedocs/gdb/General-Query-Packets.html#qXfer%20btrace%20read
>
> On Fri, Apr 1, 2016 at 7:13 PM, Greg Clayton  wrote:
>>
>> We also need to think about all other types of tracing. It might make more
>> sense to keep these calls on SBProcess and have the calls simply be:
>>
>>
>> lldb::SBTrace lldb::SBProcess::StartTrace(SBTraceOptions &trace_options,
>> lldb::SBError &error);
>>
>> And you would need to specify which threads in the SBTraceOptions object
>> itself?:
>>
>> SBTraceOptions trace_options;
>>
>> And then do some like:
>>
>> trace_options.SetTraceAllThreads();
>>
>> And maybe tracing all threads is the default. Or one can limit this to one
>> thread:
>>
>> trace_options.SetThreadID (tid);
>>
>> Then you start tracing using the "trace_options" which has the notion of
>> which threads to trace.
>>
>> lldb::SBError error;
>> lldb::SBTrace trace = process.StartTrace(trace_options, error);
>>
>> It really depends on how all different forms of trace are enabled for
>> different kinds of tracing. It takes kernel support to trace only specific
>> threads, but someone might be debugging a bare board that only has the
>> option tracing all threads on each core. When making an API we can't assume
>> we can limit this to any threads and even to any process.
>>
>> Greg
>>
>> > On Apr 1, 2016, at 2:00 AM, Pavel Labath  wrote:
>> >
>> > I second Greg's suggestions, and I have some thoughts of my own:
>> >
>> > - with the proposed API, it is not possible to get a trace for newly
>> > created threads - the process needs to be stopped first, so you can
>> > enable trace collection. There certainly are cases where this could be
>> > problematic, e.g. if you get a crash early during thread creation and
>> > you want to figure out how you got there. For this to work, we might
>> > need an API like
>> > SBProcess::TraceNewThreads(...)
>> > or
>> > SBProcess::TraceAllThreads(...)
>> > with the assumption that "all" also includes newly created threads in
>> > the future.
>> >
>> > I'm not saying this needs to be done in the first implementation, but
>> > I think that we should at least design the API in a way that will not
>> > make adding this unnecessarily hard in the future (e.g. the idea of
>> > returning an SBTrace object might be problematic, since you don't know
>> > if/how many threads will be created).
>> >
>> >
>> >
>> > Also, thinking about new APIs, should we have a way to mark an API as
>> > incubating/experimental? Maybe it would be good to mark these new APIs
>> > as experimental for a while, so we have an option of changing them in
>> > the future, if it turns out we have made the wrong decision. I was
>> > thinking of either a naming convention
>> > (SBThread::StartTraceExperimental) or some annotation/comment on the
>> > methods. When we are confident this design is good, we can remove the
>> > promote the api into the "stable" set.
>> >
>> > pl
>> >
>> >
>> >
>> >
>> > On 31 March 2016 at 18:59, Greg Clayton via lldb-dev
>> >  wrote:
>> >>
>> >>> On Mar 31, 2016, at 5:10 AM, Ravitheja Addepally via lldb-dev
>> >>>  wrote:
>> >>>
>> >>> Hello all,
>> >>>  I am currently working on enabling Intel (R) Processor
>> >>> Trace collection for lldb. I have done some previous discussions in this
>> >>> mailing list on this topic but just to summarize , the path we chose was 
>> >>> to
>> >>> implement raw trace collection in lldb and the trace will be decoded 
>> >>> outside
>> >>> LLDB. I wanted to expose this feature through the SB API's  and for trace
>> >>> data transfer I wish to develop new communication packets. Now I want to 
>> >>> get
>> >>> the new API's and packet specifications reviewed by the dev list. Please
>> >>> find the specification below ->
>> >>>
>> >>> lldb::SBError SBProcess::StartTrace(lldb::tid_t threadId, const
>> >>> SBTraceConfig &config)
>> >>>Start tracing for thread - threadId with trace configuration
>> >>> config.
>> >>>SBTraceConfig would contain the following fields-
>> >>>-> TraceType - ProcessorTrace, SoftwareTrace , any trace
>> >>> technology etc
>> >>>-> size of trace buffer
>> >>>-> size of meta data buffer
>> >>>Returns error in case starting trace was unsuccessful, which could
>> >>> occur by reasons such as
>> >>>picking non existent thread, target does not support TraceType
>> >>> selected etc.
>> >>
>> >> If you are going to trace on a thread, we should be putting this API on
>> >> SBThread. Also we have other config type classes in our public API and we
>> >> have suffixed them with Options so SBTraceConfig should actu

Re: [lldb-dev] [RFC] Contributing platform support for Linux on SystemZ

[Pavel Labath via lldb-dev]

Hello Ulrich,

It's exciting to see support for new platforms being added to LLDB.
I've had a brief glance at the patch set and I was surprised at how
few changes you had actually needed to make to lldb core to support
this. The patches look good at a first glance, but they will need to
be reviewed by respective code owners.

Going forward, the best way to handle this would be to create a
phabricator account and submit the patches there. This will make the
review much easier. For reviewers, you can use the CODE_OWNERS.txt
file (or just git history). If you don't know the right person, just
pick Greg Clayton for general stuff and me or Tamas Berghammer for
Linux-specific code, and we will route it further if needed.

Also, please run clang-format on your patches before submission. Let
me know if you need any help setting that up.



> This should provide complete support for debugging the base SystemZ
> platform. Not yet supported are optional features like transaction support
> (zEC12) or SIMD vector support (z13). Note that there is no instruction
> emulation, since our ABI requires that all code provides correct DWARF CFI
> in .eh_frame to support unwinding.

Is the CFI info correct at all PC locations, or only at call sites
(synchronous vs. asynchronous exceptions). If it's the latter, you may
still need to do some instruction emulation to "augment" the CFI info
for it to be usable at non-call-sites. However, that's definitely not
a blocker now...

> Looking forward to working with you on getting SystemZ support upstream! I'd
> also be happy to take on ongoing maintenance (setting up a build bot, fixing
> issues as they come up, etc ...).

Setting up a buildbot is definitely recommended and it will make
further significantly easier.

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

Re: [lldb-dev] Review of API and remote packets

[Pavel Labath via lldb-dev]

LLDB already has the QThreadSuffixSupported extension, which adds the
";thread:" suffix to a bunch of packets. We could say that if the
client requests this extension, we will support it on these packets as
well. Otherwise we fall back to the "Hg" thingy.

I haven't looked at how hard it would be to implement that...

pl

On 12 April 2016 at 09:01, Ravitheja Addepally  wrote:
> One of the downsides of using the gdb protocol is that these packets are
> stateful meaning the thread id option is not there and the word btrace
> stands for branch trace which basically suggests execution tracing.
>
> On Mon, Apr 11, 2016 at 4:50 PM, Pavel Labath  wrote:
>>
>> I think we should reuse packets from the gdb protocol whereever it
>> makes sense. So, if they fit your needs (and a quick glance seems to
>> confirm that), then I think you should use them.
>>
>> On 11 April 2016 at 15:28, Ravitheja Addepally 
>> wrote:
>> > Hello,
>> >Regarding the packet definitions for tracing, how about reusing
>> > the
>> > existing btrace packets ?
>> >
>> >
>> > https://sourceware.org/gdb/onlinedocs/gdb/General-Query-Packets.html#qXfer%20btrace%20read
>> >
>> > On Fri, Apr 1, 2016 at 7:13 PM, Greg Clayton  wrote:
>> >>
>> >> We also need to think about all other types of tracing. It might make
>> >> more
>> >> sense to keep these calls on SBProcess and have the calls simply be:
>> >>
>> >>
>> >> lldb::SBTrace lldb::SBProcess::StartTrace(SBTraceOptions
>> >> &trace_options,
>> >> lldb::SBError &error);
>> >>
>> >> And you would need to specify which threads in the SBTraceOptions
>> >> object
>> >> itself?:
>> >>
>> >> SBTraceOptions trace_options;
>> >>
>> >> And then do some like:
>> >>
>> >> trace_options.SetTraceAllThreads();
>> >>
>> >> And maybe tracing all threads is the default. Or one can limit this to
>> >> one
>> >> thread:
>> >>
>> >> trace_options.SetThreadID (tid);
>> >>
>> >> Then you start tracing using the "trace_options" which has the notion
>> >> of
>> >> which threads to trace.
>> >>
>> >> lldb::SBError error;
>> >> lldb::SBTrace trace = process.StartTrace(trace_options, error);
>> >>
>> >> It really depends on how all different forms of trace are enabled for
>> >> different kinds of tracing. It takes kernel support to trace only
>> >> specific
>> >> threads, but someone might be debugging a bare board that only has the
>> >> option tracing all threads on each core. When making an API we can't
>> >> assume
>> >> we can limit this to any threads and even to any process.
>> >>
>> >> Greg
>> >>
>> >> > On Apr 1, 2016, at 2:00 AM, Pavel Labath  wrote:
>> >> >
>> >> > I second Greg's suggestions, and I have some thoughts of my own:
>> >> >
>> >> > - with the proposed API, it is not possible to get a trace for newly
>> >> > created threads - the process needs to be stopped first, so you can
>> >> > enable trace collection. There certainly are cases where this could
>> >> > be
>> >> > problematic, e.g. if you get a crash early during thread creation and
>> >> > you want to figure out how you got there. For this to work, we might
>> >> > need an API like
>> >> > SBProcess::TraceNewThreads(...)
>> >> > or
>> >> > SBProcess::TraceAllThreads(...)
>> >> > with the assumption that "all" also includes newly created threads in
>> >> > the future.
>> >> >
>> >> > I'm not saying this needs to be done in the first implementation, but
>> >> > I think that we should at least design the API in a way that will not
>> >> > make adding this unnecessarily hard in the future (e.g. the idea of
>> >> > returning an SBTrace object might be problematic, since you don't
>> >> > know
>> >> > if/how many threads will be created).
>> >> >
>> >> >
>> >> >
>> >> > Also, thinking about new APIs, should we have a way to mark an API as
>> >> > incubating/experimental? Maybe it would be good to mark these new
>> >> > APIs
>> >> > as experimental for a while, so we have an option of changing them in
>> >> > the future, if it turns out we have made the wrong decision. I was
>> >> > thinking of either a naming convention
>> >> > (SBThread::StartTraceExperimental) or some annotation/comment on the
>> >> > methods. When we are confident this design is good, we can remove the
>> >> > promote the api into the "stable" set.
>> >> >
>> >> > pl
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > On 31 March 2016 at 18:59, Greg Clayton via lldb-dev
>> >> >  wrote:
>> >> >>
>> >> >>> On Mar 31, 2016, at 5:10 AM, Ravitheja Addepally via lldb-dev
>> >> >>>  wrote:
>> >> >>>
>> >> >>> Hello all,
>> >> >>>  I am currently working on enabling Intel (R) Processor
>> >> >>> Trace collection for lldb. I have done some previous discussions in
>> >> >>> this
>> >> >>> mailing list on this topic but just to summarize , the path we
>> >> >>> chose was to
>> >> >>> implement raw trace collection in lldb and the trace will be
>> >> >>> decoded outside
>> >> >>> LLDB. I wanted to expose this feature through the SB API's  and for
>> >> >>> trace
>> >> >>> data transfer I wis

Re: [lldb-dev] Review of API and remote packets

[Pavel Labath via lldb-dev]

Do we need the server to know about the user ids we handed out to the
SB API client? AFAIK, you cannot have multiple traces of the same
thread running concurrently, so a thread-id should uniquely identify a
trace. The user id can then stay a client thing for abstracting the
concrete implementation details. Or am I missing something here?


On 13 April 2016 at 10:10, Ravitheja Addepally  wrote:
> Hello,
>Ok for the thread id we may use this QThreadSuffixSupported extension
> but gdb packets also don't have userid support since gdb does not have the
> concept of user id for trace instances. Also gdb uses seperate packets for
> trace configuration and starting the trace.
>
> On Tue, Apr 12, 2016 at 12:26 PM, Pavel Labath  wrote:
>>
>> LLDB already has the QThreadSuffixSupported extension, which adds the
>> ";thread:" suffix to a bunch of packets. We could say that if the
>> client requests this extension, we will support it on these packets as
>> well. Otherwise we fall back to the "Hg" thingy.
>>
>> I haven't looked at how hard it would be to implement that...
>>
>> pl
>>
>> On 12 April 2016 at 09:01, Ravitheja Addepally 
>> wrote:
>> > One of the downsides of using the gdb protocol is that these packets are
>> > stateful meaning the thread id option is not there and the word btrace
>> > stands for branch trace which basically suggests execution tracing.
>> >
>> > On Mon, Apr 11, 2016 at 4:50 PM, Pavel Labath  wrote:
>> >>
>> >> I think we should reuse packets from the gdb protocol whereever it
>> >> makes sense. So, if they fit your needs (and a quick glance seems to
>> >> confirm that), then I think you should use them.
>> >>
>> >> On 11 April 2016 at 15:28, Ravitheja Addepally
>> >> 
>> >> wrote:
>> >> > Hello,
>> >> >Regarding the packet definitions for tracing, how about
>> >> > reusing
>> >> > the
>> >> > existing btrace packets ?
>> >> >
>> >> >
>> >> >
>> >> > https://sourceware.org/gdb/onlinedocs/gdb/General-Query-Packets.html#qXfer%20btrace%20read
>> >> >
>> >> > On Fri, Apr 1, 2016 at 7:13 PM, Greg Clayton 
>> >> > wrote:
>> >> >>
>> >> >> We also need to think about all other types of tracing. It might
>> >> >> make
>> >> >> more
>> >> >> sense to keep these calls on SBProcess and have the calls simply be:
>> >> >>
>> >> >>
>> >> >> lldb::SBTrace lldb::SBProcess::StartTrace(SBTraceOptions
>> >> >> &trace_options,
>> >> >> lldb::SBError &error);
>> >> >>
>> >> >> And you would need to specify which threads in the SBTraceOptions
>> >> >> object
>> >> >> itself?:
>> >> >>
>> >> >> SBTraceOptions trace_options;
>> >> >>
>> >> >> And then do some like:
>> >> >>
>> >> >> trace_options.SetTraceAllThreads();
>> >> >>
>> >> >> And maybe tracing all threads is the default. Or one can limit this
>> >> >> to
>> >> >> one
>> >> >> thread:
>> >> >>
>> >> >> trace_options.SetThreadID (tid);
>> >> >>
>> >> >> Then you start tracing using the "trace_options" which has the
>> >> >> notion
>> >> >> of
>> >> >> which threads to trace.
>> >> >>
>> >> >> lldb::SBError error;
>> >> >> lldb::SBTrace trace = process.StartTrace(trace_options, error);
>> >> >>
>> >> >> It really depends on how all different forms of trace are enabled
>> >> >> for
>> >> >> different kinds of tracing. It takes kernel support to trace only
>> >> >> specific
>> >> >> threads, but someone might be debugging a bare board that only has
>> >> >> the
>> >> >> option tracing all threads on each core. When making an API we can't
>> >> >> assume
>> >> >> we can limit this to any threads and even to any process.
>> >> >>
>> >> >> Greg
>> >> >>
>> >> >> > On Apr 1, 2016, at 2:00 AM, Pavel Labath 
>> >> >> > wrote:
>> >> >> >
>> >> >> > I second Greg's suggestions, and I have some thoughts of my own:
>> >> >> >
>> >> >> > - with the proposed API, it is not possible to get a trace for
>> >> >> > newly
>> >> >> > created threads - the process needs to be stopped first, so you
>> >> >> > can
>> >> >> > enable trace collection. There certainly are cases where this
>> >> >> > could
>> >> >> > be
>> >> >> > problematic, e.g. if you get a crash early during thread creation
>> >> >> > and
>> >> >> > you want to figure out how you got there. For this to work, we
>> >> >> > might
>> >> >> > need an API like
>> >> >> > SBProcess::TraceNewThreads(...)
>> >> >> > or
>> >> >> > SBProcess::TraceAllThreads(...)
>> >> >> > with the assumption that "all" also includes newly created threads
>> >> >> > in
>> >> >> > the future.
>> >> >> >
>> >> >> > I'm not saying this needs to be done in the first implementation,
>> >> >> > but
>> >> >> > I think that we should at least design the API in a way that will
>> >> >> > not
>> >> >> > make adding this unnecessarily hard in the future (e.g. the idea
>> >> >> > of
>> >> >> > returning an SBTrace object might be problematic, since you don't
>> >> >> > know
>> >> >> > if/how many threads will be created).
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > Also, thinking about new APIs, should we have a way to mark an API
>>

Re: [lldb-dev] Enabling logging from the host gdbserver

[Pavel Labath via lldb-dev]

Hi,

you can set environment variables when lunching the "platform"
instance to enable logging in the "gdbserver" instance:
LLDB_DEBUGSERVER_LOG_FILE=/path/to/log/file
LLDB_SERVER_LOG_CHANNELS="lldb all:gdb-remote all"

Also, depending on what you are trying to achieve, it may be easier to
run the gdbserver manually (perhaps in a debugger) and attach to it
from lldb via "process connect"...

cheers,
pl


On 18 April 2016 at 10:56, Tyro Software via lldb-dev
 wrote:
> Using lldb 3.8.0, what enables logging output from the daughter "gdbserver"
> process, e.g. with a tree of processes like this:
>
> \_ /bin/bash
>   \_ ./lldb-server platform --listen *:1234 --log-file test.log
> --log-channels lldb all:gdb-remote all
>  \_ ./lldb-server gdbserver 127.0.0.1:0 --native-regs --pipe 7
> \_ ./simple_x86
>
> generated by these lldb commands:
>
> (lldb) platform select remote-linux
> (lldb) platform connect connect://localhost:1234
> (lldb) target create simple_x86
> (lldb) process launch -s
>
> what I want to see is the lldb and gdb-remote logging from the "gdbserver"
> host but only the "platform" process output is written to the "test.log"
> file.
>
> How can I enable logging for the daughter "gdbserver"?
>
>
>
> ___
> 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] Ubuntu nightly package for lldb 3.8 has no binary

[Pavel Labath via lldb-dev]

Hi,

last time I tried the prebuilt packages (it was quite a while ago),
they did not work, but I had no time to figure out what's wrong with
them. I think it would be super-great if someone would take a look and
make sure the prebuilt lldb packages work. I haven't seen any mention
of these scripts in this forum though, so you may need to ask on
llvm-dev instead...

pl


On 27 April 2016 at 02:05, Francis Ricci via lldb-dev
 wrote:
> I'm trying to install lldb-3.8 on Ubuntu (trusty), but installing the
> lldb-3.8 packages doesn't appear to install a binary (only symlinks).
> According to dpkg -L, I have the following symlinks:
> /usr/bin/lldb-3.8 -> ../lib/llvm-3.8/bin/lldb
> /usr/lib/llvm-3.8/bin/lldb -> lldb-3.8.0
>
> /usr/lib/llvm-3.8/bin/lldb-3.8.0 does not exist, and dpkg doesn't show any
> other possible lldb binaries.
>
> I'm using:
> deb http://llvm.org/apt/trusty/ llvm-toolchain-trusty-3.8 main
> deb-src http://llvm.org/apt/trusty/ llvm-toolchain-trusty-3.8 main
>
> Installing lldb-3.9 works without a problem.
>
> Is this a known problem? If you can point me to the scripts used by the
> nightly builds, I can look into it.
>
> Francis
>
> ___
> 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] Bug fixes for release_38 branch

[Pavel Labath via lldb-dev]

As Tamas said, little effort has gone into the to stabilization of the
3.8 branch. Right now, you're the only one looking into it, so I think
we'll just defer to your judgement. It is a bit of a duplication of
effort but, I think it is very worthwhile for lldb project as a whole.

For the multithreaded dwarf parsing thing, if you are feeling
adventurous, you might want to try if r266423 fixes your problems, but
I think the idea of reverting that part is very reasonable as well.

pl


On 29 April 2016 at 19:03, Francis Ricci via lldb-dev
 wrote:
> I needed to have a (recent) branch of lldb which was stable for debugging
> across platforms (native darwin, native linux, android, etc). I originally
> tried using the google/stable branch (which I assume is what ships with
> Android Studio), but that had some crashes with darwin debugging. I had
> assumed that the branch shipped with xcode was a private release branch.
> Since using either google/stable or release_38 would require stabilization,
> I decided that going ahead and stabilizing release_38 would probably be
> worthwhile. I assume that this would be beneficial for non-developers who
> use lldb outside of xcode/android studio as well, given that they may
> install the linux package for the most recent stable release branch.
>
> On Fri, Apr 29, 2016 at 5:28 AM Tamas Berghammer 
> wrote:
>>
>> Is there any reason you want to use the release_38 branch specifically? As
>> far as I know nobody tested it or using it in the LLDB community so it is
>> approximately as good as any random commit on master. If you are looking for
>> a reasonably stable LLDB then I think you are better off with asking for the
>> version number shipped with xcode or with Android Studio as those versions
>> are a bit more tested and it is used by some users as well.
>>
>> On Thu, Apr 28, 2016 at 8:57 PM Francis Ricci via lldb-dev
>>  wrote:
>>>
>>> Over the last month or two, I've been working to stabilize the release_38
>>> branch of lldb, and there are commits which fix bugs on this branch that I'd
>>> like to cherry-pick down. They're listed at the bottom of this message.
>>>
>>> One thing to note - r251106 is a commit I'd like to revert, instead of a
>>> cherry-pick. When we use this commit (multithreaded dwarf parsing) on the
>>> 3.8 branch, I run into a lot of dwarf assertion failures, even after
>>> cherry-picking all the dwarf fixes I could find from master. I don't see
>>> these assertion failures on master, so it's definitely an issue that's been
>>> fixed since the branch cut, but I think the best solution for the release_38
>>> branch is to disable it for now.
>>>
>>> r264810 will have a small merge conflict due to an indentation change in
>>> lldbpexpect.py
>>> r263735 will have a small merge conflict due to a whitespace change on
>>> master. Everything else should apply cleanly.
>>>
>>> Commits:
>>> r267741 Use absolute module path when possible if sent in svr4 packets
>>> r264810 Fixed the failing test TestCommandScriptImmediateOutput on MacOSX
>>> r267468 Maintain register numbering across xml include features
>>> r267467 Properly unload modules from target image list when using svr4
>>> packets
>>> r267466 Use Process Plugin register indices when communicating with
>>> remote
>>> r267463 Store absolute path for lldb executable in dotest.py
>>> r267462 Create _lldb python symlink correctly when LLVM_LIBDIR_SUFFIX is
>>> used
>>> r265422 Fix dotest.py '-p' option for multi-process mode
>>> r265420 Print environment when dumping arch triple
>>> r265419 Make sure to update Target arch if environment changed
>>> r265418 Allow gdbremote process to read modules from memory
>>> r264476 Fix FILE * leak in Python API
>>> r264351 Make File option flags consistent for Python API
>>> r263824 Fixed a bug where DW_AT_start_scope would fall through to
>>> DW_AT_artificial in SymbolFileDWARF::ParseVariableDIE(). This was caught by
>>> the clang warning that catches unannotated case fall throughs.
>>> r263735 Fix deadlock due to thread list locking in 'bt all' with obj-c
>>> r261858 Handle the case when a variable is only valid in part of the
>>> enclosing scope
>>> r261598 Fixed a problem where the DWARF for inline functions was
>>> mis-parsed.
>>> r261279 Make sure code that is in the middle of figuring out the correct
>>> architecture on attach uses the architecture it has figured out, rather than
>>> the Target's architecture, which may not have been updated to the correct
>>> value yet.
>>> r260626 Don't crash if we have a DIE that has a DW_AT_ranges attribute
>>> and yet the SymbolFileDWARF doesn't have a DebugRanges. If this happens
>>> print a nice error message to prompt the user to file a bug and attach the
>>> offending DWARF file so we can get the correct compiler fixed.
>>> r260618 Removed a bad assertion:
>>> r260322 Added code that was commented out during testing to stops
>>> template member functions from being added to class definitions (see
>>> revision 260308 for d

Re: [lldb-dev] Redundant six.py copy

[Pavel Labath via lldb-dev]

We could have a cmake option, say -DUSE_BUILTIN_SIX=true|false
(default being whatever you like, but I'd like to avoid autodetection,
as that can produce unexpected results). Distrubution maintainers can
set it to false (which will prevent six.py from being installed by
lldb altogether) and just make the lldb package depend on the six
package. People who don't want to have system dependencies in their
shipped version of lldb, can set it to true and do what they have done
so far...

pl

On 3 May 2016 at 02:20, Kamil Rytarowski via lldb-dev
 wrote:
> Having private fallback six.py will work for everybody, just it cannot
> be installed into the global path along with Python libraries:
>
> $ pkg_info -L lldb|grep six.py
> /usr/pkg/lib/python2.7/site-packages/six.py
>
> Maybe in lldb/utils/?
>
> chieftec$ pkg_info -L lldb|grep py
> /usr/pkg/lib/python2.7/site-packages/lldb/__init__.py
> /usr/pkg/lib/python2.7/site-packages/lldb/_lldb.so
> /usr/pkg/lib/python2.7/site-packages/lldb/embedded_interpreter.py
> /usr/pkg/lib/python2.7/site-packages/lldb/formatters/Logger.py
> /usr/pkg/lib/python2.7/site-packages/lldb/formatters/__init__.py
> /usr/pkg/lib/python2.7/site-packages/lldb/formatters/attrib_fromdict.py
> /usr/pkg/lib/python2.7/site-packages/lldb/formatters/cache.py
> /usr/pkg/lib/python2.7/site-packages/lldb/formatters/cpp/__init__.py
> /usr/pkg/lib/python2.7/site-packages/lldb/formatters/cpp/gnu_libstdcpp.py
> /usr/pkg/lib/python2.7/site-packages/lldb/formatters/cpp/libcxx.py
> /usr/pkg/lib/python2.7/site-packages/lldb/formatters/metrics.py
> /usr/pkg/lib/python2.7/site-packages/lldb/lldb-argdumper
> /usr/pkg/lib/python2.7/site-packages/lldb/runtime/__init__.py
> /usr/pkg/lib/python2.7/site-packages/lldb/utils/__init__.py
> /usr/pkg/lib/python2.7/site-packages/lldb/utils/symbolication.py
> /usr/pkg/lib/python2.7/site-packages/six.py
>
> On 03.05.2016 02:13, Greg Clayton via lldb-dev wrote:
>> Can we take care of this with python include path ordering? If we are on a 
>> system that has its own six.py somewhere in the python libraries, how is it 
>> picking our version incorrectly? Aren't there search paths for the modules? 
>> If so, we might need to put any compatibility modules into a specific 
>> directory and add that to the python search paths as the last path so it 
>> would always pick up any system versions or installed versions first, then 
>> fall back to our extra ones in our directories.
>>
>> Greg
>>
>>> On May 2, 2016, at 4:08 PM, Ted Woodward via lldb-dev 
>>>  wrote:
>>>
>>> This may be true, but telling my users "you have to install six" is a 
>>> non-starter.
>>>
>>> --
>>> Qualcomm Innovation Center, Inc.
>>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
>>> Linux Foundation Collaborative Project
>>>
 -Original Message-
 From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Kamil
 Rytarowski via lldb-dev
 Sent: Monday, May 02, 2016 4:36 PM
 To: Reid Kleckner 
 Cc: LLDB 
 Subject: Re: [lldb-dev] Redundant six.py copy



 On 02.05.2016 18:40, Reid Kleckner wrote:
> On Sun, May 1, 2016 at 2:21 PM, Kamil Rytarowski via lldb-dev
> mailto:lldb-dev@lists.llvm.org>> wrote:
>
>It has been noted that LLDB installs its own copy of six.py
>(third_party/Python/module/six/six.py) that conflicts with a
 standalone
>one lang/py-six (path in pkgsrc).
>
>Could we reuse an external version shipped with a system?
 Alternatively
>are there plans to migrate to Python 3 and remove need for it?
>
>How to address this conflict cleanly?
>
>
> LLDB should continue to ship its own copy of six.py. It's a single 900
> line source file. Avoiding this duplication is not worth the headache
> of asking users to install dependencies. I can't imagine a world where
> checking in your own copy *wasn't* the intended distribution model for
> six.py.
>

 I don't agree here, built in libraries have security and maintainability 
 issues
 downstream. Correct packaging is about removing these builtin redundant
 libraries and link with upstream ones. And in case of a vulnerability (or 
 other
 kind of bug) upgrade a dependency for everybody at once.

> I'm sure LLDB would take patches to mitigate the namespace conflict.
> For example, LLDB could do something like "from lldbutils import six"
> instead of "import six", or we could avoid putting it on sys.path if
> we notice a system installation of six.

 Dynamic detection of system capabilities isn't reproducible. Also there is 
 a
 scenario of installing lldb and later one of other packages installing 
 global py-
 six.
>>>
>>>
>>> ___
>>> lldb-dev mailing list
>>> lldb-dev@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>> _

Re: [lldb-dev] [cfe-dev] [llvm-dev] Fwd: Raising CMake minimum version to 3.4.3

[Pavel Labath via lldb-dev]

Adding lldb-dev to the loop. I don't think there should be major
issues there as lldb supports a strict subset targets, just making
sure everyone is aware of the plans.

Our team manages a couple of lldb buildbots still using cmake 2.8.
We'll get started on upgrading them though.

pl

On 5 May 2016 at 01:08, Galina Kistanova via cfe-dev
 wrote:
> This sounds good to me.
> I have planned the update.
>
> Thanks
>
> Galina
>
> On Wed, May 4, 2016 at 9:50 AM, Mike Edwards via llvm-dev
>  wrote:
>>
>> Chris,
>> We have upgrade our bots (both internal and external) to CMake 3.5.2.  So
>> we are good to go.
>>
>> -Mike
>>
>> On Tue, May 3, 2016 at 12:29 PM, Chris Bieneman via llvm-dev
>>  wrote:
>>>
>>> Renato,
>>>
>>> This approach sounds great to me.
>>>
>>> Chris M let me know separately that GreenDragon is on CMake 3.5.
>>>
>>> I belive Galina and Takumi maintain the largest chunk of remaining public
>>> bots. Do either of you have any thoughts on this?
>>>
>>> Thanks,
>>> -Chris
>>>
>>> > On May 3, 2016, at 11:19 AM, Renato Golin 
>>> > wrote:
>>> >
>>> > On 3 May 2016 at 17:07, Chris Bieneman via cfe-dev
>>> >  wrote:
>>> >> Since there seems to be no strong objections remaining I’d like to
>>> >> propose the following timeline and process:
>>> >>
>>> >> 4/23 - I will send another follow-up email reminding everyone of this
>>> >> change and timeline
>>> >> 4/30 - I will send a final notice an hour before making the change to
>>> >> the LLVM, Clang, Compiler-RT, Clang-Tools-Extra, LibCXX, LibCXXABI and
>>> >> Test-Suite repos
>>> >>
>>> >> During the week of 4/30 I will revert as necessary if bots fail.
>>> >> Hopefully having the change permanently landed by the middle of the week.
>>> >>
>>> >> Does this sound agreeable to everyone?
>>> >
>>> > I'd like to propose a different approach. How about we do this the
>>> > other way around? Maybe we should try the "move first, fix later",
>>> > than the "break first, despair later".
>>> >
>>> > This week we (Linaro) have finished our buildbot migration, all of
>>> > them running on CMake 3.4.3. I'd like to see if other bot maintainers
>>> > could take the same effort before a certain date.
>>> >
>>> > So, we can still have the same dates (in May, of course), but with
>>> > different "labels":
>>> >
>>> > Soon, you send an announcement:
>>> > * Saying the consensus is to move to CMake 3.4.3 as well as a
>>> > compiled CMake for all platforms,
>>> > * That the technical reason is strong enough to do so, even if it
>>> > incurs more work to some people,
>>> > * That *ALL* bot owners should migrate as soon as possible (no later
>>> > than 30th).
>>> >
>>> > On 23rd, you send a reminder to the list informing all bot owners that
>>> > time is running out.
>>> > * If they can't do it, who could help them
>>> > * If they need push in the CMake community, or a new stable release,
>>> > it's better to have it now than then
>>> >
>>> > On 30th, you do the migration as you proposed.
>>> >
>>> > It's all the same, but with the difference that we're involving all
>>> > bot owners, and hopefully not having to revert too many times such a
>>> > troublesome change (CMake changes always mess up the bots anyway).
>>> >
>>> > Anyway, for ARM/AArch64, we're good to go.
>>> >
>>> > cheers,
>>> > --renato
>>>
>>> ___
>>> LLVM Developers mailing list
>>> llvm-...@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>>
>> ___
>> LLVM Developers mailing list
>> llvm-...@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
>
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev