llvm-project/lldb/tools/lldb-test/lldb-test.cpp

652 lines
23 KiB
C++
Raw Normal View History

//===- lldb-test.cpp ------------------------------------------ *- C++ --*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
#include "FormatUtil.h"
#include "SystemInitializerTest.h"
#include "Plugins/SymbolFile/DWARF/SymbolFileDWARF.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"
#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"
#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"
#include "lldb/Symbol/ClangASTContext.h"
#include "lldb/Symbol/ClangASTImporter.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/SymbolVendor.h"
#include "lldb/Symbol/TypeList.h"
#include "lldb/Symbol/VariableList.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"
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/Utility/CleanUp.h"
#include "lldb/Utility/DataExtractor.h"
#include "lldb/Utility/StreamString.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 "llvm/ADT/IntervalMap.h"
#include "llvm/ADT/StringRef.h"
#include "llvm/Support/CommandLine.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 "llvm/Support/MathExtras.h"
#include "llvm/Support/ManagedStatic.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"
#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"
[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>
#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");
cl::SubCommand ModuleSubcommand("module-sections",
"Display LLDB Module Information");
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");
cl::opt<std::string> Log("log", cl::desc("Path to a log file"), cl::init(""),
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);
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
namespace module {
cl::opt<bool> SectionContents("contents",
cl::desc("Dump each section's contents"),
cl::sub(ModuleSubcommand));
cl::list<std::string> InputFilenames(cl::Positional, cl::desc("<input files>"),
cl::OneOrMore, cl::sub(ModuleSubcommand));
} // namespace module
namespace symbols {
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<std::string> InputFilenames(cl::Positional,
cl::desc("<input files>"),
cl::OneOrMore,
cl::sub(SymbolsSubcommand));
enum class FindType {
None,
Function,
Namespace,
Type,
Variable,
};
static cl::opt<FindType> Find(
"find", cl::desc("Choose search type:"),
cl::values(
clEnumValN(FindType::None, "none",
"No search, just dump the module."),
clEnumValN(FindType::Function, "function", "Find functions."),
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",
cl::desc("Search using regular expressions (avaliable for variables "
"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));
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;
}
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 Expected<CompilerDeclContext> getDeclContext(SymbolVendor &Vendor);
static Error findFunctions(lldb_private::Module &Module);
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);
static int dumpSymbols(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
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));
using AllocationT = std::pair<addr_t, addr_t>;
bool areAllocationsOverlapping(const AllocationT &L, const AllocationT &R);
using AddrIntervalMap =
IntervalMap<addr_t, bool, 8, IntervalMapHalfOpenInfo<addr_t>>;
bool evalMalloc(IRMemoryMap &IRMemMap, StringRef Line,
AddrIntervalMap &AllocatedIntervals);
int evaluateMemoryMapCommands(Debugger &Dbg);
} // namespace irmemorymap
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
[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;
Status ST =
Dbg.GetTargetList().CreateTarget(Dbg, Filename, /*triple*/ "",
/*get_dependent_modules*/ false,
/*platform_options*/ nullptr, Target);
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());
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;
}
// fall through
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');
Line = Line.ltrim();
if (Line.empty() || Line[0] == '#')
continue;
if (!Persistent)
Target->RemoveAllBreakpoints(/*internal_also*/ true);
std::string Command = substitute(Line);
P.formatLine("Command: {0}", Command);
CommandReturnObject Result;
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>
opts::symbols::getDeclContext(SymbolVendor &Vendor) {
if (Context.empty())
return CompilerDeclContext();
VariableList List;
Vendor.FindGlobalVariables(ConstString(Context), nullptr, false, UINT32_MAX,
List);
if (List.Empty()) {
return make_error<StringError>("Context search didn't find a match.",
inconvertibleErrorCode());
}
if (List.GetSize() > 1) {
return make_error<StringError>("Context search found multiple matches.",
inconvertibleErrorCode());
}
return List.GetVariableAtIndex(0)->GetDeclContext();
}
Error opts::symbols::findFunctions(lldb_private::Module &Module) {
SymbolVendor &Vendor = *Module.GetSymbolVendor();
SymbolContextList List;
if (Regex) {
RegularExpression RE(Name);
assert(RE.IsValid());
Vendor.FindFunctions(RE, true, false, List);
} else {
Expected<CompilerDeclContext> ContextOr = getDeclContext(Vendor);
if (!ContextOr)
return ContextOr.takeError();
CompilerDeclContext *ContextPtr =
ContextOr->IsValid() ? &*ContextOr : nullptr;
Vendor.FindFunctions(ConstString(Name), ContextPtr, getFunctionNameFlags(),
true, false, List);
}
outs() << formatv("Found {0} functions:\n", List.GetSize());
StreamString Stream;
List.Dump(&Stream, nullptr);
outs() << Stream.GetData() << "\n";
return Error::success();
}
Error opts::symbols::findNamespaces(lldb_private::Module &Module) {
SymbolVendor &Vendor = *Module.GetSymbolVendor();
Expected<CompilerDeclContext> ContextOr = getDeclContext(Vendor);
if (!ContextOr)
return ContextOr.takeError();
CompilerDeclContext *ContextPtr =
ContextOr->IsValid() ? &*ContextOr : nullptr;
SymbolContext SC;
CompilerDeclContext Result =
Vendor.FindNamespace(SC, ConstString(Name), ContextPtr);
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) {
SymbolVendor &Vendor = *Module.GetSymbolVendor();
Expected<CompilerDeclContext> ContextOr = getDeclContext(Vendor);
if (!ContextOr)
return ContextOr.takeError();
CompilerDeclContext *ContextPtr =
ContextOr->IsValid() ? &*ContextOr : nullptr;
SymbolContext SC;
DenseSet<SymbolFile *> SearchedFiles;
TypeMap Map;
Vendor.FindTypes(SC, ConstString(Name), ContextPtr, true, UINT32_MAX,
SearchedFiles, Map);
outs() << formatv("Found {0} types:\n", Map.GetSize());
StreamString Stream;
Map.Dump(&Stream, false);
outs() << Stream.GetData() << "\n";
return Error::success();
}
Error opts::symbols::findVariables(lldb_private::Module &Module) {
SymbolVendor &Vendor = *Module.GetSymbolVendor();
VariableList List;
if (Regex) {
RegularExpression RE(Name);
assert(RE.IsValid());
Vendor.FindGlobalVariables(RE, false, UINT32_MAX, List);
} else {
Expected<CompilerDeclContext> ContextOr = getDeclContext(Vendor);
if (!ContextOr)
return ContextOr.takeError();
CompilerDeclContext *ContextPtr =
ContextOr->IsValid() ? &*ContextOr : nullptr;
Vendor.FindGlobalVariables(ConstString(Name), ContextPtr, false, UINT32_MAX,
List);
}
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();
}
int opts::symbols::dumpSymbols(Debugger &Dbg) {
if (Find != FindType::None && Regex && !Context.empty()) {
WithColor::error()
<< "Cannot search using both regular expressions and context.\n";
return 1;
}
if ((Find == FindType::Type || Find == FindType::Namespace) && Regex) {
WithColor::error() << "Cannot search for types and namespaces using "
"regular expressions.\n";
return 1;
}
if (Find == FindType::Function && Regex && getFunctionNameFlags() != 0) {
WithColor::error() << "Cannot search for types using both regular "
"expressions and function-flags.\n";
return 1;
}
if (Regex && !RegularExpression(Name).IsValid()) {
WithColor::error() << "`" << Name
<< "` is not a valid regular expression.\n";
return 1;
}
Error (*Action)(lldb_private::Module &);
switch (Find) {
case FindType::Function:
Action = findFunctions;
break;
case FindType::Namespace:
Action = findNamespaces;
break;
case FindType::Type:
Action = findTypes;
break;
case FindType::Variable:
Action = findVariables;
break;
case FindType::None:
Action = dumpModule;
break;
}
int HadErrors = 0;
for (const auto &File : InputFilenames) {
outs() << "Module: " << File << "\n";
ModuleSpec Spec{FileSpec(File, false)};
Spec.GetSymbolFileSpec().SetFile(File, false);
auto ModulePtr = std::make_shared<lldb_private::Module>(Spec);
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
SymbolVendor *Vendor = ModulePtr->GetSymbolVendor();
if (!Vendor) {
WithColor::error() << "Module has no symbol vendor.\n";
HadErrors = 1;
continue;
}
if (Error E = Action(*ModulePtr)) {
WithColor::error() << toString(std::move(E)) << "\n";
HadErrors = 1;
}
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().flush();
}
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;
}
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 dumpModules(Debugger &Dbg) {
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;
for (const auto &File : opts::module::InputFilenames) {
ModuleSpec Spec{FileSpec(File, false)};
auto ModulePtr = std::make_shared<lldb_private::Module>(Spec);
// Fetch symbol vendor before we get the section list to give the symbol
// vendor a chance to populate it.
ModulePtr->GetSymbolVendor();
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;
continue;
}
size_t Count = Sections->GetNumSections(0);
Printer.formatLine("Showing {0} sections", Count);
for (size_t I = 0; I < Count; ++I) {
AutoIndent Indent(Printer, 2);
auto S = Sections->GetSectionAtIndex(I);
assert(S);
Printer.formatLine("Index: {0}", I);
Printer.formatLine("Name: {0}", S->GetName().GetStringRef());
Printer.formatLine("Type: {0}", S->GetTypeAsCString());
Printer.formatLine("VM size: {0}", S->GetByteSize());
Printer.formatLine("File size: {0}", S->GetFileSize());
if (opts::module::SectionContents) {
DataExtractor Data;
S->GetSectionData(Data);
ArrayRef<uint8_t> Bytes = {Data.GetDataStart(), Data.GetDataEnd()};
Printer.formatBinary("Data: ", Bytes, 0);
}
Printer.NewLine();
}
}
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;
}
[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
/// Check if two half-open intervals intersect:
/// http://world.std.com/~swmcd/steven/tech/interval.html
bool opts::irmemorymap::areAllocationsOverlapping(const AllocationT &L,
const AllocationT &R) {
return R.first < L.second && L.first < R.second;
}
bool opts::irmemorymap::evalMalloc(IRMemoryMap &IRMemMap, StringRef Line,
AddrIntervalMap &AllocatedIntervals) {
// ::= malloc <size> <alignment>
size_t Size;
uint8_t Alignment;
int Matches = sscanf(Line.data(), "malloc %zu %hhu", &Size, &Alignment);
if (Matches != 2)
return false;
outs() << formatv("Command: malloc(size={0}, alignment={1})\n", Size,
Alignment);
if (!isPowerOf2_32(Alignment)) {
outs() << "Malloc error: alignment is not a power of 2\n";
exit(1);
}
// Issue the malloc in the target process with "-rw" permissions.
const uint32_t Permissions = 0x3;
const bool ZeroMemory = false;
IRMemoryMap::AllocationPolicy Policy =
IRMemoryMap::eAllocationPolicyProcessOnly;
Status ST;
addr_t Addr =
IRMemMap.Malloc(Size, Alignment, Permissions, Policy, ZeroMemory, ST);
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);
}
// Check that the allocation does not overlap another allocation. Do so by
// testing each allocation which may cover the interval [Addr, EndOfRegion).
addr_t EndOfRegion = Addr + Size;
auto Probe = AllocatedIntervals.begin();
Probe.advanceTo(Addr); //< First interval s.t stop >= Addr.
AllocationT NewAllocation = {Addr, EndOfRegion};
if (Probe != AllocatedIntervals.end()) {
while (Probe.start() < EndOfRegion) {
AllocationT ProbeAllocation = {Probe.start(), Probe.stop()};
if (areAllocationsOverlapping(ProbeAllocation, NewAllocation)) {
outs() << "Malloc error: overlapping allocation detected"
<< formatv(", previous allocation at [{0:x}, {1:x})\n",
Probe.start(), Probe.stop());
exit(1);
}
++Probe;
}
}
// Insert the new allocation into the interval map.
if (Size)
AllocatedIntervals.insert(Addr, EndOfRegion, true);
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.
CommandReturnObject Result;
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.
IRMemoryMap IRMemMap(Target);
AddrIntervalMap::Allocator AIMapAllocator;
AddrIntervalMap AllocatedIntervals(AIMapAllocator);
// 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');
Line = Line.ltrim();
if (Line.empty() || Line[0] == '#')
continue;
if (evalMalloc(IRMemMap, Line, AllocatedIntervals))
continue;
errs() << "Could not parse line: " << Line << "\n";
exit(1);
}
return 0;
}
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;
DebuggerLifetime.Initialize(llvm::make_unique<SystemInitializerTest>(),
nullptr);
CleanUp TerminateDebugger([&] { DebuggerLifetime.Terminate(); });
auto Dbg = lldb_private::Debugger::CreateInstance();
[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);
if (opts::ModuleSubcommand)
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 dumpModules(*Dbg);
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);
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;
}