`GetLSDAAddress` and `GetPersonalityRoutinePtrAddress` are unused and they create a bit of a problem for discontinuous functions, because the unwind plan for these consists of multiple eh_frame descriptors and (at least in theory) each of them could have a different value for these entities. We could say we only support functions for which these are always the same, or create some sort of a Address2LSDA lookup map, but I think it's better to leave this question to someone who actually needs this.
To be able to describe discontinuous functions, this patch changes the UnwindPlan to accept more than one address range. I've also squeezed in a couple improvements/modernizations, for example using the lower_bound function instead of a linear scan.
In most places, the rows are copied anyway (because they are generated by cumulating modifications) immediately after adding them to the unwind plans. In others, they can be moved into the unwind plan. This lets us remove some backflip copies and make `const UnwindPlan` actually mean something. I've split this patch into two (and temporarily left both APIs) as this patch was getting a bit big. This patch covers all the interesting cases. Part two all about converting "architecture default" unwind plans from ABI and InstructionEmulation plugins.
This patch uses the default parameters of countTrailingZeros, findFirstSet, and findLastSet, which are ZB_Width, ZB_Max, and ZB_Max, respectively.
As it exists today, Host::SystemLog is used exclusively for error reporting. With the introduction of diagnostic events, we have a better way of reporting those. Instead of printing directly to stderr, these messages now get printed to the debugger's error stream (when using the default event handler). Alternatively, if someone is listening for these events, they can decide how to display them, for example in the context of an IDE such as Xcode. This change also means we no longer write these messages to the system log on Darwin. As far as I know, nobody is relying on this, but I think this is something we could add to the diagnostic event mechanism. Differential revision: https://reviews.llvm.org/D128480
Most of our code was including Log.h even though that is not where the "lldb" log channel is defined (Log.h defines the generic logging infrastructure). This worked because Log.h included Logging.h, even though it should. After the recent refactor, it became impossible the two files include each other in this direction (the opposite inclusion is needed), so this patch removes the workaround that was put in place and cleans up all files to include the right thing. It also renames the file to LLDBLog to better reflect its purpose.