Instead of parsing the crashlog in one big loop, use methods that
correspond to the different parsing modes.
Differential revision: https://reviews.llvm.org/D90665
Python doesn't support enums before PEP 435, but using a class with
constants is how it's commonly emulated. It can be converted into a real
Enum (in Python 3.4 and later) by extending the Enum class:
class CrashLogParseMode(Enum):
NORMAL = 0
THREAD = 1
IMAGES = 2
THREGS = 3
SYSTEM = 4
INSTRS = 5
This property is explicitly for use only in the interactive editor,
and NOT in commands. It's use worked until we got more careful about
not leaving lldb.target lying around in the script interpreter.
I also added a quick sniff test for the save_crashlog command.
<rdar://problem/60350620>
Differential Revision: https://reviews.llvm.org/D80680
This is yet another change to the regular expressions in crashlog.py
that fix a few edge cases, and attempt to improve the readability
quite a bit in the process. My last change to support spaces in
filenames introduced a bug that caused the version/archspec field to
be parsed as part of the image name.
For example, in "0x1111111 - 0x22222 +MyApp Pro arm64 <01234>", the
name of the image was recognized as "MyApp Pro arm64" instead of
"MyApp Pro" with a "version" of arm64.
The bugfix makes the space following an optional field mandatory
*inside* the optional group.
rdar://problem/56883435
Differential Revision: https://reviews.llvm.org/D69871
For end-users there is no point in printing dSYM load errors for
system frameworks, since they will all fail and there's nothing they
can do about it. This patch hides them by default and shows them when
--verbose is present.
Differential Revision: https://reviews.llvm.org/D63310
llvm-svn: 363412
Generally having spurious `\n` doesn't matter, but here the
returning string is a command which is executed, so we want
to strip it. Pointed out by Jason.
llvm-svn: 358717
Summary:
The method find_matching_slice(self) uses uuid_str on one of the paths but the variable does not exist and so this results in a NameError exception if we take that path.
Differential Revision: https://reviews.llvm.org/D57467
llvm-svn: 352772
This is a little dangerous since the crashlog files aren't 100%
unambiguous, but the risk is mitigated by using a non-greedy +?
pattern.
rdar://problem/38478511
Differential Revision: https://reviews.llvm.org/D55608
llvm-svn: 349367
Often users have a crash log an d a .dSYM bundle, but not the original
application binary. It turns out that for crash symbolication, we can
safely fall back to using the binary inside the .dSYM bundle.
Differential Revision: https://reviews.llvm.org/D55607
llvm-svn: 349366
*** 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
version of this script. We picked up a bug at some point in March
where scripts that fail to call SBDebugger::Destroy() will crash
in the Debugger C++ dtor. I want to track the change down which
introduced the change - but this script should be calling
SBDebugger::Destroy() in the first place, so do that.
llvm-svn: 233779
SBTarget::AddModule(const char *path,
const char *triple,
const char *uuid_cstr,
const char *symfile);
If "symfile" was filled in, it would cause us to not correctly add the module. Same goes for:
SBTarget::AddModule(SBModuleSpec ...)
Where you filled in the symfile.
<rdar://problem/16529799>
llvm-svn: 205750
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
Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes:
- Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file".
- modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly
- Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was.
- modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile()
Cleaned up header includes a bit as well.
llvm-svn: 162860
(lldb) script import lldb.macosx.crashlog
(lldb) crashlog -i /tmp/*.crash
% symbolicate --crashed-only
This will symbolicate all of the crash logs only for the crashed thread.
Also print out the crash log index number in the output of the interactive "image" command:
(lldb) script import lldb.macosx.crashlog
(lldb) crashlog -i /tmp/*.crash
% image LLDB.framework
...
This then allows you to symbolicate a crash log by index accurately when you looked for an image of a specific version
llvm-svn: 160316
Also made the symbolication of the crash logs more efficient when using the "--crashed-only" ("-c") option where only the crashed thread is symbolicated. We now only download the images for the frames in the crashed thread.
llvm-svn: 160160
Modified the crashlog darwin module to always create a uuid.UUID object when making the symbolication.Image objects. Also modified it to handle some more types of crash log files and improved the register reading for thread registers of crashed threads.
llvm-svn: 156596
% PYTHONPATH=./build/Debug/LLDB.framework/Resources/Python ; ./build/Debug//LLDB.framework/Resources/Python/lldb/macosx/crashlog.py -i ~/Downloads/crashes2/*.crash )
then you get an interactive prompt where you can search for data within all crash logs. For example you can do:
% list
which will list all crash logs
And you can search for all images given an image basename, or full path:
% image LLDB
% image /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/LLDB
% image LLDB.framework
Which would all produce an output listing like:
40CD4430-7D27-3248-BE4C-71B1F36FC5D0 (1.132 - 132) /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/LLDB, __TEXT=[0x000000011f8bc000 - 0x0000000120d3efbf)
B727A528-FF1F-3B20-9E4F-BBE96C7D922D (1.136 - 136) /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/LLDB, __TEXT=[0x000000011e7f7000 - 0x000000011fc7ff87)
4D6F8DC2-5757-39C7-96B0-1A5B5171DC6B (1.137 - 137) /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/LLDB, __TEXT=[0x000000012bd7f000 - 0x000000012d1fcfef)
FBF8786F-92B9-31E3-8BCD-A82148338966 (1.137 - 137) /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/LLDB, __TEXT=[0x0000000122d78000 - 0x00000001241f5fd7)
7AE082E3-3BB7-3F64-A308-063E559DFC45 (1.143 - 143) /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/LLDB, __TEXT=[0x0000000119b8d000 - 0x000000011b02ef5f)
7AE082E3-3BB7-3F64-A308-063E559DFC45 (1.143 - 143) /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/LLDB, __TEXT=[0x0000000111497000 - 0x0000000112938f5f)
7AE082E3-3BB7-3F64-A308-063E559DFC45 (1.143 - 143) /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/LLDB, __TEXT=[0x0000000116680000 - 0x0000000117b21f5f)
llvm-svn: 156201
Cleaned up the lldb.utils.symbolication, lldb.macosx.heap and lldb.macosx.crashlog. The lldb.macosx.heap can now build a dylib for the current triple into a temp directory and use it from there.
llvm-svn: 155577
(lldb) file /path/to/file.so
(lldb) crashlog crash.log
....
Then if the file.so has already been loaded it will use the one that is already in LLDB without trying to match up the paths.
llvm-svn: 153075
python so that single and double quotes and other standard shell like argument
parsing happens as expected before passing stuff along to option parsing.
Also handle exceptions so that we don't accidentally exit lldb if an uncaught
exception occurs.
llvm-svn: 148623
filled out the command help and removed unused options.
Updated the command to have a "--load-all" option that will cause the target
that gets created to locate and load all images specified in the Binary Images
section of the crash log to allow for complete program state to be matched
to that of the crash log, not just the images that were in the stack frames
(the default).
llvm-svn: 148605
environment variable it set to include a path to lldb.py.
Also fixed the case where the executable can't be located and doesn't match
what is installed on the current system. It will still symbolicate the other
frames, and will just show what was originally in the crash log file.
Also removed the --crash-log option so the arguments to the "crashlog"
command are one or more paths to crash logs.
Fixed the script to "auto-install" itself when loaded from the embedded
script interpreter. Now you only need to import the module and the
command is ready for use.
llvm-svn: 148561
of the identifier name in the binary images section. Improved the regular
expression for the frames.
Added a new file "crashlog.lldb" which can be sourced with "command source"
that will import the module and set itself up to be used as a command.
llvm-svn: 148529
module (you can't import a module with a '-' in it) and also added a
Symbolcate(...) top level function so it can be imported and used as an
LLDB command.
Then you can import the module and map a "crashlog" command (for darwin
use only currently) to the python function "crashlog.Symbolicate":
(lldb) script import crashlog
(lldb) command script add -f crashlog.Symbolicate crashlog
Then use it to symbolicate:
(lldb) crashlog --crash-log /path/to/foo.crash
The crash log will then get symbolicated and inline frames will be added to
the crash log and the frames will be displayed. The crash log currently will
only try and fetch and setup the target images requires in order to do the
symbolication.
This will need to be iterated upon, but it is getting close to being useful
so I am going to check this in.
llvm-svn: 148528
Jonas Devlieghere