[lldb-dev] [Bug 35228] New: TestConcurrentTwoWatchpointsOneSignal flaky on linux arm64

2017-11-07 Thread via lldb-dev 
https://bugs.llvm.org/show_bug.cgi?id=35228

Bug ID: 35228
   Summary: TestConcurrentTwoWatchpointsOneSignal flaky on linux
arm64
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: lab...@google.com
CC: llvm-b...@lists.llvm.org

I've managed to figure out *what* is happening, but right now I have no idea
why is that.

The trick here is that the variables g_sigusr1_count and g_watchme are next to
each other in memory. Due to linux ptrace limitations setting a watchpoint on
g_watchme also watches the memory covered by g_sigusr1_count. Now that normally
shouldn't matter, as we have code to recognise these "false" watchpoint hits
and ignore them. However, fun things start to happen when two threads hit the
watchpoint simultaneously (one false, one real). The abridged packet log is as
follows:

lldb<   5> send packet: $c#63
lldb<1357> read packet: $T05
lldb<  16> send packet: $jThreadsInfo#c1
lldb< 579> read packet:
$[{"name":"a.out","registers":{"29":"d0fb7f00","30":"98ffd4b77f00","31":"90fb7f00","32":"ec55d0b77f00"}],"tid":3072}],{"description":"366504129148
3
366504129148","name":"a.out","reason":"watchpoint","registers":{"29":"90e465b77f00","30":"7c325900","31":"40e465b77f00","32":"e8a15500"}],"signal":5,"tid":3075}],{"description":"366504129148
3
366504129144","name":"a.out","reason":"watchpoint","registers":{"29":"901456b77f00","30":"78325900","31":"401456b77f00","32":"e0a05500"}],"signal":5,"tid":3076}]]#b9
=== two threads hit the watchpoint: one false-positive, one real
lldb<  19> send packet: $z2,59327c,4#79
lldb<   6> read packet: $OK#9a
lldb<  16> send packet: $vCont;s:0c03#e8
lldb<1187> read packet: $T05
= disable watch, single step on first thread
lldb<  16> send packet: $vCont;s:0c04#e9
lldb<1089> read packet: $T05
= single step on second thread
lldb<  19> send packet: $Z2,59327c,4#59
lldb<   6> read packet: $OK#9a
lldb<  19> send packet: $z2,59327c,4#79
lldb<   6> read packet: $OK#9a
lldb<  19> send packet: $Z2,59327c,4#59
lldb<   6> read packet: $OK#9a
lldb<  19> send packet: $z2,59327c,4#79
lldb<   6> read packet: $OK#9a
lldb<  19> send packet: $x...
lldb<2052> read packet: $...
= twidlling the watchpoint(), then reading the variable memory 
lldb<  19> send packet: $Z2,59327c,4#59
lldb<   6> read packet: $OK#9a
lldb<  19> send packet: $z2,59327c,4#79
lldb<   6> read packet: $OK#9a
lldb<  16> send packet: $vCont;s:0c04#e9
lldb<1089> read packet: $T05
= more twiddling, then another single step (!). At this point we are
definitely doing something wrong. There is no need for two single-steps on the
second thread
lldb<  19> send packet: $Z2,59327c,4#59
lldb<   6> read packet: $OK#9a
lldb<  19> send packet: $z2,59327c,4#79
lldb<   6> read packet: $OK#9a
lldb<  19> send packet: $Z2,59327c,4#59
lldb<   6> read packet: $OK#9a
Process 3072 stopped
  thread #2, name = 'a.out', stop reason = trace
frame #0: 0x0055a1ec
a.out`watchpoint_func(input=0x) at main.cpp:79
   76   do_action_args(input);
   77   
   78   g_watchme = 1; // watchpoint triggers here
-> 79   return 0;
   80   }
   81   
   82   void *
* thread #3, name = 'a.out', stop reason = watchpoint 1
frame #0: 0x0055a0e8 a.out`signal_func(input=0x007fb75614b0) at
main.cpp:70
   67   // pthread_kill(pthread_self(), SIGUSR1);
   68   
   69   g_sigusr1_count += 1;
-> 70   return 0;
   71   }
   72   
   73   void *
= now lldb reports the watchpoint hit on the "false" thread, whereas the
thread that really hit the watchpoint reports stop_reason=trace :/

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

Re: [lldb-dev] Bot failure with new "in tree compiler" changes (r316728) in llvm.org bot

2017-11-07 Thread Zachary Turner via lldb-dev 
Yea, adding a FORCE for a day or two and then removing the FORCE several
days later is a good way to handle this kind of thing.

On Tue, Nov 7, 2017 at 10:42 AM Reid Kleckner via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> In general, please try to structure changes so that CMake cache clobbers
> aren't necessary. If you introduce changes that require clobbers by
> accident, consider adding some temporary CMake logic to help buildbots
> recover on their own. Some temporary CMake hacks can save a lot of time
> across all the folks that have to discover and debug this problem.
>
> On Tue, Nov 7, 2017 at 10:28 AM, Pavel Labath via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> You probably just need to nuke the build folder.
>>
>> The reason for that is that before the patch the LLDB_TEST_C_COMPILER
>> variable was used for a different purpose (and usually empty), where
>> as now it's set by default to the in-tree clang. However, cmake will
>> not overwrite the cached value by design. (I could have worked around
>> that in cmake, but I only noticed that issue after landing the
>> change.)
>>
>> Erasing the build folder should let the new and correct default kick
>> in. If you run the check-lldb target then it will now use the in-tree
>> clang instead of the system compiler for using tests.
>>
>> sorry about the trouble,
>> pl
>>
>>
>>
>> On 7 November 2017 at 18:21, Jim Ingham via lldb-dev
>>  wrote:
>> > The lldb_cmake GreenDragon bot is now failing, e.g.:
>> >
>> >
>> http://lab.llvm.org:8080/green/view/LLDB/job/lldb_cmake/1703/consoleFull#589016626e9a0fee5-ebcc-4238-a641-c5aa112c323e
>> >
>> > This looks related to Pavel's change:
>> >
>> >> r316728 | labath | 2017-10-26 19:24:04 -0700 (Thu, 26 Oct 2017) | 18
>> lines
>> >>
>> >> Default to using in-tree clang for building test executables
>> >>
>> >> Summary:
>> >> Using the in-tree clang should be the default test configuration as
>> that
>> >> is the one compiler that we can be sure everyone has (better
>> >> reproducibility of test results). Also, it should hopefully reduce the
>> >> impact of pr35040.
>> >>
>> >> This also reduces the number of settings which control the compiler
>> >> used. LLDB_TEST_C_COMPILER is used for C files and
>> >> LLDB_TEST_CXX_COMPILER for C++ files. Both of the settings default to
>> >> the in-tree clang.
>> >>
>> >> Reviewers: zturner
>> >>
>> >> Subscribers: mgorny, davide, lldb-commits
>> >>
>> >> Differential Revision: https://reviews.llvm.org/D39215
>> >>
>> >
>> > The error is:
>> >
>> > CMake Error at tools/lldb/CMakeLists.txt:78 (message):
>> >
>> >   LLDB test compilers not specified.  Tests will not run
>> >
>> >
>> > Does the bot need to be reconfigured for these changes?
>> >
>> > Jim
>> >
>> > ___
>> > 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] Bot failure with new "in tree compiler" changes (r316728) in llvm.org bot

2017-11-07 Thread Reid Kleckner via lldb-dev 
In general, please try to structure changes so that CMake cache clobbers
aren't necessary. If you introduce changes that require clobbers by
accident, consider adding some temporary CMake logic to help buildbots
recover on their own. Some temporary CMake hacks can save a lot of time
across all the folks that have to discover and debug this problem.

On Tue, Nov 7, 2017 at 10:28 AM, Pavel Labath via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> You probably just need to nuke the build folder.
>
> The reason for that is that before the patch the LLDB_TEST_C_COMPILER
> variable was used for a different purpose (and usually empty), where
> as now it's set by default to the in-tree clang. However, cmake will
> not overwrite the cached value by design. (I could have worked around
> that in cmake, but I only noticed that issue after landing the
> change.)
>
> Erasing the build folder should let the new and correct default kick
> in. If you run the check-lldb target then it will now use the in-tree
> clang instead of the system compiler for using tests.
>
> sorry about the trouble,
> pl
>
>
>
> On 7 November 2017 at 18:21, Jim Ingham via lldb-dev
>  wrote:
> > The lldb_cmake GreenDragon bot is now failing, e.g.:
> >
> > http://lab.llvm.org:8080/green/view/LLDB/job/lldb_
> cmake/1703/consoleFull#589016626e9a0fee5-ebcc-4238-a641-c5aa112c323e
> >
> > This looks related to Pavel's change:
> >
> >> r316728 | labath | 2017-10-26 19:24:04 -0700 (Thu, 26 Oct 2017) | 18
> lines
> >>
> >> Default to using in-tree clang for building test executables
> >>
> >> Summary:
> >> Using the in-tree clang should be the default test configuration as that
> >> is the one compiler that we can be sure everyone has (better
> >> reproducibility of test results). Also, it should hopefully reduce the
> >> impact of pr35040.
> >>
> >> This also reduces the number of settings which control the compiler
> >> used. LLDB_TEST_C_COMPILER is used for C files and
> >> LLDB_TEST_CXX_COMPILER for C++ files. Both of the settings default to
> >> the in-tree clang.
> >>
> >> Reviewers: zturner
> >>
> >> Subscribers: mgorny, davide, lldb-commits
> >>
> >> Differential Revision: https://reviews.llvm.org/D39215
> >>
> >
> > The error is:
> >
> > CMake Error at tools/lldb/CMakeLists.txt:78 (message):
> >
> >   LLDB test compilers not specified.  Tests will not run
> >
> >
> > Does the bot need to be reconfigured for these changes?
> >
> > Jim
> >
> > ___
> > 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] Bot failure with new "in tree compiler" changes (r316728) in llvm.org bot

2017-11-07 Thread Jim Ingham via lldb-dev 
Good news.  I got somebody to kick the llvm.org bots, so sounds like this 
should solve the problem.

Jim


> On Nov 7, 2017, at 10:36 AM, Ted Woodward  wrote:
> 
> We had the same problem internally on our bots. A clean build blew away the 
> cmake caches and fixed the problem.
>  
> Ted
> --
> 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 Don 
> Hinton via lldb-dev
> Sent: Tuesday, November 07, 2017 12:28 PM
> To: Jim Ingham 
> Cc: LLDB 
> Subject: Re: [lldb-dev] Bot failure with new "in tree compiler" changes 
> (r316728) in llvm.org bot
>  
> I hit the same problem last week.  I ended up blowing away my build 
> directory, and the problem went away.  
>  
> Probably a cache issue, but I was unable to reproduce...
>  
> On Tue, Nov 7, 2017 at 10:21 AM, Jim Ingham via lldb-dev 
>  wrote:
>> The lldb_cmake GreenDragon bot is now failing, e.g.:
>> 
>> http://lab.llvm.org:8080/green/view/LLDB/job/lldb_cmake/1703/consoleFull#589016626e9a0fee5-ebcc-4238-a641-c5aa112c323e
>> 
>> This looks related to Pavel's change:
>> 
>> > r316728 | labath | 2017-10-26 19:24:04 -0700 (Thu, 26 Oct 2017) | 18 lines
>> >
>> > Default to using in-tree clang for building test executables
>> >
>> > Summary:
>> > Using the in-tree clang should be the default test configuration as that
>> > is the one compiler that we can be sure everyone has (better
>> > reproducibility of test results). Also, it should hopefully reduce the
>> > impact of pr35040.
>> >
>> > This also reduces the number of settings which control the compiler
>> > used. LLDB_TEST_C_COMPILER is used for C files and
>> > LLDB_TEST_CXX_COMPILER for C++ files. Both of the settings default to
>> > the in-tree clang.
>> >
>> > Reviewers: zturner
>> >
>> > Subscribers: mgorny, davide, lldb-commits
>> >
>> > Differential Revision: https://reviews.llvm.org/D39215
>> >
>> 
>> The error is:
>> 
>> CMake Error at tools/lldb/CMakeLists.txt:78 (message):
>> 
>>   LLDB test compilers not specified.  Tests will not run
>> 
>> 
>> Does the bot need to be reconfigured for these changes?
>> 
>> Jim
>> 
>> ___
>> 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] Bot failure with new "in tree compiler" changes (r316728) in llvm.org bot

2017-11-07 Thread Ted Woodward via lldb-dev 
We had the same problem internally on our bots. A clean build blew away the 
cmake caches and fixed the problem.

 

Ted

--

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 Don Hinton 
via lldb-dev
Sent: Tuesday, November 07, 2017 12:28 PM
To: Jim Ingham 
Cc: LLDB 
Subject: Re: [lldb-dev] Bot failure with new "in tree compiler" changes 
(r316728) in llvm.org bot

 

I hit the same problem last week.  I ended up blowing away my build directory, 
and the problem went away.  

 

Probably a cache issue, but I was unable to reproduce...

 

On Tue, Nov 7, 2017 at 10:21 AM, Jim Ingham via lldb-dev 
 > wrote:

The lldb_cmake GreenDragon bot is now failing, e.g.:

http://lab.llvm.org:8080/green/view/LLDB/job/lldb_cmake/1703/consoleFull#589016626e9a0fee5-ebcc-4238-a641-c5aa112c323e

This looks related to Pavel's change:

> r316728 | labath | 2017-10-26 19:24:04 -0700 (Thu, 26 Oct 2017) | 18 lines
>
> Default to using in-tree clang for building test executables
>
> Summary:
> Using the in-tree clang should be the default test configuration as that
> is the one compiler that we can be sure everyone has (better
> reproducibility of test results). Also, it should hopefully reduce the
> impact of pr35040.
>
> This also reduces the number of settings which control the compiler
> used. LLDB_TEST_C_COMPILER is used for C files and
> LLDB_TEST_CXX_COMPILER for C++ files. Both of the settings default to
> the in-tree clang.
>
> Reviewers: zturner
>
> Subscribers: mgorny, davide, lldb-commits
>
> Differential Revision: https://reviews.llvm.org/D39215
>

The error is:

CMake Error at tools/lldb/CMakeLists.txt:78 (message):

  LLDB test compilers not specified.  Tests will not run


Does the bot need to be reconfigured for these changes?

Jim

___
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] Bot failure with new "in tree compiler" changes (r316728) in llvm.org bot

2017-11-07 Thread Jim Ingham via lldb-dev 
NP, I'll find somebody who can initiate a clean rebuild.

Jim


> On Nov 7, 2017, at 10:28 AM, Pavel Labath  wrote:
> 
> You probably just need to nuke the build folder.
> 
> The reason for that is that before the patch the LLDB_TEST_C_COMPILER
> variable was used for a different purpose (and usually empty), where
> as now it's set by default to the in-tree clang. However, cmake will
> not overwrite the cached value by design. (I could have worked around
> that in cmake, but I only noticed that issue after landing the
> change.)
> 
> Erasing the build folder should let the new and correct default kick
> in. If you run the check-lldb target then it will now use the in-tree
> clang instead of the system compiler for using tests.
> 
> sorry about the trouble,
> pl
> 
> 
> 
> On 7 November 2017 at 18:21, Jim Ingham via lldb-dev
>  wrote:
>> The lldb_cmake GreenDragon bot is now failing, e.g.:
>> 
>> http://lab.llvm.org:8080/green/view/LLDB/job/lldb_cmake/1703/consoleFull#589016626e9a0fee5-ebcc-4238-a641-c5aa112c323e
>> 
>> This looks related to Pavel's change:
>> 
>>> r316728 | labath | 2017-10-26 19:24:04 -0700 (Thu, 26 Oct 2017) | 18 lines
>>> 
>>> Default to using in-tree clang for building test executables
>>> 
>>> Summary:
>>> Using the in-tree clang should be the default test configuration as that
>>> is the one compiler that we can be sure everyone has (better
>>> reproducibility of test results). Also, it should hopefully reduce the
>>> impact of pr35040.
>>> 
>>> This also reduces the number of settings which control the compiler
>>> used. LLDB_TEST_C_COMPILER is used for C files and
>>> LLDB_TEST_CXX_COMPILER for C++ files. Both of the settings default to
>>> the in-tree clang.
>>> 
>>> Reviewers: zturner
>>> 
>>> Subscribers: mgorny, davide, lldb-commits
>>> 
>>> Differential Revision: https://reviews.llvm.org/D39215
>>> 
>> 
>> The error is:
>> 
>> CMake Error at tools/lldb/CMakeLists.txt:78 (message):
>> 
>>  LLDB test compilers not specified.  Tests will not run
>> 
>> 
>> Does the bot need to be reconfigured for these changes?
>> 
>> Jim
>> 
>> ___
>> 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] Bot failure with new "in tree compiler" changes (r316728) in llvm.org bot

2017-11-07 Thread Pavel Labath via lldb-dev 
You probably just need to nuke the build folder.

The reason for that is that before the patch the LLDB_TEST_C_COMPILER
variable was used for a different purpose (and usually empty), where
as now it's set by default to the in-tree clang. However, cmake will
not overwrite the cached value by design. (I could have worked around
that in cmake, but I only noticed that issue after landing the
change.)

Erasing the build folder should let the new and correct default kick
in. If you run the check-lldb target then it will now use the in-tree
clang instead of the system compiler for using tests.

sorry about the trouble,
pl



On 7 November 2017 at 18:21, Jim Ingham via lldb-dev
 wrote:
> The lldb_cmake GreenDragon bot is now failing, e.g.:
>
> http://lab.llvm.org:8080/green/view/LLDB/job/lldb_cmake/1703/consoleFull#589016626e9a0fee5-ebcc-4238-a641-c5aa112c323e
>
> This looks related to Pavel's change:
>
>> r316728 | labath | 2017-10-26 19:24:04 -0700 (Thu, 26 Oct 2017) | 18 lines
>>
>> Default to using in-tree clang for building test executables
>>
>> Summary:
>> Using the in-tree clang should be the default test configuration as that
>> is the one compiler that we can be sure everyone has (better
>> reproducibility of test results). Also, it should hopefully reduce the
>> impact of pr35040.
>>
>> This also reduces the number of settings which control the compiler
>> used. LLDB_TEST_C_COMPILER is used for C files and
>> LLDB_TEST_CXX_COMPILER for C++ files. Both of the settings default to
>> the in-tree clang.
>>
>> Reviewers: zturner
>>
>> Subscribers: mgorny, davide, lldb-commits
>>
>> Differential Revision: https://reviews.llvm.org/D39215
>>
>
> The error is:
>
> CMake Error at tools/lldb/CMakeLists.txt:78 (message):
>
>   LLDB test compilers not specified.  Tests will not run
>
>
> Does the bot need to be reconfigured for these changes?
>
> Jim
>
> ___
> 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] Bot failure with new "in tree compiler" changes (r316728) in llvm.org bot

2017-11-07 Thread Don Hinton via lldb-dev 
I hit the same problem last week.  I ended up blowing away my build
directory, and the problem went away.

Probably a cache issue, but I was unable to reproduce...

On Tue, Nov 7, 2017 at 10:21 AM, Jim Ingham via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> The lldb_cmake GreenDragon bot is now failing, e.g.:
>
> http://lab.llvm.org:8080/green/view/LLDB/job/lldb_cmake/1703/consoleFull#
> 589016626e9a0fee5-ebcc-4238-a641-c5aa112c323e
>
> This looks related to Pavel's change:
>
> > r316728 | labath | 2017-10-26 19:24:04 -0700 (Thu, 26 Oct 2017) | 18
> lines
> >
> > Default to using in-tree clang for building test executables
> >
> > Summary:
> > Using the in-tree clang should be the default test configuration as that
> > is the one compiler that we can be sure everyone has (better
> > reproducibility of test results). Also, it should hopefully reduce the
> > impact of pr35040.
> >
> > This also reduces the number of settings which control the compiler
> > used. LLDB_TEST_C_COMPILER is used for C files and
> > LLDB_TEST_CXX_COMPILER for C++ files. Both of the settings default to
> > the in-tree clang.
> >
> > Reviewers: zturner
> >
> > Subscribers: mgorny, davide, lldb-commits
> >
> > Differential Revision: https://reviews.llvm.org/D39215
> >
>
> The error is:
>
> CMake Error at tools/lldb/CMakeLists.txt:78 (message):
>
>   LLDB test compilers not specified.  Tests will not run
>
>
> Does the bot need to be reconfigured for these changes?
>
> Jim
>
> ___
> 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] Bot failure with new "in tree compiler" changes (r316728) in llvm.org bot

2017-11-07 Thread Jim Ingham via lldb-dev 
The lldb_cmake GreenDragon bot is now failing, e.g.:

http://lab.llvm.org:8080/green/view/LLDB/job/lldb_cmake/1703/consoleFull#589016626e9a0fee5-ebcc-4238-a641-c5aa112c323e

This looks related to Pavel's change:

> r316728 | labath | 2017-10-26 19:24:04 -0700 (Thu, 26 Oct 2017) | 18 lines
> 
> Default to using in-tree clang for building test executables
> 
> Summary:
> Using the in-tree clang should be the default test configuration as that
> is the one compiler that we can be sure everyone has (better
> reproducibility of test results). Also, it should hopefully reduce the
> impact of pr35040.
> 
> This also reduces the number of settings which control the compiler
> used. LLDB_TEST_C_COMPILER is used for C files and
> LLDB_TEST_CXX_COMPILER for C++ files. Both of the settings default to
> the in-tree clang.
> 
> Reviewers: zturner
> 
> Subscribers: mgorny, davide, lldb-commits
> 
> Differential Revision: https://reviews.llvm.org/D39215
> 

The error is:

CMake Error at tools/lldb/CMakeLists.txt:78 (message):

  LLDB test compilers not specified.  Tests will not run


Does the bot need to be reconfigured for these changes?

Jim

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

[lldb-dev] [Bug 35224] New: Watchpoint in atomic sequences are not supported on arm

2017-11-07 Thread via lldb-dev 
https://bugs.llvm.org/show_bug.cgi?id=35224

Bug ID: 35224
   Summary: Watchpoint in atomic sequences are not supported on
arm
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: lab...@google.com
CC: llvm-b...@lists.llvm.org

This example probably illustrates is best:
(lldb) b main
Breakpoint 1: where = a.out`main + 8 at a.cc:4, address = 0x06a0
(lldb) pr la
Process 28313 launched: '/tmp/a.out' (aarch64)
Process 28313 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x005556a0 a.out`main at a.cc:4
   1#include 
   2std::atomic X(0);
   3int main() {
-> 4  return X++;
   5}
(lldb) watchpoint set variable X
Watchpoint created: Watchpoint 1: addr = 0x566008 size = 4 state = enabled
type = w
declare @ '/tmp/a.cc:2'
watchpoint spec = 'X'
(lldb) c
Process 28313 resuming

Watchpoint 1 hit:
Process 28313 stopped
* thread #1, name = 'a.out', stop reason = watchpoint 1
frame #0: 0x005556f4 a.out`std::__atomic_base::operator++(int)
[inlined] std::__atomic_base::fetch_add(__m=memory_order_seq_cst, __i=1,
this=0x00566008) at atomic_base.h:621
   618_GLIBCXX_ALWAYS_INLINE __int_type
   619fetch_add(__int_type __i,
   620  memory_order __m = memory_order_seq_cst) noexcept
-> 621{ return __atomic_fetch_add(&_M_i, __i, __m); }
   622  
   623_GLIBCXX_ALWAYS_INLINE __int_type
   624fetch_add(__int_type __i,
(lldb) disassemble -f
a.out`std::__atomic_base::operator++:
0x5556bc <+0>:  subsp, sp, #0x20 ; =0x20 
0x5556c0 <+4>:  strx0, [sp, #0x8]
0x5556c4 <+8>:  strw1, [sp, #0x4]
0x5556c8 <+12>: ldrx0, [sp, #0x8]
0x5556cc <+16>: strx0, [sp, #0x18]
0x5556d0 <+20>: movw0, #0x1
0x5556d4 <+24>: strw0, [sp, #0x14]
0x5556d8 <+28>: movw0, #0x5
0x5556dc <+32>: strw0, [sp, #0x10]
0x5556e0 <+36>: ldrx0, [sp, #0x18]
0x5556e4 <+40>: ldrw1, [sp, #0x14]
0x5556e8 <+44>: ldaxr  w2, [x0]
0x5556ec <+48>: addw3, w2, w1
0x5556f0 <+52>: stlxr  w4, w3, [x0]
->  0x5556f4 <+56>: cbnz   w4, 0x5556e8  ; <+44> [inlined]
std::__atomic_base::fetch_add(int, std::memory_order) + 8 at
atomic_base.h:395
0x5556f8 <+60>: movw0, w2
0x5556fc <+64>: nop
0x555700 <+68>: addsp, sp, #0x20 ; =0x20 
0x555704 <+72>: ret
(lldb) c
Process 28313 resuming

Watchpoint 1 hit:
Process 28313 stopped
* thread #1, name = 'a.out', stop reason = watchpoint 1
frame #0: 0x005556f4 a.out`std::__atomic_base::operator++(int)
[inlined] std::__atomic_base::fetch_add(__m=memory_order_seq_cst, __i=1,
this=0x00566008) at atomic_base.h:621
   618_GLIBCXX_ALWAYS_INLINE __int_type
   619fetch_add(__int_type __i,
   620  memory_order __m = memory_order_seq_cst) noexcept
-> 621{ return __atomic_fetch_add(&_M_i, __i, __m); }
   622  
   623_GLIBCXX_ALWAYS_INLINE __int_type
   624fetch_add(__int_type __i,


Even though we report the watchpoint as "hit" the first time, the data is not
actually written to memory because the act of hitting the watchpoint interrupts
the atomic block. Therefore, the inferior enters the atomic sequence again, and
the watchpoint is "hit" again, etc.

In fact the only way to make progress here is for the user to set a breakpoint
after the atomic loop, disable the watchpoint, resume the process, and then
re-enable the watchpoint (if he needs it) after the atomic block.

It would be interesting to try to help the user by automating these actions.
The tricky part would be making sure the atomic loop does not do something
fishy while we are letting it run freely, such as transferring control flow to
a place we're not expecting, or modifying the memory we did not expect it to.

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