Now that all uses of PThreadMutex have been migrated to their C++
equivalent, this PR removes PThreadMutex itself.

We've been dealing with UBSAN issues around this code for some time now
(see `9c36859b33b386fbfa9599646de1e2ae01158180` and
`1a2122e9e9d1d495fdf337a4a9445b61ca56df6f`). On recent macOS versions, a
UBSAN-enabled debugserver will crash when performing a `memcpy` of the
input `mach_exception_data_t`. The pointer to the beginning of the
exception data may not be aligned on a doubleword boundary, leading to
UBSAN failures such as:
```
$ ./bin/debugserver 0.0.0.0:5555 /Volumes/SSD/llvm-builds/llvm-worktrees/clang-work/build-sanitized-release/tools/lldb/test/Shell/Recognizer/Output/verbose_trap.test.tmp.out
/Volumes/SSD/llvm-builds/llvm-worktrees/clang-work/lldb/tools/debugserver/source/MacOSX/MachException.cpp:35:12: runtime error: store to misaligned address 0x00016ddfa634 for type 'mach_exception_data_type_t *' (aka 'long long *'), which requires 8 byte alignment
0x00016ddfa634: note: pointer points here
  02 00 00 00 03 00 01 00  00 00 00 00 11 00 00 00  00 00 00 00 00 00 00 00  08 00 00 00 00 00 00 00
              ^
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /Volumes/SSD/llvm-builds/llvm-worktrees/clang-work/lldb/tools/debugserver/source/MacOSX/MachException.cpp:35:12
```

Work around these failures by pretending the input data is a `char*`
buffer.

Drive-by changes:
* I factored out some duplicated code into a static
`AppendExceptionData` and made the types consistent

---------

Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>

Fixes [#85868](https://github.com/llvm/llvm-project/issues/85868)

Parenthesis are added as requested on ternary operators with non trivial conditions.

I used this [precedence table](https://en.cppreference.com/w/cpp/language/operator_precedence) for reference, to make sure we get the expected behavior on each change.

The mach exception data may not be doubleword aligned when we receive
it.  We use memcpy to align it later in this method when we save
the data, but for printing the value at the top, we need to do the
same or ubsan can trigger when LOG_EXCEPTIONS is enabled in
debugserver.

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

This reverts commit b10c2f846d936a98eecfcef1a90a754522282285.

Need to add the phabracator line to the message.

The mach exception data may not be doubleword aligned when we receive
it.  We use memcpy to align it later in this method when we save
the data, but for printing the value at the top, we need to do the
same or ubsan can trigger when LOG_EXCEPTIONS is enabled in
debugserver.

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

should not receive as exceptions (some will get converted to BSD
signals instead).  This is really the only stable way to ensure that
a Mach exception gets converted to it's equivalent BSD signal.  For
programs that rely on BSD signal handlers, this has to happen or you
can't even get the program to invoke the signal handler when under
the debugger.

This builds on a previous solution to this problem which required you
start debugserver with the -U flag.  This was not very discoverable
and required lldb be the one to launch debugserver, which is not always
the case.

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

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

Adrian's changes to support Catalyst processes and my
changes to support debugserver running on an arm64_32
device (Apple Watch Series 4, which uses an IPL32 model
on arm64 cpus).

llvm-svn: 368118