When a processor faults/is interrupted/gets an exception, it will stop
running code and jump to an exception catcher routine. Most processors
will store the pc that was executing in a system register, and the
catcher functions have special instructions to retrieve that & possibly
other registers. It may then save those values to stack, and the author
can add .cfi directives to tell lldb's unwinder where to find those
saved values.

ARM Cortex-M (microcontroller) processors have a simpler mechanism where
a fixed set of registers are saved to the stack on an exception, and a
unique value is put in the link register to indicate to the caller that
this has taken place. No special handling needs to be written into the
exception catcher, unless it wants to inspect these preserved values.
And it is possible for a general stack walker to walk the stack with no
special knowledge about what the catch function does.

This patch adds an Architecture plugin method to allow an Architecture
to override/augment the UnwindPlan that lldb would use for a stack
frame, given the contents of the return address register. It resembles a
feature where the LanguageRuntime can replace/augment the unwind plan
for a function, but it is doing it at offset by one level. The
LanguageRuntime is looking at the local register context and/or symbol
name to decide if it will override the unwind rules. For the Cortex-M
exception unwinds, we need to modify THIS frame's unwind plan if the
CALLER's LR had a specific value. RegisterContextUnwind has to retrieve
the caller's LR value before it has completely decided on the UnwindPlan
it will use for THIS stack frame.

This does mean that we will need one additional read of stack memory
than we currently do when unwinding, on Armv7 Cortex-M targets. The
unwinder walks the stack lazily, as stack frames are requested, and so
now if you ask for 2 stack frames, we will read enough stack to walk 2
frames, plus we will read one extra word of memory, the spilled LR value
from the stack. In practice, with 512-byte memory cache reads, this is
unlikely to be a real performance hit.

This PR includes a test with a yaml corefile description and a JSON
ObjectFile, incorporating all of the necessary stack memory and symbol
names from a real debug session I worked on. The architectural default
unwind plans are used for all stack frames except the 0th because
there's no instructions for the functions, and no unwind info. I may
need to add an encoding of unwind fules to ObjectFileJSON in the future
as we create more test cases like this.

This PR depends on the yaml2macho-core utility from
https://github.com/llvm/llvm-project/pull/153911 to run its API test.

rdar://110663219

`cfa_reg_contents` is a local variable. Whatever value we assign there
right before the `return` statement will be lost anyway.

Co-authored-by: Matej Košík <matej.kosik@codasip.com>

The test for this is artificial as I'm not aware of any upstream targets
that use DW_CFA_val_offset

RegisterContextUnwind::ReadFrameAddress now reports how it's attempting
to obtain the CFA unless all success/failure cases emit logs that
clearly identify the method it was attempting. Previously several of the
existing failure paths emit no message or a message that's
indistinguishable from those on other paths.

RegisterContextUnwind::SavedLocationForRegister is around 450 lines that
first find an abstract register location (e.g. "CFA-8") for a register
by looking in the UnwindPlans. Then it evaluates the abstract register
location to create a concrete register location (e.g. "stored at address
0x...", "live in register at frame 0"). There are some complicated cases
in the first half of the method to handle return address register
architectures correctly, in particular.

Looking at the two halves, they're both exactly 226 lines long and
there's little involvement between them except for passing an abstract
register location along.

(there were some parts in the "abstract register location" code that
would set the concrete register location, unnecessarily)

It's also a complex enough method that there are some bits of code that
aren't actually doing anything at this point.

This patch adds a RegisterContextUnwind::GetAbstractRegisterLocation
method, which does the first half, and has a clearly defined return
values.

The code to convert an AbstractRegisterLocation into a
ConcreteRegisterLocation remains in SavedLocationForRegister.

It's a bit of a tricky patch to visually inspect, despite it not
changing functionality, the reorganizations and rewrites make the diff
unreadable. Nearly all the real changes are in the "find the abstract
register location" first half of the method. I think reading the new
code in its new form is the easiest way to inspect this PR. With a
defined interface between the two of what is expected, it's pretty easy
to look at the code and reason about whether it is written correctly.

(whereas before, that was very difficult, for me at least.)

---------

Co-authored-by: Pavel Labath <pavel@labath.sk>

Basically, disable everything except the eh_frame unwind plan, as that's
the only one which supports this right now. The other plans are working
with now trying the interpret everything in between the function parts
as a part of the function, which is more likely to produce wrong results
than correct ones.

I changed the interface for object file plans, to give the
implementations a chance to implement this correctly, but I haven't
actually converted PECallFrameInfo (its only implementation) to handle
that. (from the looks of things, it should be relatively easy to do, if
it becomes necessary)

I'm also deleting UnwindPlan::GetFirstNonPrologueInsn, as it's not used,
and it doesn't work for discontinuous functions.

AddressFunctionScope was always returning the first address range of the
function (assuming it was the only one). This doesn't work for
RegisterContextUnwind (it's only caller), when the function doesn't
start at the lowest address because it throws off the 'how many bytes
"into" a function I am' computation. This patch replaces the result with
a call to (recently introduced)
SymbolContext::GetFunctionOrSymbolAddress.

Re-landing this patch with small tweaks to address CI bot failures
as it was run on many different configurations.  I think the test
may run on aarch64 Linux systems now.

When a frameless function faults or is interrupted asynchronously, the
UnwindPlan MAY have no register location rule for the return address
register (lr on arm64); the value is simply live in the lr register when
it was interrupted, and the frame below this on the stack -- e.g.
sigtramp on a Unix system -- has the full register context, including
that register.

RegisterContextUnwind::SavedLocationForRegister, when asked to find the
caller's pc value, will first see if there is a pc register location. If
there isn't, on a Return Address Register architecture like
arm/mips/riscv, we rewrite the register request from "pc" to "RA
register", and search for a location.

On frame 0 (the live frame) and an interrupted frame, the UnwindPlan may
have no register location rule for the RA Reg, that is valid. A
frameless function that never calls another may simply keep the return
address in the live register the whole way. Our instruction emulation
unwind plans explicitly add a rule (see Pavel's May 2024 change
https://github.com/llvm/llvm-project/pull/91321 ), but an UnwindPlan
sourced from debug_frame may not.

I've got a case where this exactly happens - clang debug_frame for arm64
where there is no register location for the lr in a frameless function.
There is a fault in the middle of this frameless function and we only
get the lr value from the fault handler below this frame if lr has a
register location of `IsSame`, in line with Pavel's 2024 change.

Similar to how we see a request of the RA Reg from frame 0 after failing
to find an unwind location for the pc register, the same style of
special casing is needed when this is a function that was interrupted.

Without this change, we can find the pc of the frame that was executing
when it was interrupted, but we need $lr to find its caller, and we
don't descend down to the trap handler to get that value, truncating the
stack.

rdar://145614545

This test is failing on the LLDB Incremental bot (arm64), which is
running an older set of tools (Xcode 15.2) and OS (macOS 14.1) and
the CFI directives must not be emitted correctly by either the tools
or the OS.  I will need to reproduce how this is compiling on that
older setup and see what the issue is.  Reverting for now so the
bots are not blocked.

This reverts commit e897cb139ee6ef5c145fed5394c4d96baa658e6b.