| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
There's no need to repeat this work in the loop.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The in_call_stack Python script makes it possible to modify the last
breakpoint to only stop if a given function is present in the call
stack. It will check both the symbol name and the function name (coming
from the debug info, in case the binary is stripped).
To use this, you have to:
1. Import the script into lldb.
(lldb) command script import in_call_stack.py
2. Set a breakpoint and use the in_call_stack alias.
(lldb) b foo
(lldb) in_call_stack bar
Note that this alias operates on the last set breakpoint. You can re-run
the in_call_stack command to modify the condition.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 367262
|
|
|
|
| |
llvm-svn: 367261
|
|
|
|
|
|
|
|
|
| |
Triples are always ASCII for now, but we were handed out a
unicode object.
<rdar://problem/53592772>
llvm-svn: 367260
|
|
|
|
|
|
|
|
|
| |
The functions in read_plist() want bytes as input, not
strings.
<rdar://problem/52600712>
llvm-svn: 365416
|
|
|
|
|
|
| |
target definition files, like Davide's change to x86_64_target_definition.py.
llvm-svn: 364481
|
|
|
|
|
|
|
|
| |
This forces integer division and works with python 2 and python 3.
<rdar://problem/52073911>
llvm-svn: 364465
|
|
|
|
|
|
|
|
| |
rdar://problem/51464644
Differential Revision: https://reviews.llvm.org/D63311
llvm-svn: 363413
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 363172
|
|
|
|
|
|
| |
<rdar://problem/51139357>
llvm-svn: 362044
|
|
|
|
|
|
| |
<rdar://problem/50903413>
llvm-svn: 361087
|
|
|
|
| |
llvm-svn: 358721
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
<rdar://problem/49925960>
llvm-svn: 358615
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D59584
llvm-svn: 356995
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D59582
llvm-svn: 356910
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D59586
llvm-svn: 356909
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D59580
llvm-svn: 356695
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D59588
llvm-svn: 356673
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D59585
llvm-svn: 356671
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D59583
llvm-svn: 356670
|
|
|
|
|
|
|
|
| |
Aarch32 Cortex-M target processor debugging.
<rdar://problem/48448564>
llvm-svn: 356416
|
|
|
|
| |
llvm-svn: 355572
|
|
|
|
| |
llvm-svn: 355566
|
|
|
|
| |
llvm-svn: 355562
|
|
|
|
|
|
|
| |
This revert the commit because it broke the bots. I need to find
a way that works with both versions.
llvm-svn: 355364
|
|
|
|
|
|
| |
Fixes three tests in the testsuite.
llvm-svn: 355359
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
- Add latency timings to GDB packet log summary if timestamps are on log
- Add the ability to plot the latencies for each packet type with --plot
- Don't crash the script when target xml register info is in wierd format
llvm-svn: 343243
|
|
|
|
| |
llvm-svn: 343242
|
|
|
|
|
|
|
|
|
|
| |
Fixes include:
- fix all lint errors
- add code that will automatically register and LLDB command classes by detecting the classes and any classes that have a "register_lldb_command" function
- automatically fill in the correct module name when registering commands
- automatically fill in the class name when registering command
llvm-svn: 335401
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a combination stand alone BSD archive tool that can dump BSD archives:
% bsd.py /path/to/foo.a
Search archives for an object file:
% bsd.py --object foo.o bar.a
Dump the symbol definitions found in the __.SYMDEF objects:
% bsd.py --symdef bar.a
Find symbols by name that are listed in the __.SYMDEF objects:
% bsd.py --symbol _Z123 bar.a
Extract objects from BSD archives:
% bsd.py --object foo.o bar.a --extract
% bsd.py --object foo.o bar.a --extract --outfile /tmp/foo.o
% bsd.py --object foo.o bar.a --extract --mtime 0x1234556
It also has installs a new LLDB command line command when imported into LLDB:
(lldb) command script import ~/Dropbox/bin/bsd.py
The "verify-debug-map-objects" command has been installed, type "help verify-debug-map-objects" for detailed help.
(lldb) verify-debug-map-objects a.out
This will iterate through all object files and verify the modification times match for any .o files, it will verify any .o files from BSD archives are found and have matching modification times and print out errors if any are found.
llvm-svn: 328990
|
|
|
|
|
|
| |
way to just dump the compile unit full paths and optionally their support files with the new "dump-files"command.
llvm-svn: 318424
|
|
|
|
|
|
|
|
| |
This version relies on a newer and more convenient way
to use a class to implement a command. It has been in place
since early 2015, so it should be pretty safe to use.
llvm-svn: 317043
|
|
|
|
|
|
|
| |
lldb.process. That hasn't worked for a long time. Convert it
to the form that takes an SBExecutionContext and use that instead.
llvm-svn: 315549
|
|
|
|
|
|
|
|
|
| |
Sometimes you want to step along and print a local each time as you go.
You can do that with stop hooks, but that's a little heavy-weight. This
is a sketch of a command that steps and then does "frame variable" on all
its arguments.
llvm-svn: 314958
|
|
|
|
|
|
|
|
| |
Sometimes you are debugging in source, but you really only want to see
the disassembly. That's easy to do but you have to set a few variables.
This command toggles between your old values, and a disassembly only mode.
llvm-svn: 300902
|
|
|
|
| |
llvm-svn: 300341
|
|
|
|
|
|
|
| |
Not much we can do about it but at least we can print the bad
plist and the error.
llvm-svn: 298958
|
|
|
|
|
|
| |
<rdar://problem/29191857>
llvm-svn: 289006
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** 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
|
|
|
|
| |
llvm-svn: 277884
|
|
|
|
|
|
|
|
|
|
|
| |
execution context now that the @lldb.command decorator does the right thing for the command function that takes 5 arguments.
A few fixes:
- Check the process state to make sure it is stopped
- Grab the frame from the "exe_ctx" so this will work during breakpoint callbacks
- Print out the SBDeclaration objects of the variables that shadow each other so we can see the source locations of which variable declarations are shodowing each other.
llvm-svn: 273963
|
|
|
|
|
|
| |
This shows how to grab individual blocks from stack frames and get only the variables from those blocks. It then will iterate over all of the parent blocks and look for shadowed variables.
llvm-svn: 273604
|