Commit Graph

103 Commits

Author SHA1 Message Date
Jim Ingham 134d7f9a4b Store a by name list of signals with their actions in the Target
so that they can be used to prime new Process runs.  "process handle"
was also changed to populate the dummy target if there's no selected
target, so that the settings will get copied into new targets.

Differential Revision: https://reviews.llvm.org/D126259
2022-05-26 14:50:33 -07:00
Muhammad Omair Javaid b876c23604 Revert "[lldb] Consider binary as module of last resort"
This reverts commit a3c3482ceb.
It broke LLDB API test TestBadAddressBreakpoints.py

Differential revision: https://reviews.llvm.org/D124731
2022-05-23 11:19:48 +05:00
Will Hawkins a3c3482ceb
[lldb] Consider binary as module of last resort
When setting an address breakpoint using a non-section address in lldb
before having ever run the program, the binary itself is not considered
a module. As a result, the breakpoint is unresolved (and never gets
resolved subsequently).

This patch changes that behavior: as a last resort, the binary is
considered as a module when resolving a non-section address breakpoint.

Differential revision: https://reviews.llvm.org/D124731
2022-05-20 14:01:05 -07:00
David Spickett 13e1cf8065 Reland "[lldb] Add --all option to "memory region""
This reverts commit 3e928c4b9d.

This fixes an issue seen on Windows where we did not properly
get the section names of regions if they overlapped. Windows
has regions like:
[0x00007fff928db000-0x00007fff949a0000) ---
[0x00007fff949a0000-0x00007fff949a1000) r-- PECOFF header
[0x00007fff949a0000-0x00007fff94a3d000) r-x .hexpthk
[0x00007fff949a0000-0x00007fff94a85000) r-- .rdata
[0x00007fff949a0000-0x00007fff94a88000) rw- .data
[0x00007fff949a0000-0x00007fff94a94000) r-- .pdata
[0x00007fff94a94000-0x00007fff95250000) ---

I assumed that you could just resolve the address and get the section
name using the start of the region but here you'd always get
"PECOFF header" because they all have the same start point.

The usual command repeating loop used the end address of the previous
region when requesting the next, or getting the section name.
So I've matched this in the --all scenario.

In the example above, somehow asking for the region at
0x00007fff949a1000 would get you a region that starts at
0x00007fff949a0000 but has a different end point. Using the load
address you get (what I assume is) the correct section name.
2022-05-19 13:16:36 +01:00
David Spickett 29e556fc2b [lldb] Change implementation of memory read --show-tags option
This does 2 things:
* Moves it after the short options. Which makes sense given it's
  a niche, default off option.
  (if 2 files for one option seems a bit much, I am going to reuse
  them for "memory find" later)
* Fixes the use of repeated commands. For example:
    memory read buf --show-tags
    <shows tags>
    memory read
    <shows tags>

Added tests for the repetition and updated existing help tests.

Reviewed By: omjavaid

Differential Revision: https://reviews.llvm.org/D125089
2022-05-18 16:49:09 +01:00
David Spickett 3e928c4b9d Revert "[lldb] Add --all option to "memory region""
This reverts commit 8e648f195c
due to test failures on Windows:
https://lab.llvm.org/buildbot/#/builders/83/builds/19094
2022-05-18 11:57:20 +00:00
David Spickett 8e648f195c [lldb] Add --all option to "memory region"
This adds an option to the memory region command
to print all regions at once. Like you can do by
starting at address 0 and repeating the command
manually.

memory region [-a] [<address-expression>]

(lldb) memory region --all
[0x0000000000000000-0x0000000000400000) ---
[0x0000000000400000-0x0000000000401000) r-x <...>/a.out PT_LOAD[0]
<...>
[0x0000fffffffdf000-0x0001000000000000) rw- [stack]
[0x0001000000000000-0xffffffffffffffff) ---

The output matches exactly what you'd get from
repeating the command. Including that it shows
unmapped areas between the mapped regions.

(this is why Process GetMemoryRegions is not
used, that skips unmapped areas)

Help text has been updated to show that you can have
an address or --all but not both.

Reviewed By: JDevlieghere

Differential Revision: https://reviews.llvm.org/D111791
2022-05-18 10:33:39 +00:00
Walter Erquinigo 059f39d2f4 [trace][intel pt] Support events
A trace might contain events traced during the target's execution. For
example, a thread might be paused for some period of time due to context
switches or breakpoints, which actually force a context switch. Not only
that, a trace might be paused because the CPU decides to trace only a
specific part of the target, like the address filtering provided by
intel pt, which will cause pause events. Besides this case, other kinds
of events might exist.

This patch adds the method `TraceCursor::GetEvents()`` that returns the
list of events that happened right before the instruction being pointed
at by the cursor. Some refactors were done to make this change simpler.

Besides this new API, the instruction dumper now supports the -e flag
which shows pause events, like in the following example, where pauses
happened due to breakpoints.

```
thread #1: tid = 2717361
  a.out`main + 20 at main.cpp:27:20
    0: 0x00000000004023d9    leaq   -0x1200(%rbp), %rax
  [paused]
    1: 0x00000000004023e0    movq   %rax, %rdi
  [paused]
    2: 0x00000000004023e3    callq  0x403a62                  ; std::vector<int, std::allocator<int> >::vector at stl_vector.h:391:7
  a.out`std::vector<int, std::allocator<int> >::vector() at stl_vector.h:391:7
    3: 0x0000000000403a62    pushq  %rbp
    4: 0x0000000000403a63    movq   %rsp, %rbp
```

The `dump info` command has also been updated and now it shows the
number of instructions that have associated events.

Differential Revision: https://reviews.llvm.org/D123982
2022-04-25 19:01:23 -07:00
Will Hawkins e07c092b85
[lldb] Update online help text (consistency, typo)
Update the online help text for breakpoint set to be
consistent with respect to the spelling of Objective-C
and fix a few space-related typos.

Differential revision: https://reviews.llvm.org/D124338
2022-04-25 16:31:26 -07:00
Walter Erquinigo 05b4bf2571 [trace][intelpt] Introduce instruction Ids
In order to support quick arbitrary access to instructions in the trace, we need
each instruction to have an id. It could be an index or any other value that the
trace plugin defines.

This will be useful for reverse debugging or for creating callstacks, as each
frame will need an instruction id associated with them.

I've updated the `thread trace dump instructions` command accordingly. It now
prints the instruction id instead of relative offset. I've also added a new --id
argument that allows starting the dump from an arbitrary position.

Differential Revision: https://reviews.llvm.org/D122254
2022-04-06 12:19:36 -07:00
Walter Erquinigo b7d525ad38 [trace][intelpt] fix some test failures
Minor fixes needed and now `./bin/lldb-dotest -p TestTrace` passes
correctly.

- There was an incorrect iteration.
- Some error messages changed.
- The way repeat commands are handled changed a bit, so I had to create
a new --continue arg in "thread trace dump instructions" to handle this
correctly.

Differential Revision: https://reviews.llvm.org/D122023
2022-03-18 10:35:34 -07:00
Will Hawkins d58ef6df0d [LLDB] Change enumaration to enumeration
Change enumaration to enumeration in code handling LLDB help output.

Reviewed By: labath

Differential Revision: https://reviews.llvm.org/D121800
2022-03-16 15:31:25 +01:00
Will Hawkins fe93395b92 [LLDB] Fix typos in LLDB help output.
Correct a few spelling errors and typos in the LLDB help output.

Reviewed By: labath

Differential Revision: https://reviews.llvm.org/D121802
2022-03-16 15:31:25 +01:00
Jonas Devlieghere 8a0fa4db39
[lldb] Add --exists flag to `settings set`
Add a --exists/-e flag to `settings set` that sets the setting if it
exists, but doesn't print an error otherwise. This is useful for example
when setting options in your ~/.lldbinit that might not exist in older
versions of lldb.

Differential revision: https://reviews.llvm.org/D121155
2022-03-08 22:59:26 -08:00
David Spickett 742fb13475 Revert "[lldb] Correct case in description of breakpoint --on-catch/throw"
This reverts commit 6b3b3ef344.

Jim Ingham informed me that the upper case is a hint to the option
name, like you might see in a menu to show you what the shortcut is.
2022-03-03 17:20:31 +00:00
David Spickett 6b3b3ef344 [lldb] Correct case in description of breakpoint --on-catch/throw
Somehow we ended up with catcH/throW.
2022-03-03 10:06:11 +00:00
Zequan Wu 15983c28aa [LLDB] Dump valid ranges of variables
This allows `image lookup -a ... -v` to print variables only if the given
address is covered by the valid ranges of the variables. Since variables created
in dwarf plugin always has empty scope range, print the variable if it has
empty scope.

Differential Revision: https://reviews.llvm.org/D119963
2022-03-02 13:44:19 -08:00
David Spickett 070090d08e [lldb] Add option to show memory tags in memory read output
This adds an option --show-tags to "memory read".

(lldb) memory read mte_buf mte_buf+32 -f "x" -s8 --show-tags
0x900fffff7ff8000: 0x0000000000000000 0x0000000000000000 (tag: 0x0)
0x900fffff7ff8010: 0x0000000000000000 0x0000000000000000 (tag: 0x1)

Tags are printed on the end of each line, if that
line has any tags associated with it. Meaning that
untagged memory output is unchanged.

Tags are printed based on the granule(s) of memory that
a line covers. So you may have lines with 1 tag, with many
tags, no tags or partially tagged lines.

In the case of partially tagged lines, untagged granules
will show "<no tag>" so that the ordering is obvious.
For example, a line that covers 2 granules where the first
is not tagged:

(lldb) memory read mte_buf-16 mte_buf+16 -l32 -f"x" --show-tags
0x900fffff7ff7ff0: 0x00000000 <...> (tags: <no tag> 0x0)

Untagged lines will just not have the "(tags: ..." at all.
Though they may be part of a larger output that does have
some tagged lines.

To do this I've extended DumpDataExtractor to also print
memory tags where it has a valid execution context and
is asked to print them.

There are no special alignment requirements, simply
use "memory read" as usual. All alignment is handled
in DumpDataExtractor.

We use MakeTaggedRanges to find all the tagged memory
in the current dump, then read all that into a MemoryTagMap.

The tag map is populated once in DumpDataExtractor and re-used
for each subsequently printed line (or recursive call of
DumpDataExtractor, which some formats do).

Reviewed By: omjavaid

Differential Revision: https://reviews.llvm.org/D107140
2022-01-26 14:40:39 +00:00
Greg Clayton 48207b2559 Fix "settings set -g" so it works again.
When we switched options over to use the Options.td file, a bug was introduced that caused the "-g" option for "settings set" to require a filename arguemnt. This patch fixes this issue and adds a test so this doesn't regress.

Reviewed By: JDevlieghere

Differential Revision: https://reviews.llvm.org/D116012
2021-12-28 11:03:09 -08:00
Greg Clayton d7b338537c Modify "statistics dump" to dump JSON.
This patch is a smaller version of a previous patch https://reviews.llvm.org/D110804.

This patch modifies the output of "statistics dump" to be able to get stats from the current target. It adds 3 new stats as well. The output of "statistics dump" is now emitted as JSON so that it can be used to track performance and statistics and the output could be used to populate a database that tracks performance. Sample output looks like:

(lldb) statistics dump
{
  "expressionEvaluation": {
    "failures": 0,
    "successes": 0
  },
  "firstStopTime": 0.34164492800000001,
  "frameVariable": {
    "failures": 0,
    "successes": 0
  },
  "launchOrAttachTime": 0.31969605400000001,
  "targetCreateTime": 0.0040863039999999998
}

The top level keys are:

"expressionEvaluation" which replaces the previous stats that were emitted as plain text. This dictionary contains the success and fail counts.
"frameVariable" which replaces the previous stats for "frame variable" that were emitted as plain text. This dictionary contains the success and fail counts.
"targetCreateTime" contains the number of seconds it took to create the target and load dependent libraries (if they were enabled) and also will contain symbol preloading times if that setting is enabled.
"launchOrAttachTime" is the time it takes from when the launch/attach is initiated to when the first private stop occurs.
"firstStopTime" is the time in seconds that it takes to stop at the first stop that is presented to the user via the LLDB interface. This value will only have meaning if you set a known breakpoint or stop location in your code that you want to measure as a performance test.

This diff is also meant as a place to discuess what we want out of the "statistics dump" command before adding more funcionality. It is also meant to clean up the previous code that was storting statistics in a vector of numbers within the lldb_private::Target class.

Differential Revision: https://reviews.llvm.org/D111686
2021-10-21 12:14:21 -07:00
Jim Ingham c5011aed9c Add a "command container" hierarchy to allow users to add container nodes.
The point is to allow users with a related set of script based commands
to organize their commands in a hierarchy in the command set, rather than
having to have only top-level commands.

Differential Revision: https://reviews.llvm.org/D110298
2021-10-18 15:29:24 -07:00
Jim Ingham 3bf3b96629 Add the --relative-to-command-file to "command source" so you can
have linked command files in a source tree and get to them all from
one main command file.

Differential Revision: https://reviews.llvm.org/D110601
2021-09-29 19:33:41 -07:00
Raphael Isemann c22329972f [lldb] Add a C language REPL to test LLDB's REPL infrastructure
LLDB has a bunch of code that implements REPL support, but all that code is
unreachable as no language in master currently has an implemented REPL backend.
The only REPL that exists is in the downstream Swift fork. All patches for this
generic REPL code therefore also only have tests downstream which is clearly not
a good situation.

This patch implements a basic C language REPL on top of LLDB's REPL framework.
Beside implementing the REPL interface and hooking it up into the plugin
manager, the only other small part of this patch is making the `--language` flag
of the expression command compatible with the `--repl` flag. The `--repl` flag
uses the value of `--language` to see which REPL should be started, but right
now the `--language` flag is only available in OptionGroups 1 and 2, but not in
OptionGroup 3 where the `--repl` flag is declared.

The REPL currently can currently only start if a running target exists. I'll add
the 'create and run a dummy executable' logic from Swift (which is requires when
doing `lldb --repl`) when I have time to translate all this logic to something
that will work with Clang.

I should point out that the REPL currently uses the C expression parser's
approach to persistent variables where only result variables and the ones
starting with a '$' are transferred between expressions. I'll fix that in a
follow up patch. Also the REPL currently doesn't work in a non-interactive
terminal. This seems to be fixed in the Swift fork, so I assume one of our many
REPL downstream changes addresses the issue.

Reviewed By: JDevlieghere

Differential Revision: https://reviews.llvm.org/D87281
2021-09-23 19:31:02 +02:00
Andrej Korman eee687a66d [lldb] Add minidump save-core functionality to ELF object files
This change adds save-core functionality into the ObjectFileELF that enables
saving minidump of a stopped process. This change is mainly targeting Linux
running on x86_64 machines. Minidump should contain basic information needed
to examine state of threads, local variables and stack traces. Full support
for other platforms is not so far implemented. API tests are using LLDB's
MinidumpParser.

This relands commit aafa05e, reverted in 1f986f6.
Failed tests were fixed.

Reviewed By: clayborg

Differential Revision: https://reviews.llvm.org/D108233
2021-09-01 15:14:29 +02:00
Andy Yankovsky 1f986f6057 Revert "[lldb] Add minidump save-core functionality to ELF object files"
This reverts commit aafa05e03d.

Broke builder on aarch64 --
https://lab.llvm.org/buildbot/#/builders/96/builds/10926
2021-08-31 13:36:53 +02:00
Andrej Korman aafa05e03d [lldb] Add minidump save-core functionality to ELF object files
This change adds save-core functionality into the ObjectFileELF that enables
saving minidump of a stopped process. This change is mainly targeting Linux
running on x86_64 machines. Minidump should contain basic information needed
to examine state of threads, local variables and stack traces. Full support
for other platforms is not so far implemented. API tests are using LLDB's
MinidumpParser.

Reviewed By: clayborg

Differential Revision: https://reviews.llvm.org/D108233
2021-08-31 13:04:38 +02:00
Roman Podoliaka 54c496dad6 [lldb] Allow to register frame recognizers applied beyond the first instruction
It is currently possible to register a frame recognizer, but it will be applied if and only if the frame's PC points to the very first instruction of the specified function, which limits usability of this feature.

The implementation already supports changing this behaviour by passing an additional flag, but it's not possible to set it via the command interface. Fix that.

Reviewed By: jingham

Differential Revision: https://reviews.llvm.org/D108510
2021-08-29 17:28:46 +02:00
Walter Erquinigo 602497d672 [trace] [intel pt] Create a "process trace save" command
added new command "process trace save -d <directory>".
-it saves a JSON file as <directory>/trace.json, with the main properties of the trace session.
-it saves binary Intel-pt trace as <directory>/thread_id.trace; each file saves each thread.
-it saves modules to the directory <directory>/modules .
-it only works for live process and it only support Intel-pt right now.

Example:
```
b main
run
process trace start
n
process trace save -d /tmp/mytrace
```
A file named trace.json and xxx.trace should be generated in /tmp/mytrace. To load the trace that was just saved:
```
trace load /tmp/mytrace
thread trace dump instructions
```
You should see the instructions of the trace got printed.

To run a test:
```
cd ~/llvm-sand/build/Release/fbcode-x86_64/toolchain
ninja lldb-dotest
./bin/lldb-dotest -p TestTraceSave
```

Reviewed By: wallace

Differential Revision: https://reviews.llvm.org/D107669
2021-08-27 09:34:01 -07:00
Kirill Shmakov 2cc1198e36 [lldb] Fix typo in the description of breakpoint options 2021-08-21 12:24:29 +02:00
Jim Ingham f362b05d0d Add a "current" token to the ThreadID option to break set/modify.
This provides a convenient way to limit a breakpoint
to the current thread when setting it from the command line w/o
having to figure out what the current thread is.

Differential Revision: https://reviews.llvm.org/D107015
2021-08-06 15:29:55 -07:00
David Spickett 6eded00e0c [lldb] Add "memory tag write" --end-addr option
The default mode of "memory tag write" is to calculate the
range from the start address and the number of tags given.
(just like "memory write" does)

(lldb) memory tag write mte_buf 1 2
(lldb) memory tag read mte_buf mte_buf+48
Logical tag: 0x0
Allocation tags:
[0xfffff7ff9000, 0xfffff7ff9010): 0x1
[0xfffff7ff9010, 0xfffff7ff9020): 0x2
[0xfffff7ff9020, 0xfffff7ff9030): 0x0

This new option allows you to set an end address and have
the tags repeat until that point.

(lldb) memory tag write mte_buf 1 2 --end-addr mte_buf+64
(lldb) memory tag read mte_buf mte_buf+80
Logical tag: 0x0
Allocation tags:
[0xfffff7ff9000, 0xfffff7ff9010): 0x1
[0xfffff7ff9010, 0xfffff7ff9020): 0x2
[0xfffff7ff9020, 0xfffff7ff9030): 0x1
[0xfffff7ff9030, 0xfffff7ff9040): 0x2
[0xfffff7ff9040, 0xfffff7ff9050): 0x0

This is implemented using the QMemTags packet previously
added. We skip validating the number of tags in lldb and send
them on to lldb-server, which repeats them as needed.

Apart from the number of tags, all the other client side checks
remain. Tag values, memory range must be tagged, etc.

Reviewed By: omjavaid

Differential Revision: https://reviews.llvm.org/D105183
2021-07-28 14:05:40 +01:00
Walter Erquinigo 345ace026b [trace] [intel pt] Create a "thread trace dump stats" command
When the user types that command 'thread trace dump info' and there's a running Trace session in LLDB, a raw trace in bytes should be printed; the command 'thread trace dump info all' should print the info for all the threads.

Original Author: hanbingwang

Reviewed By: clayborg, wallace

Differential Revision: https://reviews.llvm.org/D105717
2021-07-21 09:50:15 -07:00
Walter Erquinigo 04195843ef [intel pt] Add TSC timestamps
Differential Revision: https://reviews.llvm.org/D106328
2021-07-20 16:29:17 -07:00
Walter Erquinigo b0aa70761b [trace][intel pt] Implement the Intel PT cursor
D104422 added the interface for TraceCursor, which is the main way to traverse instructions in a trace. This diff implements the corresponding cursor class for Intel PT and deletes the now obsolete code.

Besides that, the logic for the "thread trace dump instructions" was adapted to use this cursor (pretty much I ended up moving code from Trace.cpp to TraceCursor.cpp). The command by default traverses the instructions backwards, and if the user passes --forwards, then it's not forwards. More information about that is in the Options.td file.

Regarding the Intel PT cursor. All Intel PT cursors for the same thread share the same DecodedThread instance. I'm not yet implementing lazy decoding because we don't need it. That'll be for later. For the time being, the entire thread trace is decoded when the first cursor for that thread is requested.

Differential Revision: https://reviews.llvm.org/D105531
2021-07-16 16:47:43 -07:00
Jonas Devlieghere f951735395 [lldb] Add the ability to silently import scripted commands
Add the ability to silence command script import. The motivation for
this change is being able to add command script import -s
lldb.macosx.crashlog to your ~/.lldbinit without it printing the
following message at the beginning of every debug session.

  "malloc_info", "ptr_refs", "cstr_refs", "find_variable", and
  "objc_refs" commands have been installed, use the "--help" options on
  these commands for detailed help.

In addition to forwarding the silent option to LoadScriptingModule, this
also changes ScriptInterpreterPythonImpl::ExecuteOneLineWithReturn and
ScriptInterpreterPythonImpl::ExecuteMultipleLines to honor the enable IO
option in ExecuteScriptOptions, which until now was ignored.

Note that IO is only enabled (or disabled) at the start of a session,
and for this particular use case, that's done when taking the Python
lock in LoadScriptingModule, which means that the changes to these two
functions are not strictly necessary, but (IMO) desirable nonetheless.

Differential revision: https://reviews.llvm.org/D105327
2021-07-09 10:05:39 -07:00
Jason Molenda 9ea6dd5cfa Add a corefile style option to process save-core; skinny corefiles
Add a new feature to process save-core on Darwin systems -- for
lldb to create a user process corefile with only the dirty (modified
memory) pages included.  All of the binaries that were used in the
corefile are assumed to still exist on the system for the duration
of the use of the corefile.  A new --style option to process save-core
is added, so a full corefile can be requested if portability across
systems, or across time, is needed for this corefile.

debugserver can now identify the dirty pages in a memory region
when queried with qMemoryRegionInfo, and the size of vm pages is
given in qHostInfo.

Create a new "all image infos" LC_NOTE for Mach-O which allows us
to describe all of the binaries that were loaded in the process --
load address, UUID, file path, segment load addresses, and optionally
whether code from the binary was executing on any thread.  The old
"read dyld_all_image_infos and then the in-memory Mach-O load
commands to get segment load addresses" no longer works when we
only have dirty memory.

rdar://69670807
Differential Revision: https://reviews.llvm.org/D88387
2021-06-20 12:26:54 -07:00
Vedant Kumar 414412d3dc [lldb/Commands] Fix spelling of target.move-to-nearest-code in helptext 2021-03-25 14:25:10 -07:00
Med Ismail Bennani 103ad3f907 [lldb/Commands] Fix short option collision for `process launch`
This patch changes the short option used in `CommandOptionsProcessLaunch`
for the `-v|--environment` command option to `-E|--environment`.

The reason for that is, that it collides with the `-v|--structured-data-value`
command option generated by `OptionGroupPythonClassWithDict` that
I'm using in an upcoming patch for the `process launch` command.

The long option `--environment` remains the same.

Differential Review: https://reviews.llvm.org/D95100

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2021-03-01 21:13:31 +01:00
Jan Kratochvil 08331281af [lldb/Commands] Fix help text typo for 'breakpoint set' -a|--address. 2021-02-19 14:33:42 +01:00
Med Ismail Bennani 7169d3a315 [lldb/Commands] Refactor ProcessLaunchCommandOptions to use TableGen (NFC)
This patch refactors the current implementation of
`ProcessLaunchCommandOptions` to be generated by TableGen.

The patch also renames the class to `CommandOptionsProcessLaunch` to
align better with the rest of the codebase style and moves it to
separate files.

Differential Review: https://reviews.llvm.org/D95059

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2021-01-20 18:53:06 +01:00
Vedant Kumar ba21376883 [Command] Fix accidental word concatenation in Options.td
Split up words that appear to have been accidentally concatenated.

This looks to be exhaustive: to find these in vim, use:

/\v[^ ]"\n +"[^ ]
2020-11-10 16:13:39 -08:00
Walter Erquinigo cfd96f057b [trace][intel-pt] Implement the basic decoding functionality
Depends on D89408.

This diff finally implements trace decoding!

The current interface is

  $ trace load /path/to/trace/session/file.json
  $ thread trace dump instructions

  thread #1: tid = 3842849, total instructions = 22
    [ 0] 0x40052d
    [ 1] 0x40052d
    ...
    [19] 0x400521

  $ # simply enter, which is a repeat command
    [20] 0x40052d
    [21] 0x400529
    ...

This doesn't do any disassembly, which will be done in the next diff.

Changes:
- Added an IntelPTDecoder class, that is a wrapper for libipt, which is the actual library that performs the decoding.
- Added TraceThreadDecoder class that decodes traces and memoizes the result to avoid repeating the decoding step.
- Added a DecodedThread class, which represents the output from decoding and that for the time being only stores the list of reconstructed instructions. Later it'll contain the function call hierarchy, which will enable reconstructing backtraces.
- Added basic APIs for accessing the trace in Trace.h:
  - GetInstructionCount, which counts the number of instructions traced for a given thread
  - IsTraceFailed, which returns an Error if decoding a thread failed
  - ForEachInstruction, which iterates on the instructions traced for a given thread, concealing the internal storage of threads, as plug-ins can decide to generate the instructions on the fly or to store them all in a vector, like I do.
- DumpTraceInstructions was updated to print the instructions or show an error message if decoding was impossible.
- Tests included

Differential Revision: https://reviews.llvm.org/D89283
2020-11-05 18:38:03 -08:00
Jonas Devlieghere 00bb397b0d [lldb] Support Python imports relative the to the current file being sourced
Make it possible to use a relative path in command script import to the
location of the file being sourced. This allows the user to put Python
scripts next to LLDB command files and importing them without having to
specify an absolute path.

To enable this behavior pass `-c` to `command script import`. The
argument can only be used when sourcing the command from a file.

rdar://68310384

Differential revision: https://reviews.llvm.org/D89334
2020-10-27 09:20:45 -07:00
Walter Erquinigo 26d861cbbd [trace] Scaffold "thread trace dump instructions"
Depends on D88841

As per the discussion in the RFC, we'll implement both

  thread trace dump [instructions | functions]

This is the first step in implementing the "instructions" dumping command.

It includes:

- A minimal ProcessTrace plugin for representing processes from a trace file. I noticed that it was a required step to mimic how core-based processes are initialized, e.g. ProcessElfCore and ProcessMinidump. I haven't had the need to create ThreadTrace yet, though. So far HistoryThread seems good enough.
- The command handling itself in CommandObjectThread, which outputs a placeholder text instead of the actual instructions. I'll do that part in the next diff.
- Tests

{F13132325}

Differential Revision: https://reviews.llvm.org/D88769
2020-10-12 12:08:18 -07:00
Jim Ingham 1b1d981598 Revert "Revert "Add the ability to write target stop-hooks using the ScriptInterpreter.""
This reverts commit f775fe5964.

I fixed a return type error in the original patch that was causing a test failure.
Also added a REQUIRES: python to the shell test so we'll skip this for
people who build lldb w/o Python.
Also added another test for the error printing.
2020-09-29 12:01:14 -07:00
Jonas Devlieghere f775fe5964 Revert "Add the ability to write target stop-hooks using the ScriptInterpreter."
This temporarily reverts commit b65966cff6
while Jim figures out why the test is failing on the bots.
2020-09-28 09:04:32 -07:00
Jim Ingham b65966cff6 Add the ability to write target stop-hooks using the ScriptInterpreter.
Differential Revision: https://reviews.llvm.org/D88123
2020-09-25 15:44:55 -07:00
Jim Ingham 3726ac41e9 Add `breakpoint delete --disabled`: deletes all disabled breakpoints.
Differential Revision: https://reviews.llvm.org/D88129
2020-09-23 11:35:11 -07:00
Walter Erquinigo 74c93956e1 Add a "Trace" plug-in to LLDB to add process trace support in stages.
This is the first in a series of patches that will adds a new processor trace plug-in to LLDB.

The idea for this first patch to to add the plug-in interface with simple commands for the trace files that can "load" and "dump" the trace information. We can test the functionality and ensure people are happy with the way things are done and how things are organized before moving on to adding more functionality.

Processor trace information can be view in a few different ways:
- post mortem where a trace is saved off that can be viewed later in the debugger
- gathered while a process is running and allow the user to step back in time (with no variables, memory or registers) to see how each thread arrived at where it is currently stopped.

This patch attempts to start with the first solution of loading a trace file after the fact. The idea is that we will use a JSON file to load the trace information. JSON allows us to specify information about the trace like:
- plug-in name in LLDB
- path to trace file
- shared library load information so we can re-create a target and symbolicate the information in the trace
- any other info that the trace plug-in will need to be able to successfully parse the trace information
  - cpu type
  - version info
  - ???

A new "trace" command was added at the top level of the LLDB commmands:
- "trace load"
- "trace dump"

I did this because if we load trace information we don't need to have a process and we might end up creating a new target for the trace information that will become active. If anyone has any input on where this would be better suited, please let me know. Walter Erquinigo will end up filling in the Intel PT specific plug-in so that it works and is tested once we can agree that the direction of this patch is the correct one, so please feel free to chime in with ideas on comments!

Reviewed By: clayborg

Differential Revision: https://reviews.llvm.org/D85705
2020-09-21 17:13:18 -07:00
Jonas Devlieghere 127faae752 [lldb] Add -l/--language option to script command
Make it possible to run the script command with a different language
than currently selected.

  $ ./bin/lldb -l python
  (lldb) script -l lua
  >>> io.stdout:write("Hello, World!\n")
  Hello, World!

When passing the language option and a raw command, you need to separate
the flag from the script code with --.

  $ ./bin/lldb -l python
  (lldb) script -l lua -- io.stdout:write("Hello, World!\n")
  Hello, World!

Differential revision: https://reviews.llvm.org/D86996
2020-09-15 09:40:17 -07:00