Which is also used by AArch64 and LoongArch.

To test this, I ran the test suite as usual on Arm and found no new 
failures, then ran it again with all test programs compiled with
`-mthumb`. This means the binaries will be entirely Thumb code.

Finally I tested it on AArch64, but this is mostly a build test,
as I did not run the entire test suite compiled to AArch32.

Prior to this change, these tests failed with `-mthumb`:
```
Failed Tests (14):
  lldb-api :: commands/process/reverse-continue/TestReverseContinue.py
  lldb-api :: functionalities/breakpoint/breakpoint_by_line_and_column/TestBreakpointByLineAndColumn.py
  lldb-api :: functionalities/data-formatter/data-formatter-cpp/TestDataFormatterCpp.py
  lldb-api :: functionalities/reverse-execution/TestReverseContinueBreakpoints.py
  lldb-api :: functionalities/reverse-execution/TestReverseContinueWatchpoints.py
  lldb-api :: functionalities/tail_call_frames/disambiguate_call_site/TestDisambiguateCallSite.py
  lldb-api :: functionalities/tail_call_frames/disambiguate_paths_to_common_sink/TestDisambiguatePathsToCommonSink.py
  lldb-api :: functionalities/tail_call_frames/disambiguate_tail_call_seq/TestDisambiguateTailCallSeq.py
  lldb-api :: functionalities/tail_call_frames/inlining_and_tail_calls/TestInliningAndTailCalls.py
  lldb-api :: functionalities/tail_call_frames/sbapi_support/TestTailCallFrameSBAPI.py
  lldb-api :: functionalities/tail_call_frames/thread_step_out_message/TestArtificialFrameStepOutMessage.py
  lldb-api :: functionalities/thread/jump/TestThreadJump.py
  lldb-api :: lang/c/vla/TestVLA.py
  lldb-api :: linux/sepdebugsymlink/TestTargetSymbolsSepDebugSymlink.py
```

After this change, no new failures occurred. So I am confident it is
correct / as bad as it always was.

Looking at those failures, it's a few things:
* Something in the reverse execution wrapper that I can't figure out,
but is
  likely nothing to do with the real breakpoints.
* The inability to tail call when building thumb code, because the call
goes
  via. a veneer that might do a mode switch.
* Assumptions about source locations being in specific places.

None of which are issues I feel like need fixing before doing this port.

I suspect there is redundant code in this, particularly aligning
addresses. I've not made an effort to remove it because A: I'm scared to
break Thumb support because it's not commonly used and B: it may be
there to handle clients other than LLDB, which don't align breakpoint
addresses before requesting them.

When debugging arm32 process on arm64 machine, arm64 lldb-server will
use `NativeRegisterContextLinux_arm`, but the server should keep using
64-bit ptrace commands for hardware watchpoint/breakpoint, even when
debugging a 32-bit tracee.

See:
https://github.com/torvalds/linux/commit/5d220ff9420f8b1689805ba2d938bedf9e0860a4

There have been many conditional compilation handling arm32 tracee on
arm64, but this one is missed out.

To reuse the 64-bit implementation, I separate the shared code from
`NativeRegisterContextLinux_arm64.cpp` to
`NativeRegisterContextLinux_arm64dbreg.cpp`, with other adjustments to
share data structures of debug registers.

Already removed in NativeRegisterContextDBReg.h

This patch removes register set definitions and other redundant code from
NativeRegisterContextLinux/RegisterContextPOSIX*_arm. Register sets are now
moved under RegisterInfosPOSIX_arm which now uses RegisterInfoAndSetInterface.
This is similar to what we earlier did for AArch64.

Reviewed By: labath

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

Summary:
This patch follows the spirit of D63594, and removes some null checks
for things which should be operating invariants. Specifically
{Read,Write}[GF]PR now no longer check whether the supplied buffers are
null, because they never are. After this, the Do*** versions of these
function no longer serve any purpose and are inlined into their callers.

Other cleanups are possible here too, but I am taking this one step at a
time because this involves a lot of architecture-specific code, which I
don't have the hardware to test on (I did do a build-test though).

Reviewers: mgorny, jankratochvil, omjavaid, alexandreyy, uweigand

Subscribers: nemanjai, javed.absar, kbarton, lldb-commits

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

llvm-svn: 370653

A lot of comments in LLDB are surrounded by an ASCII line to delimit the
begging and end of the comment.

Its use is not really consistent across the code base, sometimes the
lines are longer, sometimes they are shorter and sometimes they are
omitted. Furthermore, it looks kind of weird with the 80 column limit,
where the comment actually extends past the line, but not by much.
Furthermore, when /// is used for Doxygen comments, it looks
particularly odd. And when // is used, it incorrectly gives the
impression that it's actually a Doxygen comment.

I assume these lines were added to improve distinguishing between
comments and code. However, given that todays editors and IDEs do a
great job at highlighting comments, I think it's worth to drop this for
the sake of consistency. The alternative is fixing all the
inconsistencies, which would create a lot more churn.

Differential revision: https://reviews.llvm.org/D60508

llvm-svn: 358135

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

Reviewers: javed.absar

Subscribers: ki.stfu, JDevlieghere, lldb-commits

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

llvm-svn: 333399

Summary:
This commit removes the concrete_frame_idx member from
NativeRegisterContext and related functions, which was always set to
zero and never used.

I also change the native thread class to store a NativeRegisterContext
as a unique_ptr (documenting the ownership) and make sure it is always
initialized (most of the code was already blindly dereferencing the
register context pointer, assuming it would always be present -- this
makes its treatment consistent).

Reviewers: eugene, clayborg, krytarowski

Subscribers: aemerson, sdardis, nemanjai, javed.absar, arichardson, kristof.beyls, kbarton, uweigand, alexandreyy, lldb-commits

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

llvm-svn: 317881