[lldb/crashlog] Skip images with empty path and 0 UUID from loading

This patch skips images with an empty path or a 0 UUID from loading as a
SymbolFileJSON.

rdar://112107986

Differential Revision:

[lldb/crashlog] Skip images with empty path and 0 UUID from loading

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>

show more ...

[lldb/crashlog] Fix sticky image parsing logic

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
architec

[lldb/crashlog] Fix sticky image parsing logic

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>

show more ...

[NFC][Py Reformat] Reformat python files in lldb

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 problem

[NFC][Py Reformat] Reformat python files in lldb

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

show more ...

[lldb/crashlog] Remove tempfile prefix from inlined symbol object file

This patch changes the way we generate the ObjectFileJSON files
containing the inlined symbols from the crash report to remove

[lldb/crashlog] Remove tempfile prefix from inlined symbol object file

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>

show more ...

[lldb/crashlog] Fix JSON ObjectFile module loading issue

In 27f27d15f6c9, we added a new way to use textual (JSON) object files
and symbol files with the interactive crashlog command, using the
inli

[lldb/crashlog] Fix JSON ObjectFile module loading issue

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>

show more ...

[lldb] Use ObjectFileJSON to create modules for interactive crashlogs

Create an artificial module using a JSON object file when we can't
locate the module and dSYM through dsymForUUID (or however
lo

[lldb] Use ObjectFileJSON to create modules for interactive crashlogs

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

show more ...

[LLDB] Remove __future__ imports from examples

Not needed now that we require python 3.

Reviewed By: kastiglione, JDevlieghere

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

[lldb][crashlog] Avoid specifying arch for image when a UUID is present

When adding an image to a target for crashlog purposes, avoid specifying
the architecture of the image.

This has the effect o

[lldb][crashlog] Avoid specifying arch for image when a UUID is present

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

show more ...

[lldb] Refactor the Symbolicator initializer

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

[lldb] Refactor the Symbolicator initializer

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

show more ...

[crashlog] Pass the debugger around instead of relying on lldb.debugger

The lldb.debugger et al convenience variables are only available from
the interactive script interpreter. In all other scenari

[crashlog] Pass the debugger around instead of relying on lldb.debugger

The lldb.debugger et al convenience variables are only available from
the interactive script interpreter. In all other scenarios, they are
None (since fc1fd6bf9fcfac412b10b4193805ec5de0e8df57) before that they
were default initialized.

The crashlog script was hacking around that by setting the lldb.debugger
to a newly created debugger instance when running outside of the script
interpreter, which works fine until lldb creates a script interpreter
instance under the hood and clears the variables. This was resulting in
an AttributeError when invoking the script directly (from outside of
lldb):

AttributeError: 'NoneType' object has no attribute 'GetSourceManager'

This patch fixes that by passing around the debugger instance.

rdar://64775776

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

show more ...

Harmonize Python shebang

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

[Symbolication] Remove some dead code. Nothing exciting.

llvm-svn: 367262

[Symbolication] Remove a duplicate assignment.

llvm-svn: 367261

[Symbolication] Fix unicode compatibility between 2 and 3.

Triples are always ASCII for now, but we were handed out a
unicode object.

<rdar://problem/53592772>

llvm-svn: 367260

[Python] Unbreak the recently modified tests for python 2.

llvm-svn: 355566

[testsuite] Port crashlog to python 3, second attempt.

llvm-svn: 355562

Revert "[testsuite] Port crashlog and dependencies to Python 3."

This revert the commit because it broke the bots. I need to find
a way that works with both versions.

llvm-svn: 355364

[testsuite] Port crashlog and dependencies to Python 3.

Fixes three tests in the testsuite.

llvm-svn: 355359

*** This commit represents a complete reformatting of the LLDB source code
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:

Firstly, merging t

*** This commit represents a complete reformatting of the LLDB source code
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:

Firstly, merging this particular commit into a downstream fork may be a huge
effort. Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit. The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):

find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} +
find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;

The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.

Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit. There are alternatives available that will attempt
to look through this change and find the appropriate prior commit. YMMV.

llvm-svn: 280751

show more ...

Fixed a few places that were building a regex from an identifier without escaping the identifier text.

<rdar://problem/26090553>

llvm-svn: 272423

Fix typos.

Summary: Another round of minor typo fixes.

Reviewers: clayborg

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D13026

llvm-svn: 248243

symbolicate the application specific backtraces that are in MacOSX crash log files.

<rdar://problem/20039160>

llvm-svn: 231415

Allow classes to be intialized using current lldb::SB objects. This can help to import/export the current process state.

llvm-svn: 209702

Update the platform options help strings.

llvm-svn: 185028

<rdar://problem/13477795>

crashlog.py was always subtracting 1 to point to the previous instruction when symbolicating ARM backtraces. Many times the backtraces will include bit zero set to 1 to ind

<rdar://problem/13477795>

crashlog.py was always subtracting 1 to point to the previous instruction when symbolicating ARM backtraces. Many times the backtraces will include bit zero set to 1 to indicate thumb, so we need to make sure we mask the address and then backup one for non frame zero frames.

llvm-svn: 178812

show more ...