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

854 lines
29 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"
#include "lldb/Symbol/CompileUnit.h"
#include "lldb/Symbol/LineTable.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"
#include "llvm/Support/ManagedStatic.h"
#include "llvm/Support/MathExtras.h"
Add "lldb-test breakpoint" command and convert the case-sensitivity test to use it Summary: The command takes two input arguments: a module to use as a debug target and a file containing a list of commands. The command will execute each of the breakpoint commands in the file and dump the breakpoint state after each one. The commands are expected to be breakpoint set/remove/etc. commands, but I explicitly allow any lldb command here, so you can do things like change setting which impact breakpoint resolution, etc. There is also a "-persistent" flag, which causes lldb-test to *not* automatically clear the breakpoint list after each command. Right now I don't use it, but the idea behind it was that it could be used to test more complex combinations of breakpoint commands (set+modify, set+disable, etc.). Right now the command prints out only the basic breakpoint state, but more information can be easily added there. To enable easy matching of the "at least one breakpoint location found" state, the command explicitly prints out the string "At least one breakpoint location.". To enable testing of breakpoints set with an absolute paths, I add the ability to perform rudimentary substitutions on the commands: right now the string %p is replaced by the directory which contains the command file (so, under normal circumstances, this will perform the same substitution as lit would do for %p). I use this command to rewrite the TestBreakpointCaseSensitivity test -- the test was checking about a dozen breakpoint commands, but it was launching a new process for each one, so it took about 90 seconds to run. The new test takes about 0.3 seconds for me, which is approximately a 300x speedup. Reviewers: davide, zturner, jingham Subscribers: luporl, lldb-commits Differential Revision: https://reviews.llvm.org/D43686 llvm-svn: 326112
2018-02-27 02:50:16 +08:00
#include "llvm/Support/Path.h"
#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");
[lldb-test] Add a testing harness for the JIT's IRMemoryMap This teaches lldb-test how to launch a process, set up an IRMemoryMap, and issue memory allocations in the target process through the map. This makes it possible to test IRMemoryMap in a targeted way. This has uncovered two bugs so far. The first bug is that Malloc performs an adjustment on the pointer returned from AllocateMemory (for alignment purposes) which ultimately allows overlapping memory regions to be created. The second bug is that after most of the address space on the host side is exhausted, Malloc may return the same address multiple times. These bugs (and hopefully more!) can be uncovered and tested for with targeted lldb-test commands. At an even higher level, the motivation for addressing these bugs is that they can lead to strange user-visible failures (e.g, variables assume the wrong value during expression evaluation, or the debugger crashes). See my third comment on this swift-lldb PR for an example: https://github.com/apple/swift-lldb/pull/652 I hope lldb-test is the right place to add this testing harness. Setting up a gtest-style unit test proved too cumbersome (you need to recreate or mock way too much debugger state), as did writing end-to-end tests (it's hard to write a test that actually hits a buggy path). With lldb-test, it's easy to read/generate the test input and parse the test output. I'll attach a simple "fuzz" tester which generates failing test cases to the Phab review. Here's an example: ``` Command: malloc(size=1024, alignment=32) Malloc: address = 0xca000 Command: malloc(size=64, alignment=16) Malloc: address = 0xca400 Command: malloc(size=1024, alignment=16) Malloc: address = 0xca440 Command: malloc(size=16, alignment=8) Malloc: address = 0xca840 Command: malloc(size=2048, alignment=16) Malloc: address = 0xcb000 Command: malloc(size=64, alignment=32) Malloc: address = 0xca860 Command: malloc(size=1024, alignment=16) Malloc: address = 0xca890 Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0) ``` {F6288839} Differential Revision: https://reviews.llvm.org/D47508 llvm-svn: 333583
2018-05-31 03:39:10 +08:00
cl::opt<std::string> Log("log", cl::desc("Path to a log file"), cl::init(""),
cl::sub(BreakpointSubcommand),
cl::sub(ModuleSubcommand), cl::sub(SymbolsSubcommand),
[lldb-test] Add a testing harness for the JIT's IRMemoryMap This teaches lldb-test how to launch a process, set up an IRMemoryMap, and issue memory allocations in the target process through the map. This makes it possible to test IRMemoryMap in a targeted way. This has uncovered two bugs so far. The first bug is that Malloc performs an adjustment on the pointer returned from AllocateMemory (for alignment purposes) which ultimately allows overlapping memory regions to be created. The second bug is that after most of the address space on the host side is exhausted, Malloc may return the same address multiple times. These bugs (and hopefully more!) can be uncovered and tested for with targeted lldb-test commands. At an even higher level, the motivation for addressing these bugs is that they can lead to strange user-visible failures (e.g, variables assume the wrong value during expression evaluation, or the debugger crashes). See my third comment on this swift-lldb PR for an example: https://github.com/apple/swift-lldb/pull/652 I hope lldb-test is the right place to add this testing harness. Setting up a gtest-style unit test proved too cumbersome (you need to recreate or mock way too much debugger state), as did writing end-to-end tests (it's hard to write a test that actually hits a buggy path). With lldb-test, it's easy to read/generate the test input and parse the test output. I'll attach a simple "fuzz" tester which generates failing test cases to the Phab review. Here's an example: ``` Command: malloc(size=1024, alignment=32) Malloc: address = 0xca000 Command: malloc(size=64, alignment=16) Malloc: address = 0xca400 Command: malloc(size=1024, alignment=16) Malloc: address = 0xca440 Command: malloc(size=16, alignment=8) Malloc: address = 0xca840 Command: malloc(size=2048, alignment=16) Malloc: address = 0xcb000 Command: malloc(size=64, alignment=32) Malloc: address = 0xca860 Command: malloc(size=1024, alignment=16) Malloc: address = 0xca890 Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0) ``` {F6288839} Differential Revision: https://reviews.llvm.org/D47508 llvm-svn: 333583
2018-05-31 03:39:10 +08:00
cl::sub(IRMemoryMapSubcommand));
/// Create a target using the file pointed to by \p Filename, or abort.
TargetSP createTarget(Debugger &Dbg, const std::string &Filename);
/// Read \p Filename into a null-terminated buffer, or abort.
std::unique_ptr<MemoryBuffer> openFile(const std::string &Filename);
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."),
lldb-test symbols: Add ability to do name-based lookup Summary: lldb-test already had the ability to dump all symbol information in a module. This is interesting, but it can be too verbose, and it also does not use the same APIs that lldb uses to query symbol information. The last part is interesting to me now, because I am about to add DWARF v5 debug_names support, which needs to implement these APIs. This patch adds a set of arguments to lldb-test, which modify it's behavior from dumping all symbols to dumping only the requested information: - --find={function,namespace,type,variable} - search for the given kind of objects. - --name - the name to search for. - --regex - whether to treat the "name" as a regular expression. This is not available for all lookup types (we do not have the required APIs for namespaces and types). - --context - specifies the context, which can be used to restrict the search. This argument takes a variable name (which must be defined and be unique), and we then use the context that this variable is defined in as the search context. - --function-flags={auto,full,base,method,selector} - a set of flags to further restrict the search for function symbols. Together, these flags and their combinations cover the main SymbolFile entry points which I will need to modify for the accelerator table support, and so I plan to do most of the regression testing this way. (I've also found this a useful tool for exploration of what the given APIs are supposed to do.) I add a couple of tests to demonstrate the usage of the usage of the various options, and also an xfailed test which demonstrates a bug I found while playing with this. The only requirement for these tests is the presence of lld -- the should run on any platform which is able to build lldb. These tests use c++ code as input, but this isn't a requirement. It is also possible to use IR, assembly or json to create the test module. Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap Subscribers: mgorny, aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D46318 llvm-svn: 331447
2018-05-03 18:57:16 +08:00
clEnumValN(FindType::Function, "function", "Find functions."),
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;
}
static cl::opt<bool> Verify("verify", cl::desc("Verify symbol information."),
cl::sub(SymbolsSubcommand));
static cl::opt<std::string> File("file",
cl::desc("File (compile unit) to search."),
cl::sub(SymbolsSubcommand));
static cl::opt<int> Line("line", cl::desc("Line to search."),
cl::sub(SymbolsSubcommand));
lldb-test symbols: Add ability to do name-based lookup Summary: lldb-test already had the ability to dump all symbol information in a module. This is interesting, but it can be too verbose, and it also does not use the same APIs that lldb uses to query symbol information. The last part is interesting to me now, because I am about to add DWARF v5 debug_names support, which needs to implement these APIs. This patch adds a set of arguments to lldb-test, which modify it's behavior from dumping all symbols to dumping only the requested information: - --find={function,namespace,type,variable} - search for the given kind of objects. - --name - the name to search for. - --regex - whether to treat the "name" as a regular expression. This is not available for all lookup types (we do not have the required APIs for namespaces and types). - --context - specifies the context, which can be used to restrict the search. This argument takes a variable name (which must be defined and be unique), and we then use the context that this variable is defined in as the search context. - --function-flags={auto,full,base,method,selector} - a set of flags to further restrict the search for function symbols. Together, these flags and their combinations cover the main SymbolFile entry points which I will need to modify for the accelerator table support, and so I plan to do most of the regression testing this way. (I've also found this a useful tool for exploration of what the given APIs are supposed to do.) I add a couple of tests to demonstrate the usage of the usage of the various options, and also an xfailed test which demonstrates a bug I found while playing with this. The only requirement for these tests is the presence of lld -- the should run on any platform which is able to build lldb. These tests use c++ code as input, but this isn't a requirement. It is also possible to use IR, assembly or json to create the test module. Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap Subscribers: mgorny, aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D46318 llvm-svn: 331447
2018-05-03 18:57:16 +08:00
static 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 Error verify(lldb_private::Module &Module);
lldb-test symbols: Add ability to do name-based lookup Summary: lldb-test already had the ability to dump all symbol information in a module. This is interesting, but it can be too verbose, and it also does not use the same APIs that lldb uses to query symbol information. The last part is interesting to me now, because I am about to add DWARF v5 debug_names support, which needs to implement these APIs. This patch adds a set of arguments to lldb-test, which modify it's behavior from dumping all symbols to dumping only the requested information: - --find={function,namespace,type,variable} - search for the given kind of objects. - --name - the name to search for. - --regex - whether to treat the "name" as a regular expression. This is not available for all lookup types (we do not have the required APIs for namespaces and types). - --context - specifies the context, which can be used to restrict the search. This argument takes a variable name (which must be defined and be unique), and we then use the context that this variable is defined in as the search context. - --function-flags={auto,full,base,method,selector} - a set of flags to further restrict the search for function symbols. Together, these flags and their combinations cover the main SymbolFile entry points which I will need to modify for the accelerator table support, and so I plan to do most of the regression testing this way. (I've also found this a useful tool for exploration of what the given APIs are supposed to do.) I add a couple of tests to demonstrate the usage of the usage of the various options, and also an xfailed test which demonstrates a bug I found while playing with this. The only requirement for these tests is the presence of lld -- the should run on any platform which is able to build lldb. These tests use c++ code as input, but this isn't a requirement. It is also possible to use IR, assembly or json to create the test module. Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap Subscribers: mgorny, aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D46318 llvm-svn: 331447
2018-05-03 18:57:16 +08:00
static Expected<Error (*)(lldb_private::Module &)> getAction();
lldb-test symbols: Add ability to do name-based lookup Summary: lldb-test already had the ability to dump all symbol information in a module. This is interesting, but it can be too verbose, and it also does not use the same APIs that lldb uses to query symbol information. The last part is interesting to me now, because I am about to add DWARF v5 debug_names support, which needs to implement these APIs. This patch adds a set of arguments to lldb-test, which modify it's behavior from dumping all symbols to dumping only the requested information: - --find={function,namespace,type,variable} - search for the given kind of objects. - --name - the name to search for. - --regex - whether to treat the "name" as a regular expression. This is not available for all lookup types (we do not have the required APIs for namespaces and types). - --context - specifies the context, which can be used to restrict the search. This argument takes a variable name (which must be defined and be unique), and we then use the context that this variable is defined in as the search context. - --function-flags={auto,full,base,method,selector} - a set of flags to further restrict the search for function symbols. Together, these flags and their combinations cover the main SymbolFile entry points which I will need to modify for the accelerator table support, and so I plan to do most of the regression testing this way. (I've also found this a useful tool for exploration of what the given APIs are supposed to do.) I add a couple of tests to demonstrate the usage of the usage of the various options, and also an xfailed test which demonstrates a bug I found while playing with this. The only requirement for these tests is the presence of lld -- the should run on any platform which is able to build lldb. These tests use c++ code as input, but this isn't a requirement. It is also possible to use IR, assembly or json to create the test module. Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap Subscribers: mgorny, aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D46318 llvm-svn: 331447
2018-05-03 18:57:16 +08:00
static int dumpSymbols(Debugger &Dbg);
} // namespace symbols
[lldb-test] Add a testing harness for the JIT's IRMemoryMap This teaches lldb-test how to launch a process, set up an IRMemoryMap, and issue memory allocations in the target process through the map. This makes it possible to test IRMemoryMap in a targeted way. This has uncovered two bugs so far. The first bug is that Malloc performs an adjustment on the pointer returned from AllocateMemory (for alignment purposes) which ultimately allows overlapping memory regions to be created. The second bug is that after most of the address space on the host side is exhausted, Malloc may return the same address multiple times. These bugs (and hopefully more!) can be uncovered and tested for with targeted lldb-test commands. At an even higher level, the motivation for addressing these bugs is that they can lead to strange user-visible failures (e.g, variables assume the wrong value during expression evaluation, or the debugger crashes). See my third comment on this swift-lldb PR for an example: https://github.com/apple/swift-lldb/pull/652 I hope lldb-test is the right place to add this testing harness. Setting up a gtest-style unit test proved too cumbersome (you need to recreate or mock way too much debugger state), as did writing end-to-end tests (it's hard to write a test that actually hits a buggy path). With lldb-test, it's easy to read/generate the test input and parse the test output. I'll attach a simple "fuzz" tester which generates failing test cases to the Phab review. Here's an example: ``` Command: malloc(size=1024, alignment=32) Malloc: address = 0xca000 Command: malloc(size=64, alignment=16) Malloc: address = 0xca400 Command: malloc(size=1024, alignment=16) Malloc: address = 0xca440 Command: malloc(size=16, alignment=8) Malloc: address = 0xca840 Command: malloc(size=2048, alignment=16) Malloc: address = 0xcb000 Command: malloc(size=64, alignment=32) Malloc: address = 0xca860 Command: malloc(size=1024, alignment=16) Malloc: address = 0xca890 Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0) ``` {F6288839} Differential Revision: https://reviews.llvm.org/D47508 llvm-svn: 333583
2018-05-31 03:39:10 +08:00
namespace irmemorymap {
static cl::opt<std::string> Target(cl::Positional, cl::desc("<target>"),
cl::Required,
cl::sub(IRMemoryMapSubcommand));
static cl::opt<std::string> CommandFile(cl::Positional,
cl::desc("<command-file>"),
cl::init("-"),
cl::sub(IRMemoryMapSubcommand));
static cl::opt<bool> UseHostOnlyAllocationPolicy(
"host-only", cl::desc("Use the host-only allocation policy"),
cl::init(false), cl::sub(IRMemoryMapSubcommand));
[lldb-test] Add a testing harness for the JIT's IRMemoryMap This teaches lldb-test how to launch a process, set up an IRMemoryMap, and issue memory allocations in the target process through the map. This makes it possible to test IRMemoryMap in a targeted way. This has uncovered two bugs so far. The first bug is that Malloc performs an adjustment on the pointer returned from AllocateMemory (for alignment purposes) which ultimately allows overlapping memory regions to be created. The second bug is that after most of the address space on the host side is exhausted, Malloc may return the same address multiple times. These bugs (and hopefully more!) can be uncovered and tested for with targeted lldb-test commands. At an even higher level, the motivation for addressing these bugs is that they can lead to strange user-visible failures (e.g, variables assume the wrong value during expression evaluation, or the debugger crashes). See my third comment on this swift-lldb PR for an example: https://github.com/apple/swift-lldb/pull/652 I hope lldb-test is the right place to add this testing harness. Setting up a gtest-style unit test proved too cumbersome (you need to recreate or mock way too much debugger state), as did writing end-to-end tests (it's hard to write a test that actually hits a buggy path). With lldb-test, it's easy to read/generate the test input and parse the test output. I'll attach a simple "fuzz" tester which generates failing test cases to the Phab review. Here's an example: ``` Command: malloc(size=1024, alignment=32) Malloc: address = 0xca000 Command: malloc(size=64, alignment=16) Malloc: address = 0xca400 Command: malloc(size=1024, alignment=16) Malloc: address = 0xca440 Command: malloc(size=16, alignment=8) Malloc: address = 0xca840 Command: malloc(size=2048, alignment=16) Malloc: address = 0xcb000 Command: malloc(size=64, alignment=32) Malloc: address = 0xca860 Command: malloc(size=1024, alignment=16) Malloc: address = 0xca890 Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0) ``` {F6288839} Differential Revision: https://reviews.llvm.org/D47508 llvm-svn: 333583
2018-05-31 03:39:10 +08:00
using AllocationT = std::pair<addr_t, addr_t>;
using AddrIntervalMap =
IntervalMap<addr_t, unsigned, 8, IntervalMapHalfOpenInfo<addr_t>>;
struct IRMemoryMapTestState {
TargetSP Target;
IRMemoryMap Map;
AddrIntervalMap::Allocator IntervalMapAllocator;
AddrIntervalMap Allocations;
StringMap<addr_t> Label2AddrMap;
IRMemoryMapTestState(TargetSP Target)
: Target(Target), Map(Target), Allocations(IntervalMapAllocator) {}
};
bool areAllocationsOverlapping(const AllocationT &L, const AllocationT &R);
bool evalMalloc(StringRef Line, IRMemoryMapTestState &State);
bool evalFree(StringRef Line, IRMemoryMapTestState &State);
[lldb-test] Add a testing harness for the JIT's IRMemoryMap This teaches lldb-test how to launch a process, set up an IRMemoryMap, and issue memory allocations in the target process through the map. This makes it possible to test IRMemoryMap in a targeted way. This has uncovered two bugs so far. The first bug is that Malloc performs an adjustment on the pointer returned from AllocateMemory (for alignment purposes) which ultimately allows overlapping memory regions to be created. The second bug is that after most of the address space on the host side is exhausted, Malloc may return the same address multiple times. These bugs (and hopefully more!) can be uncovered and tested for with targeted lldb-test commands. At an even higher level, the motivation for addressing these bugs is that they can lead to strange user-visible failures (e.g, variables assume the wrong value during expression evaluation, or the debugger crashes). See my third comment on this swift-lldb PR for an example: https://github.com/apple/swift-lldb/pull/652 I hope lldb-test is the right place to add this testing harness. Setting up a gtest-style unit test proved too cumbersome (you need to recreate or mock way too much debugger state), as did writing end-to-end tests (it's hard to write a test that actually hits a buggy path). With lldb-test, it's easy to read/generate the test input and parse the test output. I'll attach a simple "fuzz" tester which generates failing test cases to the Phab review. Here's an example: ``` Command: malloc(size=1024, alignment=32) Malloc: address = 0xca000 Command: malloc(size=64, alignment=16) Malloc: address = 0xca400 Command: malloc(size=1024, alignment=16) Malloc: address = 0xca440 Command: malloc(size=16, alignment=8) Malloc: address = 0xca840 Command: malloc(size=2048, alignment=16) Malloc: address = 0xcb000 Command: malloc(size=64, alignment=32) Malloc: address = 0xca860 Command: malloc(size=1024, alignment=16) Malloc: address = 0xca890 Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0) ``` {F6288839} Differential Revision: https://reviews.llvm.org/D47508 llvm-svn: 333583
2018-05-31 03:39:10 +08:00
int evaluateMemoryMapCommands(Debugger &Dbg);
} // namespace irmemorymap
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
template <typename... Args>
static Error make_string_error(const char *Format, Args &&... args) {
return llvm::make_error<llvm::StringError>(
llvm::formatv(Format, std::forward<Args>(args)...).str(),
llvm::inconvertibleErrorCode());
}
[lldb-test] Add a testing harness for the JIT's IRMemoryMap This teaches lldb-test how to launch a process, set up an IRMemoryMap, and issue memory allocations in the target process through the map. This makes it possible to test IRMemoryMap in a targeted way. This has uncovered two bugs so far. The first bug is that Malloc performs an adjustment on the pointer returned from AllocateMemory (for alignment purposes) which ultimately allows overlapping memory regions to be created. The second bug is that after most of the address space on the host side is exhausted, Malloc may return the same address multiple times. These bugs (and hopefully more!) can be uncovered and tested for with targeted lldb-test commands. At an even higher level, the motivation for addressing these bugs is that they can lead to strange user-visible failures (e.g, variables assume the wrong value during expression evaluation, or the debugger crashes). See my third comment on this swift-lldb PR for an example: https://github.com/apple/swift-lldb/pull/652 I hope lldb-test is the right place to add this testing harness. Setting up a gtest-style unit test proved too cumbersome (you need to recreate or mock way too much debugger state), as did writing end-to-end tests (it's hard to write a test that actually hits a buggy path). With lldb-test, it's easy to read/generate the test input and parse the test output. I'll attach a simple "fuzz" tester which generates failing test cases to the Phab review. Here's an example: ``` Command: malloc(size=1024, alignment=32) Malloc: address = 0xca000 Command: malloc(size=64, alignment=16) Malloc: address = 0xca400 Command: malloc(size=1024, alignment=16) Malloc: address = 0xca440 Command: malloc(size=16, alignment=8) Malloc: address = 0xca840 Command: malloc(size=2048, alignment=16) Malloc: address = 0xcb000 Command: malloc(size=64, alignment=32) Malloc: address = 0xca860 Command: malloc(size=1024, alignment=16) Malloc: address = 0xca890 Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0) ``` {F6288839} Differential Revision: https://reviews.llvm.org/D47508 llvm-svn: 333583
2018-05-31 03:39:10 +08:00
TargetSP opts::createTarget(Debugger &Dbg, const std::string &Filename) {
TargetSP Target;
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, UINT32_MAX, List);
if (List.Empty())
return make_string_error("Context search didn't find a match.");
if (List.GetSize() > 1)
return make_string_error("Context search found multiple matches.");
lldb-test symbols: Add ability to do name-based lookup Summary: lldb-test already had the ability to dump all symbol information in a module. This is interesting, but it can be too verbose, and it also does not use the same APIs that lldb uses to query symbol information. The last part is interesting to me now, because I am about to add DWARF v5 debug_names support, which needs to implement these APIs. This patch adds a set of arguments to lldb-test, which modify it's behavior from dumping all symbols to dumping only the requested information: - --find={function,namespace,type,variable} - search for the given kind of objects. - --name - the name to search for. - --regex - whether to treat the "name" as a regular expression. This is not available for all lookup types (we do not have the required APIs for namespaces and types). - --context - specifies the context, which can be used to restrict the search. This argument takes a variable name (which must be defined and be unique), and we then use the context that this variable is defined in as the search context. - --function-flags={auto,full,base,method,selector} - a set of flags to further restrict the search for function symbols. Together, these flags and their combinations cover the main SymbolFile entry points which I will need to modify for the accelerator table support, and so I plan to do most of the regression testing this way. (I've also found this a useful tool for exploration of what the given APIs are supposed to do.) I add a couple of tests to demonstrate the usage of the usage of the various options, and also an xfailed test which demonstrates a bug I found while playing with this. The only requirement for these tests is the presence of lld -- the should run on any platform which is able to build lldb. These tests use c++ code as input, but this isn't a requirement. It is also possible to use IR, assembly or json to create the test module. Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap Subscribers: mgorny, aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D46318 llvm-svn: 331447
2018-05-03 18:57:16 +08:00
return List.GetVariableAtIndex(0)->GetDeclContext();
}
Error opts::symbols::findFunctions(lldb_private::Module &Module) {
SymbolVendor &Vendor = *Module.GetSymbolVendor();
SymbolContextList List;
if (!File.empty()) {
assert(Line != 0);
FileSpec src_file(File, false);
size_t cu_count = Module.GetNumCompileUnits();
for (size_t i = 0; i < cu_count; i++) {
lldb::CompUnitSP cu_sp = Module.GetCompileUnitAtIndex(i);
if (!cu_sp)
continue;
LineEntry le;
cu_sp->FindLineEntry(0, Line, &src_file, false, &le);
if (!le.IsValid())
continue;
auto addr = le.GetSameLineContiguousAddressRange().GetBaseAddress();
if (!addr.IsValid())
continue;
SymbolContext sc;
uint32_t resolved =
addr.CalculateSymbolContext(&sc, eSymbolContextFunction);
if (resolved & eSymbolContextFunction)
List.Append(sc);
}
} else if (Regex) {
lldb-test symbols: Add ability to do name-based lookup Summary: lldb-test already had the ability to dump all symbol information in a module. This is interesting, but it can be too verbose, and it also does not use the same APIs that lldb uses to query symbol information. The last part is interesting to me now, because I am about to add DWARF v5 debug_names support, which needs to implement these APIs. This patch adds a set of arguments to lldb-test, which modify it's behavior from dumping all symbols to dumping only the requested information: - --find={function,namespace,type,variable} - search for the given kind of objects. - --name - the name to search for. - --regex - whether to treat the "name" as a regular expression. This is not available for all lookup types (we do not have the required APIs for namespaces and types). - --context - specifies the context, which can be used to restrict the search. This argument takes a variable name (which must be defined and be unique), and we then use the context that this variable is defined in as the search context. - --function-flags={auto,full,base,method,selector} - a set of flags to further restrict the search for function symbols. Together, these flags and their combinations cover the main SymbolFile entry points which I will need to modify for the accelerator table support, and so I plan to do most of the regression testing this way. (I've also found this a useful tool for exploration of what the given APIs are supposed to do.) I add a couple of tests to demonstrate the usage of the usage of the various options, and also an xfailed test which demonstrates a bug I found while playing with this. The only requirement for these tests is the presence of lld -- the should run on any platform which is able to build lldb. These tests use c++ code as input, but this isn't a requirement. It is also possible to use IR, assembly or json to create the test module. Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap Subscribers: mgorny, aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D46318 llvm-svn: 331447
2018-05-03 18:57:16 +08:00
RegularExpression RE(Name);
assert(RE.IsValid());
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);
lldb-test symbols: Add ability to do name-based lookup Summary: lldb-test already had the ability to dump all symbol information in a module. This is interesting, but it can be too verbose, and it also does not use the same APIs that lldb uses to query symbol information. The last part is interesting to me now, because I am about to add DWARF v5 debug_names support, which needs to implement these APIs. This patch adds a set of arguments to lldb-test, which modify it's behavior from dumping all symbols to dumping only the requested information: - --find={function,namespace,type,variable} - search for the given kind of objects. - --name - the name to search for. - --regex - whether to treat the "name" as a regular expression. This is not available for all lookup types (we do not have the required APIs for namespaces and types). - --context - specifies the context, which can be used to restrict the search. This argument takes a variable name (which must be defined and be unique), and we then use the context that this variable is defined in as the search context. - --function-flags={auto,full,base,method,selector} - a set of flags to further restrict the search for function symbols. Together, these flags and their combinations cover the main SymbolFile entry points which I will need to modify for the accelerator table support, and so I plan to do most of the regression testing this way. (I've also found this a useful tool for exploration of what the given APIs are supposed to do.) I add a couple of tests to demonstrate the usage of the usage of the various options, and also an xfailed test which demonstrates a bug I found while playing with this. The only requirement for these tests is the presence of lld -- the should run on any platform which is able to build lldb. These tests use c++ code as input, but this isn't a requirement. It is also possible to use IR, assembly or json to create the test module. Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap Subscribers: mgorny, aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D46318 llvm-svn: 331447
2018-05-03 18:57:16 +08:00
}
outs() << formatv("Found {0} functions:\n", List.GetSize());
StreamString Stream;
List.Dump(&Stream, nullptr);
outs() << Stream.GetData() << "\n";
return Error::success();
}
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);
lldb-test symbols: Add ability to do name-based lookup Summary: lldb-test already had the ability to dump all symbol information in a module. This is interesting, but it can be too verbose, and it also does not use the same APIs that lldb uses to query symbol information. The last part is interesting to me now, because I am about to add DWARF v5 debug_names support, which needs to implement these APIs. This patch adds a set of arguments to lldb-test, which modify it's behavior from dumping all symbols to dumping only the requested information: - --find={function,namespace,type,variable} - search for the given kind of objects. - --name - the name to search for. - --regex - whether to treat the "name" as a regular expression. This is not available for all lookup types (we do not have the required APIs for namespaces and types). - --context - specifies the context, which can be used to restrict the search. This argument takes a variable name (which must be defined and be unique), and we then use the context that this variable is defined in as the search context. - --function-flags={auto,full,base,method,selector} - a set of flags to further restrict the search for function symbols. Together, these flags and their combinations cover the main SymbolFile entry points which I will need to modify for the accelerator table support, and so I plan to do most of the regression testing this way. (I've also found this a useful tool for exploration of what the given APIs are supposed to do.) I add a couple of tests to demonstrate the usage of the usage of the various options, and also an xfailed test which demonstrates a bug I found while playing with this. The only requirement for these tests is the presence of lld -- the should run on any platform which is able to build lldb. These tests use c++ code as input, but this isn't a requirement. It is also possible to use IR, assembly or json to create the test module. Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap Subscribers: mgorny, aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D46318 llvm-svn: 331447
2018-05-03 18:57:16 +08:00
outs() << formatv("Found {0} types:\n", Map.GetSize());
StreamString Stream;
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, UINT32_MAX, List);
} else if (!File.empty()) {
CompUnitSP CU;
for (size_t Ind = 0; !CU && Ind < Module.GetNumCompileUnits(); ++Ind) {
CompUnitSP Candidate = Module.GetCompileUnitAtIndex(Ind);
if (!Candidate || Candidate->GetFilename().GetStringRef() != File)
continue;
if (CU)
return make_string_error("Multiple compile units for file `{0}` found.",
File);
CU = std::move(Candidate);
}
if (!CU)
return make_string_error("Compile unit `{0}` not found.", File);
List.AddVariables(CU->GetVariableList(true).get());
lldb-test symbols: Add ability to do name-based lookup Summary: lldb-test already had the ability to dump all symbol information in a module. This is interesting, but it can be too verbose, and it also does not use the same APIs that lldb uses to query symbol information. The last part is interesting to me now, because I am about to add DWARF v5 debug_names support, which needs to implement these APIs. This patch adds a set of arguments to lldb-test, which modify it's behavior from dumping all symbols to dumping only the requested information: - --find={function,namespace,type,variable} - search for the given kind of objects. - --name - the name to search for. - --regex - whether to treat the "name" as a regular expression. This is not available for all lookup types (we do not have the required APIs for namespaces and types). - --context - specifies the context, which can be used to restrict the search. This argument takes a variable name (which must be defined and be unique), and we then use the context that this variable is defined in as the search context. - --function-flags={auto,full,base,method,selector} - a set of flags to further restrict the search for function symbols. Together, these flags and their combinations cover the main SymbolFile entry points which I will need to modify for the accelerator table support, and so I plan to do most of the regression testing this way. (I've also found this a useful tool for exploration of what the given APIs are supposed to do.) I add a couple of tests to demonstrate the usage of the usage of the various options, and also an xfailed test which demonstrates a bug I found while playing with this. The only requirement for these tests is the presence of lld -- the should run on any platform which is able to build lldb. These tests use c++ code as input, but this isn't a requirement. It is also possible to use IR, assembly or json to create the test module. Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap Subscribers: mgorny, aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D46318 llvm-svn: 331447
2018-05-03 18:57:16 +08:00
} else {
Expected<CompilerDeclContext> ContextOr = getDeclContext(Vendor);
if (!ContextOr)
return ContextOr.takeError();
CompilerDeclContext *ContextPtr =
ContextOr->IsValid() ? &*ContextOr : nullptr;
Vendor.FindGlobalVariables(ConstString(Name), ContextPtr, UINT32_MAX, List);
lldb-test symbols: Add ability to do name-based lookup Summary: lldb-test already had the ability to dump all symbol information in a module. This is interesting, but it can be too verbose, and it also does not use the same APIs that lldb uses to query symbol information. The last part is interesting to me now, because I am about to add DWARF v5 debug_names support, which needs to implement these APIs. This patch adds a set of arguments to lldb-test, which modify it's behavior from dumping all symbols to dumping only the requested information: - --find={function,namespace,type,variable} - search for the given kind of objects. - --name - the name to search for. - --regex - whether to treat the "name" as a regular expression. This is not available for all lookup types (we do not have the required APIs for namespaces and types). - --context - specifies the context, which can be used to restrict the search. This argument takes a variable name (which must be defined and be unique), and we then use the context that this variable is defined in as the search context. - --function-flags={auto,full,base,method,selector} - a set of flags to further restrict the search for function symbols. Together, these flags and their combinations cover the main SymbolFile entry points which I will need to modify for the accelerator table support, and so I plan to do most of the regression testing this way. (I've also found this a useful tool for exploration of what the given APIs are supposed to do.) I add a couple of tests to demonstrate the usage of the usage of the various options, and also an xfailed test which demonstrates a bug I found while playing with this. The only requirement for these tests is the presence of lld -- the should run on any platform which is able to build lldb. These tests use c++ code as input, but this isn't a requirement. It is also possible to use IR, assembly or json to create the test module. Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap Subscribers: mgorny, aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D46318 llvm-svn: 331447
2018-05-03 18:57:16 +08:00
}
outs() << formatv("Found {0} variables:\n", List.GetSize());
StreamString Stream;
List.Dump(&Stream, false);
outs() << Stream.GetData() << "\n";
return Error::success();
Add "lldb-test breakpoint" command and convert the case-sensitivity test to use it Summary: The command takes two input arguments: a module to use as a debug target and a file containing a list of commands. The command will execute each of the breakpoint commands in the file and dump the breakpoint state after each one. The commands are expected to be breakpoint set/remove/etc. commands, but I explicitly allow any lldb command here, so you can do things like change setting which impact breakpoint resolution, etc. There is also a "-persistent" flag, which causes lldb-test to *not* automatically clear the breakpoint list after each command. Right now I don't use it, but the idea behind it was that it could be used to test more complex combinations of breakpoint commands (set+modify, set+disable, etc.). Right now the command prints out only the basic breakpoint state, but more information can be easily added there. To enable easy matching of the "at least one breakpoint location found" state, the command explicitly prints out the string "At least one breakpoint location.". To enable testing of breakpoints set with an absolute paths, I add the ability to perform rudimentary substitutions on the commands: right now the string %p is replaced by the directory which contains the command file (so, under normal circumstances, this will perform the same substitution as lit would do for %p). I use this command to rewrite the TestBreakpointCaseSensitivity test -- the test was checking about a dozen breakpoint commands, but it was launching a new process for each one, so it took about 90 seconds to run. The new test takes about 0.3 seconds for me, which is approximately a 300x speedup. Reviewers: davide, zturner, jingham Subscribers: luporl, lldb-commits Differential Revision: https://reviews.llvm.org/D43686 llvm-svn: 326112
2018-02-27 02:50:16 +08:00
}
lldb-test symbols: Add ability to do name-based lookup Summary: lldb-test already had the ability to dump all symbol information in a module. This is interesting, but it can be too verbose, and it also does not use the same APIs that lldb uses to query symbol information. The last part is interesting to me now, because I am about to add DWARF v5 debug_names support, which needs to implement these APIs. This patch adds a set of arguments to lldb-test, which modify it's behavior from dumping all symbols to dumping only the requested information: - --find={function,namespace,type,variable} - search for the given kind of objects. - --name - the name to search for. - --regex - whether to treat the "name" as a regular expression. This is not available for all lookup types (we do not have the required APIs for namespaces and types). - --context - specifies the context, which can be used to restrict the search. This argument takes a variable name (which must be defined and be unique), and we then use the context that this variable is defined in as the search context. - --function-flags={auto,full,base,method,selector} - a set of flags to further restrict the search for function symbols. Together, these flags and their combinations cover the main SymbolFile entry points which I will need to modify for the accelerator table support, and so I plan to do most of the regression testing this way. (I've also found this a useful tool for exploration of what the given APIs are supposed to do.) I add a couple of tests to demonstrate the usage of the usage of the various options, and also an xfailed test which demonstrates a bug I found while playing with this. The only requirement for these tests is the presence of lld -- the should run on any platform which is able to build lldb. These tests use c++ code as input, but this isn't a requirement. It is also possible to use IR, assembly or json to create the test module. Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap Subscribers: mgorny, aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D46318 llvm-svn: 331447
2018-05-03 18:57:16 +08:00
Error opts::symbols::dumpModule(lldb_private::Module &Module) {
StreamString Stream;
Module.ParseAllDebugSymbols();
Module.Dump(&Stream);
outs() << Stream.GetData() << "\n";
return Error::success();
}
Error opts::symbols::verify(lldb_private::Module &Module) {
SymbolVendor &plugin = *Module.GetSymbolVendor();
SymbolFile *symfile = plugin.GetSymbolFile();
if (!symfile)
return make_string_error("Module has no symbol file.");
uint32_t comp_units_count = symfile->GetNumCompileUnits();
outs() << "Found " << comp_units_count << " compile units.\n";
for (uint32_t i = 0; i < comp_units_count; i++) {
lldb::CompUnitSP comp_unit = symfile->ParseCompileUnitAtIndex(i);
if (!comp_unit)
return make_string_error("Connot parse compile unit {0}.", i);
outs() << "Processing '" << comp_unit->GetFilename().AsCString()
<< "' compile unit.\n";
LineTable *lt = comp_unit->GetLineTable();
if (!lt)
return make_string_error("Can't get a line table of a compile unit.");
uint32_t count = lt->GetSize();
outs() << "The line table contains " << count << " entries.\n";
if (count == 0)
continue;
LineEntry le;
if (!lt->GetLineEntryAtIndex(0, le))
return make_string_error("Can't get a line entry of a compile unit.");
for (uint32_t i = 1; i < count; i++) {
lldb::addr_t curr_end =
le.range.GetBaseAddress().GetFileAddress() + le.range.GetByteSize();
if (!lt->GetLineEntryAtIndex(i, le))
return make_string_error("Can't get a line entry of a compile unit");
if (curr_end > le.range.GetBaseAddress().GetFileAddress())
return make_string_error(
"Line table of a compile unit is inconsistent.");
}
}
outs() << "The symbol information is verified.\n";
return Error::success();
}
Expected<Error (*)(lldb_private::Module &)> opts::symbols::getAction() {
if (Verify) {
if (Find != FindType::None)
return make_string_error(
"Cannot both search and verify symbol information.");
if (Regex || !Context.empty() || !Name.empty() || !File.empty() ||
Line != 0)
return make_string_error(
"-regex, -context, -name, -file and -line options are not "
"applicable for symbol verification.");
return verify;
lldb-test symbols: Add ability to do name-based lookup Summary: lldb-test already had the ability to dump all symbol information in a module. This is interesting, but it can be too verbose, and it also does not use the same APIs that lldb uses to query symbol information. The last part is interesting to me now, because I am about to add DWARF v5 debug_names support, which needs to implement these APIs. This patch adds a set of arguments to lldb-test, which modify it's behavior from dumping all symbols to dumping only the requested information: - --find={function,namespace,type,variable} - search for the given kind of objects. - --name - the name to search for. - --regex - whether to treat the "name" as a regular expression. This is not available for all lookup types (we do not have the required APIs for namespaces and types). - --context - specifies the context, which can be used to restrict the search. This argument takes a variable name (which must be defined and be unique), and we then use the context that this variable is defined in as the search context. - --function-flags={auto,full,base,method,selector} - a set of flags to further restrict the search for function symbols. Together, these flags and their combinations cover the main SymbolFile entry points which I will need to modify for the accelerator table support, and so I plan to do most of the regression testing this way. (I've also found this a useful tool for exploration of what the given APIs are supposed to do.) I add a couple of tests to demonstrate the usage of the usage of the various options, and also an xfailed test which demonstrates a bug I found while playing with this. The only requirement for these tests is the presence of lld -- the should run on any platform which is able to build lldb. These tests use c++ code as input, but this isn't a requirement. It is also possible to use IR, assembly or json to create the test module. Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap Subscribers: mgorny, aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D46318 llvm-svn: 331447
2018-05-03 18:57:16 +08:00
}
if (Regex && !Context.empty())
return make_string_error(
"Cannot search using both regular expressions and context.");
if (Regex && !RegularExpression(Name).IsValid())
return make_string_error("`{0}` is not a valid regular expression.", Name);
if (Regex + !Context.empty() + !File.empty() >= 2)
return make_string_error(
"Only one of -regex, -context and -file may be used simultaneously.");
if (Regex && Name.empty())
return make_string_error("-regex used without a -name");
switch (Find) {
case FindType::None:
if (!Context.empty() || !Name.empty() || !File.empty() || Line != 0)
return make_string_error(
"Specify search type (-find) to use search options.");
return dumpModule;
case FindType::Function:
if (!File.empty() + (Line != 0) == 1)
return make_string_error("Both file name and line number must be "
"specified when searching a function "
"by file position.");
if (Regex + (getFunctionNameFlags() != 0) + !File.empty() >= 2)
return make_string_error("Only one of regular expression, function-flags "
"and file position may be used simultaneously "
"when searching a function.");
return findFunctions;
case FindType::Namespace:
if (Regex || !File.empty() || Line != 0)
return make_string_error("Cannot search for namespaces using regular "
"expressions, file names or line numbers.");
return findNamespaces;
case FindType::Type:
if (Regex || !File.empty() || Line != 0)
return make_string_error("Cannot search for types using regular "
"expressions, file names or line numbers.");
return findTypes;
case FindType::Variable:
if (Line != 0)
return make_string_error("Cannot search for variables "
"using line numbers.");
return findVariables;
lldb-test symbols: Add ability to do name-based lookup Summary: lldb-test already had the ability to dump all symbol information in a module. This is interesting, but it can be too verbose, and it also does not use the same APIs that lldb uses to query symbol information. The last part is interesting to me now, because I am about to add DWARF v5 debug_names support, which needs to implement these APIs. This patch adds a set of arguments to lldb-test, which modify it's behavior from dumping all symbols to dumping only the requested information: - --find={function,namespace,type,variable} - search for the given kind of objects. - --name - the name to search for. - --regex - whether to treat the "name" as a regular expression. This is not available for all lookup types (we do not have the required APIs for namespaces and types). - --context - specifies the context, which can be used to restrict the search. This argument takes a variable name (which must be defined and be unique), and we then use the context that this variable is defined in as the search context. - --function-flags={auto,full,base,method,selector} - a set of flags to further restrict the search for function symbols. Together, these flags and their combinations cover the main SymbolFile entry points which I will need to modify for the accelerator table support, and so I plan to do most of the regression testing this way. (I've also found this a useful tool for exploration of what the given APIs are supposed to do.) I add a couple of tests to demonstrate the usage of the usage of the various options, and also an xfailed test which demonstrates a bug I found while playing with this. The only requirement for these tests is the presence of lld -- the should run on any platform which is able to build lldb. These tests use c++ code as input, but this isn't a requirement. It is also possible to use IR, assembly or json to create the test module. Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap Subscribers: mgorny, aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D46318 llvm-svn: 331447
2018-05-03 18:57:16 +08:00
}
}
int opts::symbols::dumpSymbols(Debugger &Dbg) {
auto ActionOr = getAction();
if (!ActionOr) {
logAllUnhandledErrors(ActionOr.takeError(), WithColor::error(), "");
lldb-test symbols: Add ability to do name-based lookup Summary: lldb-test already had the ability to dump all symbol information in a module. This is interesting, but it can be too verbose, and it also does not use the same APIs that lldb uses to query symbol information. The last part is interesting to me now, because I am about to add DWARF v5 debug_names support, which needs to implement these APIs. This patch adds a set of arguments to lldb-test, which modify it's behavior from dumping all symbols to dumping only the requested information: - --find={function,namespace,type,variable} - search for the given kind of objects. - --name - the name to search for. - --regex - whether to treat the "name" as a regular expression. This is not available for all lookup types (we do not have the required APIs for namespaces and types). - --context - specifies the context, which can be used to restrict the search. This argument takes a variable name (which must be defined and be unique), and we then use the context that this variable is defined in as the search context. - --function-flags={auto,full,base,method,selector} - a set of flags to further restrict the search for function symbols. Together, these flags and their combinations cover the main SymbolFile entry points which I will need to modify for the accelerator table support, and so I plan to do most of the regression testing this way. (I've also found this a useful tool for exploration of what the given APIs are supposed to do.) I add a couple of tests to demonstrate the usage of the usage of the various options, and also an xfailed test which demonstrates a bug I found while playing with this. The only requirement for these tests is the presence of lld -- the should run on any platform which is able to build lldb. These tests use c++ code as input, but this isn't a requirement. It is also possible to use IR, assembly or json to create the test module. Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap Subscribers: mgorny, aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D46318 llvm-svn: 331447
2018-05-03 18:57:16 +08:00
return 1;
}
auto Action = *ActionOr;
lldb-test symbols: Add ability to do name-based lookup Summary: lldb-test already had the ability to dump all symbol information in a module. This is interesting, but it can be too verbose, and it also does not use the same APIs that lldb uses to query symbol information. The last part is interesting to me now, because I am about to add DWARF v5 debug_names support, which needs to implement these APIs. This patch adds a set of arguments to lldb-test, which modify it's behavior from dumping all symbols to dumping only the requested information: - --find={function,namespace,type,variable} - search for the given kind of objects. - --name - the name to search for. - --regex - whether to treat the "name" as a regular expression. This is not available for all lookup types (we do not have the required APIs for namespaces and types). - --context - specifies the context, which can be used to restrict the search. This argument takes a variable name (which must be defined and be unique), and we then use the context that this variable is defined in as the search context. - --function-flags={auto,full,base,method,selector} - a set of flags to further restrict the search for function symbols. Together, these flags and their combinations cover the main SymbolFile entry points which I will need to modify for the accelerator table support, and so I plan to do most of the regression testing this way. (I've also found this a useful tool for exploration of what the given APIs are supposed to do.) I add a couple of tests to demonstrate the usage of the usage of the various options, and also an xfailed test which demonstrates a bug I found while playing with this. The only requirement for these tests is the presence of lld -- the should run on any platform which is able to build lldb. These tests use c++ code as input, but this isn't a requirement. It is also possible to use IR, assembly or json to create the test module. Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap Subscribers: mgorny, aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D46318 llvm-svn: 331447
2018-05-03 18:57:16 +08:00
int HadErrors = 0;
for (const auto &File : InputFilenames) {
outs() << "Module: " << File << "\n";
ModuleSpec Spec{FileSpec(File, false)};
Spec.GetSymbolFileSpec().SetFile(File, false, FileSpec::Style::native);
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;
}
lldb-test symbols: Add ability to do name-based lookup Summary: lldb-test already had the ability to dump all symbol information in a module. This is interesting, but it can be too verbose, and it also does not use the same APIs that lldb uses to query symbol information. The last part is interesting to me now, because I am about to add DWARF v5 debug_names support, which needs to implement these APIs. This patch adds a set of arguments to lldb-test, which modify it's behavior from dumping all symbols to dumping only the requested information: - --find={function,namespace,type,variable} - search for the given kind of objects. - --name - the name to search for. - --regex - whether to treat the "name" as a regular expression. This is not available for all lookup types (we do not have the required APIs for namespaces and types). - --context - specifies the context, which can be used to restrict the search. This argument takes a variable name (which must be defined and be unique), and we then use the context that this variable is defined in as the search context. - --function-flags={auto,full,base,method,selector} - a set of flags to further restrict the search for function symbols. Together, these flags and their combinations cover the main SymbolFile entry points which I will need to modify for the accelerator table support, and so I plan to do most of the regression testing this way. (I've also found this a useful tool for exploration of what the given APIs are supposed to do.) I add a couple of tests to demonstrate the usage of the usage of the various options, and also an xfailed test which demonstrates a bug I found while playing with this. The only requirement for these tests is the presence of lld -- the should run on any platform which is able to build lldb. These tests use c++ code as input, but this isn't a requirement. It is also possible to use IR, assembly or json to create the test module. Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap Subscribers: mgorny, aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D46318 llvm-svn: 331447
2018-05-03 18:57:16 +08:00
if (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(StringRef Line,
IRMemoryMapTestState &State) {
// ::= <label> = malloc <size> <alignment>
StringRef Label;
std::tie(Label, Line) = Line.split('=');
if (Line.empty())
return false;
Label = Label.trim();
Line = Line.trim();
[lldb-test] Add a testing harness for the JIT's IRMemoryMap This teaches lldb-test how to launch a process, set up an IRMemoryMap, and issue memory allocations in the target process through the map. This makes it possible to test IRMemoryMap in a targeted way. This has uncovered two bugs so far. The first bug is that Malloc performs an adjustment on the pointer returned from AllocateMemory (for alignment purposes) which ultimately allows overlapping memory regions to be created. The second bug is that after most of the address space on the host side is exhausted, Malloc may return the same address multiple times. These bugs (and hopefully more!) can be uncovered and tested for with targeted lldb-test commands. At an even higher level, the motivation for addressing these bugs is that they can lead to strange user-visible failures (e.g, variables assume the wrong value during expression evaluation, or the debugger crashes). See my third comment on this swift-lldb PR for an example: https://github.com/apple/swift-lldb/pull/652 I hope lldb-test is the right place to add this testing harness. Setting up a gtest-style unit test proved too cumbersome (you need to recreate or mock way too much debugger state), as did writing end-to-end tests (it's hard to write a test that actually hits a buggy path). With lldb-test, it's easy to read/generate the test input and parse the test output. I'll attach a simple "fuzz" tester which generates failing test cases to the Phab review. Here's an example: ``` Command: malloc(size=1024, alignment=32) Malloc: address = 0xca000 Command: malloc(size=64, alignment=16) Malloc: address = 0xca400 Command: malloc(size=1024, alignment=16) Malloc: address = 0xca440 Command: malloc(size=16, alignment=8) Malloc: address = 0xca840 Command: malloc(size=2048, alignment=16) Malloc: address = 0xcb000 Command: malloc(size=64, alignment=32) Malloc: address = 0xca860 Command: malloc(size=1024, alignment=16) Malloc: address = 0xca890 Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0) ``` {F6288839} Differential Revision: https://reviews.llvm.org/D47508 llvm-svn: 333583
2018-05-31 03:39:10 +08:00
size_t Size;
uint8_t Alignment;
int Matches = sscanf(Line.data(), "malloc %zu %hhu", &Size, &Alignment);
if (Matches != 2)
return false;
outs() << formatv("Command: {0} = malloc(size={1}, alignment={2})\n", Label,
Size, Alignment);
[lldb-test] Add a testing harness for the JIT's IRMemoryMap This teaches lldb-test how to launch a process, set up an IRMemoryMap, and issue memory allocations in the target process through the map. This makes it possible to test IRMemoryMap in a targeted way. This has uncovered two bugs so far. The first bug is that Malloc performs an adjustment on the pointer returned from AllocateMemory (for alignment purposes) which ultimately allows overlapping memory regions to be created. The second bug is that after most of the address space on the host side is exhausted, Malloc may return the same address multiple times. These bugs (and hopefully more!) can be uncovered and tested for with targeted lldb-test commands. At an even higher level, the motivation for addressing these bugs is that they can lead to strange user-visible failures (e.g, variables assume the wrong value during expression evaluation, or the debugger crashes). See my third comment on this swift-lldb PR for an example: https://github.com/apple/swift-lldb/pull/652 I hope lldb-test is the right place to add this testing harness. Setting up a gtest-style unit test proved too cumbersome (you need to recreate or mock way too much debugger state), as did writing end-to-end tests (it's hard to write a test that actually hits a buggy path). With lldb-test, it's easy to read/generate the test input and parse the test output. I'll attach a simple "fuzz" tester which generates failing test cases to the Phab review. Here's an example: ``` Command: malloc(size=1024, alignment=32) Malloc: address = 0xca000 Command: malloc(size=64, alignment=16) Malloc: address = 0xca400 Command: malloc(size=1024, alignment=16) Malloc: address = 0xca440 Command: malloc(size=16, alignment=8) Malloc: address = 0xca840 Command: malloc(size=2048, alignment=16) Malloc: address = 0xcb000 Command: malloc(size=64, alignment=32) Malloc: address = 0xca860 Command: malloc(size=1024, alignment=16) Malloc: address = 0xca890 Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0) ``` {F6288839} Differential Revision: https://reviews.llvm.org/D47508 llvm-svn: 333583
2018-05-31 03:39:10 +08:00
if (!isPowerOf2_32(Alignment)) {
outs() << "Malloc error: alignment is not a power of 2\n";
exit(1);
}
IRMemoryMap::AllocationPolicy AP =
UseHostOnlyAllocationPolicy ? IRMemoryMap::eAllocationPolicyHostOnly
: IRMemoryMap::eAllocationPolicyProcessOnly;
[lldb-test] Add a testing harness for the JIT's IRMemoryMap This teaches lldb-test how to launch a process, set up an IRMemoryMap, and issue memory allocations in the target process through the map. This makes it possible to test IRMemoryMap in a targeted way. This has uncovered two bugs so far. The first bug is that Malloc performs an adjustment on the pointer returned from AllocateMemory (for alignment purposes) which ultimately allows overlapping memory regions to be created. The second bug is that after most of the address space on the host side is exhausted, Malloc may return the same address multiple times. These bugs (and hopefully more!) can be uncovered and tested for with targeted lldb-test commands. At an even higher level, the motivation for addressing these bugs is that they can lead to strange user-visible failures (e.g, variables assume the wrong value during expression evaluation, or the debugger crashes). See my third comment on this swift-lldb PR for an example: https://github.com/apple/swift-lldb/pull/652 I hope lldb-test is the right place to add this testing harness. Setting up a gtest-style unit test proved too cumbersome (you need to recreate or mock way too much debugger state), as did writing end-to-end tests (it's hard to write a test that actually hits a buggy path). With lldb-test, it's easy to read/generate the test input and parse the test output. I'll attach a simple "fuzz" tester which generates failing test cases to the Phab review. Here's an example: ``` Command: malloc(size=1024, alignment=32) Malloc: address = 0xca000 Command: malloc(size=64, alignment=16) Malloc: address = 0xca400 Command: malloc(size=1024, alignment=16) Malloc: address = 0xca440 Command: malloc(size=16, alignment=8) Malloc: address = 0xca840 Command: malloc(size=2048, alignment=16) Malloc: address = 0xcb000 Command: malloc(size=64, alignment=32) Malloc: address = 0xca860 Command: malloc(size=1024, alignment=16) Malloc: address = 0xca890 Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0) ``` {F6288839} Differential Revision: https://reviews.llvm.org/D47508 llvm-svn: 333583
2018-05-31 03:39:10 +08:00
// Issue the malloc in the target process with "-rw" permissions.
const uint32_t Permissions = 0x3;
const bool ZeroMemory = false;
Status ST;
addr_t Addr =
State.Map.Malloc(Size, Alignment, Permissions, AP, ZeroMemory, ST);
[lldb-test] Add a testing harness for the JIT's IRMemoryMap This teaches lldb-test how to launch a process, set up an IRMemoryMap, and issue memory allocations in the target process through the map. This makes it possible to test IRMemoryMap in a targeted way. This has uncovered two bugs so far. The first bug is that Malloc performs an adjustment on the pointer returned from AllocateMemory (for alignment purposes) which ultimately allows overlapping memory regions to be created. The second bug is that after most of the address space on the host side is exhausted, Malloc may return the same address multiple times. These bugs (and hopefully more!) can be uncovered and tested for with targeted lldb-test commands. At an even higher level, the motivation for addressing these bugs is that they can lead to strange user-visible failures (e.g, variables assume the wrong value during expression evaluation, or the debugger crashes). See my third comment on this swift-lldb PR for an example: https://github.com/apple/swift-lldb/pull/652 I hope lldb-test is the right place to add this testing harness. Setting up a gtest-style unit test proved too cumbersome (you need to recreate or mock way too much debugger state), as did writing end-to-end tests (it's hard to write a test that actually hits a buggy path). With lldb-test, it's easy to read/generate the test input and parse the test output. I'll attach a simple "fuzz" tester which generates failing test cases to the Phab review. Here's an example: ``` Command: malloc(size=1024, alignment=32) Malloc: address = 0xca000 Command: malloc(size=64, alignment=16) Malloc: address = 0xca400 Command: malloc(size=1024, alignment=16) Malloc: address = 0xca440 Command: malloc(size=16, alignment=8) Malloc: address = 0xca840 Command: malloc(size=2048, alignment=16) Malloc: address = 0xcb000 Command: malloc(size=64, alignment=32) Malloc: address = 0xca860 Command: malloc(size=1024, alignment=16) Malloc: address = 0xca890 Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0) ``` {F6288839} Differential Revision: https://reviews.llvm.org/D47508 llvm-svn: 333583
2018-05-31 03:39:10 +08:00
if (ST.Fail()) {
outs() << formatv("Malloc error: {0}\n", ST);
return true;
}
// Print the result of the allocation before checking its validity.
outs() << formatv("Malloc: address = {0:x}\n", Addr);
// Check that the allocation is aligned.
if (!Addr || Addr % Alignment != 0) {
outs() << "Malloc error: zero or unaligned allocation detected\n";
exit(1);
}
// 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 = State.Allocations.begin();
[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
Probe.advanceTo(Addr); //< First interval s.t stop >= Addr.
AllocationT NewAllocation = {Addr, EndOfRegion};
while (Probe != State.Allocations.end() && 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);
[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
}
++Probe;
[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
}
// Insert the new allocation into the interval map. Use unique allocation IDs
// to inhibit interval coalescing.
static unsigned AllocationID = 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
if (Size)
State.Allocations.insert(Addr, EndOfRegion, AllocationID++);
// Store the label -> address mapping.
State.Label2AddrMap[Label] = Addr;
return true;
}
bool opts::irmemorymap::evalFree(StringRef Line, IRMemoryMapTestState &State) {
// ::= free <label>
if (!Line.consume_front("free"))
return false;
StringRef Label = Line.trim();
outs() << formatv("Command: free({0})\n", Label);
auto LabelIt = State.Label2AddrMap.find(Label);
if (LabelIt == State.Label2AddrMap.end()) {
outs() << "Free error: Invalid allocation label\n";
exit(1);
}
Status ST;
addr_t Addr = LabelIt->getValue();
State.Map.Free(Addr, ST);
if (ST.Fail()) {
outs() << formatv("Free error: {0}\n", ST);
exit(1);
}
// Erase the allocation from the live interval map.
auto Interval = State.Allocations.find(Addr);
if (Interval != State.Allocations.end()) {
outs() << formatv("Free: [{0:x}, {1:x})\n", Interval.start(),
Interval.stop());
Interval.erase();
}
[lldb-test] Add a testing harness for the JIT's IRMemoryMap This teaches lldb-test how to launch a process, set up an IRMemoryMap, and issue memory allocations in the target process through the map. This makes it possible to test IRMemoryMap in a targeted way. This has uncovered two bugs so far. The first bug is that Malloc performs an adjustment on the pointer returned from AllocateMemory (for alignment purposes) which ultimately allows overlapping memory regions to be created. The second bug is that after most of the address space on the host side is exhausted, Malloc may return the same address multiple times. These bugs (and hopefully more!) can be uncovered and tested for with targeted lldb-test commands. At an even higher level, the motivation for addressing these bugs is that they can lead to strange user-visible failures (e.g, variables assume the wrong value during expression evaluation, or the debugger crashes). See my third comment on this swift-lldb PR for an example: https://github.com/apple/swift-lldb/pull/652 I hope lldb-test is the right place to add this testing harness. Setting up a gtest-style unit test proved too cumbersome (you need to recreate or mock way too much debugger state), as did writing end-to-end tests (it's hard to write a test that actually hits a buggy path). With lldb-test, it's easy to read/generate the test input and parse the test output. I'll attach a simple "fuzz" tester which generates failing test cases to the Phab review. Here's an example: ``` Command: malloc(size=1024, alignment=32) Malloc: address = 0xca000 Command: malloc(size=64, alignment=16) Malloc: address = 0xca400 Command: malloc(size=1024, alignment=16) Malloc: address = 0xca440 Command: malloc(size=16, alignment=8) Malloc: address = 0xca840 Command: malloc(size=2048, alignment=16) Malloc: address = 0xcb000 Command: malloc(size=64, alignment=32) Malloc: address = 0xca860 Command: malloc(size=1024, alignment=16) Malloc: address = 0xca890 Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0) ``` {F6288839} Differential Revision: https://reviews.llvm.org/D47508 llvm-svn: 333583
2018-05-31 03:39:10 +08:00
return true;
}
int opts::irmemorymap::evaluateMemoryMapCommands(Debugger &Dbg) {
// Set up a Target.
TargetSP Target = opts::createTarget(Dbg, irmemorymap::Target);
// Set up a Process. In order to allocate memory within a target, this
// process must be alive and must support JIT'ing.
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.
IRMemoryMapTestState State(Target);
[lldb-test] Add a testing harness for the JIT's IRMemoryMap This teaches lldb-test how to launch a process, set up an IRMemoryMap, and issue memory allocations in the target process through the map. This makes it possible to test IRMemoryMap in a targeted way. This has uncovered two bugs so far. The first bug is that Malloc performs an adjustment on the pointer returned from AllocateMemory (for alignment purposes) which ultimately allows overlapping memory regions to be created. The second bug is that after most of the address space on the host side is exhausted, Malloc may return the same address multiple times. These bugs (and hopefully more!) can be uncovered and tested for with targeted lldb-test commands. At an even higher level, the motivation for addressing these bugs is that they can lead to strange user-visible failures (e.g, variables assume the wrong value during expression evaluation, or the debugger crashes). See my third comment on this swift-lldb PR for an example: https://github.com/apple/swift-lldb/pull/652 I hope lldb-test is the right place to add this testing harness. Setting up a gtest-style unit test proved too cumbersome (you need to recreate or mock way too much debugger state), as did writing end-to-end tests (it's hard to write a test that actually hits a buggy path). With lldb-test, it's easy to read/generate the test input and parse the test output. I'll attach a simple "fuzz" tester which generates failing test cases to the Phab review. Here's an example: ``` Command: malloc(size=1024, alignment=32) Malloc: address = 0xca000 Command: malloc(size=64, alignment=16) Malloc: address = 0xca400 Command: malloc(size=1024, alignment=16) Malloc: address = 0xca440 Command: malloc(size=16, alignment=8) Malloc: address = 0xca840 Command: malloc(size=2048, alignment=16) Malloc: address = 0xcb000 Command: malloc(size=64, alignment=32) Malloc: address = 0xca860 Command: malloc(size=1024, alignment=16) Malloc: address = 0xca890 Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0) ``` {F6288839} Differential Revision: https://reviews.llvm.org/D47508 llvm-svn: 333583
2018-05-31 03:39:10 +08:00
// Parse and apply commands from the command file.
std::unique_ptr<MemoryBuffer> MB = opts::openFile(irmemorymap::CommandFile);
StringRef Rest = MB->getBuffer();
while (!Rest.empty()) {
StringRef Line;
std::tie(Line, Rest) = Rest.split('\n');
Line = Line.ltrim();
if (Line.empty() || Line[0] == '#')
continue;
if (evalMalloc(Line, State))
[lldb-test] Add a testing harness for the JIT's IRMemoryMap This teaches lldb-test how to launch a process, set up an IRMemoryMap, and issue memory allocations in the target process through the map. This makes it possible to test IRMemoryMap in a targeted way. This has uncovered two bugs so far. The first bug is that Malloc performs an adjustment on the pointer returned from AllocateMemory (for alignment purposes) which ultimately allows overlapping memory regions to be created. The second bug is that after most of the address space on the host side is exhausted, Malloc may return the same address multiple times. These bugs (and hopefully more!) can be uncovered and tested for with targeted lldb-test commands. At an even higher level, the motivation for addressing these bugs is that they can lead to strange user-visible failures (e.g, variables assume the wrong value during expression evaluation, or the debugger crashes). See my third comment on this swift-lldb PR for an example: https://github.com/apple/swift-lldb/pull/652 I hope lldb-test is the right place to add this testing harness. Setting up a gtest-style unit test proved too cumbersome (you need to recreate or mock way too much debugger state), as did writing end-to-end tests (it's hard to write a test that actually hits a buggy path). With lldb-test, it's easy to read/generate the test input and parse the test output. I'll attach a simple "fuzz" tester which generates failing test cases to the Phab review. Here's an example: ``` Command: malloc(size=1024, alignment=32) Malloc: address = 0xca000 Command: malloc(size=64, alignment=16) Malloc: address = 0xca400 Command: malloc(size=1024, alignment=16) Malloc: address = 0xca440 Command: malloc(size=16, alignment=8) Malloc: address = 0xca840 Command: malloc(size=2048, alignment=16) Malloc: address = 0xcb000 Command: malloc(size=64, alignment=32) Malloc: address = 0xca860 Command: malloc(size=1024, alignment=16) Malloc: address = 0xca890 Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0) ``` {F6288839} Differential Revision: https://reviews.llvm.org/D47508 llvm-svn: 333583
2018-05-31 03:39:10 +08:00
continue;
if (evalFree(Line, State))
continue;
[lldb-test] Add a testing harness for the JIT's IRMemoryMap This teaches lldb-test how to launch a process, set up an IRMemoryMap, and issue memory allocations in the target process through the map. This makes it possible to test IRMemoryMap in a targeted way. This has uncovered two bugs so far. The first bug is that Malloc performs an adjustment on the pointer returned from AllocateMemory (for alignment purposes) which ultimately allows overlapping memory regions to be created. The second bug is that after most of the address space on the host side is exhausted, Malloc may return the same address multiple times. These bugs (and hopefully more!) can be uncovered and tested for with targeted lldb-test commands. At an even higher level, the motivation for addressing these bugs is that they can lead to strange user-visible failures (e.g, variables assume the wrong value during expression evaluation, or the debugger crashes). See my third comment on this swift-lldb PR for an example: https://github.com/apple/swift-lldb/pull/652 I hope lldb-test is the right place to add this testing harness. Setting up a gtest-style unit test proved too cumbersome (you need to recreate or mock way too much debugger state), as did writing end-to-end tests (it's hard to write a test that actually hits a buggy path). With lldb-test, it's easy to read/generate the test input and parse the test output. I'll attach a simple "fuzz" tester which generates failing test cases to the Phab review. Here's an example: ``` Command: malloc(size=1024, alignment=32) Malloc: address = 0xca000 Command: malloc(size=64, alignment=16) Malloc: address = 0xca400 Command: malloc(size=1024, alignment=16) Malloc: address = 0xca440 Command: malloc(size=16, alignment=8) Malloc: address = 0xca840 Command: malloc(size=2048, alignment=16) Malloc: address = 0xcb000 Command: malloc(size=64, alignment=32) Malloc: address = 0xca860 Command: malloc(size=1024, alignment=16) Malloc: address = 0xca890 Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0) ``` {F6288839} Differential Revision: https://reviews.llvm.org/D47508 llvm-svn: 333583
2018-05-31 03:39:10 +08:00
errs() << "Could not parse line: " << Line << "\n";
exit(1);
}
return 0;
}
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;
}