llvm-project.git/lldb/test/Shell/ScriptInterpreter/Python/Crashlog/Inputs/interactive_crashlog, branch main

[lldb/crashlog] Add test for 8f75c4d01eff3c65d7ae40bfd05582de7dffa590 (NFC)

2023-08-18T19:50:39+00:00

Signed-off-by: Med Ismail Bennani

[lldb/crashlog] Add test for non-symbolicated report crash

2023-06-02T00:50:55+00:00

Signed-off-by: Med Ismail Bennani

[lldb/crashlog] Load inlined symbol into interactive crashlog

2023-05-20T03:08:18+00:00

Sometimes, crash reports come with inlined symbols. These provide the
exact stacktrace from the user binary.

However, when investigating a crash, it's very likely that the images related
to the crashed thread are not available on the debugging user system or
that the versions don't match. This causes interactive crashlog to show
a degraded backtrace in lldb.

This patch aims to address that issue, by parsing the inlined symbols
from the crash report and load them into lldb's target.

This patch is a follow-up to 27f27d1, focusing on inlined symbols
loading from legacy (non-json) crash reports.

To do so, it updates the stack frame regular expression to make the
capture groups more granular, to be able to extract the symbol name, the
offset and the source location if available, while making it more
maintainable.

So now, when parsing the crash report, we build a data structure
containing all the symbol information for each stackframe. Then, after
launching the scripted process for interactive mode, we write a JSON
symbol file for each module, only containing the symbols that it contains.

Finally, we load the json symbol file into lldb, before showing the user
the process status and backtrace.

rdar://97345586

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

Signed-off-by: Med Ismail Bennani

[lldb] Use ObjectFileJSON to create modules for interactive crashlogs

2023-04-13T23:56:29+00:00

Create an artificial module using a JSON object file when we can't
locate the module and dSYM through dsymForUUID (or however
locate_module_and_debug_symbols is implemented). By parsing the symbols
from the crashlog and making them part of the JSON object file, LLDB can
symbolicate frames it otherwise wouldn't be able to, as there is no
module for it.

For non-interactive crashlogs, that never was a problem because we could
simply show the "pre-symbolicated" frame from the input. For interactive
crashlogs, we need a way to pass the symbol information to LLDB so that
it can symbolicate the frames, which is what motivated the JSON object
file format.

Differential revision: https://reviews.llvm.org/D148172

[lldb/crashlog] Skip null image dsym fetching on interactive mode

2022-08-10T04:01:37+00:00

Sometimes, it can happen that a crash report has null images in its list
of used binaries. This manifests like such:

```
    0x0 - 0xffffffffffffffff ??? (*) <00000000-0000-0000-0000-000000000000> ???
```

When fetching debug symbols to symbolicate the crashlog stackframe,
having null images causes `dsymForUUID` to hang for few seconds.

This patch addresses that by skipping null images from being load by the
scripted process.

rdar://97419487

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

Signed-off-by: Med Ismail Bennani

[lldb/crashlog] Fix interactive crashlog test

2022-08-09T23:33:31+00:00

This patch should fix the interactive crashlog test by checking in the
binary as a yaml to regeneate the binary with the addresses and offsets
when running the test.

rdar://93655633

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

Signed-off-by: Med Ismail Bennani