debugserver takes the address of a watchpoint exception and calculates
which watchpoint was responsible for it. There was an off-by-one error
in the range calculation which causes two watchpoints on consecutive
ranges to not correctly identify hits to the second watchpoint. The
result is that lldb wouldn't show the second watchpoint as ever being
hit.

Re-landing this test with a modification to only require two
watchpoints in the test, instead of four.  If four watchpoints can
be set, it will test them.

rdar://145107575

This reverts commit 21d912121c9f41385b165a736be787527f5bd7c2.

Failure on the aarch64 ubuntu bot when setting the 4th watchpoint;
may be a hardware limitation on that bot.  I thought creating four
watchpoints would be generally safe, but I don't need to do that
for my test, will re-land without it.

debugserver takes the address of a watchpoint exception and calculates
which watchpoint was responsible for it. There was an off-by-one error
in the range calculation which causes two watchpoints on consecutive
ranges to not correctly identify hits to the second watchpoint. The
result is that lldb wouldn't show the second watchpoint as ever being
hit.

rdar://145107575

Have debugserver parse the watchpoint flags out of the exception
syndrome register when we get a watchpoint mach exception.  Relay
those fields up to lldb in the stop reply packet, if the watchpoint
number was reported by the hardware, use the address from that as
the watchpoint address.

Change how watchpoints are reported to lldb from using the mach
exception data, to using the `reason:watchpoint` and `description:asciihex`
method that lldb-server uses, which can relay the actual trap address
as well as the address of a watched memory region responsible for
the trap, so lldb can step past it.

Have debugserver look for the nearest watchpoint that it has set
when it gets a watchpoint trap, so accesses that are reported as
starting before the watched region are associated with the correct
watchpoint to lldb.  Add a test case for this specific issue.

Differential Revision: https://reviews.llvm.org/D147820
rdar://83996471

Applied modernize-use-equals-default clang-tidy check over LLDB.

This check is already present in the lldb/.clang-tidy config.

Differential Revision: https://reviews.llvm.org/D121844

The C headers are deprecated so as requested in D102845, this is replacing them
all with their (not deprecated) C++ equivalent.

Reviewed By: shafik

Differential Revision: https://reviews.llvm.org/D103084

to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

*** to conform to clang-format’s LLVM style.  This kind of mass change has
*** two obvious implications:

Firstly, merging this particular commit into a downstream fork may be a huge
effort.  Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit.  The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):

    find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} +
    find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;

The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.

Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit.  There are alternatives available that will attempt
to look through this change and find the appropriate prior commit.  YMMV.

llvm-svn: 280751

llvm-svn: 231692

325,000 breakpoints for running "breakpoint set --func-regex ." on lldb itself (after hitting a breakpoint at main so that LLDB.framework is loaded) used to take up to an hour to set, now we are down under a minute. With warm file caches, we are at 40 seconds, and that is with setting 325,000 breakpoint through the GDB remote API. Linux and the native debuggers might be faster. I haven't timed what how much is debug info parsing and how much is the protocol traffic to/from GDB remote.

That there were many performance issues. Most of them were due to storing breakpoints in the wrong data structures, or using the wrong iterators to traverse the lists, traversing the lists in inefficient ways, and not optimizing certain function name lookups/symbol merges correctly.

Debugging after that is also now very efficient. There were issues with replacing the breakpoint opcodes in memory that was read, and those routines were also fixed.

llvm-svn: 183820