This fixes a data race between the main thread and the default event handler thread. The statusline format option value was protected by a mutex, but it was returned as a pointer, allowing one thread to access it while another was modifying it. Avoid the data race by returning format values by value instead of by pointer.
This overload is taking a StackFrame, so we just need to change how we obtain the ranges out of it. A slightly fiddly aspect is the code which tries to provide a default dissassembly range for the case where we don't have a real one. I believe this case is only relevant for symbol-based stack frames as debug info always has size/range for the functions (if it didn't we wouldn't even resolve the stack frame to a function), which is why I've split the handling of the two cases. We already have a test case for disassembly of discontinuous functions (in test/Shell/Commands/command-disassemble.s), so I'm not creating another one as this is just a slightly different entry point into the same code.
The main change is to permit the disassembler class to process/store multiple (discontinuous) ranges of addresses. The result is not ambiguous because each instruction knows its size (in addition to its address), so we can check for discontinuity by looking at whether the next instruction begins where the previous ends. This patch doesn't handle the "disassemble" CLI command, which uses a more elaborate mechanism for disassembling and printing instructions.
Lots of code around LLDB was directly accessing the target's section load list. This NFC patch makes the section load list private so the Target class can access it, but everyone else now uses accessor functions. This allows us to control the resolving of addresses and will allow for functionality in LLDB which can lazily resolve addresses in JIT plug-ins with a future patch.
When retrieving the location of the function declaration, we were dropping the file component on the floor, which resulted in an amusingly confusing situation were we displayed the file containing the implementation of the function, but used the line number of the declaration. This patch fixes that. It required a small refactor Function::GetStartLineSourceLineInfo to return a SupportFile (instead of just the file spec), which in turn necessitated changes in a couple of other places as well.
Add the ability to override the disassembly CPU and CPU features through a target setting (`target.disassembly-cpu` and `target.disassembly-features`) and a `disassemble` command option (`--cpu` and `--features`). This is especially relevant for architectures like RISC-V which relies heavily on CPU extensions. The majority of this patch is plumbing the options through. I recommend looking at DisassemblerLLVMC and the test for the observable change in behavior.
To support detecting MD5 checksum mismatches, deal with SupportFiles rather than a plain FileSpecs in the SourceManager.
This member variable is completely unused. I also don't think it makes a ton of sense since (1) The "base address" can be obtained from the first Instruction in its InstructionList, and (2) InstructionLists may not be a series of contiguous instructions (even though they are most of the time).
This is another step towards supporting DWARF5 checksums and inline source code in LLDB. This is a reland of #85468 but without the functional change of storing the support file from the line table (yet).
Reverts llvm/llvm-project#85468 because @slackito reports this broke stepping in one of their tests [1] and this patch was meant to be NFC. [1] https://github.com/llvm/llvm-project/commit/d5a277d309e92b1d3e493da6036cffdf815105b1#commitcomment-139991120