While fixing bugs in the x86_64 LC_THREAD parser in ObjectFileMachO, I noticed that the other LC_THREAD parsers are all less clear than they should be. To recap, a Mach-O LC_THREAD load command has a byte size for the entire payload. Within the payload, there will be one or more register sets provided. A register set starts with a UInt32 "flavor", the type of register set defined in the system headers, and a UInt32 "count", the number of UInt32 words of memory for this register set. After one register set, there may be additional sets. A parser can skip an unknown register set flavor by using the count field to get to the next register set. When the total byte size of the LC_THREAD load command has been parsed, it is completed. This patch fixes the riscv/arm/arm64 LC_THREAD parsers to use the total byte size as the exit condition, and to skip past unrecognized register sets, instead of stopping parsing. Instead of fixing the i386 corefile support, I removed it. The last macOS that supported 32-bit Intel code was macOS 10.14 in 2018. I also removed i386 KDP support, 32-bit intel kernel debugging hasn't been supported for even longer than that. It would be preferable to do these things separately, but I couldn't bring myself to update the i386 LC_THREAD parser, and it required very few changes to remove this support entirely.
lldb-server had limited support for single-stepping through the lr/sc atomic sequence. This patch enhances that support for all possible atomic sequences. The previous version contained an incorrect regex pattern in the test, causing the riscv-specific test to run on other platforms. This reland fixes the regex (see lldb/test/API/riscv/step/TestSoftwareStep.py)
In the same way that memory regions may be known from a core file but
not readable, tag segments can also have no content. For example:
```
$ readelf --segments core
<...>
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
<...>
LOAD 0x0000000000002000 0x0000ffff93899000 0x0000000000000000
0x0000000000000000 0x0000000000001000 RW 0x1000
<...>
LOPROC+0x2 0x0000000000008000 0x0000ffff93899000 0x0000000000000000
0x0000000000000000 0x0000000000001000 0x0
```
This happens if you have a restricted coredump filter or size limit.
The area of virtual memory this segment covers is 0x1000, or 4096 bytes
aka one tagged page. It's FileSiz would normally be 0x80. Tags are
packed 2 per byte and granules are 16 bytes. 4096 / 16 / 2 = 128 or
0x80.
But here it has no data, and in theory a corrupt file might have some
data but not all. This triggered an assert in
UnpackTagsFromCoreFileSegment and crashed lldb.
To fix this I have made UnpackTagsFromCoreFileSegment return an expected
and returned an error in this case instead of asserting. This will be
seen by the user, as shown in the added API test.
Reverts llvm/llvm-project#127505 because `riscv/step/TestSoftwareStep.py` is failing on the bots.
@dmpots and I were investigating a crash when he was developing LLDB earlier. When I loaded the core I was surprised to see LLDB didn't have information for the SI_CODE. Upon inspection we had an si_code of `128`, which is the decimal of SI_KERNEL at `0x80`. These were overlooked in my last addition of the negative si_codes, and this patch adds SI_USER and SI_KERNEL to the list, covering us for all the codes available to all signals. [Linux reference link](https://github.com/torvalds/linux/blob/74b4cc9b8780bfe8a3992c9ac0033bf22ac01f19/include/uapi/asm-generic/siginfo.h#L175)  I kept the code naming the same as what is defined in the Linux source code. SI_KERNEL to my understanding usually indicates something went awry in the Kernel itself, but I think adding that additional detail would not be helpful to most users. @DavidSpickett I'd appreciate your insight into that.
lldb-server had limited support for single-stepping through the lr/sc atomic sequence. This patch enhances that support for all possible atomic sequences.
The only difference from the original PR are the added BRIEF and FULL_DOCS arguments to define_property, which are required for cmake<3.23.
Causes failures on several bots. This reverts commits 714b2fdf3a385e5b9a95c435f56b1696ec3ec9e8 and e7c1da7c8ef31c258619c1668062985e7ae83b70.
Some inter-plugin dependencies are okay, others are not. Yet others not, but we're sort of stuck with them. The idea is to be able to prevent backsliding while making sure that acceptable dependencies are.. accepted. For context, see https://github.com/llvm/llvm-project/pull/139170 and the attached changes to the documentation.
Recently the Linux Kernel has fixed a bunch of issues in SME support and while testing that, I found two tests failing: FAIL: test_za_register_dynamic_config_main_disabled (TestZAThreadedDynamic.AArch64ZAThreadedTestCase) FAIL: test_za_register_dynamic_config_main_enabled (TestZAThreadedDynamic.AArch64ZAThreadedTestCase) These tests write to vg during streaming mode from lldb and expect to see that za has been resized to match it. Instead, it was unavailable. lldb-server was sending the correct amount of data but lldb client was expecting the old size. Turns out that instead of a write to vg invalidating svg, it was invalidating... something else. I'm still not sure how these tests ever worked but with this one line fix, they pass again. I did not see this issue with SVE or streaming SVE Z registers because those always resize using the value of vg, and vg always has the value we just wrote. (remember that vg is the vector length of the **current** mode, not of non-streaming mode, whereas svg is the vector length of streaming mode, even if you are currently in non-streaming mode)