Finally figured out the issue with TestCortexMExceptionUnwind.py failing on some CI. When the llvm is configured without the ARM target enabled, the ARM ABI plugins will not be initialized in lldb, and the unwind engine won't backtrace more than one stack frame. This test requires that the ARM target be enabled in the llvm cmake. Update the decorator to specify that; should be the end of these mysterious fails.
Still seeing a failure on a CI bot with this test that I cannot reproduce locally, but luckily this one CI bot is giving me trace output from the tests. Turn on the unwind log when tracing is enabled, migth get a better hint what's up with this test fail.
This test, with a corefile created via yaml2macho-core plus an ObjectFileJSON binary with symbol addresses and ranges, was failing on some machines/CI because the wrong ABI was being picked. The bytes of the functions were not included in the yaml or .json binary. The unwind falls back to using the ABI plugin default unwind plans. We have two armv7 ABIs - the Darwin ABI that always uses r7 as the frame pointer, and the AAPCS ABI which uses r11 code. In reality, armv7 code uses r11 in arm mode, r7 in thumb code. But the ABI ArchDefaultUnwindPlan doesn't have any access to the Target's ArchSpec or Process register state, to determine the correct processor state (arm or thumb). And in fact, on Cortex-M targets, the instructions are always thumb, so the arch default unwind plan (hardcoded r11) is always wrong. The corefile doesn't specify a vendor/os, only a cpu. The object file json specifies the armv7m-apple-* triple, which will select the correct ABI plugin, and the test runs. In some cases, it looks like the Process ABI was fetched after opening the corefile, but before the binary.json was loaded and corrected the Target's ArchSpec. And we never re-evaluate the ABI once it is set, in a Process. When we picked the AAPCS armv7 ABI, we would try to use r11 as frame pointer, and the unwind would stop after one stack frame. I'm stepping around this problem by (1) adding the register bytes of the prologues of every test function in the backtrace, and (2) shortening the function ranges (in binary.json) to specify that the functions are all just long enough for the prologue where execution is stopped. The instruction emulation plugin will fail if it can't get all of the bytes from the function instructions, so I hacked the function sizes in the .json to cover the prologue plus one and changed the addresses in the backtrace to fit within those ranges. [ updated this commit to keep the @skipIfRemote on the API test because two remote CI bots are failing for reasons I don't quite see. ]
This reverts commit 01a8f9b81870ac9bfe26d80fa3313d56cb8cbe13. The reason is "lldb-remote-linux-win" buildbot breakage (https://lab.llvm.org/buildbot/#/builders/197/builds/9625).
This test, with a corefile created via yaml2macho-core plus an ObjectFileJSON binary with symbol addresses and ranges, was failing on some machines/CI because the wrong ABI was being picked. The bytes of the functions were not included in the yaml or .json binary. The unwind falls back to using the ABI plugin default unwind plans. We have two armv7 ABIs - the Darwin ABI that always uses r7 as the frame pointer, and the AAPCS ABI which uses r11 code. In reality, armv7 code uses r11 in arm mode, r7 in thumb code. But the ABI ArchDefaultUnwindPlan doesn't have any access to the Target's ArchSpec or Process register state, to determine the correct processor state (arm or thumb). And in fact, on Cortex-M targets, the instructions are always thumb, so the arch default unwind plan (hardcoded r11) is always wrong. The corefile doesn't specify a vendor/os, only a cpu. The object file json specifies the armv7m-apple-* triple, which will select the correct ABI plugin, and the test runs. In some cases, it looks like the Process ABI was fetched after opening the corefile, but before the binary.json was loaded and corrected the Target's ArchSpec. And we never re-evaluate the ABI once it is set, in a Process. When we picked the AAPCS armv7 ABI, we would try to use r11 as frame pointer, and the unwind would stop after one stack frame. I'm stepping around this problem by (1) adding the register bytes of the prologues of every test function in the backtrace, and (2) shortening the function ranges (in binary.json) to specify that the functions are all just long enough for the prologue where execution is stopped. The instruction emulation plugin will fail if it can't get all of the bytes from the function instructions, so I hacked the function sizes in the .json to cover the prologue plus one and changed the addresses in the backtrace to fit within those ranges.
The lldb-remote-linux-ubuntu bot (and only this bot) is still failing for TestCortexMExceptionUnwind.py because the Target triple is somehow inheriting a non-Darwin OS. I marked this API test skipUnlessDarwin but this bot can be identified more specifically by a skipIfRemote test. There's no benefit to running this test remotely anyway; it doesn't execute any code.
This reverts commit 336503c4e1cdb5eaefde0536a34f0a95bc0c57bf.
to possibly debug why this test fails on the lldb-remote-linux-ubuntu CI bot. I'm sure the Target ArchSpec is somehow ending up _not_ armv7m-apple-* like it should be, but I'd like to gather a little more info before I just give up on running this test on linux systems.