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.
If we're not touching them, we don't need to do anything special to pass them along -- with one important caveat: due to how cmake arguments work, the implicitly passed arguments need to be specified before arguments that we handle. This isn't particularly nice, but the alternative is enumerating all arguments that can be used by llvm_add_library and the macros it calls (it also relies on implicit passing of some arguments to llvm_process_sources).
We need to iterate through the all symbol context ranges returned by (since #126505) SymbolContext::GetAddressRange. This also includes a fix to print the function offsets as signed values. I've also wanted to check that the addresses which are in the middle of the function do *not* resolve to the function, but that's not entirely the case right now. This appears to be a separate issue though, so I've just left a TODO for now.
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.
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.
We got a bug report that the disassember output was not relocated (i.e. a load address) for a core file (like it is for a live process). It turns out this behavior it depends on whether the instructions were read from an executable file or from process memory (a core file will not typically contain the memory image for segments backed by an executable file). It's unclear whether this behavior is intentional, or if it was just trying to handle the case where we're dissassembling a module without a process, but I think it's undesirable. What makes it particularly confusing is that the instruction addresses are relocated in this case (unlike the when we don't have a process), so with large files and adresses it gets very hard to see whether the relocation has been applied or not. This patch removes the data_from_file check so that the instruction is relocated regardless of where it was read from. It will still not get relocated for the raw module use case, as those can't be relocated anywhere as they don't have a load address.
As specified in the docs, 1) raw_string_ostream is always unbuffered and 2) the underlying buffer may be used directly ( 65b13610a5226b84889b923bae884ba395ad084d for further reference ) * Don't call raw_string_ostream::flush(), which is essentially a no-op. * Avoid unneeded calls to raw_string_ostream::str(), to avoid excess indirection.