Co-authored-by: Eisuke Kawashima <e-kwsm@users.noreply.github.com>
This patch skips images with an empty path or a 0 UUID from loading as a SymbolFileJSON. rdar://112107986 Differential Revision: https://reviews.llvm.org/D157137 Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
Prior to this patch, when a user loaded multiple crash report in lldb, they could get in a situation where all the targets would keep the same architecture and executable path as the first one that we've created. The reason behind this was that even if we created a new CrashLog object, which is derived from a Symbolicator class that has a newly constructoted image list as a default argument, because that default argument is only created once when the function is defined, every CrashLog object would share the same list. That will cause use to append newly parsed images to the same Symbolicator image list accross multiple CrashLog objects. To address this, this patch changes the default argument value for the image parameter to `None` and only initialize it as an empty list when no argument was passed. This also removes the image list stored in each CrashLog parsers since they shouldn't have any state and should be re-usable. So now, the only source of truth is stored in the CrashLog object. rdar://84984949 Differential Revision: https://reviews.llvm.org/D157044 Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
This is an ongoing series of commits that are reformatting our Python code. Reformatting is done with `black` (23.1.0). If you end up having problems merging this commit because you have made changes to a python file, the best way to handle that is to run `git checkout --ours <yourfile>` and then reformat it with black. RFC: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style Differential revision: https://reviews.llvm.org/D151460
This patch changes the way we generate the ObjectFileJSON files containing the inlined symbols from the crash report to remove the tempfile prefix from the object file name. To do so, instead of creating a new tempfile for each module, we create a temporary directory that contains each module object file with the same name as the module. This makes the backtraces only contain the module name without the temfile prefix which makes it look like a regular stackframe. Differential Revision: https://reviews.llvm.org/D151045 Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
In 27f27d15f6c9, we added a new way to use textual (JSON) object files and symbol files with the interactive crashlog command, using the inlined symbols from the crash report. However, there was a missing piece after successfully adding the textual module to the target, we didn't mark it as available causing the module loading to exit early. This patch addresses that issue by marking the module as available when added successfully to the target. Differential Revision: https://reviews.llvm.org/D149477 Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
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
Not needed now that we require python 3. Reviewed By: kastiglione, JDevlieghere Differential Revision: https://reviews.llvm.org/D131772
When adding an image to a target for crashlog purposes, avoid specifying
the architecture of the image.
This has the effect of making SBTarget::AddModule infer the ArchSpec for
the image based on the SBTarget's architecture, which LLDB puts serious
effort into calculating correctly (in TargetList::CreateTargetInternal).
The status quo is that LLDB randomly guesses the ArchSpec for a module
if its architecture is specified, via:
```
SBTarget::AddModule -> Platform::GetAugmentedArchSpec -> Platform::IsCompatibleArchitecture ->
GetSupportedArchitectureAtIndex -> {ARM,x86}GetSupportedArchitectureAtIndex
```
... which means that the same crashlog can fail to load on an Apple
Silicon Mac (due to the random guess of arm64e-apple-macosx for the
module's ArchSpec not being compatible with the SBTarget's (correct)
ArchSpec), while loading just fine on an Intel Mac.
I'm not sure how to add a test for this (it doesn't look like there's
test coverage of this path in-tree). It seems like it would be pretty
complicated to regression test: the host LLDB would need to be built for
arm64e, we'd need a hand-crafted arm64e iOS crashlog, and we'd need a
binary with an iOS deployment target. I'm open to other / simpler
options.
rdar://82679400
Differential Revision: https://reviews.llvm.org/D110013
We found out that we have clients relying on the old signature of the Symbolicator initializer. Make the signature compatible again and provide a factory method to initialize the class correctly based on whether you have a target or want the symbolicator to create one for you. Differential revision: D92601