2017-12-01 08:52:51 +08:00
|
|
|
//===- lldb-test.cpp ------------------------------------------ *- C++ --*-===//
|
|
|
|
//
|
2019-01-19 16:50:56 +08:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2017-12-01 08:52:51 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "FormatUtil.h"
|
|
|
|
#include "SystemInitializerTest.h"
|
|
|
|
|
2017-12-02 08:15:29 +08:00
|
|
|
#include "Plugins/SymbolFile/DWARF/SymbolFileDWARF.h"
|
[lldb] Move clang-based files out of Symbol
Summary:
This change represents the move of ClangASTImporter, ClangASTMetadata,
ClangExternalASTSourceCallbacks, ClangUtil, CxxModuleHandler, and
TypeSystemClang from lldbSource to lldbPluginExpressionParserClang.h
This explicitly removes knowledge of clang internals from lldbSymbol,
moving towards a more generic core implementation of lldb.
Reviewers: JDevlieghere, davide, aprantl, teemperor, clayborg, labath, jingham, shafik
Subscribers: emaste, mgorny, arphaman, jfb, usaxena95, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73661
2020-01-30 03:59:28 +08:00
|
|
|
#include "Plugins/TypeSystem/Clang/TypeSystemClang.h"
|
Add "lldb-test breakpoint" command and convert the case-sensitivity test to use it
Summary:
The command takes two input arguments: a module to use as a debug target
and a file containing a list of commands. The command will execute each
of the breakpoint commands in the file and dump the breakpoint state
after each one.
The commands are expected to be breakpoint set/remove/etc. commands, but
I explicitly allow any lldb command here, so you can do things like
change setting which impact breakpoint resolution, etc. There is also a
"-persistent" flag, which causes lldb-test to *not* automatically clear
the breakpoint list after each command. Right now I don't use it, but
the idea behind it was that it could be used to test more complex
combinations of breakpoint commands (set+modify, set+disable, etc.).
Right now the command prints out only the basic breakpoint state, but
more information can be easily added there. To enable easy matching of
the "at least one breakpoint location found" state, the command
explicitly prints out the string "At least one breakpoint location.".
To enable testing of breakpoints set with an absolute paths, I add the
ability to perform rudimentary substitutions on the commands: right now
the string %p is replaced by the directory which contains the command
file (so, under normal circumstances, this will perform the same
substitution as lit would do for %p).
I use this command to rewrite the TestBreakpointCaseSensitivity test --
the test was checking about a dozen breakpoint commands, but it was
launching a new process for each one, so it took about 90 seconds to
run. The new test takes about 0.3 seconds for me, which is approximately
a 300x speedup.
Reviewers: davide, zturner, jingham
Subscribers: luporl, lldb-commits
Differential Revision: https://reviews.llvm.org/D43686
llvm-svn: 326112
2018-02-27 02:50:16 +08:00
|
|
|
#include "lldb/Breakpoint/BreakpointLocation.h"
|
2017-12-01 08:52:51 +08:00
|
|
|
#include "lldb/Core/Debugger.h"
|
|
|
|
#include "lldb/Core/Module.h"
|
|
|
|
#include "lldb/Core/Section.h"
|
[lldb-test] Add a testing harness for the JIT's IRMemoryMap
This teaches lldb-test how to launch a process, set up an IRMemoryMap,
and issue memory allocations in the target process through the map. This
makes it possible to test IRMemoryMap in a targeted way.
This has uncovered two bugs so far. The first bug is that Malloc
performs an adjustment on the pointer returned from AllocateMemory (for
alignment purposes) which ultimately allows overlapping memory regions
to be created. The second bug is that after most of the address space on
the host side is exhausted, Malloc may return the same address multiple
times. These bugs (and hopefully more!) can be uncovered and tested for
with targeted lldb-test commands.
At an even higher level, the motivation for addressing these bugs is
that they can lead to strange user-visible failures (e.g, variables
assume the wrong value during expression evaluation, or the debugger
crashes). See my third comment on this swift-lldb PR for an example:
https://github.com/apple/swift-lldb/pull/652
I hope lldb-test is the right place to add this testing harness. Setting
up a gtest-style unit test proved too cumbersome (you need to recreate
or mock way too much debugger state), as did writing end-to-end tests
(it's hard to write a test that actually hits a buggy path).
With lldb-test, it's easy to read/generate the test input and parse the
test output. I'll attach a simple "fuzz" tester which generates failing
test cases to the Phab review. Here's an example:
```
Command: malloc(size=1024, alignment=32)
Malloc: address = 0xca000
Command: malloc(size=64, alignment=16)
Malloc: address = 0xca400
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca440
Command: malloc(size=16, alignment=8)
Malloc: address = 0xca840
Command: malloc(size=2048, alignment=16)
Malloc: address = 0xcb000
Command: malloc(size=64, alignment=32)
Malloc: address = 0xca860
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca890
Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0)
```
{F6288839}
Differential Revision: https://reviews.llvm.org/D47508
llvm-svn: 333583
2018-05-31 03:39:10 +08:00
|
|
|
#include "lldb/Expression/IRMemoryMap.h"
|
2017-12-01 08:52:51 +08:00
|
|
|
#include "lldb/Initialization/SystemLifetimeManager.h"
|
Add "lldb-test breakpoint" command and convert the case-sensitivity test to use it
Summary:
The command takes two input arguments: a module to use as a debug target
and a file containing a list of commands. The command will execute each
of the breakpoint commands in the file and dump the breakpoint state
after each one.
The commands are expected to be breakpoint set/remove/etc. commands, but
I explicitly allow any lldb command here, so you can do things like
change setting which impact breakpoint resolution, etc. There is also a
"-persistent" flag, which causes lldb-test to *not* automatically clear
the breakpoint list after each command. Right now I don't use it, but
the idea behind it was that it could be used to test more complex
combinations of breakpoint commands (set+modify, set+disable, etc.).
Right now the command prints out only the basic breakpoint state, but
more information can be easily added there. To enable easy matching of
the "at least one breakpoint location found" state, the command
explicitly prints out the string "At least one breakpoint location.".
To enable testing of breakpoints set with an absolute paths, I add the
ability to perform rudimentary substitutions on the commands: right now
the string %p is replaced by the directory which contains the command
file (so, under normal circumstances, this will perform the same
substitution as lit would do for %p).
I use this command to rewrite the TestBreakpointCaseSensitivity test --
the test was checking about a dozen breakpoint commands, but it was
launching a new process for each one, so it took about 90 seconds to
run. The new test takes about 0.3 seconds for me, which is approximately
a 300x speedup.
Reviewers: davide, zturner, jingham
Subscribers: luporl, lldb-commits
Differential Revision: https://reviews.llvm.org/D43686
llvm-svn: 326112
2018-02-27 02:50:16 +08:00
|
|
|
#include "lldb/Interpreter/CommandInterpreter.h"
|
|
|
|
#include "lldb/Interpreter/CommandReturnObject.h"
|
2018-06-08 10:45:25 +08:00
|
|
|
#include "lldb/Symbol/CompileUnit.h"
|
|
|
|
#include "lldb/Symbol/LineTable.h"
|
2019-08-06 17:12:42 +08:00
|
|
|
#include "lldb/Symbol/SymbolFile.h"
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
#include "lldb/Symbol/TypeList.h"
|
2019-08-06 17:12:42 +08:00
|
|
|
#include "lldb/Symbol/TypeMap.h"
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
#include "lldb/Symbol/VariableList.h"
|
2019-08-23 05:45:58 +08:00
|
|
|
#include "lldb/Target/Language.h"
|
[lldb-test] Add a testing harness for the JIT's IRMemoryMap
This teaches lldb-test how to launch a process, set up an IRMemoryMap,
and issue memory allocations in the target process through the map. This
makes it possible to test IRMemoryMap in a targeted way.
This has uncovered two bugs so far. The first bug is that Malloc
performs an adjustment on the pointer returned from AllocateMemory (for
alignment purposes) which ultimately allows overlapping memory regions
to be created. The second bug is that after most of the address space on
the host side is exhausted, Malloc may return the same address multiple
times. These bugs (and hopefully more!) can be uncovered and tested for
with targeted lldb-test commands.
At an even higher level, the motivation for addressing these bugs is
that they can lead to strange user-visible failures (e.g, variables
assume the wrong value during expression evaluation, or the debugger
crashes). See my third comment on this swift-lldb PR for an example:
https://github.com/apple/swift-lldb/pull/652
I hope lldb-test is the right place to add this testing harness. Setting
up a gtest-style unit test proved too cumbersome (you need to recreate
or mock way too much debugger state), as did writing end-to-end tests
(it's hard to write a test that actually hits a buggy path).
With lldb-test, it's easy to read/generate the test input and parse the
test output. I'll attach a simple "fuzz" tester which generates failing
test cases to the Phab review. Here's an example:
```
Command: malloc(size=1024, alignment=32)
Malloc: address = 0xca000
Command: malloc(size=64, alignment=16)
Malloc: address = 0xca400
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca440
Command: malloc(size=16, alignment=8)
Malloc: address = 0xca840
Command: malloc(size=2048, alignment=16)
Malloc: address = 0xcb000
Command: malloc(size=64, alignment=32)
Malloc: address = 0xca860
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca890
Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0)
```
{F6288839}
Differential Revision: https://reviews.llvm.org/D47508
llvm-svn: 333583
2018-05-31 03:39:10 +08:00
|
|
|
#include "lldb/Target/Process.h"
|
|
|
|
#include "lldb/Target/Target.h"
|
2017-12-01 08:52:51 +08:00
|
|
|
#include "lldb/Utility/DataExtractor.h"
|
2021-03-20 05:20:26 +08:00
|
|
|
#include "lldb/Utility/LLDBAssert.h"
|
ELF: more section creation cleanup
Summary:
This patch attempts to move as much code as possible out of the
CreateSections function to make room for future improvements there. Some
of this may be slightly over-engineered (VMAddressProvider), but I
wanted to keep the logic of this function very simple, because once I
start taking segment headers into acount (as discussed in D55356), the
function is going to grow significantly.
While in there, I also added tests for various bits of functionality.
This should be NFC, except that I changed the order of hac^H^Heuristicks
for determining section type slightly. Previously, name-based deduction
(.symtab -> symtab) would take precedence over type-based (SHT_SYMTAB ->
symtab) one. In fact we would assert if we ran into a .text section with
type SHT_SYMTAB. Though unlikely to matter in practice, this order
seemed wrong to me, so I have inverted it.
Reviewers: clayborg, krytarowski, espindola
Subscribers: emaste, arichardson, lldb-commits
Differential Revision: https://reviews.llvm.org/D55706
llvm-svn: 349268
2018-12-15 21:45:38 +08:00
|
|
|
#include "lldb/Utility/State.h"
|
2017-12-02 08:15:29 +08:00
|
|
|
#include "lldb/Utility/StreamString.h"
|
2017-12-01 08:52:51 +08:00
|
|
|
|
[lldb-test] Add a testing harness for the JIT's IRMemoryMap
This teaches lldb-test how to launch a process, set up an IRMemoryMap,
and issue memory allocations in the target process through the map. This
makes it possible to test IRMemoryMap in a targeted way.
This has uncovered two bugs so far. The first bug is that Malloc
performs an adjustment on the pointer returned from AllocateMemory (for
alignment purposes) which ultimately allows overlapping memory regions
to be created. The second bug is that after most of the address space on
the host side is exhausted, Malloc may return the same address multiple
times. These bugs (and hopefully more!) can be uncovered and tested for
with targeted lldb-test commands.
At an even higher level, the motivation for addressing these bugs is
that they can lead to strange user-visible failures (e.g, variables
assume the wrong value during expression evaluation, or the debugger
crashes). See my third comment on this swift-lldb PR for an example:
https://github.com/apple/swift-lldb/pull/652
I hope lldb-test is the right place to add this testing harness. Setting
up a gtest-style unit test proved too cumbersome (you need to recreate
or mock way too much debugger state), as did writing end-to-end tests
(it's hard to write a test that actually hits a buggy path).
With lldb-test, it's easy to read/generate the test input and parse the
test output. I'll attach a simple "fuzz" tester which generates failing
test cases to the Phab review. Here's an example:
```
Command: malloc(size=1024, alignment=32)
Malloc: address = 0xca000
Command: malloc(size=64, alignment=16)
Malloc: address = 0xca400
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca440
Command: malloc(size=16, alignment=8)
Malloc: address = 0xca840
Command: malloc(size=2048, alignment=16)
Malloc: address = 0xcb000
Command: malloc(size=64, alignment=32)
Malloc: address = 0xca860
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca890
Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0)
```
{F6288839}
Differential Revision: https://reviews.llvm.org/D47508
llvm-svn: 333583
2018-05-31 03:39:10 +08:00
|
|
|
#include "llvm/ADT/IntervalMap.h"
|
2019-09-10 08:20:50 +08:00
|
|
|
#include "llvm/ADT/ScopeExit.h"
|
2017-12-01 08:52:51 +08:00
|
|
|
#include "llvm/ADT/StringRef.h"
|
|
|
|
#include "llvm/Support/CommandLine.h"
|
|
|
|
#include "llvm/Support/ManagedStatic.h"
|
2018-06-28 18:03:42 +08:00
|
|
|
#include "llvm/Support/MathExtras.h"
|
Add "lldb-test breakpoint" command and convert the case-sensitivity test to use it
Summary:
The command takes two input arguments: a module to use as a debug target
and a file containing a list of commands. The command will execute each
of the breakpoint commands in the file and dump the breakpoint state
after each one.
The commands are expected to be breakpoint set/remove/etc. commands, but
I explicitly allow any lldb command here, so you can do things like
change setting which impact breakpoint resolution, etc. There is also a
"-persistent" flag, which causes lldb-test to *not* automatically clear
the breakpoint list after each command. Right now I don't use it, but
the idea behind it was that it could be used to test more complex
combinations of breakpoint commands (set+modify, set+disable, etc.).
Right now the command prints out only the basic breakpoint state, but
more information can be easily added there. To enable easy matching of
the "at least one breakpoint location found" state, the command
explicitly prints out the string "At least one breakpoint location.".
To enable testing of breakpoints set with an absolute paths, I add the
ability to perform rudimentary substitutions on the commands: right now
the string %p is replaced by the directory which contains the command
file (so, under normal circumstances, this will perform the same
substitution as lit would do for %p).
I use this command to rewrite the TestBreakpointCaseSensitivity test --
the test was checking about a dozen breakpoint commands, but it was
launching a new process for each one, so it took about 90 seconds to
run. The new test takes about 0.3 seconds for me, which is approximately
a 300x speedup.
Reviewers: davide, zturner, jingham
Subscribers: luporl, lldb-commits
Differential Revision: https://reviews.llvm.org/D43686
llvm-svn: 326112
2018-02-27 02:50:16 +08:00
|
|
|
#include "llvm/Support/Path.h"
|
2017-12-01 08:52:51 +08:00
|
|
|
#include "llvm/Support/PrettyStackTrace.h"
|
|
|
|
#include "llvm/Support/Signals.h"
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
#include "llvm/Support/WithColor.h"
|
2019-10-12 00:36:20 +08:00
|
|
|
|
[lldb-test] Add a testing harness for the JIT's IRMemoryMap
This teaches lldb-test how to launch a process, set up an IRMemoryMap,
and issue memory allocations in the target process through the map. This
makes it possible to test IRMemoryMap in a targeted way.
This has uncovered two bugs so far. The first bug is that Malloc
performs an adjustment on the pointer returned from AllocateMemory (for
alignment purposes) which ultimately allows overlapping memory regions
to be created. The second bug is that after most of the address space on
the host side is exhausted, Malloc may return the same address multiple
times. These bugs (and hopefully more!) can be uncovered and tested for
with targeted lldb-test commands.
At an even higher level, the motivation for addressing these bugs is
that they can lead to strange user-visible failures (e.g, variables
assume the wrong value during expression evaluation, or the debugger
crashes). See my third comment on this swift-lldb PR for an example:
https://github.com/apple/swift-lldb/pull/652
I hope lldb-test is the right place to add this testing harness. Setting
up a gtest-style unit test proved too cumbersome (you need to recreate
or mock way too much debugger state), as did writing end-to-end tests
(it's hard to write a test that actually hits a buggy path).
With lldb-test, it's easy to read/generate the test input and parse the
test output. I'll attach a simple "fuzz" tester which generates failing
test cases to the Phab review. Here's an example:
```
Command: malloc(size=1024, alignment=32)
Malloc: address = 0xca000
Command: malloc(size=64, alignment=16)
Malloc: address = 0xca400
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca440
Command: malloc(size=16, alignment=8)
Malloc: address = 0xca840
Command: malloc(size=2048, alignment=16)
Malloc: address = 0xcb000
Command: malloc(size=64, alignment=32)
Malloc: address = 0xca860
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca890
Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0)
```
{F6288839}
Differential Revision: https://reviews.llvm.org/D47508
llvm-svn: 333583
2018-05-31 03:39:10 +08:00
|
|
|
#include <cstdio>
|
2017-12-01 08:52:51 +08:00
|
|
|
#include <thread>
|
|
|
|
|
|
|
|
using namespace lldb;
|
|
|
|
using namespace lldb_private;
|
|
|
|
using namespace llvm;
|
|
|
|
|
|
|
|
namespace opts {
|
Add "lldb-test breakpoint" command and convert the case-sensitivity test to use it
Summary:
The command takes two input arguments: a module to use as a debug target
and a file containing a list of commands. The command will execute each
of the breakpoint commands in the file and dump the breakpoint state
after each one.
The commands are expected to be breakpoint set/remove/etc. commands, but
I explicitly allow any lldb command here, so you can do things like
change setting which impact breakpoint resolution, etc. There is also a
"-persistent" flag, which causes lldb-test to *not* automatically clear
the breakpoint list after each command. Right now I don't use it, but
the idea behind it was that it could be used to test more complex
combinations of breakpoint commands (set+modify, set+disable, etc.).
Right now the command prints out only the basic breakpoint state, but
more information can be easily added there. To enable easy matching of
the "at least one breakpoint location found" state, the command
explicitly prints out the string "At least one breakpoint location.".
To enable testing of breakpoints set with an absolute paths, I add the
ability to perform rudimentary substitutions on the commands: right now
the string %p is replaced by the directory which contains the command
file (so, under normal circumstances, this will perform the same
substitution as lit would do for %p).
I use this command to rewrite the TestBreakpointCaseSensitivity test --
the test was checking about a dozen breakpoint commands, but it was
launching a new process for each one, so it took about 90 seconds to
run. The new test takes about 0.3 seconds for me, which is approximately
a 300x speedup.
Reviewers: davide, zturner, jingham
Subscribers: luporl, lldb-commits
Differential Revision: https://reviews.llvm.org/D43686
llvm-svn: 326112
2018-02-27 02:50:16 +08:00
|
|
|
static cl::SubCommand BreakpointSubcommand("breakpoints",
|
|
|
|
"Test breakpoint resolution");
|
2018-06-29 20:15:54 +08:00
|
|
|
cl::SubCommand ObjectFileSubcommand("object-file",
|
|
|
|
"Display LLDB object file information");
|
2017-12-02 08:15:29 +08:00
|
|
|
cl::SubCommand SymbolsSubcommand("symbols", "Dump symbols for an object file");
|
[lldb-test] Add a testing harness for the JIT's IRMemoryMap
This teaches lldb-test how to launch a process, set up an IRMemoryMap,
and issue memory allocations in the target process through the map. This
makes it possible to test IRMemoryMap in a targeted way.
This has uncovered two bugs so far. The first bug is that Malloc
performs an adjustment on the pointer returned from AllocateMemory (for
alignment purposes) which ultimately allows overlapping memory regions
to be created. The second bug is that after most of the address space on
the host side is exhausted, Malloc may return the same address multiple
times. These bugs (and hopefully more!) can be uncovered and tested for
with targeted lldb-test commands.
At an even higher level, the motivation for addressing these bugs is
that they can lead to strange user-visible failures (e.g, variables
assume the wrong value during expression evaluation, or the debugger
crashes). See my third comment on this swift-lldb PR for an example:
https://github.com/apple/swift-lldb/pull/652
I hope lldb-test is the right place to add this testing harness. Setting
up a gtest-style unit test proved too cumbersome (you need to recreate
or mock way too much debugger state), as did writing end-to-end tests
(it's hard to write a test that actually hits a buggy path).
With lldb-test, it's easy to read/generate the test input and parse the
test output. I'll attach a simple "fuzz" tester which generates failing
test cases to the Phab review. Here's an example:
```
Command: malloc(size=1024, alignment=32)
Malloc: address = 0xca000
Command: malloc(size=64, alignment=16)
Malloc: address = 0xca400
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca440
Command: malloc(size=16, alignment=8)
Malloc: address = 0xca840
Command: malloc(size=2048, alignment=16)
Malloc: address = 0xcb000
Command: malloc(size=64, alignment=32)
Malloc: address = 0xca860
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca890
Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0)
```
{F6288839}
Differential Revision: https://reviews.llvm.org/D47508
llvm-svn: 333583
2018-05-31 03:39:10 +08:00
|
|
|
cl::SubCommand IRMemoryMapSubcommand("ir-memory-map", "Test IRMemoryMap");
|
2021-03-20 05:20:26 +08:00
|
|
|
cl::SubCommand AssertSubcommand("assert", "Test assert handling");
|
2018-06-01 06:09:00 +08:00
|
|
|
|
[lldb-test] Add a testing harness for the JIT's IRMemoryMap
This teaches lldb-test how to launch a process, set up an IRMemoryMap,
and issue memory allocations in the target process through the map. This
makes it possible to test IRMemoryMap in a targeted way.
This has uncovered two bugs so far. The first bug is that Malloc
performs an adjustment on the pointer returned from AllocateMemory (for
alignment purposes) which ultimately allows overlapping memory regions
to be created. The second bug is that after most of the address space on
the host side is exhausted, Malloc may return the same address multiple
times. These bugs (and hopefully more!) can be uncovered and tested for
with targeted lldb-test commands.
At an even higher level, the motivation for addressing these bugs is
that they can lead to strange user-visible failures (e.g, variables
assume the wrong value during expression evaluation, or the debugger
crashes). See my third comment on this swift-lldb PR for an example:
https://github.com/apple/swift-lldb/pull/652
I hope lldb-test is the right place to add this testing harness. Setting
up a gtest-style unit test proved too cumbersome (you need to recreate
or mock way too much debugger state), as did writing end-to-end tests
(it's hard to write a test that actually hits a buggy path).
With lldb-test, it's easy to read/generate the test input and parse the
test output. I'll attach a simple "fuzz" tester which generates failing
test cases to the Phab review. Here's an example:
```
Command: malloc(size=1024, alignment=32)
Malloc: address = 0xca000
Command: malloc(size=64, alignment=16)
Malloc: address = 0xca400
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca440
Command: malloc(size=16, alignment=8)
Malloc: address = 0xca840
Command: malloc(size=2048, alignment=16)
Malloc: address = 0xcb000
Command: malloc(size=64, alignment=32)
Malloc: address = 0xca860
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca890
Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0)
```
{F6288839}
Differential Revision: https://reviews.llvm.org/D47508
llvm-svn: 333583
2018-05-31 03:39:10 +08:00
|
|
|
cl::opt<std::string> Log("log", cl::desc("Path to a log file"), cl::init(""),
|
2018-06-01 06:09:00 +08:00
|
|
|
cl::sub(BreakpointSubcommand),
|
2018-06-29 20:15:54 +08:00
|
|
|
cl::sub(ObjectFileSubcommand),
|
|
|
|
cl::sub(SymbolsSubcommand),
|
[lldb-test] Add a testing harness for the JIT's IRMemoryMap
This teaches lldb-test how to launch a process, set up an IRMemoryMap,
and issue memory allocations in the target process through the map. This
makes it possible to test IRMemoryMap in a targeted way.
This has uncovered two bugs so far. The first bug is that Malloc
performs an adjustment on the pointer returned from AllocateMemory (for
alignment purposes) which ultimately allows overlapping memory regions
to be created. The second bug is that after most of the address space on
the host side is exhausted, Malloc may return the same address multiple
times. These bugs (and hopefully more!) can be uncovered and tested for
with targeted lldb-test commands.
At an even higher level, the motivation for addressing these bugs is
that they can lead to strange user-visible failures (e.g, variables
assume the wrong value during expression evaluation, or the debugger
crashes). See my third comment on this swift-lldb PR for an example:
https://github.com/apple/swift-lldb/pull/652
I hope lldb-test is the right place to add this testing harness. Setting
up a gtest-style unit test proved too cumbersome (you need to recreate
or mock way too much debugger state), as did writing end-to-end tests
(it's hard to write a test that actually hits a buggy path).
With lldb-test, it's easy to read/generate the test input and parse the
test output. I'll attach a simple "fuzz" tester which generates failing
test cases to the Phab review. Here's an example:
```
Command: malloc(size=1024, alignment=32)
Malloc: address = 0xca000
Command: malloc(size=64, alignment=16)
Malloc: address = 0xca400
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca440
Command: malloc(size=16, alignment=8)
Malloc: address = 0xca840
Command: malloc(size=2048, alignment=16)
Malloc: address = 0xcb000
Command: malloc(size=64, alignment=32)
Malloc: address = 0xca860
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca890
Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0)
```
{F6288839}
Differential Revision: https://reviews.llvm.org/D47508
llvm-svn: 333583
2018-05-31 03:39:10 +08:00
|
|
|
cl::sub(IRMemoryMapSubcommand));
|
|
|
|
|
|
|
|
/// Create a target using the file pointed to by \p Filename, or abort.
|
|
|
|
TargetSP createTarget(Debugger &Dbg, const std::string &Filename);
|
|
|
|
|
|
|
|
/// Read \p Filename into a null-terminated buffer, or abort.
|
|
|
|
std::unique_ptr<MemoryBuffer> openFile(const std::string &Filename);
|
2017-12-01 08:52:51 +08:00
|
|
|
|
Add "lldb-test breakpoint" command and convert the case-sensitivity test to use it
Summary:
The command takes two input arguments: a module to use as a debug target
and a file containing a list of commands. The command will execute each
of the breakpoint commands in the file and dump the breakpoint state
after each one.
The commands are expected to be breakpoint set/remove/etc. commands, but
I explicitly allow any lldb command here, so you can do things like
change setting which impact breakpoint resolution, etc. There is also a
"-persistent" flag, which causes lldb-test to *not* automatically clear
the breakpoint list after each command. Right now I don't use it, but
the idea behind it was that it could be used to test more complex
combinations of breakpoint commands (set+modify, set+disable, etc.).
Right now the command prints out only the basic breakpoint state, but
more information can be easily added there. To enable easy matching of
the "at least one breakpoint location found" state, the command
explicitly prints out the string "At least one breakpoint location.".
To enable testing of breakpoints set with an absolute paths, I add the
ability to perform rudimentary substitutions on the commands: right now
the string %p is replaced by the directory which contains the command
file (so, under normal circumstances, this will perform the same
substitution as lit would do for %p).
I use this command to rewrite the TestBreakpointCaseSensitivity test --
the test was checking about a dozen breakpoint commands, but it was
launching a new process for each one, so it took about 90 seconds to
run. The new test takes about 0.3 seconds for me, which is approximately
a 300x speedup.
Reviewers: davide, zturner, jingham
Subscribers: luporl, lldb-commits
Differential Revision: https://reviews.llvm.org/D43686
llvm-svn: 326112
2018-02-27 02:50:16 +08:00
|
|
|
namespace breakpoint {
|
|
|
|
static cl::opt<std::string> Target(cl::Positional, cl::desc("<target>"),
|
|
|
|
cl::Required, cl::sub(BreakpointSubcommand));
|
|
|
|
static cl::opt<std::string> CommandFile(cl::Positional,
|
|
|
|
cl::desc("<command-file>"),
|
|
|
|
cl::init("-"),
|
|
|
|
cl::sub(BreakpointSubcommand));
|
|
|
|
static cl::opt<bool> Persistent(
|
|
|
|
"persistent",
|
|
|
|
cl::desc("Don't automatically remove all breakpoints before each command"),
|
|
|
|
cl::sub(BreakpointSubcommand));
|
|
|
|
|
|
|
|
static llvm::StringRef plural(uintmax_t value) { return value == 1 ? "" : "s"; }
|
|
|
|
static void dumpState(const BreakpointList &List, LinePrinter &P);
|
|
|
|
static std::string substitute(StringRef Cmd);
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
static int evaluateBreakpoints(Debugger &Dbg);
|
Add "lldb-test breakpoint" command and convert the case-sensitivity test to use it
Summary:
The command takes two input arguments: a module to use as a debug target
and a file containing a list of commands. The command will execute each
of the breakpoint commands in the file and dump the breakpoint state
after each one.
The commands are expected to be breakpoint set/remove/etc. commands, but
I explicitly allow any lldb command here, so you can do things like
change setting which impact breakpoint resolution, etc. There is also a
"-persistent" flag, which causes lldb-test to *not* automatically clear
the breakpoint list after each command. Right now I don't use it, but
the idea behind it was that it could be used to test more complex
combinations of breakpoint commands (set+modify, set+disable, etc.).
Right now the command prints out only the basic breakpoint state, but
more information can be easily added there. To enable easy matching of
the "at least one breakpoint location found" state, the command
explicitly prints out the string "At least one breakpoint location.".
To enable testing of breakpoints set with an absolute paths, I add the
ability to perform rudimentary substitutions on the commands: right now
the string %p is replaced by the directory which contains the command
file (so, under normal circumstances, this will perform the same
substitution as lit would do for %p).
I use this command to rewrite the TestBreakpointCaseSensitivity test --
the test was checking about a dozen breakpoint commands, but it was
launching a new process for each one, so it took about 90 seconds to
run. The new test takes about 0.3 seconds for me, which is approximately
a 300x speedup.
Reviewers: davide, zturner, jingham
Subscribers: luporl, lldb-commits
Differential Revision: https://reviews.llvm.org/D43686
llvm-svn: 326112
2018-02-27 02:50:16 +08:00
|
|
|
} // namespace breakpoint
|
|
|
|
|
2018-06-29 20:15:54 +08:00
|
|
|
namespace object {
|
2017-12-01 08:52:51 +08:00
|
|
|
cl::opt<bool> SectionContents("contents",
|
|
|
|
cl::desc("Dump each section's contents"),
|
2018-06-29 20:15:54 +08:00
|
|
|
cl::sub(ObjectFileSubcommand));
|
[pecoff] Implement ObjectFilePECOFF::GetDependedModules()
Summary:
This parses entries in pecoff import tables for imported DLLs and
is intended as the first step to allow LLDB to load a PE's shared
modules when creating a target on the LLDB console.
Reviewers: rnk, zturner, aleksandr.urakov, lldb-commits, labath, asmith
Reviewed By: labath, asmith
Subscribers: labath, lemo, clayborg, Hui, mgorny, mgrang, teemperor
Differential Revision: https://reviews.llvm.org/D53094
llvm-svn: 348527
2018-12-07 05:36:39 +08:00
|
|
|
cl::opt<bool> SectionDependentModules("dep-modules",
|
|
|
|
cl::desc("Dump each dependent module"),
|
|
|
|
cl::sub(ObjectFileSubcommand));
|
2017-12-01 08:52:51 +08:00
|
|
|
cl::list<std::string> InputFilenames(cl::Positional, cl::desc("<input files>"),
|
2018-06-29 20:15:54 +08:00
|
|
|
cl::OneOrMore,
|
|
|
|
cl::sub(ObjectFileSubcommand));
|
|
|
|
} // namespace object
|
2017-12-02 08:15:29 +08:00
|
|
|
|
|
|
|
namespace symbols {
|
Introduce SymbolFileBreakpad and use it to fill symtab
Summary:
This commit adds the glue code necessary to integrate the
SymbolFileBreakpad into the plugin system. Most of the methods are
stubbed out. The only method implemented method is AddSymbols, which
parses the PUBLIC "section" of the breakpad "object file", and fills out
the Module's symtab.
To enable testing this, I've made two additional changes:
- dump Symtab from the SymbolVendor class. The symtab was already being
dumped as a part of the object file dump, but that happened before
symbol vendor kicked in, so it did not reflect any symbols added
there.
- add ability to explicitly specify the external symbol file in
lldb-test (so that the object file could be linked with the breakpad
symbol file). To make things simpler, I've changed lldb-test from
consuming multiple inputs (and dumping their symbols) to having it
just process a single file per invocation. This was not a problem
since everyone was using it that way already.
Reviewers: clayborg, zturner, lemo, markmentovai, amccarth
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D56173
llvm-svn: 350924
2019-01-11 19:17:51 +08:00
|
|
|
static cl::opt<std::string> InputFile(cl::Positional, cl::desc("<input file>"),
|
|
|
|
cl::Required, cl::sub(SymbolsSubcommand));
|
|
|
|
|
|
|
|
static cl::opt<std::string>
|
|
|
|
SymbolPath("symbol-file",
|
|
|
|
cl::desc("The file from which to fetch symbol information."),
|
|
|
|
cl::value_desc("file"), cl::sub(SymbolsSubcommand));
|
|
|
|
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
enum class FindType {
|
|
|
|
None,
|
|
|
|
Function,
|
2018-08-29 15:26:11 +08:00
|
|
|
Block,
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
Namespace,
|
|
|
|
Type,
|
|
|
|
Variable,
|
|
|
|
};
|
|
|
|
static cl::opt<FindType> Find(
|
|
|
|
"find", cl::desc("Choose search type:"),
|
|
|
|
cl::values(
|
2018-06-28 18:03:42 +08:00
|
|
|
clEnumValN(FindType::None, "none", "No search, just dump the module."),
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
clEnumValN(FindType::Function, "function", "Find functions."),
|
2018-08-29 15:26:11 +08:00
|
|
|
clEnumValN(FindType::Block, "block", "Find blocks."),
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
clEnumValN(FindType::Namespace, "namespace", "Find namespaces."),
|
|
|
|
clEnumValN(FindType::Type, "type", "Find types."),
|
|
|
|
clEnumValN(FindType::Variable, "variable", "Find global variables.")),
|
|
|
|
cl::sub(SymbolsSubcommand));
|
|
|
|
|
|
|
|
static cl::opt<std::string> Name("name", cl::desc("Name to find."),
|
|
|
|
cl::sub(SymbolsSubcommand));
|
|
|
|
static cl::opt<bool>
|
|
|
|
Regex("regex",
|
2020-04-07 00:06:02 +08:00
|
|
|
cl::desc("Search using regular expressions (available for variables "
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
"and functions only)."),
|
|
|
|
cl::sub(SymbolsSubcommand));
|
|
|
|
static cl::opt<std::string>
|
|
|
|
Context("context",
|
|
|
|
cl::desc("Restrict search to the context of the given variable."),
|
|
|
|
cl::value_desc("variable"), cl::sub(SymbolsSubcommand));
|
|
|
|
|
2019-08-21 00:44:25 +08:00
|
|
|
static cl::opt<std::string> CompilerContext(
|
|
|
|
"compiler-context",
|
|
|
|
cl::desc("Specify a compiler context as \"kind:name,...\"."),
|
|
|
|
cl::value_desc("context"), cl::sub(SymbolsSubcommand));
|
|
|
|
|
2019-08-23 05:45:58 +08:00
|
|
|
static cl::opt<std::string>
|
|
|
|
Language("language", cl::desc("Specify a language type, like C99."),
|
|
|
|
cl::value_desc("language"), cl::sub(SymbolsSubcommand));
|
|
|
|
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
static cl::list<FunctionNameType> FunctionNameFlags(
|
|
|
|
"function-flags", cl::desc("Function search flags:"),
|
|
|
|
cl::values(clEnumValN(eFunctionNameTypeAuto, "auto",
|
|
|
|
"Automatically deduce flags based on name."),
|
|
|
|
clEnumValN(eFunctionNameTypeFull, "full", "Full function name."),
|
|
|
|
clEnumValN(eFunctionNameTypeBase, "base", "Base name."),
|
|
|
|
clEnumValN(eFunctionNameTypeMethod, "method", "Method name."),
|
|
|
|
clEnumValN(eFunctionNameTypeSelector, "selector",
|
|
|
|
"Selector name.")),
|
|
|
|
cl::sub(SymbolsSubcommand));
|
|
|
|
static FunctionNameType getFunctionNameFlags() {
|
|
|
|
FunctionNameType Result = FunctionNameType(0);
|
|
|
|
for (FunctionNameType Flag : FunctionNameFlags)
|
|
|
|
Result = FunctionNameType(Result | Flag);
|
|
|
|
return Result;
|
2017-12-02 08:15:29 +08:00
|
|
|
}
|
2017-12-01 08:52:51 +08:00
|
|
|
|
[PDB] Restore AST from PDB symbols
Summary:
This patch adds an implementation of retrieving of declarations and declaration
contexts based on PDB symbols.
PDB has different type symbols for const-qualified types, and this
implementation ensures that only one declaration was created for both const
and non-const types, but creates different compiler types for them.
The implementation also processes the case when there are two symbols
corresponding to a variable. It's possible e.g. for class static variables,
they has one global symbol and one symbol belonging to a class.
PDB has no info about namespaces, so this implementation parses the full symbol
name and tries to figure out if the symbol belongs to namespace or not,
and then creates nested namespaces if necessary.
Reviewers: asmith, zturner, labath
Reviewed By: asmith
Subscribers: aleksandr.urakov, teemperor, lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D51162
llvm-svn: 341782
2018-09-10 16:08:43 +08:00
|
|
|
static cl::opt<bool> DumpAST("dump-ast",
|
|
|
|
cl::desc("Dump AST restored from symbols."),
|
|
|
|
cl::sub(SymbolsSubcommand));
|
2020-04-17 05:10:23 +08:00
|
|
|
static cl::opt<bool> DumpClangAST(
|
|
|
|
"dump-clang-ast",
|
|
|
|
cl::desc("Dump clang AST restored from symbols. When used on its own this "
|
|
|
|
"will dump the entire AST of all loaded symbols. When combined "
|
|
|
|
"with -find, it changes the presentation of the search results "
|
|
|
|
"from pretty-printing the types to an AST dump."),
|
|
|
|
cl::sub(SymbolsSubcommand));
|
[PDB] Restore AST from PDB symbols
Summary:
This patch adds an implementation of retrieving of declarations and declaration
contexts based on PDB symbols.
PDB has different type symbols for const-qualified types, and this
implementation ensures that only one declaration was created for both const
and non-const types, but creates different compiler types for them.
The implementation also processes the case when there are two symbols
corresponding to a variable. It's possible e.g. for class static variables,
they has one global symbol and one symbol belonging to a class.
PDB has no info about namespaces, so this implementation parses the full symbol
name and tries to figure out if the symbol belongs to namespace or not,
and then creates nested namespaces if necessary.
Reviewers: asmith, zturner, labath
Reviewed By: asmith
Subscribers: aleksandr.urakov, teemperor, lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D51162
llvm-svn: 341782
2018-09-10 16:08:43 +08:00
|
|
|
|
2018-06-08 10:45:25 +08:00
|
|
|
static cl::opt<bool> Verify("verify", cl::desc("Verify symbol information."),
|
|
|
|
cl::sub(SymbolsSubcommand));
|
|
|
|
|
2018-06-12 20:57:36 +08:00
|
|
|
static cl::opt<std::string> File("file",
|
|
|
|
cl::desc("File (compile unit) to search."),
|
|
|
|
cl::sub(SymbolsSubcommand));
|
2018-06-28 18:03:42 +08:00
|
|
|
static cl::opt<int> Line("line", cl::desc("Line to search."),
|
|
|
|
cl::sub(SymbolsSubcommand));
|
2018-06-12 20:57:36 +08:00
|
|
|
|
2019-08-06 17:12:42 +08:00
|
|
|
static Expected<CompilerDeclContext> getDeclContext(SymbolFile &Symfile);
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
|
|
|
|
static Error findFunctions(lldb_private::Module &Module);
|
2018-08-29 15:26:11 +08:00
|
|
|
static Error findBlocks(lldb_private::Module &Module);
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
static Error findNamespaces(lldb_private::Module &Module);
|
|
|
|
static Error findTypes(lldb_private::Module &Module);
|
|
|
|
static Error findVariables(lldb_private::Module &Module);
|
|
|
|
static Error dumpModule(lldb_private::Module &Module);
|
[PDB] Restore AST from PDB symbols
Summary:
This patch adds an implementation of retrieving of declarations and declaration
contexts based on PDB symbols.
PDB has different type symbols for const-qualified types, and this
implementation ensures that only one declaration was created for both const
and non-const types, but creates different compiler types for them.
The implementation also processes the case when there are two symbols
corresponding to a variable. It's possible e.g. for class static variables,
they has one global symbol and one symbol belonging to a class.
PDB has no info about namespaces, so this implementation parses the full symbol
name and tries to figure out if the symbol belongs to namespace or not,
and then creates nested namespaces if necessary.
Reviewers: asmith, zturner, labath
Reviewed By: asmith
Subscribers: aleksandr.urakov, teemperor, lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D51162
llvm-svn: 341782
2018-09-10 16:08:43 +08:00
|
|
|
static Error dumpAST(lldb_private::Module &Module);
|
2020-04-17 05:10:23 +08:00
|
|
|
static Error dumpEntireClangAST(lldb_private::Module &Module);
|
2018-06-08 10:45:25 +08:00
|
|
|
static Error verify(lldb_private::Module &Module);
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
|
2018-06-12 21:26:43 +08:00
|
|
|
static Expected<Error (*)(lldb_private::Module &)> getAction();
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
static int dumpSymbols(Debugger &Dbg);
|
2018-06-28 18:03:42 +08:00
|
|
|
} // namespace symbols
|
[lldb-test] Add a testing harness for the JIT's IRMemoryMap
This teaches lldb-test how to launch a process, set up an IRMemoryMap,
and issue memory allocations in the target process through the map. This
makes it possible to test IRMemoryMap in a targeted way.
This has uncovered two bugs so far. The first bug is that Malloc
performs an adjustment on the pointer returned from AllocateMemory (for
alignment purposes) which ultimately allows overlapping memory regions
to be created. The second bug is that after most of the address space on
the host side is exhausted, Malloc may return the same address multiple
times. These bugs (and hopefully more!) can be uncovered and tested for
with targeted lldb-test commands.
At an even higher level, the motivation for addressing these bugs is
that they can lead to strange user-visible failures (e.g, variables
assume the wrong value during expression evaluation, or the debugger
crashes). See my third comment on this swift-lldb PR for an example:
https://github.com/apple/swift-lldb/pull/652
I hope lldb-test is the right place to add this testing harness. Setting
up a gtest-style unit test proved too cumbersome (you need to recreate
or mock way too much debugger state), as did writing end-to-end tests
(it's hard to write a test that actually hits a buggy path).
With lldb-test, it's easy to read/generate the test input and parse the
test output. I'll attach a simple "fuzz" tester which generates failing
test cases to the Phab review. Here's an example:
```
Command: malloc(size=1024, alignment=32)
Malloc: address = 0xca000
Command: malloc(size=64, alignment=16)
Malloc: address = 0xca400
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca440
Command: malloc(size=16, alignment=8)
Malloc: address = 0xca840
Command: malloc(size=2048, alignment=16)
Malloc: address = 0xcb000
Command: malloc(size=64, alignment=32)
Malloc: address = 0xca860
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca890
Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0)
```
{F6288839}
Differential Revision: https://reviews.llvm.org/D47508
llvm-svn: 333583
2018-05-31 03:39:10 +08:00
|
|
|
|
|
|
|
namespace irmemorymap {
|
|
|
|
static cl::opt<std::string> Target(cl::Positional, cl::desc("<target>"),
|
|
|
|
cl::Required,
|
|
|
|
cl::sub(IRMemoryMapSubcommand));
|
|
|
|
static cl::opt<std::string> CommandFile(cl::Positional,
|
|
|
|
cl::desc("<command-file>"),
|
|
|
|
cl::init("-"),
|
|
|
|
cl::sub(IRMemoryMapSubcommand));
|
2018-06-01 06:09:00 +08:00
|
|
|
static cl::opt<bool> UseHostOnlyAllocationPolicy(
|
|
|
|
"host-only", cl::desc("Use the host-only allocation policy"),
|
|
|
|
cl::init(false), cl::sub(IRMemoryMapSubcommand));
|
|
|
|
|
[lldb-test] Add a testing harness for the JIT's IRMemoryMap
This teaches lldb-test how to launch a process, set up an IRMemoryMap,
and issue memory allocations in the target process through the map. This
makes it possible to test IRMemoryMap in a targeted way.
This has uncovered two bugs so far. The first bug is that Malloc
performs an adjustment on the pointer returned from AllocateMemory (for
alignment purposes) which ultimately allows overlapping memory regions
to be created. The second bug is that after most of the address space on
the host side is exhausted, Malloc may return the same address multiple
times. These bugs (and hopefully more!) can be uncovered and tested for
with targeted lldb-test commands.
At an even higher level, the motivation for addressing these bugs is
that they can lead to strange user-visible failures (e.g, variables
assume the wrong value during expression evaluation, or the debugger
crashes). See my third comment on this swift-lldb PR for an example:
https://github.com/apple/swift-lldb/pull/652
I hope lldb-test is the right place to add this testing harness. Setting
up a gtest-style unit test proved too cumbersome (you need to recreate
or mock way too much debugger state), as did writing end-to-end tests
(it's hard to write a test that actually hits a buggy path).
With lldb-test, it's easy to read/generate the test input and parse the
test output. I'll attach a simple "fuzz" tester which generates failing
test cases to the Phab review. Here's an example:
```
Command: malloc(size=1024, alignment=32)
Malloc: address = 0xca000
Command: malloc(size=64, alignment=16)
Malloc: address = 0xca400
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca440
Command: malloc(size=16, alignment=8)
Malloc: address = 0xca840
Command: malloc(size=2048, alignment=16)
Malloc: address = 0xcb000
Command: malloc(size=64, alignment=32)
Malloc: address = 0xca860
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca890
Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0)
```
{F6288839}
Differential Revision: https://reviews.llvm.org/D47508
llvm-svn: 333583
2018-05-31 03:39:10 +08:00
|
|
|
using AllocationT = std::pair<addr_t, addr_t>;
|
|
|
|
using AddrIntervalMap =
|
2018-06-28 18:03:42 +08:00
|
|
|
IntervalMap<addr_t, unsigned, 8, IntervalMapHalfOpenInfo<addr_t>>;
|
2018-06-05 01:11:15 +08:00
|
|
|
|
|
|
|
struct IRMemoryMapTestState {
|
|
|
|
TargetSP Target;
|
|
|
|
IRMemoryMap Map;
|
|
|
|
|
|
|
|
AddrIntervalMap::Allocator IntervalMapAllocator;
|
|
|
|
AddrIntervalMap Allocations;
|
|
|
|
|
|
|
|
StringMap<addr_t> Label2AddrMap;
|
|
|
|
|
|
|
|
IRMemoryMapTestState(TargetSP Target)
|
|
|
|
: Target(Target), Map(Target), Allocations(IntervalMapAllocator) {}
|
|
|
|
};
|
|
|
|
|
|
|
|
bool evalMalloc(StringRef Line, IRMemoryMapTestState &State);
|
|
|
|
bool evalFree(StringRef Line, IRMemoryMapTestState &State);
|
[lldb-test] Add a testing harness for the JIT's IRMemoryMap
This teaches lldb-test how to launch a process, set up an IRMemoryMap,
and issue memory allocations in the target process through the map. This
makes it possible to test IRMemoryMap in a targeted way.
This has uncovered two bugs so far. The first bug is that Malloc
performs an adjustment on the pointer returned from AllocateMemory (for
alignment purposes) which ultimately allows overlapping memory regions
to be created. The second bug is that after most of the address space on
the host side is exhausted, Malloc may return the same address multiple
times. These bugs (and hopefully more!) can be uncovered and tested for
with targeted lldb-test commands.
At an even higher level, the motivation for addressing these bugs is
that they can lead to strange user-visible failures (e.g, variables
assume the wrong value during expression evaluation, or the debugger
crashes). See my third comment on this swift-lldb PR for an example:
https://github.com/apple/swift-lldb/pull/652
I hope lldb-test is the right place to add this testing harness. Setting
up a gtest-style unit test proved too cumbersome (you need to recreate
or mock way too much debugger state), as did writing end-to-end tests
(it's hard to write a test that actually hits a buggy path).
With lldb-test, it's easy to read/generate the test input and parse the
test output. I'll attach a simple "fuzz" tester which generates failing
test cases to the Phab review. Here's an example:
```
Command: malloc(size=1024, alignment=32)
Malloc: address = 0xca000
Command: malloc(size=64, alignment=16)
Malloc: address = 0xca400
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca440
Command: malloc(size=16, alignment=8)
Malloc: address = 0xca840
Command: malloc(size=2048, alignment=16)
Malloc: address = 0xcb000
Command: malloc(size=64, alignment=32)
Malloc: address = 0xca860
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca890
Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0)
```
{F6288839}
Differential Revision: https://reviews.llvm.org/D47508
llvm-svn: 333583
2018-05-31 03:39:10 +08:00
|
|
|
int evaluateMemoryMapCommands(Debugger &Dbg);
|
|
|
|
} // namespace irmemorymap
|
|
|
|
|
2021-03-20 05:20:26 +08:00
|
|
|
namespace assert {
|
|
|
|
int lldb_assert(Debugger &Dbg);
|
|
|
|
} // namespace assert
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
} // namespace opts
|
2017-12-01 08:52:51 +08:00
|
|
|
|
2019-08-21 00:44:25 +08:00
|
|
|
std::vector<CompilerContext> parseCompilerContext() {
|
|
|
|
std::vector<CompilerContext> result;
|
|
|
|
if (opts::symbols::CompilerContext.empty())
|
|
|
|
return result;
|
|
|
|
|
|
|
|
StringRef str{opts::symbols::CompilerContext};
|
|
|
|
SmallVector<StringRef, 8> entries_str;
|
|
|
|
str.split(entries_str, ',', /*maxSplit*/-1, /*keepEmpty=*/false);
|
|
|
|
for (auto entry_str : entries_str) {
|
|
|
|
StringRef key, value;
|
|
|
|
std::tie(key, value) = entry_str.split(':');
|
|
|
|
auto kind =
|
|
|
|
StringSwitch<CompilerContextKind>(key)
|
|
|
|
.Case("TranslationUnit", CompilerContextKind::TranslationUnit)
|
|
|
|
.Case("Module", CompilerContextKind::Module)
|
|
|
|
.Case("Namespace", CompilerContextKind::Namespace)
|
|
|
|
.Case("Class", CompilerContextKind::Class)
|
2019-08-22 02:06:56 +08:00
|
|
|
.Case("Struct", CompilerContextKind::Struct)
|
2019-08-21 00:44:25 +08:00
|
|
|
.Case("Union", CompilerContextKind::Union)
|
|
|
|
.Case("Function", CompilerContextKind::Function)
|
|
|
|
.Case("Variable", CompilerContextKind::Variable)
|
2019-08-22 02:06:56 +08:00
|
|
|
.Case("Enum", CompilerContextKind::Enum)
|
2019-08-21 00:44:25 +08:00
|
|
|
.Case("Typedef", CompilerContextKind::Typedef)
|
2019-08-22 02:06:56 +08:00
|
|
|
.Case("AnyModule", CompilerContextKind::AnyModule)
|
|
|
|
.Case("AnyType", CompilerContextKind::AnyType)
|
2019-08-21 00:44:25 +08:00
|
|
|
.Default(CompilerContextKind::Invalid);
|
|
|
|
if (value.empty()) {
|
|
|
|
WithColor::error() << "compiler context entry has no \"name\"\n";
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
result.push_back({kind, ConstString{value}});
|
|
|
|
}
|
|
|
|
outs() << "Search context: {\n";
|
|
|
|
for (auto entry: result)
|
|
|
|
entry.Dump();
|
|
|
|
outs() << "}\n";
|
|
|
|
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
2018-06-12 20:57:36 +08:00
|
|
|
template <typename... Args>
|
|
|
|
static Error make_string_error(const char *Format, Args &&... args) {
|
|
|
|
return llvm::make_error<llvm::StringError>(
|
|
|
|
llvm::formatv(Format, std::forward<Args>(args)...).str(),
|
|
|
|
llvm::inconvertibleErrorCode());
|
|
|
|
}
|
|
|
|
|
[lldb-test] Add a testing harness for the JIT's IRMemoryMap
This teaches lldb-test how to launch a process, set up an IRMemoryMap,
and issue memory allocations in the target process through the map. This
makes it possible to test IRMemoryMap in a targeted way.
This has uncovered two bugs so far. The first bug is that Malloc
performs an adjustment on the pointer returned from AllocateMemory (for
alignment purposes) which ultimately allows overlapping memory regions
to be created. The second bug is that after most of the address space on
the host side is exhausted, Malloc may return the same address multiple
times. These bugs (and hopefully more!) can be uncovered and tested for
with targeted lldb-test commands.
At an even higher level, the motivation for addressing these bugs is
that they can lead to strange user-visible failures (e.g, variables
assume the wrong value during expression evaluation, or the debugger
crashes). See my third comment on this swift-lldb PR for an example:
https://github.com/apple/swift-lldb/pull/652
I hope lldb-test is the right place to add this testing harness. Setting
up a gtest-style unit test proved too cumbersome (you need to recreate
or mock way too much debugger state), as did writing end-to-end tests
(it's hard to write a test that actually hits a buggy path).
With lldb-test, it's easy to read/generate the test input and parse the
test output. I'll attach a simple "fuzz" tester which generates failing
test cases to the Phab review. Here's an example:
```
Command: malloc(size=1024, alignment=32)
Malloc: address = 0xca000
Command: malloc(size=64, alignment=16)
Malloc: address = 0xca400
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca440
Command: malloc(size=16, alignment=8)
Malloc: address = 0xca840
Command: malloc(size=2048, alignment=16)
Malloc: address = 0xcb000
Command: malloc(size=64, alignment=32)
Malloc: address = 0xca860
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca890
Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0)
```
{F6288839}
Differential Revision: https://reviews.llvm.org/D47508
llvm-svn: 333583
2018-05-31 03:39:10 +08:00
|
|
|
TargetSP opts::createTarget(Debugger &Dbg, const std::string &Filename) {
|
|
|
|
TargetSP Target;
|
2018-09-20 17:09:05 +08:00
|
|
|
Status ST = Dbg.GetTargetList().CreateTarget(
|
|
|
|
Dbg, Filename, /*triple*/ "", eLoadDependentsNo,
|
|
|
|
/*platform_options*/ nullptr, Target);
|
[lldb-test] Add a testing harness for the JIT's IRMemoryMap
This teaches lldb-test how to launch a process, set up an IRMemoryMap,
and issue memory allocations in the target process through the map. This
makes it possible to test IRMemoryMap in a targeted way.
This has uncovered two bugs so far. The first bug is that Malloc
performs an adjustment on the pointer returned from AllocateMemory (for
alignment purposes) which ultimately allows overlapping memory regions
to be created. The second bug is that after most of the address space on
the host side is exhausted, Malloc may return the same address multiple
times. These bugs (and hopefully more!) can be uncovered and tested for
with targeted lldb-test commands.
At an even higher level, the motivation for addressing these bugs is
that they can lead to strange user-visible failures (e.g, variables
assume the wrong value during expression evaluation, or the debugger
crashes). See my third comment on this swift-lldb PR for an example:
https://github.com/apple/swift-lldb/pull/652
I hope lldb-test is the right place to add this testing harness. Setting
up a gtest-style unit test proved too cumbersome (you need to recreate
or mock way too much debugger state), as did writing end-to-end tests
(it's hard to write a test that actually hits a buggy path).
With lldb-test, it's easy to read/generate the test input and parse the
test output. I'll attach a simple "fuzz" tester which generates failing
test cases to the Phab review. Here's an example:
```
Command: malloc(size=1024, alignment=32)
Malloc: address = 0xca000
Command: malloc(size=64, alignment=16)
Malloc: address = 0xca400
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca440
Command: malloc(size=16, alignment=8)
Malloc: address = 0xca840
Command: malloc(size=2048, alignment=16)
Malloc: address = 0xcb000
Command: malloc(size=64, alignment=32)
Malloc: address = 0xca860
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca890
Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0)
```
{F6288839}
Differential Revision: https://reviews.llvm.org/D47508
llvm-svn: 333583
2018-05-31 03:39:10 +08:00
|
|
|
if (ST.Fail()) {
|
|
|
|
errs() << formatv("Failed to create target '{0}: {1}\n", Filename, ST);
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
return Target;
|
|
|
|
}
|
|
|
|
|
|
|
|
std::unique_ptr<MemoryBuffer> opts::openFile(const std::string &Filename) {
|
|
|
|
auto MB = MemoryBuffer::getFileOrSTDIN(Filename);
|
|
|
|
if (!MB) {
|
|
|
|
errs() << formatv("Could not open file '{0}: {1}\n", Filename,
|
|
|
|
MB.getError().message());
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
return std::move(*MB);
|
|
|
|
}
|
|
|
|
|
Add "lldb-test breakpoint" command and convert the case-sensitivity test to use it
Summary:
The command takes two input arguments: a module to use as a debug target
and a file containing a list of commands. The command will execute each
of the breakpoint commands in the file and dump the breakpoint state
after each one.
The commands are expected to be breakpoint set/remove/etc. commands, but
I explicitly allow any lldb command here, so you can do things like
change setting which impact breakpoint resolution, etc. There is also a
"-persistent" flag, which causes lldb-test to *not* automatically clear
the breakpoint list after each command. Right now I don't use it, but
the idea behind it was that it could be used to test more complex
combinations of breakpoint commands (set+modify, set+disable, etc.).
Right now the command prints out only the basic breakpoint state, but
more information can be easily added there. To enable easy matching of
the "at least one breakpoint location found" state, the command
explicitly prints out the string "At least one breakpoint location.".
To enable testing of breakpoints set with an absolute paths, I add the
ability to perform rudimentary substitutions on the commands: right now
the string %p is replaced by the directory which contains the command
file (so, under normal circumstances, this will perform the same
substitution as lit would do for %p).
I use this command to rewrite the TestBreakpointCaseSensitivity test --
the test was checking about a dozen breakpoint commands, but it was
launching a new process for each one, so it took about 90 seconds to
run. The new test takes about 0.3 seconds for me, which is approximately
a 300x speedup.
Reviewers: davide, zturner, jingham
Subscribers: luporl, lldb-commits
Differential Revision: https://reviews.llvm.org/D43686
llvm-svn: 326112
2018-02-27 02:50:16 +08:00
|
|
|
void opts::breakpoint::dumpState(const BreakpointList &List, LinePrinter &P) {
|
|
|
|
P.formatLine("{0} breakpoint{1}", List.GetSize(), plural(List.GetSize()));
|
|
|
|
if (List.GetSize() > 0)
|
|
|
|
P.formatLine("At least one breakpoint.");
|
|
|
|
for (size_t i = 0, e = List.GetSize(); i < e; ++i) {
|
|
|
|
BreakpointSP BP = List.GetBreakpointAtIndex(i);
|
|
|
|
P.formatLine("Breakpoint ID {0}:", BP->GetID());
|
|
|
|
AutoIndent Indent(P, 2);
|
|
|
|
P.formatLine("{0} location{1}.", BP->GetNumLocations(),
|
|
|
|
plural(BP->GetNumLocations()));
|
|
|
|
if (BP->GetNumLocations() > 0)
|
|
|
|
P.formatLine("At least one location.");
|
|
|
|
P.formatLine("{0} resolved location{1}.", BP->GetNumResolvedLocations(),
|
|
|
|
plural(BP->GetNumResolvedLocations()));
|
|
|
|
if (BP->GetNumResolvedLocations() > 0)
|
|
|
|
P.formatLine("At least one resolved location.");
|
|
|
|
for (size_t l = 0, le = BP->GetNumLocations(); l < le; ++l) {
|
|
|
|
BreakpointLocationSP Loc = BP->GetLocationAtIndex(l);
|
|
|
|
P.formatLine("Location ID {0}:", Loc->GetID());
|
|
|
|
AutoIndent Indent(P, 2);
|
|
|
|
P.formatLine("Enabled: {0}", Loc->IsEnabled());
|
|
|
|
P.formatLine("Resolved: {0}", Loc->IsResolved());
|
2018-03-13 05:17:04 +08:00
|
|
|
SymbolContext sc;
|
|
|
|
Loc->GetAddress().CalculateSymbolContext(&sc);
|
|
|
|
lldb_private::StreamString S;
|
|
|
|
sc.DumpStopContext(&S, BP->GetTarget().GetProcessSP().get(),
|
|
|
|
Loc->GetAddress(), false, true, false, true, true);
|
|
|
|
P.formatLine("Address: {0}", S.GetString());
|
Add "lldb-test breakpoint" command and convert the case-sensitivity test to use it
Summary:
The command takes two input arguments: a module to use as a debug target
and a file containing a list of commands. The command will execute each
of the breakpoint commands in the file and dump the breakpoint state
after each one.
The commands are expected to be breakpoint set/remove/etc. commands, but
I explicitly allow any lldb command here, so you can do things like
change setting which impact breakpoint resolution, etc. There is also a
"-persistent" flag, which causes lldb-test to *not* automatically clear
the breakpoint list after each command. Right now I don't use it, but
the idea behind it was that it could be used to test more complex
combinations of breakpoint commands (set+modify, set+disable, etc.).
Right now the command prints out only the basic breakpoint state, but
more information can be easily added there. To enable easy matching of
the "at least one breakpoint location found" state, the command
explicitly prints out the string "At least one breakpoint location.".
To enable testing of breakpoints set with an absolute paths, I add the
ability to perform rudimentary substitutions on the commands: right now
the string %p is replaced by the directory which contains the command
file (so, under normal circumstances, this will perform the same
substitution as lit would do for %p).
I use this command to rewrite the TestBreakpointCaseSensitivity test --
the test was checking about a dozen breakpoint commands, but it was
launching a new process for each one, so it took about 90 seconds to
run. The new test takes about 0.3 seconds for me, which is approximately
a 300x speedup.
Reviewers: davide, zturner, jingham
Subscribers: luporl, lldb-commits
Differential Revision: https://reviews.llvm.org/D43686
llvm-svn: 326112
2018-02-27 02:50:16 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
P.NewLine();
|
|
|
|
}
|
|
|
|
|
|
|
|
std::string opts::breakpoint::substitute(StringRef Cmd) {
|
|
|
|
std::string Result;
|
|
|
|
raw_string_ostream OS(Result);
|
|
|
|
while (!Cmd.empty()) {
|
|
|
|
switch (Cmd[0]) {
|
|
|
|
case '%':
|
|
|
|
if (Cmd.consume_front("%p") && (Cmd.empty() || !isalnum(Cmd[0]))) {
|
[lldb-test] Add a testing harness for the JIT's IRMemoryMap
This teaches lldb-test how to launch a process, set up an IRMemoryMap,
and issue memory allocations in the target process through the map. This
makes it possible to test IRMemoryMap in a targeted way.
This has uncovered two bugs so far. The first bug is that Malloc
performs an adjustment on the pointer returned from AllocateMemory (for
alignment purposes) which ultimately allows overlapping memory regions
to be created. The second bug is that after most of the address space on
the host side is exhausted, Malloc may return the same address multiple
times. These bugs (and hopefully more!) can be uncovered and tested for
with targeted lldb-test commands.
At an even higher level, the motivation for addressing these bugs is
that they can lead to strange user-visible failures (e.g, variables
assume the wrong value during expression evaluation, or the debugger
crashes). See my third comment on this swift-lldb PR for an example:
https://github.com/apple/swift-lldb/pull/652
I hope lldb-test is the right place to add this testing harness. Setting
up a gtest-style unit test proved too cumbersome (you need to recreate
or mock way too much debugger state), as did writing end-to-end tests
(it's hard to write a test that actually hits a buggy path).
With lldb-test, it's easy to read/generate the test input and parse the
test output. I'll attach a simple "fuzz" tester which generates failing
test cases to the Phab review. Here's an example:
```
Command: malloc(size=1024, alignment=32)
Malloc: address = 0xca000
Command: malloc(size=64, alignment=16)
Malloc: address = 0xca400
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca440
Command: malloc(size=16, alignment=8)
Malloc: address = 0xca840
Command: malloc(size=2048, alignment=16)
Malloc: address = 0xcb000
Command: malloc(size=64, alignment=32)
Malloc: address = 0xca860
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca890
Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0)
```
{F6288839}
Differential Revision: https://reviews.llvm.org/D47508
llvm-svn: 333583
2018-05-31 03:39:10 +08:00
|
|
|
OS << sys::path::parent_path(breakpoint::CommandFile);
|
Add "lldb-test breakpoint" command and convert the case-sensitivity test to use it
Summary:
The command takes two input arguments: a module to use as a debug target
and a file containing a list of commands. The command will execute each
of the breakpoint commands in the file and dump the breakpoint state
after each one.
The commands are expected to be breakpoint set/remove/etc. commands, but
I explicitly allow any lldb command here, so you can do things like
change setting which impact breakpoint resolution, etc. There is also a
"-persistent" flag, which causes lldb-test to *not* automatically clear
the breakpoint list after each command. Right now I don't use it, but
the idea behind it was that it could be used to test more complex
combinations of breakpoint commands (set+modify, set+disable, etc.).
Right now the command prints out only the basic breakpoint state, but
more information can be easily added there. To enable easy matching of
the "at least one breakpoint location found" state, the command
explicitly prints out the string "At least one breakpoint location.".
To enable testing of breakpoints set with an absolute paths, I add the
ability to perform rudimentary substitutions on the commands: right now
the string %p is replaced by the directory which contains the command
file (so, under normal circumstances, this will perform the same
substitution as lit would do for %p).
I use this command to rewrite the TestBreakpointCaseSensitivity test --
the test was checking about a dozen breakpoint commands, but it was
launching a new process for each one, so it took about 90 seconds to
run. The new test takes about 0.3 seconds for me, which is approximately
a 300x speedup.
Reviewers: davide, zturner, jingham
Subscribers: luporl, lldb-commits
Differential Revision: https://reviews.llvm.org/D43686
llvm-svn: 326112
2018-02-27 02:50:16 +08:00
|
|
|
break;
|
|
|
|
}
|
Fix clang -Wimplicit-fallthrough warnings across llvm, NFC
This patch should not introduce any behavior changes. It consists of
mostly one of two changes:
1. Replacing fall through comments with the LLVM_FALLTHROUGH macro
2. Inserting 'break' before falling through into a case block consisting
of only 'break'.
We were already using this warning with GCC, but its warning behaves
slightly differently. In this patch, the following differences are
relevant:
1. GCC recognizes comments that say "fall through" as annotations, clang
doesn't
2. GCC doesn't warn on "case N: foo(); default: break;", clang does
3. GCC doesn't warn when the case contains a switch, but falls through
the outer case.
I will enable the warning separately in a follow-up patch so that it can
be cleanly reverted if necessary.
Reviewers: alexfh, rsmith, lattner, rtrieu, EricWF, bollu
Differential Revision: https://reviews.llvm.org/D53950
llvm-svn: 345882
2018-11-02 03:54:45 +08:00
|
|
|
LLVM_FALLTHROUGH;
|
Add "lldb-test breakpoint" command and convert the case-sensitivity test to use it
Summary:
The command takes two input arguments: a module to use as a debug target
and a file containing a list of commands. The command will execute each
of the breakpoint commands in the file and dump the breakpoint state
after each one.
The commands are expected to be breakpoint set/remove/etc. commands, but
I explicitly allow any lldb command here, so you can do things like
change setting which impact breakpoint resolution, etc. There is also a
"-persistent" flag, which causes lldb-test to *not* automatically clear
the breakpoint list after each command. Right now I don't use it, but
the idea behind it was that it could be used to test more complex
combinations of breakpoint commands (set+modify, set+disable, etc.).
Right now the command prints out only the basic breakpoint state, but
more information can be easily added there. To enable easy matching of
the "at least one breakpoint location found" state, the command
explicitly prints out the string "At least one breakpoint location.".
To enable testing of breakpoints set with an absolute paths, I add the
ability to perform rudimentary substitutions on the commands: right now
the string %p is replaced by the directory which contains the command
file (so, under normal circumstances, this will perform the same
substitution as lit would do for %p).
I use this command to rewrite the TestBreakpointCaseSensitivity test --
the test was checking about a dozen breakpoint commands, but it was
launching a new process for each one, so it took about 90 seconds to
run. The new test takes about 0.3 seconds for me, which is approximately
a 300x speedup.
Reviewers: davide, zturner, jingham
Subscribers: luporl, lldb-commits
Differential Revision: https://reviews.llvm.org/D43686
llvm-svn: 326112
2018-02-27 02:50:16 +08:00
|
|
|
default:
|
|
|
|
size_t pos = Cmd.find('%');
|
|
|
|
OS << Cmd.substr(0, pos);
|
|
|
|
Cmd = Cmd.substr(pos);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return std::move(OS.str());
|
|
|
|
}
|
|
|
|
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
int opts::breakpoint::evaluateBreakpoints(Debugger &Dbg) {
|
[lldb-test] Add a testing harness for the JIT's IRMemoryMap
This teaches lldb-test how to launch a process, set up an IRMemoryMap,
and issue memory allocations in the target process through the map. This
makes it possible to test IRMemoryMap in a targeted way.
This has uncovered two bugs so far. The first bug is that Malloc
performs an adjustment on the pointer returned from AllocateMemory (for
alignment purposes) which ultimately allows overlapping memory regions
to be created. The second bug is that after most of the address space on
the host side is exhausted, Malloc may return the same address multiple
times. These bugs (and hopefully more!) can be uncovered and tested for
with targeted lldb-test commands.
At an even higher level, the motivation for addressing these bugs is
that they can lead to strange user-visible failures (e.g, variables
assume the wrong value during expression evaluation, or the debugger
crashes). See my third comment on this swift-lldb PR for an example:
https://github.com/apple/swift-lldb/pull/652
I hope lldb-test is the right place to add this testing harness. Setting
up a gtest-style unit test proved too cumbersome (you need to recreate
or mock way too much debugger state), as did writing end-to-end tests
(it's hard to write a test that actually hits a buggy path).
With lldb-test, it's easy to read/generate the test input and parse the
test output. I'll attach a simple "fuzz" tester which generates failing
test cases to the Phab review. Here's an example:
```
Command: malloc(size=1024, alignment=32)
Malloc: address = 0xca000
Command: malloc(size=64, alignment=16)
Malloc: address = 0xca400
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca440
Command: malloc(size=16, alignment=8)
Malloc: address = 0xca840
Command: malloc(size=2048, alignment=16)
Malloc: address = 0xcb000
Command: malloc(size=64, alignment=32)
Malloc: address = 0xca860
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca890
Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0)
```
{F6288839}
Differential Revision: https://reviews.llvm.org/D47508
llvm-svn: 333583
2018-05-31 03:39:10 +08:00
|
|
|
TargetSP Target = opts::createTarget(Dbg, breakpoint::Target);
|
|
|
|
std::unique_ptr<MemoryBuffer> MB = opts::openFile(breakpoint::CommandFile);
|
Add "lldb-test breakpoint" command and convert the case-sensitivity test to use it
Summary:
The command takes two input arguments: a module to use as a debug target
and a file containing a list of commands. The command will execute each
of the breakpoint commands in the file and dump the breakpoint state
after each one.
The commands are expected to be breakpoint set/remove/etc. commands, but
I explicitly allow any lldb command here, so you can do things like
change setting which impact breakpoint resolution, etc. There is also a
"-persistent" flag, which causes lldb-test to *not* automatically clear
the breakpoint list after each command. Right now I don't use it, but
the idea behind it was that it could be used to test more complex
combinations of breakpoint commands (set+modify, set+disable, etc.).
Right now the command prints out only the basic breakpoint state, but
more information can be easily added there. To enable easy matching of
the "at least one breakpoint location found" state, the command
explicitly prints out the string "At least one breakpoint location.".
To enable testing of breakpoints set with an absolute paths, I add the
ability to perform rudimentary substitutions on the commands: right now
the string %p is replaced by the directory which contains the command
file (so, under normal circumstances, this will perform the same
substitution as lit would do for %p).
I use this command to rewrite the TestBreakpointCaseSensitivity test --
the test was checking about a dozen breakpoint commands, but it was
launching a new process for each one, so it took about 90 seconds to
run. The new test takes about 0.3 seconds for me, which is approximately
a 300x speedup.
Reviewers: davide, zturner, jingham
Subscribers: luporl, lldb-commits
Differential Revision: https://reviews.llvm.org/D43686
llvm-svn: 326112
2018-02-27 02:50:16 +08:00
|
|
|
|
|
|
|
LinePrinter P(4, outs());
|
[lldb-test] Add a testing harness for the JIT's IRMemoryMap
This teaches lldb-test how to launch a process, set up an IRMemoryMap,
and issue memory allocations in the target process through the map. This
makes it possible to test IRMemoryMap in a targeted way.
This has uncovered two bugs so far. The first bug is that Malloc
performs an adjustment on the pointer returned from AllocateMemory (for
alignment purposes) which ultimately allows overlapping memory regions
to be created. The second bug is that after most of the address space on
the host side is exhausted, Malloc may return the same address multiple
times. These bugs (and hopefully more!) can be uncovered and tested for
with targeted lldb-test commands.
At an even higher level, the motivation for addressing these bugs is
that they can lead to strange user-visible failures (e.g, variables
assume the wrong value during expression evaluation, or the debugger
crashes). See my third comment on this swift-lldb PR for an example:
https://github.com/apple/swift-lldb/pull/652
I hope lldb-test is the right place to add this testing harness. Setting
up a gtest-style unit test proved too cumbersome (you need to recreate
or mock way too much debugger state), as did writing end-to-end tests
(it's hard to write a test that actually hits a buggy path).
With lldb-test, it's easy to read/generate the test input and parse the
test output. I'll attach a simple "fuzz" tester which generates failing
test cases to the Phab review. Here's an example:
```
Command: malloc(size=1024, alignment=32)
Malloc: address = 0xca000
Command: malloc(size=64, alignment=16)
Malloc: address = 0xca400
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca440
Command: malloc(size=16, alignment=8)
Malloc: address = 0xca840
Command: malloc(size=2048, alignment=16)
Malloc: address = 0xcb000
Command: malloc(size=64, alignment=32)
Malloc: address = 0xca860
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca890
Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0)
```
{F6288839}
Differential Revision: https://reviews.llvm.org/D47508
llvm-svn: 333583
2018-05-31 03:39:10 +08:00
|
|
|
StringRef Rest = MB->getBuffer();
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
int HadErrors = 0;
|
Add "lldb-test breakpoint" command and convert the case-sensitivity test to use it
Summary:
The command takes two input arguments: a module to use as a debug target
and a file containing a list of commands. The command will execute each
of the breakpoint commands in the file and dump the breakpoint state
after each one.
The commands are expected to be breakpoint set/remove/etc. commands, but
I explicitly allow any lldb command here, so you can do things like
change setting which impact breakpoint resolution, etc. There is also a
"-persistent" flag, which causes lldb-test to *not* automatically clear
the breakpoint list after each command. Right now I don't use it, but
the idea behind it was that it could be used to test more complex
combinations of breakpoint commands (set+modify, set+disable, etc.).
Right now the command prints out only the basic breakpoint state, but
more information can be easily added there. To enable easy matching of
the "at least one breakpoint location found" state, the command
explicitly prints out the string "At least one breakpoint location.".
To enable testing of breakpoints set with an absolute paths, I add the
ability to perform rudimentary substitutions on the commands: right now
the string %p is replaced by the directory which contains the command
file (so, under normal circumstances, this will perform the same
substitution as lit would do for %p).
I use this command to rewrite the TestBreakpointCaseSensitivity test --
the test was checking about a dozen breakpoint commands, but it was
launching a new process for each one, so it took about 90 seconds to
run. The new test takes about 0.3 seconds for me, which is approximately
a 300x speedup.
Reviewers: davide, zturner, jingham
Subscribers: luporl, lldb-commits
Differential Revision: https://reviews.llvm.org/D43686
llvm-svn: 326112
2018-02-27 02:50:16 +08:00
|
|
|
while (!Rest.empty()) {
|
|
|
|
StringRef Line;
|
|
|
|
std::tie(Line, Rest) = Rest.split('\n');
|
2019-06-08 05:13:30 +08:00
|
|
|
Line = Line.ltrim().rtrim();
|
Add "lldb-test breakpoint" command and convert the case-sensitivity test to use it
Summary:
The command takes two input arguments: a module to use as a debug target
and a file containing a list of commands. The command will execute each
of the breakpoint commands in the file and dump the breakpoint state
after each one.
The commands are expected to be breakpoint set/remove/etc. commands, but
I explicitly allow any lldb command here, so you can do things like
change setting which impact breakpoint resolution, etc. There is also a
"-persistent" flag, which causes lldb-test to *not* automatically clear
the breakpoint list after each command. Right now I don't use it, but
the idea behind it was that it could be used to test more complex
combinations of breakpoint commands (set+modify, set+disable, etc.).
Right now the command prints out only the basic breakpoint state, but
more information can be easily added there. To enable easy matching of
the "at least one breakpoint location found" state, the command
explicitly prints out the string "At least one breakpoint location.".
To enable testing of breakpoints set with an absolute paths, I add the
ability to perform rudimentary substitutions on the commands: right now
the string %p is replaced by the directory which contains the command
file (so, under normal circumstances, this will perform the same
substitution as lit would do for %p).
I use this command to rewrite the TestBreakpointCaseSensitivity test --
the test was checking about a dozen breakpoint commands, but it was
launching a new process for each one, so it took about 90 seconds to
run. The new test takes about 0.3 seconds for me, which is approximately
a 300x speedup.
Reviewers: davide, zturner, jingham
Subscribers: luporl, lldb-commits
Differential Revision: https://reviews.llvm.org/D43686
llvm-svn: 326112
2018-02-27 02:50:16 +08:00
|
|
|
if (Line.empty() || Line[0] == '#')
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (!Persistent)
|
|
|
|
Target->RemoveAllBreakpoints(/*internal_also*/ true);
|
|
|
|
|
|
|
|
std::string Command = substitute(Line);
|
|
|
|
P.formatLine("Command: {0}", Command);
|
2020-06-10 01:21:09 +08:00
|
|
|
CommandReturnObject Result(/*colors*/ false);
|
Add "lldb-test breakpoint" command and convert the case-sensitivity test to use it
Summary:
The command takes two input arguments: a module to use as a debug target
and a file containing a list of commands. The command will execute each
of the breakpoint commands in the file and dump the breakpoint state
after each one.
The commands are expected to be breakpoint set/remove/etc. commands, but
I explicitly allow any lldb command here, so you can do things like
change setting which impact breakpoint resolution, etc. There is also a
"-persistent" flag, which causes lldb-test to *not* automatically clear
the breakpoint list after each command. Right now I don't use it, but
the idea behind it was that it could be used to test more complex
combinations of breakpoint commands (set+modify, set+disable, etc.).
Right now the command prints out only the basic breakpoint state, but
more information can be easily added there. To enable easy matching of
the "at least one breakpoint location found" state, the command
explicitly prints out the string "At least one breakpoint location.".
To enable testing of breakpoints set with an absolute paths, I add the
ability to perform rudimentary substitutions on the commands: right now
the string %p is replaced by the directory which contains the command
file (so, under normal circumstances, this will perform the same
substitution as lit would do for %p).
I use this command to rewrite the TestBreakpointCaseSensitivity test --
the test was checking about a dozen breakpoint commands, but it was
launching a new process for each one, so it took about 90 seconds to
run. The new test takes about 0.3 seconds for me, which is approximately
a 300x speedup.
Reviewers: davide, zturner, jingham
Subscribers: luporl, lldb-commits
Differential Revision: https://reviews.llvm.org/D43686
llvm-svn: 326112
2018-02-27 02:50:16 +08:00
|
|
|
if (!Dbg.GetCommandInterpreter().HandleCommand(
|
|
|
|
Command.c_str(), /*add_to_history*/ eLazyBoolNo, Result)) {
|
|
|
|
P.formatLine("Failed: {0}", Result.GetErrorData());
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
HadErrors = 1;
|
Add "lldb-test breakpoint" command and convert the case-sensitivity test to use it
Summary:
The command takes two input arguments: a module to use as a debug target
and a file containing a list of commands. The command will execute each
of the breakpoint commands in the file and dump the breakpoint state
after each one.
The commands are expected to be breakpoint set/remove/etc. commands, but
I explicitly allow any lldb command here, so you can do things like
change setting which impact breakpoint resolution, etc. There is also a
"-persistent" flag, which causes lldb-test to *not* automatically clear
the breakpoint list after each command. Right now I don't use it, but
the idea behind it was that it could be used to test more complex
combinations of breakpoint commands (set+modify, set+disable, etc.).
Right now the command prints out only the basic breakpoint state, but
more information can be easily added there. To enable easy matching of
the "at least one breakpoint location found" state, the command
explicitly prints out the string "At least one breakpoint location.".
To enable testing of breakpoints set with an absolute paths, I add the
ability to perform rudimentary substitutions on the commands: right now
the string %p is replaced by the directory which contains the command
file (so, under normal circumstances, this will perform the same
substitution as lit would do for %p).
I use this command to rewrite the TestBreakpointCaseSensitivity test --
the test was checking about a dozen breakpoint commands, but it was
launching a new process for each one, so it took about 90 seconds to
run. The new test takes about 0.3 seconds for me, which is approximately
a 300x speedup.
Reviewers: davide, zturner, jingham
Subscribers: luporl, lldb-commits
Differential Revision: https://reviews.llvm.org/D43686
llvm-svn: 326112
2018-02-27 02:50:16 +08:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
dumpState(Target->GetBreakpointList(/*internal*/ false), P);
|
|
|
|
}
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
return HadErrors;
|
|
|
|
}
|
|
|
|
|
|
|
|
Expected<CompilerDeclContext>
|
2019-08-06 17:12:42 +08:00
|
|
|
opts::symbols::getDeclContext(SymbolFile &Symfile) {
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
if (Context.empty())
|
|
|
|
return CompilerDeclContext();
|
|
|
|
VariableList List;
|
2020-02-18 02:25:52 +08:00
|
|
|
Symfile.FindGlobalVariables(ConstString(Context), CompilerDeclContext(),
|
|
|
|
UINT32_MAX, List);
|
2018-06-12 20:57:36 +08:00
|
|
|
if (List.Empty())
|
|
|
|
return make_string_error("Context search didn't find a match.");
|
|
|
|
if (List.GetSize() > 1)
|
|
|
|
return make_string_error("Context search found multiple matches.");
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
return List.GetVariableAtIndex(0)->GetDeclContext();
|
|
|
|
}
|
|
|
|
|
2020-04-17 05:10:23 +08:00
|
|
|
static lldb::DescriptionLevel GetDescriptionLevel() {
|
|
|
|
return opts::symbols::DumpClangAST ? eDescriptionLevelVerbose : eDescriptionLevelFull;
|
|
|
|
}
|
|
|
|
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
Error opts::symbols::findFunctions(lldb_private::Module &Module) {
|
2019-08-06 17:12:42 +08:00
|
|
|
SymbolFile &Symfile = *Module.GetSymbolFile();
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
SymbolContextList List;
|
2018-06-28 18:03:42 +08:00
|
|
|
if (!File.empty()) {
|
|
|
|
assert(Line != 0);
|
|
|
|
|
2018-11-02 05:05:36 +08:00
|
|
|
FileSpec src_file(File);
|
2018-06-28 18:03:42 +08:00
|
|
|
size_t cu_count = Module.GetNumCompileUnits();
|
|
|
|
for (size_t i = 0; i < cu_count; i++) {
|
|
|
|
lldb::CompUnitSP cu_sp = Module.GetCompileUnitAtIndex(i);
|
|
|
|
if (!cu_sp)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
LineEntry le;
|
|
|
|
cu_sp->FindLineEntry(0, Line, &src_file, false, &le);
|
|
|
|
if (!le.IsValid())
|
|
|
|
continue;
|
2019-05-07 04:01:21 +08:00
|
|
|
const bool include_inlined_functions = false;
|
|
|
|
auto addr =
|
|
|
|
le.GetSameLineContiguousAddressRange(include_inlined_functions)
|
|
|
|
.GetBaseAddress();
|
2018-06-28 18:03:42 +08:00
|
|
|
if (!addr.IsValid())
|
|
|
|
continue;
|
|
|
|
|
|
|
|
SymbolContext sc;
|
|
|
|
uint32_t resolved =
|
|
|
|
addr.CalculateSymbolContext(&sc, eSymbolContextFunction);
|
|
|
|
if (resolved & eSymbolContextFunction)
|
|
|
|
List.Append(sc);
|
|
|
|
}
|
|
|
|
} else if (Regex) {
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
RegularExpression RE(Name);
|
|
|
|
assert(RE.IsValid());
|
2019-10-18 03:56:40 +08:00
|
|
|
List.Clear();
|
|
|
|
Symfile.FindFunctions(RE, true, List);
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
} else {
|
2019-08-06 17:12:42 +08:00
|
|
|
Expected<CompilerDeclContext> ContextOr = getDeclContext(Symfile);
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
if (!ContextOr)
|
|
|
|
return ContextOr.takeError();
|
2020-02-18 02:25:52 +08:00
|
|
|
const CompilerDeclContext &ContextPtr =
|
|
|
|
ContextOr->IsValid() ? *ContextOr : CompilerDeclContext();
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
|
2019-10-18 03:56:40 +08:00
|
|
|
List.Clear();
|
2019-08-06 17:12:42 +08:00
|
|
|
Symfile.FindFunctions(ConstString(Name), ContextPtr, getFunctionNameFlags(),
|
2019-10-18 03:56:40 +08:00
|
|
|
true, List);
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
}
|
|
|
|
outs() << formatv("Found {0} functions:\n", List.GetSize());
|
|
|
|
StreamString Stream;
|
|
|
|
List.Dump(&Stream, nullptr);
|
|
|
|
outs() << Stream.GetData() << "\n";
|
|
|
|
return Error::success();
|
|
|
|
}
|
|
|
|
|
2018-08-29 15:26:11 +08:00
|
|
|
Error opts::symbols::findBlocks(lldb_private::Module &Module) {
|
|
|
|
assert(!Regex);
|
|
|
|
assert(!File.empty());
|
|
|
|
assert(Line != 0);
|
|
|
|
|
|
|
|
SymbolContextList List;
|
|
|
|
|
2018-11-02 05:05:36 +08:00
|
|
|
FileSpec src_file(File);
|
2018-08-29 15:26:11 +08:00
|
|
|
size_t cu_count = Module.GetNumCompileUnits();
|
|
|
|
for (size_t i = 0; i < cu_count; i++) {
|
|
|
|
lldb::CompUnitSP cu_sp = Module.GetCompileUnitAtIndex(i);
|
|
|
|
if (!cu_sp)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
LineEntry le;
|
|
|
|
cu_sp->FindLineEntry(0, Line, &src_file, false, &le);
|
|
|
|
if (!le.IsValid())
|
|
|
|
continue;
|
2019-05-07 04:01:21 +08:00
|
|
|
const bool include_inlined_functions = false;
|
|
|
|
auto addr = le.GetSameLineContiguousAddressRange(include_inlined_functions)
|
|
|
|
.GetBaseAddress();
|
2018-08-29 15:26:11 +08:00
|
|
|
if (!addr.IsValid())
|
|
|
|
continue;
|
|
|
|
|
|
|
|
SymbolContext sc;
|
|
|
|
uint32_t resolved = addr.CalculateSymbolContext(&sc, eSymbolContextBlock);
|
|
|
|
if (resolved & eSymbolContextBlock)
|
|
|
|
List.Append(sc);
|
|
|
|
}
|
|
|
|
|
|
|
|
outs() << formatv("Found {0} blocks:\n", List.GetSize());
|
|
|
|
StreamString Stream;
|
|
|
|
List.Dump(&Stream, nullptr);
|
|
|
|
outs() << Stream.GetData() << "\n";
|
|
|
|
return Error::success();
|
|
|
|
}
|
|
|
|
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
Error opts::symbols::findNamespaces(lldb_private::Module &Module) {
|
2019-08-06 17:12:42 +08:00
|
|
|
SymbolFile &Symfile = *Module.GetSymbolFile();
|
|
|
|
Expected<CompilerDeclContext> ContextOr = getDeclContext(Symfile);
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
if (!ContextOr)
|
|
|
|
return ContextOr.takeError();
|
2020-02-18 02:25:52 +08:00
|
|
|
const CompilerDeclContext &ContextPtr =
|
|
|
|
ContextOr->IsValid() ? *ContextOr : CompilerDeclContext();
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
|
|
|
|
CompilerDeclContext Result =
|
2019-08-06 17:12:42 +08:00
|
|
|
Symfile.FindNamespace(ConstString(Name), ContextPtr);
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
if (Result)
|
|
|
|
outs() << "Found namespace: "
|
|
|
|
<< Result.GetScopeQualifiedName().GetStringRef() << "\n";
|
|
|
|
else
|
|
|
|
outs() << "Namespace not found.\n";
|
|
|
|
return Error::success();
|
|
|
|
}
|
|
|
|
|
|
|
|
Error opts::symbols::findTypes(lldb_private::Module &Module) {
|
2019-08-06 17:12:42 +08:00
|
|
|
SymbolFile &Symfile = *Module.GetSymbolFile();
|
|
|
|
Expected<CompilerDeclContext> ContextOr = getDeclContext(Symfile);
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
if (!ContextOr)
|
|
|
|
return ContextOr.takeError();
|
2020-02-18 02:25:52 +08:00
|
|
|
const CompilerDeclContext &ContextPtr =
|
|
|
|
ContextOr->IsValid() ? *ContextOr : CompilerDeclContext();
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
|
2019-08-23 05:45:58 +08:00
|
|
|
LanguageSet languages;
|
|
|
|
if (!Language.empty())
|
|
|
|
languages.Insert(Language::GetLanguageTypeFromString(Language));
|
2020-06-10 01:21:09 +08:00
|
|
|
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
DenseSet<SymbolFile *> SearchedFiles;
|
|
|
|
TypeMap Map;
|
2019-08-21 00:44:25 +08:00
|
|
|
if (!Name.empty())
|
2019-10-01 00:42:28 +08:00
|
|
|
Symfile.FindTypes(ConstString(Name), ContextPtr, UINT32_MAX, SearchedFiles,
|
|
|
|
Map);
|
2019-08-21 00:44:25 +08:00
|
|
|
else
|
2019-11-13 01:25:59 +08:00
|
|
|
Module.FindTypes(parseCompilerContext(), languages, SearchedFiles, Map);
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
|
|
|
|
outs() << formatv("Found {0} types:\n", Map.GetSize());
|
|
|
|
StreamString Stream;
|
2020-04-17 05:10:23 +08:00
|
|
|
// Resolve types to force-materialize typedef types.
|
|
|
|
Map.ForEach([&](TypeSP &type) {
|
|
|
|
type->GetFullCompilerType();
|
|
|
|
return false;
|
|
|
|
});
|
|
|
|
Map.Dump(&Stream, false, GetDescriptionLevel());
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
outs() << Stream.GetData() << "\n";
|
|
|
|
return Error::success();
|
|
|
|
}
|
|
|
|
|
|
|
|
Error opts::symbols::findVariables(lldb_private::Module &Module) {
|
2019-08-06 17:12:42 +08:00
|
|
|
SymbolFile &Symfile = *Module.GetSymbolFile();
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
VariableList List;
|
|
|
|
if (Regex) {
|
|
|
|
RegularExpression RE(Name);
|
|
|
|
assert(RE.IsValid());
|
2019-08-06 17:12:42 +08:00
|
|
|
Symfile.FindGlobalVariables(RE, UINT32_MAX, List);
|
2018-06-12 20:57:36 +08:00
|
|
|
} else if (!File.empty()) {
|
|
|
|
CompUnitSP CU;
|
|
|
|
for (size_t Ind = 0; !CU && Ind < Module.GetNumCompileUnits(); ++Ind) {
|
|
|
|
CompUnitSP Candidate = Module.GetCompileUnitAtIndex(Ind);
|
2019-11-28 23:22:44 +08:00
|
|
|
if (!Candidate ||
|
|
|
|
Candidate->GetPrimaryFile().GetFilename().GetStringRef() != File)
|
2018-06-12 20:57:36 +08:00
|
|
|
continue;
|
|
|
|
if (CU)
|
|
|
|
return make_string_error("Multiple compile units for file `{0}` found.",
|
|
|
|
File);
|
|
|
|
CU = std::move(Candidate);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!CU)
|
|
|
|
return make_string_error("Compile unit `{0}` not found.", File);
|
|
|
|
|
|
|
|
List.AddVariables(CU->GetVariableList(true).get());
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
} else {
|
2019-08-06 17:12:42 +08:00
|
|
|
Expected<CompilerDeclContext> ContextOr = getDeclContext(Symfile);
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
if (!ContextOr)
|
|
|
|
return ContextOr.takeError();
|
2020-02-18 02:25:52 +08:00
|
|
|
const CompilerDeclContext &ContextPtr =
|
|
|
|
ContextOr->IsValid() ? *ContextOr : CompilerDeclContext();
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
|
2019-08-06 17:12:42 +08:00
|
|
|
Symfile.FindGlobalVariables(ConstString(Name), ContextPtr, UINT32_MAX, List);
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
}
|
|
|
|
outs() << formatv("Found {0} variables:\n", List.GetSize());
|
|
|
|
StreamString Stream;
|
|
|
|
List.Dump(&Stream, false);
|
|
|
|
outs() << Stream.GetData() << "\n";
|
|
|
|
return Error::success();
|
Add "lldb-test breakpoint" command and convert the case-sensitivity test to use it
Summary:
The command takes two input arguments: a module to use as a debug target
and a file containing a list of commands. The command will execute each
of the breakpoint commands in the file and dump the breakpoint state
after each one.
The commands are expected to be breakpoint set/remove/etc. commands, but
I explicitly allow any lldb command here, so you can do things like
change setting which impact breakpoint resolution, etc. There is also a
"-persistent" flag, which causes lldb-test to *not* automatically clear
the breakpoint list after each command. Right now I don't use it, but
the idea behind it was that it could be used to test more complex
combinations of breakpoint commands (set+modify, set+disable, etc.).
Right now the command prints out only the basic breakpoint state, but
more information can be easily added there. To enable easy matching of
the "at least one breakpoint location found" state, the command
explicitly prints out the string "At least one breakpoint location.".
To enable testing of breakpoints set with an absolute paths, I add the
ability to perform rudimentary substitutions on the commands: right now
the string %p is replaced by the directory which contains the command
file (so, under normal circumstances, this will perform the same
substitution as lit would do for %p).
I use this command to rewrite the TestBreakpointCaseSensitivity test --
the test was checking about a dozen breakpoint commands, but it was
launching a new process for each one, so it took about 90 seconds to
run. The new test takes about 0.3 seconds for me, which is approximately
a 300x speedup.
Reviewers: davide, zturner, jingham
Subscribers: luporl, lldb-commits
Differential Revision: https://reviews.llvm.org/D43686
llvm-svn: 326112
2018-02-27 02:50:16 +08:00
|
|
|
}
|
|
|
|
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
Error opts::symbols::dumpModule(lldb_private::Module &Module) {
|
|
|
|
StreamString Stream;
|
|
|
|
Module.ParseAllDebugSymbols();
|
|
|
|
Module.Dump(&Stream);
|
|
|
|
outs() << Stream.GetData() << "\n";
|
|
|
|
return Error::success();
|
|
|
|
}
|
|
|
|
|
[PDB] Restore AST from PDB symbols
Summary:
This patch adds an implementation of retrieving of declarations and declaration
contexts based on PDB symbols.
PDB has different type symbols for const-qualified types, and this
implementation ensures that only one declaration was created for both const
and non-const types, but creates different compiler types for them.
The implementation also processes the case when there are two symbols
corresponding to a variable. It's possible e.g. for class static variables,
they has one global symbol and one symbol belonging to a class.
PDB has no info about namespaces, so this implementation parses the full symbol
name and tries to figure out if the symbol belongs to namespace or not,
and then creates nested namespaces if necessary.
Reviewers: asmith, zturner, labath
Reviewed By: asmith
Subscribers: aleksandr.urakov, teemperor, lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D51162
llvm-svn: 341782
2018-09-10 16:08:43 +08:00
|
|
|
Error opts::symbols::dumpAST(lldb_private::Module &Module) {
|
2019-08-06 17:12:42 +08:00
|
|
|
Module.ParseAllDebugSymbols();
|
[PDB] Restore AST from PDB symbols
Summary:
This patch adds an implementation of retrieving of declarations and declaration
contexts based on PDB symbols.
PDB has different type symbols for const-qualified types, and this
implementation ensures that only one declaration was created for both const
and non-const types, but creates different compiler types for them.
The implementation also processes the case when there are two symbols
corresponding to a variable. It's possible e.g. for class static variables,
they has one global symbol and one symbol belonging to a class.
PDB has no info about namespaces, so this implementation parses the full symbol
name and tries to figure out if the symbol belongs to namespace or not,
and then creates nested namespaces if necessary.
Reviewers: asmith, zturner, labath
Reviewed By: asmith
Subscribers: aleksandr.urakov, teemperor, lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D51162
llvm-svn: 341782
2018-09-10 16:08:43 +08:00
|
|
|
|
2019-10-12 00:36:20 +08:00
|
|
|
SymbolFile *symfile = Module.GetSymbolFile();
|
[PDB] Restore AST from PDB symbols
Summary:
This patch adds an implementation of retrieving of declarations and declaration
contexts based on PDB symbols.
PDB has different type symbols for const-qualified types, and this
implementation ensures that only one declaration was created for both const
and non-const types, but creates different compiler types for them.
The implementation also processes the case when there are two symbols
corresponding to a variable. It's possible e.g. for class static variables,
they has one global symbol and one symbol belonging to a class.
PDB has no info about namespaces, so this implementation parses the full symbol
name and tries to figure out if the symbol belongs to namespace or not,
and then creates nested namespaces if necessary.
Reviewers: asmith, zturner, labath
Reviewed By: asmith
Subscribers: aleksandr.urakov, teemperor, lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D51162
llvm-svn: 341782
2018-09-10 16:08:43 +08:00
|
|
|
if (!symfile)
|
|
|
|
return make_string_error("Module has no symbol file.");
|
|
|
|
|
2019-10-12 00:36:20 +08:00
|
|
|
llvm::Expected<TypeSystem &> type_system_or_err =
|
2019-07-31 06:12:34 +08:00
|
|
|
symfile->GetTypeSystemForLanguage(eLanguageTypeC_plus_plus);
|
|
|
|
if (!type_system_or_err)
|
[lldb][NFC] Rename ClangASTContext to TypeSystemClang
Summary:
This commit renames ClangASTContext to TypeSystemClang to better reflect what this class is actually supposed to do
(implement the TypeSystem interface for Clang). It also gets rid of the very confusing situation that we have both a
`clang::ASTContext` and a `ClangASTContext` in clang (which sometimes causes Clang people to think I'm fiddling
with Clang's ASTContext when I'm actually just doing LLDB work).
I also have plans to potentially have multiple clang::ASTContext instances associated with one ClangASTContext so
the ASTContext naming will then become even more confusing to people.
Reviewers: #lldb, aprantl, shafik, clayborg, labath, JDevlieghere, davide, espindola, jdoerfert, xiaobai
Reviewed By: clayborg, labath, xiaobai
Subscribers: wuzish, emaste, nemanjai, mgorny, kbarton, MaskRay, arphaman, jfb, usaxena95, jingham, xiaobai, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72684
2020-01-23 17:04:13 +08:00
|
|
|
return make_string_error("Can't retrieve TypeSystemClang");
|
2019-07-31 06:12:34 +08:00
|
|
|
|
|
|
|
auto *clang_ast_ctx =
|
[lldb][NFC] Rename ClangASTContext to TypeSystemClang
Summary:
This commit renames ClangASTContext to TypeSystemClang to better reflect what this class is actually supposed to do
(implement the TypeSystem interface for Clang). It also gets rid of the very confusing situation that we have both a
`clang::ASTContext` and a `ClangASTContext` in clang (which sometimes causes Clang people to think I'm fiddling
with Clang's ASTContext when I'm actually just doing LLDB work).
I also have plans to potentially have multiple clang::ASTContext instances associated with one ClangASTContext so
the ASTContext naming will then become even more confusing to people.
Reviewers: #lldb, aprantl, shafik, clayborg, labath, JDevlieghere, davide, espindola, jdoerfert, xiaobai
Reviewed By: clayborg, labath, xiaobai
Subscribers: wuzish, emaste, nemanjai, mgorny, kbarton, MaskRay, arphaman, jfb, usaxena95, jingham, xiaobai, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72684
2020-01-23 17:04:13 +08:00
|
|
|
llvm::dyn_cast_or_null<TypeSystemClang>(&type_system_or_err.get());
|
[PDB] Restore AST from PDB symbols
Summary:
This patch adds an implementation of retrieving of declarations and declaration
contexts based on PDB symbols.
PDB has different type symbols for const-qualified types, and this
implementation ensures that only one declaration was created for both const
and non-const types, but creates different compiler types for them.
The implementation also processes the case when there are two symbols
corresponding to a variable. It's possible e.g. for class static variables,
they has one global symbol and one symbol belonging to a class.
PDB has no info about namespaces, so this implementation parses the full symbol
name and tries to figure out if the symbol belongs to namespace or not,
and then creates nested namespaces if necessary.
Reviewers: asmith, zturner, labath
Reviewed By: asmith
Subscribers: aleksandr.urakov, teemperor, lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D51162
llvm-svn: 341782
2018-09-10 16:08:43 +08:00
|
|
|
if (!clang_ast_ctx)
|
[lldb][NFC] Rename ClangASTContext to TypeSystemClang
Summary:
This commit renames ClangASTContext to TypeSystemClang to better reflect what this class is actually supposed to do
(implement the TypeSystem interface for Clang). It also gets rid of the very confusing situation that we have both a
`clang::ASTContext` and a `ClangASTContext` in clang (which sometimes causes Clang people to think I'm fiddling
with Clang's ASTContext when I'm actually just doing LLDB work).
I also have plans to potentially have multiple clang::ASTContext instances associated with one ClangASTContext so
the ASTContext naming will then become even more confusing to people.
Reviewers: #lldb, aprantl, shafik, clayborg, labath, JDevlieghere, davide, espindola, jdoerfert, xiaobai
Reviewed By: clayborg, labath, xiaobai
Subscribers: wuzish, emaste, nemanjai, mgorny, kbarton, MaskRay, arphaman, jfb, usaxena95, jingham, xiaobai, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72684
2020-01-23 17:04:13 +08:00
|
|
|
return make_string_error("Retrieved TypeSystem was not a TypeSystemClang");
|
[PDB] Restore AST from PDB symbols
Summary:
This patch adds an implementation of retrieving of declarations and declaration
contexts based on PDB symbols.
PDB has different type symbols for const-qualified types, and this
implementation ensures that only one declaration was created for both const
and non-const types, but creates different compiler types for them.
The implementation also processes the case when there are two symbols
corresponding to a variable. It's possible e.g. for class static variables,
they has one global symbol and one symbol belonging to a class.
PDB has no info about namespaces, so this implementation parses the full symbol
name and tries to figure out if the symbol belongs to namespace or not,
and then creates nested namespaces if necessary.
Reviewers: asmith, zturner, labath
Reviewed By: asmith
Subscribers: aleksandr.urakov, teemperor, lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D51162
llvm-svn: 341782
2018-09-10 16:08:43 +08:00
|
|
|
|
2019-12-22 05:40:52 +08:00
|
|
|
clang::ASTContext &ast_ctx = clang_ast_ctx->getASTContext();
|
[PDB] Restore AST from PDB symbols
Summary:
This patch adds an implementation of retrieving of declarations and declaration
contexts based on PDB symbols.
PDB has different type symbols for const-qualified types, and this
implementation ensures that only one declaration was created for both const
and non-const types, but creates different compiler types for them.
The implementation also processes the case when there are two symbols
corresponding to a variable. It's possible e.g. for class static variables,
they has one global symbol and one symbol belonging to a class.
PDB has no info about namespaces, so this implementation parses the full symbol
name and tries to figure out if the symbol belongs to namespace or not,
and then creates nested namespaces if necessary.
Reviewers: asmith, zturner, labath
Reviewed By: asmith
Subscribers: aleksandr.urakov, teemperor, lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D51162
llvm-svn: 341782
2018-09-10 16:08:43 +08:00
|
|
|
|
2019-12-22 05:40:52 +08:00
|
|
|
clang::TranslationUnitDecl *tu = ast_ctx.getTranslationUnitDecl();
|
[PDB] Restore AST from PDB symbols
Summary:
This patch adds an implementation of retrieving of declarations and declaration
contexts based on PDB symbols.
PDB has different type symbols for const-qualified types, and this
implementation ensures that only one declaration was created for both const
and non-const types, but creates different compiler types for them.
The implementation also processes the case when there are two symbols
corresponding to a variable. It's possible e.g. for class static variables,
they has one global symbol and one symbol belonging to a class.
PDB has no info about namespaces, so this implementation parses the full symbol
name and tries to figure out if the symbol belongs to namespace or not,
and then creates nested namespaces if necessary.
Reviewers: asmith, zturner, labath
Reviewed By: asmith
Subscribers: aleksandr.urakov, teemperor, lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D51162
llvm-svn: 341782
2018-09-10 16:08:43 +08:00
|
|
|
if (!tu)
|
|
|
|
return make_string_error("Can't retrieve translation unit declaration.");
|
|
|
|
|
|
|
|
tu->print(outs());
|
|
|
|
|
|
|
|
return Error::success();
|
|
|
|
}
|
|
|
|
|
2020-04-17 05:10:23 +08:00
|
|
|
Error opts::symbols::dumpEntireClangAST(lldb_private::Module &Module) {
|
2019-10-12 00:36:20 +08:00
|
|
|
Module.ParseAllDebugSymbols();
|
|
|
|
|
|
|
|
SymbolFile *symfile = Module.GetSymbolFile();
|
|
|
|
if (!symfile)
|
|
|
|
return make_string_error("Module has no symbol file.");
|
|
|
|
|
|
|
|
llvm::Expected<TypeSystem &> type_system_or_err =
|
2019-11-22 09:21:49 +08:00
|
|
|
symfile->GetTypeSystemForLanguage(eLanguageTypeObjC_plus_plus);
|
2019-10-12 00:36:20 +08:00
|
|
|
if (!type_system_or_err)
|
[lldb][NFC] Rename ClangASTContext to TypeSystemClang
Summary:
This commit renames ClangASTContext to TypeSystemClang to better reflect what this class is actually supposed to do
(implement the TypeSystem interface for Clang). It also gets rid of the very confusing situation that we have both a
`clang::ASTContext` and a `ClangASTContext` in clang (which sometimes causes Clang people to think I'm fiddling
with Clang's ASTContext when I'm actually just doing LLDB work).
I also have plans to potentially have multiple clang::ASTContext instances associated with one ClangASTContext so
the ASTContext naming will then become even more confusing to people.
Reviewers: #lldb, aprantl, shafik, clayborg, labath, JDevlieghere, davide, espindola, jdoerfert, xiaobai
Reviewed By: clayborg, labath, xiaobai
Subscribers: wuzish, emaste, nemanjai, mgorny, kbarton, MaskRay, arphaman, jfb, usaxena95, jingham, xiaobai, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72684
2020-01-23 17:04:13 +08:00
|
|
|
return make_string_error("Can't retrieve TypeSystemClang");
|
2019-10-12 00:36:20 +08:00
|
|
|
|
|
|
|
auto *clang_ast_ctx =
|
[lldb][NFC] Rename ClangASTContext to TypeSystemClang
Summary:
This commit renames ClangASTContext to TypeSystemClang to better reflect what this class is actually supposed to do
(implement the TypeSystem interface for Clang). It also gets rid of the very confusing situation that we have both a
`clang::ASTContext` and a `ClangASTContext` in clang (which sometimes causes Clang people to think I'm fiddling
with Clang's ASTContext when I'm actually just doing LLDB work).
I also have plans to potentially have multiple clang::ASTContext instances associated with one ClangASTContext so
the ASTContext naming will then become even more confusing to people.
Reviewers: #lldb, aprantl, shafik, clayborg, labath, JDevlieghere, davide, espindola, jdoerfert, xiaobai
Reviewed By: clayborg, labath, xiaobai
Subscribers: wuzish, emaste, nemanjai, mgorny, kbarton, MaskRay, arphaman, jfb, usaxena95, jingham, xiaobai, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72684
2020-01-23 17:04:13 +08:00
|
|
|
llvm::dyn_cast_or_null<TypeSystemClang>(&type_system_or_err.get());
|
2019-10-12 00:36:20 +08:00
|
|
|
if (!clang_ast_ctx)
|
[lldb][NFC] Rename ClangASTContext to TypeSystemClang
Summary:
This commit renames ClangASTContext to TypeSystemClang to better reflect what this class is actually supposed to do
(implement the TypeSystem interface for Clang). It also gets rid of the very confusing situation that we have both a
`clang::ASTContext` and a `ClangASTContext` in clang (which sometimes causes Clang people to think I'm fiddling
with Clang's ASTContext when I'm actually just doing LLDB work).
I also have plans to potentially have multiple clang::ASTContext instances associated with one ClangASTContext so
the ASTContext naming will then become even more confusing to people.
Reviewers: #lldb, aprantl, shafik, clayborg, labath, JDevlieghere, davide, espindola, jdoerfert, xiaobai
Reviewed By: clayborg, labath, xiaobai
Subscribers: wuzish, emaste, nemanjai, mgorny, kbarton, MaskRay, arphaman, jfb, usaxena95, jingham, xiaobai, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72684
2020-01-23 17:04:13 +08:00
|
|
|
return make_string_error("Retrieved TypeSystem was not a TypeSystemClang");
|
2019-10-12 00:36:20 +08:00
|
|
|
|
|
|
|
StreamString Stream;
|
|
|
|
clang_ast_ctx->DumpFromSymbolFile(Stream, Name);
|
|
|
|
outs() << Stream.GetData() << "\n";
|
|
|
|
|
|
|
|
return Error::success();
|
|
|
|
}
|
|
|
|
|
2018-06-08 10:45:25 +08:00
|
|
|
Error opts::symbols::verify(lldb_private::Module &Module) {
|
2019-08-06 17:12:42 +08:00
|
|
|
SymbolFile *symfile = Module.GetSymbolFile();
|
2018-06-08 10:45:25 +08:00
|
|
|
if (!symfile)
|
2018-06-12 20:57:36 +08:00
|
|
|
return make_string_error("Module has no symbol file.");
|
2018-06-08 10:45:25 +08:00
|
|
|
|
|
|
|
uint32_t comp_units_count = symfile->GetNumCompileUnits();
|
|
|
|
|
|
|
|
outs() << "Found " << comp_units_count << " compile units.\n";
|
|
|
|
|
|
|
|
for (uint32_t i = 0; i < comp_units_count; i++) {
|
2019-07-23 17:24:02 +08:00
|
|
|
lldb::CompUnitSP comp_unit = symfile->GetCompileUnitAtIndex(i);
|
2018-06-08 10:45:25 +08:00
|
|
|
if (!comp_unit)
|
2020-04-07 00:06:02 +08:00
|
|
|
return make_string_error("Cannot parse compile unit {0}.", i);
|
2018-06-08 10:45:25 +08:00
|
|
|
|
2019-11-28 23:22:44 +08:00
|
|
|
outs() << "Processing '"
|
|
|
|
<< comp_unit->GetPrimaryFile().GetFilename().AsCString()
|
2018-06-28 18:03:42 +08:00
|
|
|
<< "' compile unit.\n";
|
2018-06-08 10:45:25 +08:00
|
|
|
|
|
|
|
LineTable *lt = comp_unit->GetLineTable();
|
|
|
|
if (!lt)
|
2018-06-12 20:57:36 +08:00
|
|
|
return make_string_error("Can't get a line table of a compile unit.");
|
2018-06-08 10:45:25 +08:00
|
|
|
|
|
|
|
uint32_t count = lt->GetSize();
|
|
|
|
|
|
|
|
outs() << "The line table contains " << count << " entries.\n";
|
|
|
|
|
|
|
|
if (count == 0)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
LineEntry le;
|
|
|
|
if (!lt->GetLineEntryAtIndex(0, le))
|
2018-06-12 20:57:36 +08:00
|
|
|
return make_string_error("Can't get a line entry of a compile unit.");
|
2018-06-08 10:45:25 +08:00
|
|
|
|
|
|
|
for (uint32_t i = 1; i < count; i++) {
|
|
|
|
lldb::addr_t curr_end =
|
2018-06-28 18:03:42 +08:00
|
|
|
le.range.GetBaseAddress().GetFileAddress() + le.range.GetByteSize();
|
2018-06-08 10:45:25 +08:00
|
|
|
|
|
|
|
if (!lt->GetLineEntryAtIndex(i, le))
|
2018-06-12 20:57:36 +08:00
|
|
|
return make_string_error("Can't get a line entry of a compile unit");
|
2018-06-08 10:45:25 +08:00
|
|
|
|
|
|
|
if (curr_end > le.range.GetBaseAddress().GetFileAddress())
|
2018-06-12 20:57:36 +08:00
|
|
|
return make_string_error(
|
|
|
|
"Line table of a compile unit is inconsistent.");
|
2018-06-08 10:45:25 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
outs() << "The symbol information is verified.\n";
|
|
|
|
|
|
|
|
return Error::success();
|
|
|
|
}
|
|
|
|
|
2018-06-12 21:26:43 +08:00
|
|
|
Expected<Error (*)(lldb_private::Module &)> opts::symbols::getAction() {
|
[PDB] Restore AST from PDB symbols
Summary:
This patch adds an implementation of retrieving of declarations and declaration
contexts based on PDB symbols.
PDB has different type symbols for const-qualified types, and this
implementation ensures that only one declaration was created for both const
and non-const types, but creates different compiler types for them.
The implementation also processes the case when there are two symbols
corresponding to a variable. It's possible e.g. for class static variables,
they has one global symbol and one symbol belonging to a class.
PDB has no info about namespaces, so this implementation parses the full symbol
name and tries to figure out if the symbol belongs to namespace or not,
and then creates nested namespaces if necessary.
Reviewers: asmith, zturner, labath
Reviewed By: asmith
Subscribers: aleksandr.urakov, teemperor, lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D51162
llvm-svn: 341782
2018-09-10 16:08:43 +08:00
|
|
|
if (Verify && DumpAST)
|
|
|
|
return make_string_error(
|
|
|
|
"Cannot both verify symbol information and dump AST.");
|
|
|
|
|
2018-06-12 20:57:36 +08:00
|
|
|
if (Verify) {
|
|
|
|
if (Find != FindType::None)
|
|
|
|
return make_string_error(
|
|
|
|
"Cannot both search and verify symbol information.");
|
2018-06-28 18:03:42 +08:00
|
|
|
if (Regex || !Context.empty() || !Name.empty() || !File.empty() ||
|
|
|
|
Line != 0)
|
|
|
|
return make_string_error(
|
|
|
|
"-regex, -context, -name, -file and -line options are not "
|
|
|
|
"applicable for symbol verification.");
|
2018-06-12 20:57:36 +08:00
|
|
|
return verify;
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
}
|
2018-06-12 20:57:36 +08:00
|
|
|
|
[PDB] Restore AST from PDB symbols
Summary:
This patch adds an implementation of retrieving of declarations and declaration
contexts based on PDB symbols.
PDB has different type symbols for const-qualified types, and this
implementation ensures that only one declaration was created for both const
and non-const types, but creates different compiler types for them.
The implementation also processes the case when there are two symbols
corresponding to a variable. It's possible e.g. for class static variables,
they has one global symbol and one symbol belonging to a class.
PDB has no info about namespaces, so this implementation parses the full symbol
name and tries to figure out if the symbol belongs to namespace or not,
and then creates nested namespaces if necessary.
Reviewers: asmith, zturner, labath
Reviewed By: asmith
Subscribers: aleksandr.urakov, teemperor, lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D51162
llvm-svn: 341782
2018-09-10 16:08:43 +08:00
|
|
|
if (DumpAST) {
|
|
|
|
if (Find != FindType::None)
|
[pecoff] Implement ObjectFilePECOFF::GetDependedModules()
Summary:
This parses entries in pecoff import tables for imported DLLs and
is intended as the first step to allow LLDB to load a PE's shared
modules when creating a target on the LLDB console.
Reviewers: rnk, zturner, aleksandr.urakov, lldb-commits, labath, asmith
Reviewed By: labath, asmith
Subscribers: labath, lemo, clayborg, Hui, mgorny, mgrang, teemperor
Differential Revision: https://reviews.llvm.org/D53094
llvm-svn: 348527
2018-12-07 05:36:39 +08:00
|
|
|
return make_string_error("Cannot both search and dump AST.");
|
[PDB] Restore AST from PDB symbols
Summary:
This patch adds an implementation of retrieving of declarations and declaration
contexts based on PDB symbols.
PDB has different type symbols for const-qualified types, and this
implementation ensures that only one declaration was created for both const
and non-const types, but creates different compiler types for them.
The implementation also processes the case when there are two symbols
corresponding to a variable. It's possible e.g. for class static variables,
they has one global symbol and one symbol belonging to a class.
PDB has no info about namespaces, so this implementation parses the full symbol
name and tries to figure out if the symbol belongs to namespace or not,
and then creates nested namespaces if necessary.
Reviewers: asmith, zturner, labath
Reviewed By: asmith
Subscribers: aleksandr.urakov, teemperor, lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D51162
llvm-svn: 341782
2018-09-10 16:08:43 +08:00
|
|
|
if (Regex || !Context.empty() || !Name.empty() || !File.empty() ||
|
|
|
|
Line != 0)
|
|
|
|
return make_string_error(
|
|
|
|
"-regex, -context, -name, -file and -line options are not "
|
|
|
|
"applicable for dumping AST.");
|
|
|
|
return dumpAST;
|
|
|
|
}
|
|
|
|
|
2019-10-12 00:36:20 +08:00
|
|
|
if (DumpClangAST) {
|
2020-04-17 05:10:23 +08:00
|
|
|
if (Find == FindType::None) {
|
|
|
|
if (Regex || !Context.empty() || !File.empty() || Line != 0)
|
|
|
|
return make_string_error(
|
|
|
|
"-regex, -context, -name, -file and -line options are not "
|
|
|
|
"applicable for dumping the entire clang AST. Either combine with "
|
|
|
|
"-find, or use -dump-clang-ast as a standalone option.");
|
|
|
|
return dumpEntireClangAST;
|
|
|
|
}
|
|
|
|
if (Find != FindType::Type)
|
|
|
|
return make_string_error("This combination of -dump-clang-ast and -find "
|
|
|
|
"<kind> is not yet implemented.");
|
2019-10-12 00:36:20 +08:00
|
|
|
}
|
|
|
|
|
2018-06-12 20:57:36 +08:00
|
|
|
if (Regex && !Context.empty())
|
|
|
|
return make_string_error(
|
|
|
|
"Cannot search using both regular expressions and context.");
|
|
|
|
|
|
|
|
if (Regex && !RegularExpression(Name).IsValid())
|
|
|
|
return make_string_error("`{0}` is not a valid regular expression.", Name);
|
|
|
|
|
|
|
|
if (Regex + !Context.empty() + !File.empty() >= 2)
|
|
|
|
return make_string_error(
|
|
|
|
"Only one of -regex, -context and -file may be used simultaneously.");
|
|
|
|
if (Regex && Name.empty())
|
|
|
|
return make_string_error("-regex used without a -name");
|
|
|
|
|
|
|
|
switch (Find) {
|
|
|
|
case FindType::None:
|
2018-06-28 18:03:42 +08:00
|
|
|
if (!Context.empty() || !Name.empty() || !File.empty() || Line != 0)
|
2018-06-12 20:57:36 +08:00
|
|
|
return make_string_error(
|
|
|
|
"Specify search type (-find) to use search options.");
|
|
|
|
return dumpModule;
|
|
|
|
|
|
|
|
case FindType::Function:
|
2018-06-28 18:03:42 +08:00
|
|
|
if (!File.empty() + (Line != 0) == 1)
|
|
|
|
return make_string_error("Both file name and line number must be "
|
|
|
|
"specified when searching a function "
|
|
|
|
"by file position.");
|
|
|
|
if (Regex + (getFunctionNameFlags() != 0) + !File.empty() >= 2)
|
|
|
|
return make_string_error("Only one of regular expression, function-flags "
|
|
|
|
"and file position may be used simultaneously "
|
|
|
|
"when searching a function.");
|
2018-06-12 20:57:36 +08:00
|
|
|
return findFunctions;
|
|
|
|
|
2018-08-29 15:26:11 +08:00
|
|
|
case FindType::Block:
|
|
|
|
if (File.empty() || Line == 0)
|
|
|
|
return make_string_error("Both file name and line number must be "
|
|
|
|
"specified when searching a block.");
|
|
|
|
if (Regex || getFunctionNameFlags() != 0)
|
|
|
|
return make_string_error("Cannot use regular expression or "
|
|
|
|
"function-flags for searching a block.");
|
|
|
|
return findBlocks;
|
|
|
|
|
2018-06-12 20:57:36 +08:00
|
|
|
case FindType::Namespace:
|
2018-06-28 18:03:42 +08:00
|
|
|
if (Regex || !File.empty() || Line != 0)
|
2018-06-12 20:57:36 +08:00
|
|
|
return make_string_error("Cannot search for namespaces using regular "
|
2018-06-28 18:03:42 +08:00
|
|
|
"expressions, file names or line numbers.");
|
2018-06-12 20:57:36 +08:00
|
|
|
return findNamespaces;
|
|
|
|
|
|
|
|
case FindType::Type:
|
2018-06-28 18:03:42 +08:00
|
|
|
if (Regex || !File.empty() || Line != 0)
|
2018-06-12 20:57:36 +08:00
|
|
|
return make_string_error("Cannot search for types using regular "
|
2018-06-28 18:03:42 +08:00
|
|
|
"expressions, file names or line numbers.");
|
2019-08-21 00:44:25 +08:00
|
|
|
if (!Name.empty() && !CompilerContext.empty())
|
|
|
|
return make_string_error("Name is ignored if compiler context present.");
|
|
|
|
|
2018-06-12 20:57:36 +08:00
|
|
|
return findTypes;
|
|
|
|
|
|
|
|
case FindType::Variable:
|
2018-06-28 18:03:42 +08:00
|
|
|
if (Line != 0)
|
|
|
|
return make_string_error("Cannot search for variables "
|
|
|
|
"using line numbers.");
|
2018-06-12 20:57:36 +08:00
|
|
|
return findVariables;
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
}
|
[PDB] Restore AST from PDB symbols
Summary:
This patch adds an implementation of retrieving of declarations and declaration
contexts based on PDB symbols.
PDB has different type symbols for const-qualified types, and this
implementation ensures that only one declaration was created for both const
and non-const types, but creates different compiler types for them.
The implementation also processes the case when there are two symbols
corresponding to a variable. It's possible e.g. for class static variables,
they has one global symbol and one symbol belonging to a class.
PDB has no info about namespaces, so this implementation parses the full symbol
name and tries to figure out if the symbol belongs to namespace or not,
and then creates nested namespaces if necessary.
Reviewers: asmith, zturner, labath
Reviewed By: asmith
Subscribers: aleksandr.urakov, teemperor, lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D51162
llvm-svn: 341782
2018-09-10 16:08:43 +08:00
|
|
|
|
|
|
|
llvm_unreachable("Unsupported symbol action.");
|
2018-06-12 20:57:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
int opts::symbols::dumpSymbols(Debugger &Dbg) {
|
|
|
|
auto ActionOr = getAction();
|
|
|
|
if (!ActionOr) {
|
|
|
|
logAllUnhandledErrors(ActionOr.takeError(), WithColor::error(), "");
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
return 1;
|
|
|
|
}
|
2018-06-12 20:57:36 +08:00
|
|
|
auto Action = *ActionOr;
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
|
Introduce SymbolFileBreakpad and use it to fill symtab
Summary:
This commit adds the glue code necessary to integrate the
SymbolFileBreakpad into the plugin system. Most of the methods are
stubbed out. The only method implemented method is AddSymbols, which
parses the PUBLIC "section" of the breakpad "object file", and fills out
the Module's symtab.
To enable testing this, I've made two additional changes:
- dump Symtab from the SymbolVendor class. The symtab was already being
dumped as a part of the object file dump, but that happened before
symbol vendor kicked in, so it did not reflect any symbols added
there.
- add ability to explicitly specify the external symbol file in
lldb-test (so that the object file could be linked with the breakpad
symbol file). To make things simpler, I've changed lldb-test from
consuming multiple inputs (and dumping their symbols) to having it
just process a single file per invocation. This was not a problem
since everyone was using it that way already.
Reviewers: clayborg, zturner, lemo, markmentovai, amccarth
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D56173
llvm-svn: 350924
2019-01-11 19:17:51 +08:00
|
|
|
outs() << "Module: " << InputFile << "\n";
|
|
|
|
ModuleSpec Spec{FileSpec(InputFile)};
|
|
|
|
StringRef Symbols = SymbolPath.empty() ? InputFile : SymbolPath;
|
|
|
|
Spec.GetSymbolFileSpec().SetFile(Symbols, FileSpec::Style::native);
|
2018-06-12 20:57:36 +08:00
|
|
|
|
Introduce SymbolFileBreakpad and use it to fill symtab
Summary:
This commit adds the glue code necessary to integrate the
SymbolFileBreakpad into the plugin system. Most of the methods are
stubbed out. The only method implemented method is AddSymbols, which
parses the PUBLIC "section" of the breakpad "object file", and fills out
the Module's symtab.
To enable testing this, I've made two additional changes:
- dump Symtab from the SymbolVendor class. The symtab was already being
dumped as a part of the object file dump, but that happened before
symbol vendor kicked in, so it did not reflect any symbols added
there.
- add ability to explicitly specify the external symbol file in
lldb-test (so that the object file could be linked with the breakpad
symbol file). To make things simpler, I've changed lldb-test from
consuming multiple inputs (and dumping their symbols) to having it
just process a single file per invocation. This was not a problem
since everyone was using it that way already.
Reviewers: clayborg, zturner, lemo, markmentovai, amccarth
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D56173
llvm-svn: 350924
2019-01-11 19:17:51 +08:00
|
|
|
auto ModulePtr = std::make_shared<lldb_private::Module>(Spec);
|
2019-08-06 17:12:42 +08:00
|
|
|
SymbolFile *Symfile = ModulePtr->GetSymbolFile();
|
|
|
|
if (!Symfile) {
|
Introduce SymbolFileBreakpad and use it to fill symtab
Summary:
This commit adds the glue code necessary to integrate the
SymbolFileBreakpad into the plugin system. Most of the methods are
stubbed out. The only method implemented method is AddSymbols, which
parses the PUBLIC "section" of the breakpad "object file", and fills out
the Module's symtab.
To enable testing this, I've made two additional changes:
- dump Symtab from the SymbolVendor class. The symtab was already being
dumped as a part of the object file dump, but that happened before
symbol vendor kicked in, so it did not reflect any symbols added
there.
- add ability to explicitly specify the external symbol file in
lldb-test (so that the object file could be linked with the breakpad
symbol file). To make things simpler, I've changed lldb-test from
consuming multiple inputs (and dumping their symbols) to having it
just process a single file per invocation. This was not a problem
since everyone was using it that way already.
Reviewers: clayborg, zturner, lemo, markmentovai, amccarth
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D56173
llvm-svn: 350924
2019-01-11 19:17:51 +08:00
|
|
|
WithColor::error() << "Module has no symbol vendor.\n";
|
|
|
|
return 1;
|
|
|
|
}
|
2017-12-02 08:15:29 +08:00
|
|
|
|
Introduce SymbolFileBreakpad and use it to fill symtab
Summary:
This commit adds the glue code necessary to integrate the
SymbolFileBreakpad into the plugin system. Most of the methods are
stubbed out. The only method implemented method is AddSymbols, which
parses the PUBLIC "section" of the breakpad "object file", and fills out
the Module's symtab.
To enable testing this, I've made two additional changes:
- dump Symtab from the SymbolVendor class. The symtab was already being
dumped as a part of the object file dump, but that happened before
symbol vendor kicked in, so it did not reflect any symbols added
there.
- add ability to explicitly specify the external symbol file in
lldb-test (so that the object file could be linked with the breakpad
symbol file). To make things simpler, I've changed lldb-test from
consuming multiple inputs (and dumping their symbols) to having it
just process a single file per invocation. This was not a problem
since everyone was using it that way already.
Reviewers: clayborg, zturner, lemo, markmentovai, amccarth
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D56173
llvm-svn: 350924
2019-01-11 19:17:51 +08:00
|
|
|
if (Error E = Action(*ModulePtr)) {
|
|
|
|
WithColor::error() << toString(std::move(E)) << "\n";
|
|
|
|
return 1;
|
2017-12-02 08:15:29 +08:00
|
|
|
}
|
Introduce SymbolFileBreakpad and use it to fill symtab
Summary:
This commit adds the glue code necessary to integrate the
SymbolFileBreakpad into the plugin system. Most of the methods are
stubbed out. The only method implemented method is AddSymbols, which
parses the PUBLIC "section" of the breakpad "object file", and fills out
the Module's symtab.
To enable testing this, I've made two additional changes:
- dump Symtab from the SymbolVendor class. The symtab was already being
dumped as a part of the object file dump, but that happened before
symbol vendor kicked in, so it did not reflect any symbols added
there.
- add ability to explicitly specify the external symbol file in
lldb-test (so that the object file could be linked with the breakpad
symbol file). To make things simpler, I've changed lldb-test from
consuming multiple inputs (and dumping their symbols) to having it
just process a single file per invocation. This was not a problem
since everyone was using it that way already.
Reviewers: clayborg, zturner, lemo, markmentovai, amccarth
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D56173
llvm-svn: 350924
2019-01-11 19:17:51 +08:00
|
|
|
|
|
|
|
return 0;
|
2017-12-02 08:15:29 +08:00
|
|
|
}
|
|
|
|
|
2018-12-12 20:35:25 +08:00
|
|
|
static void dumpSectionList(LinePrinter &Printer, const SectionList &List, bool is_subsection) {
|
|
|
|
size_t Count = List.GetNumSections(0);
|
|
|
|
if (Count == 0) {
|
|
|
|
Printer.formatLine("There are no {0}sections", is_subsection ? "sub" : "");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
Printer.formatLine("Showing {0} {1}sections", Count,
|
|
|
|
is_subsection ? "sub" : "");
|
|
|
|
for (size_t I = 0; I < Count; ++I) {
|
|
|
|
auto S = List.GetSectionAtIndex(I);
|
|
|
|
assert(S);
|
|
|
|
AutoIndent Indent(Printer, 2);
|
|
|
|
Printer.formatLine("Index: {0}", I);
|
2018-12-18 23:56:45 +08:00
|
|
|
Printer.formatLine("ID: {0:x}", S->GetID());
|
2018-12-12 20:35:25 +08:00
|
|
|
Printer.formatLine("Name: {0}", S->GetName().GetStringRef());
|
|
|
|
Printer.formatLine("Type: {0}", S->GetTypeAsCString());
|
ELF: more section creation cleanup
Summary:
This patch attempts to move as much code as possible out of the
CreateSections function to make room for future improvements there. Some
of this may be slightly over-engineered (VMAddressProvider), but I
wanted to keep the logic of this function very simple, because once I
start taking segment headers into acount (as discussed in D55356), the
function is going to grow significantly.
While in there, I also added tests for various bits of functionality.
This should be NFC, except that I changed the order of hac^H^Heuristicks
for determining section type slightly. Previously, name-based deduction
(.symtab -> symtab) would take precedence over type-based (SHT_SYMTAB ->
symtab) one. In fact we would assert if we ran into a .text section with
type SHT_SYMTAB. Though unlikely to matter in practice, this order
seemed wrong to me, so I have inverted it.
Reviewers: clayborg, krytarowski, espindola
Subscribers: emaste, arichardson, lldb-commits
Differential Revision: https://reviews.llvm.org/D55706
llvm-svn: 349268
2018-12-15 21:45:38 +08:00
|
|
|
Printer.formatLine("Permissions: {0}", GetPermissionsAsCString(S->GetPermissions()));
|
2018-12-12 23:46:18 +08:00
|
|
|
Printer.formatLine("Thread specific: {0:y}", S->IsThreadSpecific());
|
ELF: more section creation cleanup
Summary:
This patch attempts to move as much code as possible out of the
CreateSections function to make room for future improvements there. Some
of this may be slightly over-engineered (VMAddressProvider), but I
wanted to keep the logic of this function very simple, because once I
start taking segment headers into acount (as discussed in D55356), the
function is going to grow significantly.
While in there, I also added tests for various bits of functionality.
This should be NFC, except that I changed the order of hac^H^Heuristicks
for determining section type slightly. Previously, name-based deduction
(.symtab -> symtab) would take precedence over type-based (SHT_SYMTAB ->
symtab) one. In fact we would assert if we ran into a .text section with
type SHT_SYMTAB. Though unlikely to matter in practice, this order
seemed wrong to me, so I have inverted it.
Reviewers: clayborg, krytarowski, espindola
Subscribers: emaste, arichardson, lldb-commits
Differential Revision: https://reviews.llvm.org/D55706
llvm-svn: 349268
2018-12-15 21:45:38 +08:00
|
|
|
Printer.formatLine("VM address: {0:x}", S->GetFileAddress());
|
2018-12-12 20:35:25 +08:00
|
|
|
Printer.formatLine("VM size: {0}", S->GetByteSize());
|
|
|
|
Printer.formatLine("File size: {0}", S->GetFileSize());
|
|
|
|
|
|
|
|
if (opts::object::SectionContents) {
|
2019-07-12 04:26:53 +08:00
|
|
|
lldb_private::DataExtractor Data;
|
2018-12-12 20:35:25 +08:00
|
|
|
S->GetSectionData(Data);
|
2020-02-25 16:11:13 +08:00
|
|
|
ArrayRef<uint8_t> Bytes(Data.GetDataStart(), Data.GetDataEnd());
|
2018-12-12 20:35:25 +08:00
|
|
|
Printer.formatBinary("Data: ", Bytes, 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (S->GetType() == eSectionTypeContainer)
|
|
|
|
dumpSectionList(Printer, S->GetChildren(), true);
|
|
|
|
Printer.NewLine();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-06-29 20:15:54 +08:00
|
|
|
static int dumpObjectFiles(Debugger &Dbg) {
|
2017-12-01 08:52:51 +08:00
|
|
|
LinePrinter Printer(4, llvm::outs());
|
|
|
|
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
int HadErrors = 0;
|
2018-06-29 20:15:54 +08:00
|
|
|
for (const auto &File : opts::object::InputFilenames) {
|
2018-11-02 05:05:36 +08:00
|
|
|
ModuleSpec Spec{FileSpec(File)};
|
2017-12-01 08:52:51 +08:00
|
|
|
|
2017-12-02 08:15:29 +08:00
|
|
|
auto ModulePtr = std::make_shared<lldb_private::Module>(Spec);
|
Re-commit "Introduce ObjectFileBreakpad"
This re-commits r348592, which was reverted due to a failing test on
macos.
The issue was that I was passing a null pointer for the
"CreateMemoryInstance" callback when registering ObjectFileBreakpad,
which caused crashes when attemping to load modules from memory. The
correct thing to do is to pass a callback which always returns a null
pointer (as breakpad files are never loaded in inferior memory).
It turns out that there is only one test which exercises this code path,
and it's mac-only, so I've create a new test which should run everywhere
(except windows, as one cannot delete an executable which is being run).
Unfortunately, this test still fails on linux for other reasons, but at
least it gives us something to aim for.
The original commit message was:
This patch adds the scaffolding necessary for lldb to recognise symbol
files generated by breakpad. These (textual) files contain just enough
information to be able to produce a backtrace from a crash
dump. This information includes:
- UUID, architecture and name of the module
- line tables
- list of symbols
- unwind information
A minimal breakpad file could look like this:
MODULE Linux x86_64 0000000024B5D199F0F766FFFFFF5DC30 a.out
INFO CODE_ID 00000000B52499D1F0F766FFFFFF5DC3
FILE 0 /tmp/a.c
FUNC 1010 10 0 _start
1010 4 4 0
1014 5 5 0
1019 5 6 0
101e 2 7 0
PUBLIC 1010 0 _start
STACK CFI INIT 1010 10 .cfa: $rsp 8 + .ra: .cfa -8 + ^
STACK CFI 1011 $rbp: .cfa -16 + ^ .cfa: $rsp 16 +
STACK CFI 1014 .cfa: $rbp 16 +
Even though this data would normally be considered "symbol" information,
in the current lldb infrastructure it is assumed every SymbolFile object
is backed by an ObjectFile instance. So, in order to better interoperate
with the rest of the code (particularly symbol vendors).
In this patch I just parse the breakpad header, which is enough to
populate the UUID and architecture fields of the ObjectFile interface.
The rough plan for followup patches is to expose the individual parts of
the breakpad file as ObjectFile "sections", which can then be used by
other parts of the codebase (SymbolFileBreakpad ?) to vend the necessary
information.
Reviewers: clayborg, zturner, lemo, amccarth
Subscribers: mgorny, fedor.sergeev, markmentovai, lldb-commits
Differential Revision: https://reviews.llvm.org/D55214
llvm-svn: 348773
2018-12-11 01:16:38 +08:00
|
|
|
|
|
|
|
ObjectFile *ObjectPtr = ModulePtr->GetObjectFile();
|
|
|
|
if (!ObjectPtr) {
|
|
|
|
WithColor::error() << File << " not recognised as an object file\n";
|
|
|
|
HadErrors = 1;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2018-03-06 23:56:20 +08:00
|
|
|
// Fetch symbol vendor before we get the section list to give the symbol
|
|
|
|
// vendor a chance to populate it.
|
2019-08-06 17:12:42 +08:00
|
|
|
ModulePtr->GetSymbolFile();
|
2017-12-01 08:52:51 +08:00
|
|
|
SectionList *Sections = ModulePtr->GetSectionList();
|
|
|
|
if (!Sections) {
|
|
|
|
llvm::errs() << "Could not load sections for module " << File << "\n";
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
HadErrors = 1;
|
2017-12-01 08:52:51 +08:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
Re-commit "Introduce ObjectFileBreakpad"
This re-commits r348592, which was reverted due to a failing test on
macos.
The issue was that I was passing a null pointer for the
"CreateMemoryInstance" callback when registering ObjectFileBreakpad,
which caused crashes when attemping to load modules from memory. The
correct thing to do is to pass a callback which always returns a null
pointer (as breakpad files are never loaded in inferior memory).
It turns out that there is only one test which exercises this code path,
and it's mac-only, so I've create a new test which should run everywhere
(except windows, as one cannot delete an executable which is being run).
Unfortunately, this test still fails on linux for other reasons, but at
least it gives us something to aim for.
The original commit message was:
This patch adds the scaffolding necessary for lldb to recognise symbol
files generated by breakpad. These (textual) files contain just enough
information to be able to produce a backtrace from a crash
dump. This information includes:
- UUID, architecture and name of the module
- line tables
- list of symbols
- unwind information
A minimal breakpad file could look like this:
MODULE Linux x86_64 0000000024B5D199F0F766FFFFFF5DC30 a.out
INFO CODE_ID 00000000B52499D1F0F766FFFFFF5DC3
FILE 0 /tmp/a.c
FUNC 1010 10 0 _start
1010 4 4 0
1014 5 5 0
1019 5 6 0
101e 2 7 0
PUBLIC 1010 0 _start
STACK CFI INIT 1010 10 .cfa: $rsp 8 + .ra: .cfa -8 + ^
STACK CFI 1011 $rbp: .cfa -16 + ^ .cfa: $rsp 16 +
STACK CFI 1014 .cfa: $rbp 16 +
Even though this data would normally be considered "symbol" information,
in the current lldb infrastructure it is assumed every SymbolFile object
is backed by an ObjectFile instance. So, in order to better interoperate
with the rest of the code (particularly symbol vendors).
In this patch I just parse the breakpad header, which is enough to
populate the UUID and architecture fields of the ObjectFile interface.
The rough plan for followup patches is to expose the individual parts of
the breakpad file as ObjectFile "sections", which can then be used by
other parts of the codebase (SymbolFileBreakpad ?) to vend the necessary
information.
Reviewers: clayborg, zturner, lemo, amccarth
Subscribers: mgorny, fedor.sergeev, markmentovai, lldb-commits
Differential Revision: https://reviews.llvm.org/D55214
llvm-svn: 348773
2018-12-11 01:16:38 +08:00
|
|
|
Printer.formatLine("Plugin name: {0}", ObjectPtr->GetPluginName());
|
2018-06-29 20:15:54 +08:00
|
|
|
Printer.formatLine("Architecture: {0}",
|
|
|
|
ModulePtr->GetArchitecture().GetTriple().getTriple());
|
|
|
|
Printer.formatLine("UUID: {0}", ModulePtr->GetUUID().GetAsString());
|
Re-commit "Introduce ObjectFileBreakpad"
This re-commits r348592, which was reverted due to a failing test on
macos.
The issue was that I was passing a null pointer for the
"CreateMemoryInstance" callback when registering ObjectFileBreakpad,
which caused crashes when attemping to load modules from memory. The
correct thing to do is to pass a callback which always returns a null
pointer (as breakpad files are never loaded in inferior memory).
It turns out that there is only one test which exercises this code path,
and it's mac-only, so I've create a new test which should run everywhere
(except windows, as one cannot delete an executable which is being run).
Unfortunately, this test still fails on linux for other reasons, but at
least it gives us something to aim for.
The original commit message was:
This patch adds the scaffolding necessary for lldb to recognise symbol
files generated by breakpad. These (textual) files contain just enough
information to be able to produce a backtrace from a crash
dump. This information includes:
- UUID, architecture and name of the module
- line tables
- list of symbols
- unwind information
A minimal breakpad file could look like this:
MODULE Linux x86_64 0000000024B5D199F0F766FFFFFF5DC30 a.out
INFO CODE_ID 00000000B52499D1F0F766FFFFFF5DC3
FILE 0 /tmp/a.c
FUNC 1010 10 0 _start
1010 4 4 0
1014 5 5 0
1019 5 6 0
101e 2 7 0
PUBLIC 1010 0 _start
STACK CFI INIT 1010 10 .cfa: $rsp 8 + .ra: .cfa -8 + ^
STACK CFI 1011 $rbp: .cfa -16 + ^ .cfa: $rsp 16 +
STACK CFI 1014 .cfa: $rbp 16 +
Even though this data would normally be considered "symbol" information,
in the current lldb infrastructure it is assumed every SymbolFile object
is backed by an ObjectFile instance. So, in order to better interoperate
with the rest of the code (particularly symbol vendors).
In this patch I just parse the breakpad header, which is enough to
populate the UUID and architecture fields of the ObjectFile interface.
The rough plan for followup patches is to expose the individual parts of
the breakpad file as ObjectFile "sections", which can then be used by
other parts of the codebase (SymbolFileBreakpad ?) to vend the necessary
information.
Reviewers: clayborg, zturner, lemo, amccarth
Subscribers: mgorny, fedor.sergeev, markmentovai, lldb-commits
Differential Revision: https://reviews.llvm.org/D55214
llvm-svn: 348773
2018-12-11 01:16:38 +08:00
|
|
|
Printer.formatLine("Executable: {0}", ObjectPtr->IsExecutable());
|
|
|
|
Printer.formatLine("Stripped: {0}", ObjectPtr->IsStripped());
|
|
|
|
Printer.formatLine("Type: {0}", ObjectPtr->GetType());
|
|
|
|
Printer.formatLine("Strata: {0}", ObjectPtr->GetStrata());
|
2019-01-10 17:32:31 +08:00
|
|
|
Printer.formatLine("Base VM address: {0:x}",
|
|
|
|
ObjectPtr->GetBaseAddress().GetFileAddress());
|
2018-06-29 20:15:54 +08:00
|
|
|
|
2018-12-12 20:35:25 +08:00
|
|
|
dumpSectionList(Printer, *Sections, /*is_subsection*/ false);
|
[pecoff] Implement ObjectFilePECOFF::GetDependedModules()
Summary:
This parses entries in pecoff import tables for imported DLLs and
is intended as the first step to allow LLDB to load a PE's shared
modules when creating a target on the LLDB console.
Reviewers: rnk, zturner, aleksandr.urakov, lldb-commits, labath, asmith
Reviewed By: labath, asmith
Subscribers: labath, lemo, clayborg, Hui, mgorny, mgrang, teemperor
Differential Revision: https://reviews.llvm.org/D53094
llvm-svn: 348527
2018-12-07 05:36:39 +08:00
|
|
|
|
|
|
|
if (opts::object::SectionDependentModules) {
|
|
|
|
// A non-empty section list ensures a valid object file.
|
|
|
|
auto Obj = ModulePtr->GetObjectFile();
|
|
|
|
FileSpecList Files;
|
|
|
|
auto Count = Obj->GetDependentModules(Files);
|
|
|
|
Printer.formatLine("Showing {0} dependent module(s)", Count);
|
|
|
|
for (size_t I = 0; I < Files.GetSize(); ++I) {
|
|
|
|
AutoIndent Indent(Printer, 2);
|
|
|
|
Printer.formatLine("Name: {0}",
|
|
|
|
Files.GetFileSpecAtIndex(I).GetCString());
|
|
|
|
}
|
|
|
|
Printer.NewLine();
|
|
|
|
}
|
2017-12-01 08:52:51 +08:00
|
|
|
}
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
return HadErrors;
|
2017-12-01 08:52:51 +08:00
|
|
|
}
|
|
|
|
|
2018-06-05 01:11:15 +08:00
|
|
|
bool opts::irmemorymap::evalMalloc(StringRef Line,
|
|
|
|
IRMemoryMapTestState &State) {
|
|
|
|
// ::= <label> = malloc <size> <alignment>
|
|
|
|
StringRef Label;
|
|
|
|
std::tie(Label, Line) = Line.split('=');
|
|
|
|
if (Line.empty())
|
|
|
|
return false;
|
|
|
|
Label = Label.trim();
|
|
|
|
Line = Line.trim();
|
[lldb-test] Add a testing harness for the JIT's IRMemoryMap
This teaches lldb-test how to launch a process, set up an IRMemoryMap,
and issue memory allocations in the target process through the map. This
makes it possible to test IRMemoryMap in a targeted way.
This has uncovered two bugs so far. The first bug is that Malloc
performs an adjustment on the pointer returned from AllocateMemory (for
alignment purposes) which ultimately allows overlapping memory regions
to be created. The second bug is that after most of the address space on
the host side is exhausted, Malloc may return the same address multiple
times. These bugs (and hopefully more!) can be uncovered and tested for
with targeted lldb-test commands.
At an even higher level, the motivation for addressing these bugs is
that they can lead to strange user-visible failures (e.g, variables
assume the wrong value during expression evaluation, or the debugger
crashes). See my third comment on this swift-lldb PR for an example:
https://github.com/apple/swift-lldb/pull/652
I hope lldb-test is the right place to add this testing harness. Setting
up a gtest-style unit test proved too cumbersome (you need to recreate
or mock way too much debugger state), as did writing end-to-end tests
(it's hard to write a test that actually hits a buggy path).
With lldb-test, it's easy to read/generate the test input and parse the
test output. I'll attach a simple "fuzz" tester which generates failing
test cases to the Phab review. Here's an example:
```
Command: malloc(size=1024, alignment=32)
Malloc: address = 0xca000
Command: malloc(size=64, alignment=16)
Malloc: address = 0xca400
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca440
Command: malloc(size=16, alignment=8)
Malloc: address = 0xca840
Command: malloc(size=2048, alignment=16)
Malloc: address = 0xcb000
Command: malloc(size=64, alignment=32)
Malloc: address = 0xca860
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca890
Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0)
```
{F6288839}
Differential Revision: https://reviews.llvm.org/D47508
llvm-svn: 333583
2018-05-31 03:39:10 +08:00
|
|
|
size_t Size;
|
|
|
|
uint8_t Alignment;
|
|
|
|
int Matches = sscanf(Line.data(), "malloc %zu %hhu", &Size, &Alignment);
|
|
|
|
if (Matches != 2)
|
|
|
|
return false;
|
|
|
|
|
2018-06-05 01:11:15 +08:00
|
|
|
outs() << formatv("Command: {0} = malloc(size={1}, alignment={2})\n", Label,
|
|
|
|
Size, Alignment);
|
[lldb-test] Add a testing harness for the JIT's IRMemoryMap
This teaches lldb-test how to launch a process, set up an IRMemoryMap,
and issue memory allocations in the target process through the map. This
makes it possible to test IRMemoryMap in a targeted way.
This has uncovered two bugs so far. The first bug is that Malloc
performs an adjustment on the pointer returned from AllocateMemory (for
alignment purposes) which ultimately allows overlapping memory regions
to be created. The second bug is that after most of the address space on
the host side is exhausted, Malloc may return the same address multiple
times. These bugs (and hopefully more!) can be uncovered and tested for
with targeted lldb-test commands.
At an even higher level, the motivation for addressing these bugs is
that they can lead to strange user-visible failures (e.g, variables
assume the wrong value during expression evaluation, or the debugger
crashes). See my third comment on this swift-lldb PR for an example:
https://github.com/apple/swift-lldb/pull/652
I hope lldb-test is the right place to add this testing harness. Setting
up a gtest-style unit test proved too cumbersome (you need to recreate
or mock way too much debugger state), as did writing end-to-end tests
(it's hard to write a test that actually hits a buggy path).
With lldb-test, it's easy to read/generate the test input and parse the
test output. I'll attach a simple "fuzz" tester which generates failing
test cases to the Phab review. Here's an example:
```
Command: malloc(size=1024, alignment=32)
Malloc: address = 0xca000
Command: malloc(size=64, alignment=16)
Malloc: address = 0xca400
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca440
Command: malloc(size=16, alignment=8)
Malloc: address = 0xca840
Command: malloc(size=2048, alignment=16)
Malloc: address = 0xcb000
Command: malloc(size=64, alignment=32)
Malloc: address = 0xca860
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca890
Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0)
```
{F6288839}
Differential Revision: https://reviews.llvm.org/D47508
llvm-svn: 333583
2018-05-31 03:39:10 +08:00
|
|
|
if (!isPowerOf2_32(Alignment)) {
|
|
|
|
outs() << "Malloc error: alignment is not a power of 2\n";
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
2018-06-01 06:09:00 +08:00
|
|
|
IRMemoryMap::AllocationPolicy AP =
|
|
|
|
UseHostOnlyAllocationPolicy ? IRMemoryMap::eAllocationPolicyHostOnly
|
|
|
|
: IRMemoryMap::eAllocationPolicyProcessOnly;
|
|
|
|
|
[lldb-test] Add a testing harness for the JIT's IRMemoryMap
This teaches lldb-test how to launch a process, set up an IRMemoryMap,
and issue memory allocations in the target process through the map. This
makes it possible to test IRMemoryMap in a targeted way.
This has uncovered two bugs so far. The first bug is that Malloc
performs an adjustment on the pointer returned from AllocateMemory (for
alignment purposes) which ultimately allows overlapping memory regions
to be created. The second bug is that after most of the address space on
the host side is exhausted, Malloc may return the same address multiple
times. These bugs (and hopefully more!) can be uncovered and tested for
with targeted lldb-test commands.
At an even higher level, the motivation for addressing these bugs is
that they can lead to strange user-visible failures (e.g, variables
assume the wrong value during expression evaluation, or the debugger
crashes). See my third comment on this swift-lldb PR for an example:
https://github.com/apple/swift-lldb/pull/652
I hope lldb-test is the right place to add this testing harness. Setting
up a gtest-style unit test proved too cumbersome (you need to recreate
or mock way too much debugger state), as did writing end-to-end tests
(it's hard to write a test that actually hits a buggy path).
With lldb-test, it's easy to read/generate the test input and parse the
test output. I'll attach a simple "fuzz" tester which generates failing
test cases to the Phab review. Here's an example:
```
Command: malloc(size=1024, alignment=32)
Malloc: address = 0xca000
Command: malloc(size=64, alignment=16)
Malloc: address = 0xca400
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca440
Command: malloc(size=16, alignment=8)
Malloc: address = 0xca840
Command: malloc(size=2048, alignment=16)
Malloc: address = 0xcb000
Command: malloc(size=64, alignment=32)
Malloc: address = 0xca860
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca890
Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0)
```
{F6288839}
Differential Revision: https://reviews.llvm.org/D47508
llvm-svn: 333583
2018-05-31 03:39:10 +08:00
|
|
|
// Issue the malloc in the target process with "-rw" permissions.
|
|
|
|
const uint32_t Permissions = 0x3;
|
|
|
|
const bool ZeroMemory = false;
|
|
|
|
Status ST;
|
|
|
|
addr_t Addr =
|
2018-06-05 01:11:15 +08:00
|
|
|
State.Map.Malloc(Size, Alignment, Permissions, AP, ZeroMemory, ST);
|
[lldb-test] Add a testing harness for the JIT's IRMemoryMap
This teaches lldb-test how to launch a process, set up an IRMemoryMap,
and issue memory allocations in the target process through the map. This
makes it possible to test IRMemoryMap in a targeted way.
This has uncovered two bugs so far. The first bug is that Malloc
performs an adjustment on the pointer returned from AllocateMemory (for
alignment purposes) which ultimately allows overlapping memory regions
to be created. The second bug is that after most of the address space on
the host side is exhausted, Malloc may return the same address multiple
times. These bugs (and hopefully more!) can be uncovered and tested for
with targeted lldb-test commands.
At an even higher level, the motivation for addressing these bugs is
that they can lead to strange user-visible failures (e.g, variables
assume the wrong value during expression evaluation, or the debugger
crashes). See my third comment on this swift-lldb PR for an example:
https://github.com/apple/swift-lldb/pull/652
I hope lldb-test is the right place to add this testing harness. Setting
up a gtest-style unit test proved too cumbersome (you need to recreate
or mock way too much debugger state), as did writing end-to-end tests
(it's hard to write a test that actually hits a buggy path).
With lldb-test, it's easy to read/generate the test input and parse the
test output. I'll attach a simple "fuzz" tester which generates failing
test cases to the Phab review. Here's an example:
```
Command: malloc(size=1024, alignment=32)
Malloc: address = 0xca000
Command: malloc(size=64, alignment=16)
Malloc: address = 0xca400
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca440
Command: malloc(size=16, alignment=8)
Malloc: address = 0xca840
Command: malloc(size=2048, alignment=16)
Malloc: address = 0xcb000
Command: malloc(size=64, alignment=32)
Malloc: address = 0xca860
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca890
Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0)
```
{F6288839}
Differential Revision: https://reviews.llvm.org/D47508
llvm-svn: 333583
2018-05-31 03:39:10 +08:00
|
|
|
if (ST.Fail()) {
|
|
|
|
outs() << formatv("Malloc error: {0}\n", ST);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Print the result of the allocation before checking its validity.
|
|
|
|
outs() << formatv("Malloc: address = {0:x}\n", Addr);
|
|
|
|
|
|
|
|
// Check that the allocation is aligned.
|
|
|
|
if (!Addr || Addr % Alignment != 0) {
|
|
|
|
outs() << "Malloc error: zero or unaligned allocation detected\n";
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
2018-12-27 17:32:04 +08:00
|
|
|
// In case of Size == 0, we still expect the returned address to be unique and
|
|
|
|
// non-overlapping.
|
|
|
|
addr_t EndOfRegion = Addr + std::max<size_t>(Size, 1);
|
|
|
|
if (State.Allocations.overlaps(Addr, EndOfRegion)) {
|
|
|
|
auto I = State.Allocations.find(Addr);
|
|
|
|
outs() << "Malloc error: overlapping allocation detected"
|
|
|
|
<< formatv(", previous allocation at [{0:x}, {1:x})\n", I.start(),
|
|
|
|
I.stop());
|
|
|
|
exit(1);
|
[lldb-test] Add a testing harness for the JIT's IRMemoryMap
This teaches lldb-test how to launch a process, set up an IRMemoryMap,
and issue memory allocations in the target process through the map. This
makes it possible to test IRMemoryMap in a targeted way.
This has uncovered two bugs so far. The first bug is that Malloc
performs an adjustment on the pointer returned from AllocateMemory (for
alignment purposes) which ultimately allows overlapping memory regions
to be created. The second bug is that after most of the address space on
the host side is exhausted, Malloc may return the same address multiple
times. These bugs (and hopefully more!) can be uncovered and tested for
with targeted lldb-test commands.
At an even higher level, the motivation for addressing these bugs is
that they can lead to strange user-visible failures (e.g, variables
assume the wrong value during expression evaluation, or the debugger
crashes). See my third comment on this swift-lldb PR for an example:
https://github.com/apple/swift-lldb/pull/652
I hope lldb-test is the right place to add this testing harness. Setting
up a gtest-style unit test proved too cumbersome (you need to recreate
or mock way too much debugger state), as did writing end-to-end tests
(it's hard to write a test that actually hits a buggy path).
With lldb-test, it's easy to read/generate the test input and parse the
test output. I'll attach a simple "fuzz" tester which generates failing
test cases to the Phab review. Here's an example:
```
Command: malloc(size=1024, alignment=32)
Malloc: address = 0xca000
Command: malloc(size=64, alignment=16)
Malloc: address = 0xca400
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca440
Command: malloc(size=16, alignment=8)
Malloc: address = 0xca840
Command: malloc(size=2048, alignment=16)
Malloc: address = 0xcb000
Command: malloc(size=64, alignment=32)
Malloc: address = 0xca860
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca890
Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0)
```
{F6288839}
Differential Revision: https://reviews.llvm.org/D47508
llvm-svn: 333583
2018-05-31 03:39:10 +08:00
|
|
|
}
|
|
|
|
|
[pecoff] Implement ObjectFilePECOFF::GetDependedModules()
Summary:
This parses entries in pecoff import tables for imported DLLs and
is intended as the first step to allow LLDB to load a PE's shared
modules when creating a target on the LLDB console.
Reviewers: rnk, zturner, aleksandr.urakov, lldb-commits, labath, asmith
Reviewed By: labath, asmith
Subscribers: labath, lemo, clayborg, Hui, mgorny, mgrang, teemperor
Differential Revision: https://reviews.llvm.org/D53094
llvm-svn: 348527
2018-12-07 05:36:39 +08:00
|
|
|
// Insert the new allocation into the interval map. Use unique allocation
|
|
|
|
// IDs to inhibit interval coalescing.
|
2018-06-01 06:09:01 +08:00
|
|
|
static unsigned AllocationID = 0;
|
2018-12-27 17:32:04 +08:00
|
|
|
State.Allocations.insert(Addr, EndOfRegion, AllocationID++);
|
2018-06-05 01:11:15 +08:00
|
|
|
|
|
|
|
// Store the label -> address mapping.
|
|
|
|
State.Label2AddrMap[Label] = Addr;
|
2018-06-01 06:09:01 +08:00
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2018-06-05 01:11:15 +08:00
|
|
|
bool opts::irmemorymap::evalFree(StringRef Line, IRMemoryMapTestState &State) {
|
|
|
|
// ::= free <label>
|
|
|
|
if (!Line.consume_front("free"))
|
2018-06-01 06:09:01 +08:00
|
|
|
return false;
|
2018-06-05 01:11:15 +08:00
|
|
|
StringRef Label = Line.trim();
|
2018-06-01 06:09:01 +08:00
|
|
|
|
2018-06-05 01:11:15 +08:00
|
|
|
outs() << formatv("Command: free({0})\n", Label);
|
|
|
|
auto LabelIt = State.Label2AddrMap.find(Label);
|
|
|
|
if (LabelIt == State.Label2AddrMap.end()) {
|
|
|
|
outs() << "Free error: Invalid allocation label\n";
|
2018-06-01 06:09:01 +08:00
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
|
|
|
Status ST;
|
2018-06-05 01:11:15 +08:00
|
|
|
addr_t Addr = LabelIt->getValue();
|
|
|
|
State.Map.Free(Addr, ST);
|
2018-06-01 06:09:01 +08:00
|
|
|
if (ST.Fail()) {
|
|
|
|
outs() << formatv("Free error: {0}\n", ST);
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Erase the allocation from the live interval map.
|
2018-06-05 01:11:15 +08:00
|
|
|
auto Interval = State.Allocations.find(Addr);
|
|
|
|
if (Interval != State.Allocations.end()) {
|
|
|
|
outs() << formatv("Free: [{0:x}, {1:x})\n", Interval.start(),
|
|
|
|
Interval.stop());
|
|
|
|
Interval.erase();
|
|
|
|
}
|
[lldb-test] Add a testing harness for the JIT's IRMemoryMap
This teaches lldb-test how to launch a process, set up an IRMemoryMap,
and issue memory allocations in the target process through the map. This
makes it possible to test IRMemoryMap in a targeted way.
This has uncovered two bugs so far. The first bug is that Malloc
performs an adjustment on the pointer returned from AllocateMemory (for
alignment purposes) which ultimately allows overlapping memory regions
to be created. The second bug is that after most of the address space on
the host side is exhausted, Malloc may return the same address multiple
times. These bugs (and hopefully more!) can be uncovered and tested for
with targeted lldb-test commands.
At an even higher level, the motivation for addressing these bugs is
that they can lead to strange user-visible failures (e.g, variables
assume the wrong value during expression evaluation, or the debugger
crashes). See my third comment on this swift-lldb PR for an example:
https://github.com/apple/swift-lldb/pull/652
I hope lldb-test is the right place to add this testing harness. Setting
up a gtest-style unit test proved too cumbersome (you need to recreate
or mock way too much debugger state), as did writing end-to-end tests
(it's hard to write a test that actually hits a buggy path).
With lldb-test, it's easy to read/generate the test input and parse the
test output. I'll attach a simple "fuzz" tester which generates failing
test cases to the Phab review. Here's an example:
```
Command: malloc(size=1024, alignment=32)
Malloc: address = 0xca000
Command: malloc(size=64, alignment=16)
Malloc: address = 0xca400
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca440
Command: malloc(size=16, alignment=8)
Malloc: address = 0xca840
Command: malloc(size=2048, alignment=16)
Malloc: address = 0xcb000
Command: malloc(size=64, alignment=32)
Malloc: address = 0xca860
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca890
Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0)
```
{F6288839}
Differential Revision: https://reviews.llvm.org/D47508
llvm-svn: 333583
2018-05-31 03:39:10 +08:00
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
int opts::irmemorymap::evaluateMemoryMapCommands(Debugger &Dbg) {
|
|
|
|
// Set up a Target.
|
|
|
|
TargetSP Target = opts::createTarget(Dbg, irmemorymap::Target);
|
|
|
|
|
|
|
|
// Set up a Process. In order to allocate memory within a target, this
|
|
|
|
// process must be alive and must support JIT'ing.
|
2020-06-10 01:21:09 +08:00
|
|
|
CommandReturnObject Result(/*colors*/ false);
|
[lldb-test] Add a testing harness for the JIT's IRMemoryMap
This teaches lldb-test how to launch a process, set up an IRMemoryMap,
and issue memory allocations in the target process through the map. This
makes it possible to test IRMemoryMap in a targeted way.
This has uncovered two bugs so far. The first bug is that Malloc
performs an adjustment on the pointer returned from AllocateMemory (for
alignment purposes) which ultimately allows overlapping memory regions
to be created. The second bug is that after most of the address space on
the host side is exhausted, Malloc may return the same address multiple
times. These bugs (and hopefully more!) can be uncovered and tested for
with targeted lldb-test commands.
At an even higher level, the motivation for addressing these bugs is
that they can lead to strange user-visible failures (e.g, variables
assume the wrong value during expression evaluation, or the debugger
crashes). See my third comment on this swift-lldb PR for an example:
https://github.com/apple/swift-lldb/pull/652
I hope lldb-test is the right place to add this testing harness. Setting
up a gtest-style unit test proved too cumbersome (you need to recreate
or mock way too much debugger state), as did writing end-to-end tests
(it's hard to write a test that actually hits a buggy path).
With lldb-test, it's easy to read/generate the test input and parse the
test output. I'll attach a simple "fuzz" tester which generates failing
test cases to the Phab review. Here's an example:
```
Command: malloc(size=1024, alignment=32)
Malloc: address = 0xca000
Command: malloc(size=64, alignment=16)
Malloc: address = 0xca400
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca440
Command: malloc(size=16, alignment=8)
Malloc: address = 0xca840
Command: malloc(size=2048, alignment=16)
Malloc: address = 0xcb000
Command: malloc(size=64, alignment=32)
Malloc: address = 0xca860
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca890
Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0)
```
{F6288839}
Differential Revision: https://reviews.llvm.org/D47508
llvm-svn: 333583
2018-05-31 03:39:10 +08:00
|
|
|
Dbg.SetAsyncExecution(false);
|
|
|
|
CommandInterpreter &CI = Dbg.GetCommandInterpreter();
|
|
|
|
auto IssueCmd = [&](const char *Cmd) -> bool {
|
|
|
|
return CI.HandleCommand(Cmd, eLazyBoolNo, Result);
|
|
|
|
};
|
|
|
|
if (!IssueCmd("b main") || !IssueCmd("run")) {
|
|
|
|
outs() << formatv("Failed: {0}\n", Result.GetErrorData());
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
|
|
|
ProcessSP Process = Target->GetProcessSP();
|
|
|
|
if (!Process || !Process->IsAlive() || !Process->CanJIT()) {
|
|
|
|
outs() << "Cannot use process to test IRMemoryMap\n";
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Set up an IRMemoryMap and associated testing state.
|
2018-06-05 01:11:15 +08:00
|
|
|
IRMemoryMapTestState State(Target);
|
[lldb-test] Add a testing harness for the JIT's IRMemoryMap
This teaches lldb-test how to launch a process, set up an IRMemoryMap,
and issue memory allocations in the target process through the map. This
makes it possible to test IRMemoryMap in a targeted way.
This has uncovered two bugs so far. The first bug is that Malloc
performs an adjustment on the pointer returned from AllocateMemory (for
alignment purposes) which ultimately allows overlapping memory regions
to be created. The second bug is that after most of the address space on
the host side is exhausted, Malloc may return the same address multiple
times. These bugs (and hopefully more!) can be uncovered and tested for
with targeted lldb-test commands.
At an even higher level, the motivation for addressing these bugs is
that they can lead to strange user-visible failures (e.g, variables
assume the wrong value during expression evaluation, or the debugger
crashes). See my third comment on this swift-lldb PR for an example:
https://github.com/apple/swift-lldb/pull/652
I hope lldb-test is the right place to add this testing harness. Setting
up a gtest-style unit test proved too cumbersome (you need to recreate
or mock way too much debugger state), as did writing end-to-end tests
(it's hard to write a test that actually hits a buggy path).
With lldb-test, it's easy to read/generate the test input and parse the
test output. I'll attach a simple "fuzz" tester which generates failing
test cases to the Phab review. Here's an example:
```
Command: malloc(size=1024, alignment=32)
Malloc: address = 0xca000
Command: malloc(size=64, alignment=16)
Malloc: address = 0xca400
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca440
Command: malloc(size=16, alignment=8)
Malloc: address = 0xca840
Command: malloc(size=2048, alignment=16)
Malloc: address = 0xcb000
Command: malloc(size=64, alignment=32)
Malloc: address = 0xca860
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca890
Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0)
```
{F6288839}
Differential Revision: https://reviews.llvm.org/D47508
llvm-svn: 333583
2018-05-31 03:39:10 +08:00
|
|
|
|
|
|
|
// Parse and apply commands from the command file.
|
|
|
|
std::unique_ptr<MemoryBuffer> MB = opts::openFile(irmemorymap::CommandFile);
|
|
|
|
StringRef Rest = MB->getBuffer();
|
|
|
|
while (!Rest.empty()) {
|
|
|
|
StringRef Line;
|
|
|
|
std::tie(Line, Rest) = Rest.split('\n');
|
2019-06-08 05:13:30 +08:00
|
|
|
Line = Line.ltrim().rtrim();
|
[lldb-test] Add a testing harness for the JIT's IRMemoryMap
This teaches lldb-test how to launch a process, set up an IRMemoryMap,
and issue memory allocations in the target process through the map. This
makes it possible to test IRMemoryMap in a targeted way.
This has uncovered two bugs so far. The first bug is that Malloc
performs an adjustment on the pointer returned from AllocateMemory (for
alignment purposes) which ultimately allows overlapping memory regions
to be created. The second bug is that after most of the address space on
the host side is exhausted, Malloc may return the same address multiple
times. These bugs (and hopefully more!) can be uncovered and tested for
with targeted lldb-test commands.
At an even higher level, the motivation for addressing these bugs is
that they can lead to strange user-visible failures (e.g, variables
assume the wrong value during expression evaluation, or the debugger
crashes). See my third comment on this swift-lldb PR for an example:
https://github.com/apple/swift-lldb/pull/652
I hope lldb-test is the right place to add this testing harness. Setting
up a gtest-style unit test proved too cumbersome (you need to recreate
or mock way too much debugger state), as did writing end-to-end tests
(it's hard to write a test that actually hits a buggy path).
With lldb-test, it's easy to read/generate the test input and parse the
test output. I'll attach a simple "fuzz" tester which generates failing
test cases to the Phab review. Here's an example:
```
Command: malloc(size=1024, alignment=32)
Malloc: address = 0xca000
Command: malloc(size=64, alignment=16)
Malloc: address = 0xca400
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca440
Command: malloc(size=16, alignment=8)
Malloc: address = 0xca840
Command: malloc(size=2048, alignment=16)
Malloc: address = 0xcb000
Command: malloc(size=64, alignment=32)
Malloc: address = 0xca860
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca890
Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0)
```
{F6288839}
Differential Revision: https://reviews.llvm.org/D47508
llvm-svn: 333583
2018-05-31 03:39:10 +08:00
|
|
|
|
|
|
|
if (Line.empty() || Line[0] == '#')
|
|
|
|
continue;
|
|
|
|
|
2018-06-05 01:11:15 +08:00
|
|
|
if (evalMalloc(Line, State))
|
[lldb-test] Add a testing harness for the JIT's IRMemoryMap
This teaches lldb-test how to launch a process, set up an IRMemoryMap,
and issue memory allocations in the target process through the map. This
makes it possible to test IRMemoryMap in a targeted way.
This has uncovered two bugs so far. The first bug is that Malloc
performs an adjustment on the pointer returned from AllocateMemory (for
alignment purposes) which ultimately allows overlapping memory regions
to be created. The second bug is that after most of the address space on
the host side is exhausted, Malloc may return the same address multiple
times. These bugs (and hopefully more!) can be uncovered and tested for
with targeted lldb-test commands.
At an even higher level, the motivation for addressing these bugs is
that they can lead to strange user-visible failures (e.g, variables
assume the wrong value during expression evaluation, or the debugger
crashes). See my third comment on this swift-lldb PR for an example:
https://github.com/apple/swift-lldb/pull/652
I hope lldb-test is the right place to add this testing harness. Setting
up a gtest-style unit test proved too cumbersome (you need to recreate
or mock way too much debugger state), as did writing end-to-end tests
(it's hard to write a test that actually hits a buggy path).
With lldb-test, it's easy to read/generate the test input and parse the
test output. I'll attach a simple "fuzz" tester which generates failing
test cases to the Phab review. Here's an example:
```
Command: malloc(size=1024, alignment=32)
Malloc: address = 0xca000
Command: malloc(size=64, alignment=16)
Malloc: address = 0xca400
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca440
Command: malloc(size=16, alignment=8)
Malloc: address = 0xca840
Command: malloc(size=2048, alignment=16)
Malloc: address = 0xcb000
Command: malloc(size=64, alignment=32)
Malloc: address = 0xca860
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca890
Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0)
```
{F6288839}
Differential Revision: https://reviews.llvm.org/D47508
llvm-svn: 333583
2018-05-31 03:39:10 +08:00
|
|
|
continue;
|
|
|
|
|
2018-06-05 01:11:15 +08:00
|
|
|
if (evalFree(Line, State))
|
2018-06-01 06:09:01 +08:00
|
|
|
continue;
|
|
|
|
|
[lldb-test] Add a testing harness for the JIT's IRMemoryMap
This teaches lldb-test how to launch a process, set up an IRMemoryMap,
and issue memory allocations in the target process through the map. This
makes it possible to test IRMemoryMap in a targeted way.
This has uncovered two bugs so far. The first bug is that Malloc
performs an adjustment on the pointer returned from AllocateMemory (for
alignment purposes) which ultimately allows overlapping memory regions
to be created. The second bug is that after most of the address space on
the host side is exhausted, Malloc may return the same address multiple
times. These bugs (and hopefully more!) can be uncovered and tested for
with targeted lldb-test commands.
At an even higher level, the motivation for addressing these bugs is
that they can lead to strange user-visible failures (e.g, variables
assume the wrong value during expression evaluation, or the debugger
crashes). See my third comment on this swift-lldb PR for an example:
https://github.com/apple/swift-lldb/pull/652
I hope lldb-test is the right place to add this testing harness. Setting
up a gtest-style unit test proved too cumbersome (you need to recreate
or mock way too much debugger state), as did writing end-to-end tests
(it's hard to write a test that actually hits a buggy path).
With lldb-test, it's easy to read/generate the test input and parse the
test output. I'll attach a simple "fuzz" tester which generates failing
test cases to the Phab review. Here's an example:
```
Command: malloc(size=1024, alignment=32)
Malloc: address = 0xca000
Command: malloc(size=64, alignment=16)
Malloc: address = 0xca400
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca440
Command: malloc(size=16, alignment=8)
Malloc: address = 0xca840
Command: malloc(size=2048, alignment=16)
Malloc: address = 0xcb000
Command: malloc(size=64, alignment=32)
Malloc: address = 0xca860
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca890
Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0)
```
{F6288839}
Differential Revision: https://reviews.llvm.org/D47508
llvm-svn: 333583
2018-05-31 03:39:10 +08:00
|
|
|
errs() << "Could not parse line: " << Line << "\n";
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2021-03-20 05:20:26 +08:00
|
|
|
int opts::assert::lldb_assert(Debugger &Dbg) {
|
|
|
|
lldbassert(false && "lldb-test assert");
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2017-12-01 08:52:51 +08:00
|
|
|
int main(int argc, const char *argv[]) {
|
|
|
|
StringRef ToolName = argv[0];
|
|
|
|
sys::PrintStackTraceOnErrorSignal(ToolName);
|
|
|
|
PrettyStackTraceProgram X(argc, argv);
|
|
|
|
llvm_shutdown_obj Y;
|
|
|
|
|
|
|
|
cl::ParseCommandLineOptions(argc, argv, "LLDB Testing Utility\n");
|
|
|
|
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
SystemLifetimeManager DebuggerLifetime;
|
2018-12-04 01:28:29 +08:00
|
|
|
if (auto e = DebuggerLifetime.Initialize(
|
2019-08-15 06:19:23 +08:00
|
|
|
std::make_unique<SystemInitializerTest>(), nullptr)) {
|
2018-12-04 01:28:29 +08:00
|
|
|
WithColor::error() << "initialization failed: " << toString(std::move(e))
|
|
|
|
<< '\n';
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2019-09-10 08:20:50 +08:00
|
|
|
auto TerminateDebugger =
|
|
|
|
llvm::make_scope_exit([&] { DebuggerLifetime.Terminate(); });
|
2017-12-01 08:52:51 +08:00
|
|
|
|
|
|
|
auto Dbg = lldb_private::Debugger::CreateInstance();
|
2019-06-17 22:46:17 +08:00
|
|
|
ModuleList::GetGlobalModuleListProperties().SetEnableExternalLookup(false);
|
2020-06-10 01:21:09 +08:00
|
|
|
CommandReturnObject Result(/*colors*/ false);
|
2019-07-30 00:10:16 +08:00
|
|
|
Dbg->GetCommandInterpreter().HandleCommand(
|
|
|
|
"settings set plugin.process.gdb-remote.packet-timeout 60",
|
|
|
|
/*add_to_history*/ eLazyBoolNo, Result);
|
2020-08-12 02:36:35 +08:00
|
|
|
Dbg->GetCommandInterpreter().HandleCommand(
|
|
|
|
"settings set target.inherit-tcc true",
|
|
|
|
/*add_to_history*/ eLazyBoolNo, Result);
|
2020-12-10 10:39:29 +08:00
|
|
|
Dbg->GetCommandInterpreter().HandleCommand(
|
|
|
|
"settings set target.detach-on-error false",
|
|
|
|
/*add_to_history*/ eLazyBoolNo, Result);
|
2017-12-01 08:52:51 +08:00
|
|
|
|
[lldb-test] Add a testing harness for the JIT's IRMemoryMap
This teaches lldb-test how to launch a process, set up an IRMemoryMap,
and issue memory allocations in the target process through the map. This
makes it possible to test IRMemoryMap in a targeted way.
This has uncovered two bugs so far. The first bug is that Malloc
performs an adjustment on the pointer returned from AllocateMemory (for
alignment purposes) which ultimately allows overlapping memory regions
to be created. The second bug is that after most of the address space on
the host side is exhausted, Malloc may return the same address multiple
times. These bugs (and hopefully more!) can be uncovered and tested for
with targeted lldb-test commands.
At an even higher level, the motivation for addressing these bugs is
that they can lead to strange user-visible failures (e.g, variables
assume the wrong value during expression evaluation, or the debugger
crashes). See my third comment on this swift-lldb PR for an example:
https://github.com/apple/swift-lldb/pull/652
I hope lldb-test is the right place to add this testing harness. Setting
up a gtest-style unit test proved too cumbersome (you need to recreate
or mock way too much debugger state), as did writing end-to-end tests
(it's hard to write a test that actually hits a buggy path).
With lldb-test, it's easy to read/generate the test input and parse the
test output. I'll attach a simple "fuzz" tester which generates failing
test cases to the Phab review. Here's an example:
```
Command: malloc(size=1024, alignment=32)
Malloc: address = 0xca000
Command: malloc(size=64, alignment=16)
Malloc: address = 0xca400
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca440
Command: malloc(size=16, alignment=8)
Malloc: address = 0xca840
Command: malloc(size=2048, alignment=16)
Malloc: address = 0xcb000
Command: malloc(size=64, alignment=32)
Malloc: address = 0xca860
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca890
Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0)
```
{F6288839}
Differential Revision: https://reviews.llvm.org/D47508
llvm-svn: 333583
2018-05-31 03:39:10 +08:00
|
|
|
if (!opts::Log.empty())
|
|
|
|
Dbg->EnableLog("lldb", {"all"}, opts::Log, 0, errs());
|
|
|
|
|
Add "lldb-test breakpoint" command and convert the case-sensitivity test to use it
Summary:
The command takes two input arguments: a module to use as a debug target
and a file containing a list of commands. The command will execute each
of the breakpoint commands in the file and dump the breakpoint state
after each one.
The commands are expected to be breakpoint set/remove/etc. commands, but
I explicitly allow any lldb command here, so you can do things like
change setting which impact breakpoint resolution, etc. There is also a
"-persistent" flag, which causes lldb-test to *not* automatically clear
the breakpoint list after each command. Right now I don't use it, but
the idea behind it was that it could be used to test more complex
combinations of breakpoint commands (set+modify, set+disable, etc.).
Right now the command prints out only the basic breakpoint state, but
more information can be easily added there. To enable easy matching of
the "at least one breakpoint location found" state, the command
explicitly prints out the string "At least one breakpoint location.".
To enable testing of breakpoints set with an absolute paths, I add the
ability to perform rudimentary substitutions on the commands: right now
the string %p is replaced by the directory which contains the command
file (so, under normal circumstances, this will perform the same
substitution as lit would do for %p).
I use this command to rewrite the TestBreakpointCaseSensitivity test --
the test was checking about a dozen breakpoint commands, but it was
launching a new process for each one, so it took about 90 seconds to
run. The new test takes about 0.3 seconds for me, which is approximately
a 300x speedup.
Reviewers: davide, zturner, jingham
Subscribers: luporl, lldb-commits
Differential Revision: https://reviews.llvm.org/D43686
llvm-svn: 326112
2018-02-27 02:50:16 +08:00
|
|
|
if (opts::BreakpointSubcommand)
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
return opts::breakpoint::evaluateBreakpoints(*Dbg);
|
2018-06-29 20:15:54 +08:00
|
|
|
if (opts::ObjectFileSubcommand)
|
|
|
|
return dumpObjectFiles(*Dbg);
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
if (opts::SymbolsSubcommand)
|
|
|
|
return opts::symbols::dumpSymbols(*Dbg);
|
[lldb-test] Add a testing harness for the JIT's IRMemoryMap
This teaches lldb-test how to launch a process, set up an IRMemoryMap,
and issue memory allocations in the target process through the map. This
makes it possible to test IRMemoryMap in a targeted way.
This has uncovered two bugs so far. The first bug is that Malloc
performs an adjustment on the pointer returned from AllocateMemory (for
alignment purposes) which ultimately allows overlapping memory regions
to be created. The second bug is that after most of the address space on
the host side is exhausted, Malloc may return the same address multiple
times. These bugs (and hopefully more!) can be uncovered and tested for
with targeted lldb-test commands.
At an even higher level, the motivation for addressing these bugs is
that they can lead to strange user-visible failures (e.g, variables
assume the wrong value during expression evaluation, or the debugger
crashes). See my third comment on this swift-lldb PR for an example:
https://github.com/apple/swift-lldb/pull/652
I hope lldb-test is the right place to add this testing harness. Setting
up a gtest-style unit test proved too cumbersome (you need to recreate
or mock way too much debugger state), as did writing end-to-end tests
(it's hard to write a test that actually hits a buggy path).
With lldb-test, it's easy to read/generate the test input and parse the
test output. I'll attach a simple "fuzz" tester which generates failing
test cases to the Phab review. Here's an example:
```
Command: malloc(size=1024, alignment=32)
Malloc: address = 0xca000
Command: malloc(size=64, alignment=16)
Malloc: address = 0xca400
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca440
Command: malloc(size=16, alignment=8)
Malloc: address = 0xca840
Command: malloc(size=2048, alignment=16)
Malloc: address = 0xcb000
Command: malloc(size=64, alignment=32)
Malloc: address = 0xca860
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca890
Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0)
```
{F6288839}
Differential Revision: https://reviews.llvm.org/D47508
llvm-svn: 333583
2018-05-31 03:39:10 +08:00
|
|
|
if (opts::IRMemoryMapSubcommand)
|
|
|
|
return opts::irmemorymap::evaluateMemoryMapCommands(*Dbg);
|
2021-03-20 05:20:26 +08:00
|
|
|
if (opts::AssertSubcommand)
|
|
|
|
return opts::assert::lldb_assert(*Dbg);
|
2017-12-01 08:52:51 +08:00
|
|
|
|
lldb-test symbols: Add ability to do name-based lookup
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
2018-05-03 18:57:16 +08:00
|
|
|
WithColor::error() << "No command specified.\n";
|
|
|
|
return 1;
|
2017-12-01 08:52:51 +08:00
|
|
|
}
|