With this commit, we also hide the implementation details of
`std::invoke`. To do so, the `LibCXXFrameRecognizer` got a couple more
regular expressions.

The regular expression passed into `AddRecognizer` became problematic,
as it was evaluated on the demangled name. Those names also included
result types for C++ symbols. For `std::__invoke` the return type is a
huge `decltype(...)`, making the regular expresison really hard to
write.

Instead, I added support to `AddRecognizer` for matching on the
demangled names without result type and argument types.

By hiding the implementation details of `invoke`, also the back traces
for `std::function` become even nicer, because `std::function` is using
`__invoke` internally.

Co-authored-by: Adrian Prantl <aprantl@apple.com>

This patch hoists the `SymbolLocation` struct from the
`AssertFrameRecognizer` source file, since it's pretty generic and could
be reused for other purposes.

Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>

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.

While on regular Linux system (Fedora 34 GA, not updated):

* thread #1, name = '1', stop reason = hit program assert
    frame #0: 0x00007ffff7e242a2 libc.so.6`raise + 322
    frame #1: 0x00007ffff7e0d8a4 libc.so.6`abort + 278
    frame #2: 0x00007ffff7e0d789 libc.so.6`__assert_fail_base.cold + 15
    frame #3: 0x00007ffff7e1ca16 libc.so.6`__assert_fail + 70
  * frame #4: 0x00000000004011bd 1`main at assert.c:7:3

On Fedora 35 pre-release one gets:

* thread #1, name = '1', stop reason = signal SIGABRT
  * frame #0: 0x00007ffff7e48ee3 libc.so.6`pthread_kill@GLIBC_2.2.5 + 67
    frame #1: 0x00007ffff7dfb986 libc.so.6`raise + 22
    frame #2: 0x00007ffff7de5806 libc.so.6`abort + 230
    frame #3: 0x00007ffff7de571b libc.so.6`__assert_fail_base.cold + 15
    frame #4: 0x00007ffff7df4646 libc.so.6`__assert_fail + 70
    frame #5: 0x00000000004011bd 1`main at assert.c:7:3

I did not write a testcase as one needs the specific glibc. An
artificial test would just copy the changed source.

Reviewed By: mib

Differential Revision: https://reviews.llvm.org/D105133

I only have a crash report for this.  I could reproduce it with a slightly older
lldb by running an expression that called pthread_kill, but we started making modules
for our expression JIT code, so that no longer triggers the bug.  I can't think of another
good way to test it but the fix is obvious.

Summary:

Currently the frame recognizers are stored in a global list (the list in the
StackFrameRecognizersManagerImpl singleton to be precise). All commands and
plugins that modify the list are just modifying that global list of recognizers
which is shared by all Target and Debugger instances.

This is clearly against the idea of LLDB being usable as a library and it also
leads to some very obscure errors as now multiple tests are sharing the used
frame recognizers. For example D83400 is currently failing as it reorders some
test_ functions which permanently changes the frame recognizers of all
debuggers/targets. As all frame recognizers are also initialized in a 'once'
guard, it's also impossible to every restore back the original frame recognizers
once they are deleted in a process.

This patch just moves the frame recognizers into the current target. This seems
the way everyone assumes the system works as for example the assert frame
recognizers is using the current target to find the function/so-name to look for
(which only works if the recognizers are stored in the target).

Reviewers: jingham, mib

Reviewed By: jingham, mib

Subscribers: MrHate, JDevlieghere

Differential Revision: https://reviews.llvm.org/D83757

This patch changes the way the StackFrame Recognizers match a certain
frame.

Until now, recognizers could be registered with a function
name but also an alternate symbol.
This change is motivated by a test failure for the Assert frame
recognizer on Linux. Depending the version of the libc, the abort
function (triggered by an assertion), could have more than two
signatures (i.e. `raise`, `__GI_raise` and `gsignal`).

Instead of only checking the default symbol name and the alternate one,
lldb will iterate over a list of symbols to match against.

rdar://60386577

Differential Revision: https://reviews.llvm.org/D76188

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>

This reimplements commit 6b2979c12300b90a1e69791d43ee9cff14f4265e and updates
the tests to reflect the addition of the alternate symbol attribute.

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>

This reverts commit 1a39f1b966a8d8f15ed0d5a832d5097cccefe93b as
it breaks macOS.