The maximum number of load/store watchpoints and fetch instruction
watchpoints is 14 each according to LoongArch Reference Manual [1],
so extend the maximum number of watchpoints from 8 to 14 for ptrace.

A new struct user_watch_state_v2 was added into uapi in the related
kernel commit 531936dee53e ("LoongArch: Extend the maximum number of
watchpoints") [2], but there may be no struct user_watch_state_v2 in
the system header in time.

In order to avoid undefined or redefined error, just add a new struct
loongarch_user_watch_state in LLDB which is same with the uapi struct
user_watch_state_v2, then replace the current user_watch_state with
loongarch_user_watch_state.

As far as I can tell, the only users for this struct in the userspace
are GDB and LLDB, there are no any problems of software compatibility
between the application and kernel according to the analysis.

The compatibility problem has been considered while developing and
testing. When the applications in the userspace get watchpoint state,
the length will be specified which is no bigger than the sizeof struct
user_watch_state or user_watch_state_v2, the actual length is assigned
as the minimal value of the application and kernel in the generic code
of ptrace:

```
kernel/ptrace.c: ptrace_regset():

	kiov->iov_len = min(kiov->iov_len,
                            (__kernel_size_t) (regset->n * regset->size));

	if (req == PTRACE_GETREGSET)
                return copy_regset_to_user(task, view, regset_no, 0,
                                           kiov->iov_len, kiov->iov_base);
	else
                return copy_regset_from_user(task, view, regset_no, 0,
                                             kiov->iov_len, kiov->iov_base);
```

For example, there are four kind of combinations, all of them work well.

(1) "older kernel + older app", the actual length is 8+(8+8+4+4)*8=200;
(2) "newer kernel + newer app", the actual length is 8+(8+8+4+4)*14=344;
(3) "older kernel + newer app", the actual length is 8+(8+8+4+4)*8=200;
(4) "newer kernel + older app", the actual length is 8+(8+8+4+4)*8=200.

[1]
https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#control-and-status-registers-related-to-watchpoints
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=531936dee53e

Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>

On some OS distros such as LoongArch Fedora 38 mate-5 [1], there are
no macro definitions NT_LOONGARCH_HW_BREAK and NT_LOONGARCH_HW_WATCH
in the system header, then there exist some errors when building LLDB
on LoongArch.

(1) Description of Problem:

```
llvm-project/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_loongarch64.cpp:529:16:
error: 'NT_LOONGARCH_HW_WATCH' was not declared in this scope; did you mean 'NT_LOONGARCH_LBT'?
  529 |   int regset = NT_LOONGARCH_HW_WATCH;
      |                ^~~~~~~~~~~~~~~~~~~~~
      |                NT_LOONGARCH_LBT
llvm-project/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_loongarch64.cpp:543:12:
error: 'NT_LOONGARCH_HW_BREAK' was not declared in this scope; did you mean 'NT_LOONGARCH_CSR'?
  543 |   regset = NT_LOONGARCH_HW_BREAK;
      |            ^~~~~~~~~~~~~~~~~~~~~
      |            NT_LOONGARCH_CSR
```

(2) Steps to Reproduce:

```
git clone https://github.com/llvm/llvm-project.git
mkdir -p llvm-project/llvm/build && cd llvm-project/llvm/build
cmake .. -G "Ninja" \
         -DCMAKE_BUILD_TYPE=Release \
         -DLLVM_BUILD_RUNTIME=OFF \
         -DLLVM_ENABLE_PROJECTS="clang;lldb" \
         -DCMAKE_INSTALL_PREFIX=/usr/local/llvm \
         -DLLVM_TARGETS_TO_BUILD="LoongArch" \
         -DLLVM_HOST_TRIPLE=loongarch64-redhat-linux
ninja
```

(3) Additional Info:

Maybe there are no problems on the OS distros with newer glibc devel
library, so this issue is related with OS distros.

(4) Root Cause Analysis:

This is because the related Linux kernel commit [2] was merged in
2023-02-25 and the glibc devel library has some delay with kernel,
the glibc version of specified OS distros is not updated in time.

(5) Final Solution:

One way is to ask the maintainer of OS distros to update glibc devel
library, but it is better to not depend on the glibc version.

In order to avoid the build errors, just define NT_LOONGARCH_HW_BREAK
and NT_LOONGARCH_HW_WATCH in LLDB if there are no these definitions in
the system header.

By the way, in order to fit within 80 columns, use C++-style comments
for the new added NT_LOONGARCH_HW_BREAK and NT_LOONGARCH_HW_WATCH.

While at it, for consistency, just modify the current NT_LOONGARCH_LSX
and NT_LOONGARCH_LASX to C++-style comments too.

[1]
https://mirrors.wsyu.edu.cn/fedora/linux/development/rawhide/Everything/loongarch64/iso/livecd-fedora-mate-5.loongarch64.iso
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1a69f7a161a7

Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>

With this patch, vector registers can be read and written when debugging a live process.

Note: We currently assume that all LoongArch64 processors include the
LSX and LASX extensions.

To add test cases, the following modifications were also made:
lldb/packages/Python/lldbsuite/test/lldbtest.py
lldb/packages/Python/lldbsuite/test/make/Makefile.rules

Reviewed By: DavidSpickett, SixWeining

Pull Request: https://github.com/llvm/llvm-project/pull/120664

This patch adds support for setting/clearing hardware watchpoints and
breakpoints on LoongArch 64-bit hardware.

Refer to the following document for the hw break/watchpoint:
https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#control-and-status-registers-related-to-watchpoints

Fix Failed Tests:
  lldb-shell :: Subprocess/clone-follow-child-wp.test
  lldb-shell :: Subprocess/clone-follow-parent-wp.test
  lldb-shell :: Subprocess/fork-follow-child-wp.test
  lldb-shell :: Subprocess/fork-follow-parent-wp.test
  lldb-shell :: Subprocess/vfork-follow-child-wp.test
  lldb-shell :: Subprocess/vfork-follow-parent-wp.test
  lldb-shell :: Watchpoint/ExpressionLanguage.test

Depends on: #118043

Reviewed By: SixWeining

Pull Request: https://github.com/llvm/llvm-project/pull/118770

This patch removes all of the Set.* methods from Status.

This cleanup is part of a series of patches that make it harder use the
anti-pattern of keeping a long-lives Status object around and updating
it while dropping any errors it contains on the floor.

This patch is largely NFC, the more interesting next steps this enables
is to:
1. remove Status.Clear()
2. assert that Status::operator=() never overwrites an error
3. remove Status::operator=()

Note that step (2) will bring 90% of the benefits for users, and step
(3) will dramatically clean up the error handling code in various
places. In the end my goal is to convert all APIs that are of the form

`    ResultTy DoFoo(Status& error)
`
to

`    llvm::Expected<ResultTy> DoFoo()
`
How to read this patch?

The interesting changes are in Status.h and Status.cpp, all other
changes are mostly

` perl -pi -e 's/\.SetErrorString/ = Status::FromErrorString/g' $(git
grep -l SetErrorString lldb/source)
`
plus the occasional manual cleanup.

Use the same register layout as Linux kernel, implement the
related read and write operations.

Reviewed By: SixWeining, xen0n, DavidSpickett

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

Add as little code as possible to allow compiling lldb on LoongArch.
Actual functionality will be implemented later.

Reviewed By: SixWeining, DavidSpickett

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