[Lldb-commits] [PATCH] D44998: ObjectFileELF: Add support for arbitrarily named code sections
kbaladurin added inline comments.
Herald added a reviewer: espindola.
Comment at:
packages/Python/lldbsuite/test/arm/breakpoint-thumb-codesection/TestBreakpointThumbCodesection.py:29
+
+self.runCmd("run")
+
labath wrote:
> Do you think there's any added value in making sure that the breakpoint is
> *hit* (instead of just making sure that it's resolved to the right file
> address). If it's the latter we could make this a non-execution test and have
> it run everywhere (e.g., via lldb-test breakpoint) instead of just on arm
> hardware.
I think we need to make sure that breakpoint is *hit* and program can
successfully continue execution after it, because it is resolved to right
address in both cases:
lldb without this patch:
```
$ llvm-arm/bin/lldb thumb-bp
(lldb) target create "thumb-bp"
Current executable set to 'thumb-bp' (arm).
(lldb) b bp.c:3
Breakpoint 1: where = thumb-bp`f + 6 at bp.c:3, address = 0x000103f6
(lldb) r
Process 22192 launched: '/home/kbaladurin/thumb-bp' (arm)
Process 22192 stopped
* thread #1: tid = 22192, 0x000103d0 thumb-bp`__libc_csu_init + 32, name =
'thumb-bp', stop reason = signal SIGSEGV: invalid address (fault address: 0x0)
frame #0: 0x000103d0 thumb-bp`__libc_csu_init + 32
thumb-bp`__libc_csu_init:
-> 0x103d0 <+32>: ldrr3, [r5], #4
0x103d4 <+36>: movr2, r9
0x103d6 <+38>: movr1, r8
0x103d8 <+40>: movr0, r7
(lldb) disas -n f
thumb-bp`f:
0x103f0 <+0>: strmi r11, [r1], -r2, lsl #1
0x103f4 <+4>: stmdals r1, {r0, r12, pc}
0x103f8 <+8>: .long 0x91003001; unknown opcode
0x103fc <+12>: ldrbmi r11, [r0, -r2]!
```
lldb with this patch:
```
$ llvm-arm-patch/bin/lldb thumb-bp
(lldb) target create "thumb-bp"
Current executable set to 'thumb-bp' (arm).
(lldb) b bp.c:3
Breakpoint 1: where = thumb-bp`f + 6 at bp.c:3, address = 0x000103f6
(lldb) r
Process 22282 launched: '/home/kbaladurin/thumb-bp' (arm)
Process 22282 stopped
* thread #1: tid = 22282, 0x000103f6 thumb-bp`f(a=10) + 6 at bp.c:3, name =
'thumb-bp', stop reason = breakpoint 1.1
frame #0: 0x000103f6 thumb-bp`f(a=10) + 6 at bp.c:3
1__attribute__((section("__codesection")))
2int f(int a) {
-> 3 return a + 1; // Set break point at this line.
4}
5
6int main() {
7 return f(10);
(lldb) disas
thumb-bp`f:
0x103f0 <+0>: subsp, #0x8
0x103f2 <+2>: movr1, r0
0x103f4 <+4>: strr0, [sp, #0x4]
-> 0x103f6 <+6>: ldrr0, [sp, #0x4]
0x103f8 <+8>: adds r0, #0x1
0x103fa <+10>: strr1, [sp]
0x103fc <+12>: addsp, #0x8
0x103fe <+14>: bx lr
```
In both cases resolved address is 0x103f6 that is right according to the debug
information:
```
Line Number Statements:
[0x0025] Extended opcode 2: set Address to 0x103f0
[0x002c] Special opcode 6: advance Address by 0 to 0x103f0 and Line by 1
to 2
[0x002d] Set column to 10
[0x002f] Set prologue_end to true
[0x0030] Special opcode 90: advance Address by 6 to 0x103f6 and Line by
1 to 3
```
But lldb uses arm breakpoint in the first case and thumb one in the second.
https://reviews.llvm.org/D44998
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D44998: ObjectFileELF: Add support for arbitrarily named code sections
labath accepted this revision. labath added a comment. I see, thanks for explaining that. https://reviews.llvm.org/D44998 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [lldb] r328990 - Added a BSD archive tool.
> On Apr 2, 2018, at 10:27 AM, Davide Italiano wrote: > > Now with the correct e-mail. > How is this different from llvm-objdump or llvm-readobj? It was originally created for parsing .a files and getting the mod date as a hex number from the BSD object info. I needed a tool that could verify a debug map that used .a files. There are build scenarios where people are seeing LLDB not load .o files from .a files and they don't know why. This installs an LLDB command that can be used to verify all of the .o files in a debug map and reports if they are all ok, or if any are out date, missing, wrong in the .a file, missing from the .a file, etc. You can't use llvm-objdump or llvm-readobj for this task. It can also extract individual .o files from a .a file. It can also find a symbol in the __.SYMDEF to tell you which .a file contains a symbol by name. > (also you might want to update your commit e-mail as reply-to seems to > still be set to your @apple address and bounces back). > > Thanks, > > -- > Davide > > On Mon, Apr 2, 2018 at 10:25 AM, Davide Italiano > wrote: >> On Mon, Apr 2, 2018 at 10:20 AM, Greg Clayton via lldb-commits >> wrote: >>> Author: gclayton >>> Date: Mon Apr 2 10:20:21 2018 >>> New Revision: 328990 >>> >>> URL: http://llvm.org/viewvc/llvm-project?rev=328990&view=rev >>> Log: >>> Added a BSD archive tool. >>> >>> This is a combination stand alone BSD archive tool that can dump BSD >>> archives: >>> >> >> How is this different from llvm-objdump or llvm-readobj? ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [lldb] r328990 - Added a BSD archive tool.
On Tue, Apr 3, 2018 at 7:24 AM, Greg Clayton wrote: > > >> On Apr 2, 2018, at 10:27 AM, Davide Italiano wrote: >> >> Now with the correct e-mail. >> How is this different from llvm-objdump or llvm-readobj? > > It was originally created for parsing .a files and getting the mod date as a > hex number from the BSD object info. I needed a tool that could verify a > debug map that used .a files. There are build scenarios where people are > seeing LLDB not load .o files from .a files and they don't know why. This > installs an LLDB command that can be used to verify all of the .o files in a > debug map and reports if they are all ok, or if any are out date, missing, > wrong in the .a file, missing from the .a file, etc. You can't use > llvm-objdump or llvm-readobj for this task. > I see, I would've built that on top of lib/Archive, but given you wrote the code, I won't complain :) > It can also extract individual .o files from a .a file. > FWIW, A BSD archive can be opened with any archiver you want, including, e.g. Winrar. > It can also find a symbol in the __.SYMDEF to tell you which .a file contains > a symbol by name. > llvm-readobj/llvm-objdump don't implement this just because nobody wanted to, but I don't see why it wouldn't be possible (if we really wanted it). Thanks, -- Davide ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D45215: RFC/WIP: Have lit run the lldb test suite
JDevlieghere created this revision. JDevlieghere added reviewers: davide, labath, aprantl, vsk, jasonmolenda, jingham, friss. Herald added a subscriber: llvm-commits. With `lldb-dotest` checked in, this is the next step in allowing us to run the LLDB test suite with lit. I've converted a single test to give an idea of what I have in mind. My goal is for this to live next to lldb-dotest until we're convinced that this is the way to go, at which point we can start moving functionality from dotest to lit. For example, with the current approach when a test is not supported it will show up as `PASS` in lit because dotest returned exit code 0. Repository: rL LLVM https://reviews.llvm.org/D45215 Files: lit/TestSuite packages/Python/lldbsuite/test/lit.local.cfg packages/Python/lldbsuite/test/warnings/uuid/TestAddDsymCommand.test Index: packages/Python/lldbsuite/test/warnings/uuid/TestAddDsymCommand.test === --- /dev/null +++ packages/Python/lldbsuite/test/warnings/uuid/TestAddDsymCommand.test @@ -0,0 +1 @@ +RUN: lldb-dotest %S Index: packages/Python/lldbsuite/test/lit.local.cfg === --- /dev/null +++ packages/Python/lldbsuite/test/lit.local.cfg @@ -0,0 +1 @@ +config.suffixes = ['.test'] Index: lit/TestSuite === --- /dev/null +++ lit/TestSuite @@ -0,0 +1 @@ +../packages/Python/lldbsuite/test/ \ No newline at end of file Index: packages/Python/lldbsuite/test/warnings/uuid/TestAddDsymCommand.test === --- /dev/null +++ packages/Python/lldbsuite/test/warnings/uuid/TestAddDsymCommand.test @@ -0,0 +1 @@ +RUN: lldb-dotest %S Index: packages/Python/lldbsuite/test/lit.local.cfg === --- /dev/null +++ packages/Python/lldbsuite/test/lit.local.cfg @@ -0,0 +1 @@ +config.suffixes = ['.test'] Index: lit/TestSuite === --- /dev/null +++ lit/TestSuite @@ -0,0 +1 @@ +../packages/Python/lldbsuite/test/ \ No newline at end of file ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D45215: RFC/WIP: Have lit run the lldb test suite
JDevlieghere added a comment. In https://reviews.llvm.org/D45215#1055820, @davide wrote: > Can you add another test or two? It's a little complicated to see what's > going on here, but from your description, it makes sense. > I'm not particularly worried right now to distinguish between `UNSUPPORTED` > and `PASS`. In practice, it doesn't matter (at least for the transition > phase). Sure thing, let me update the diff with some more examples! Repository: rL LLVM https://reviews.llvm.org/D45215 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D45215: RFC/WIP: Have lit run the lldb test suite
davide added a comment. Can you add another test or two? It's a little complicated to see what's going on here, but from your description, it makes sense. I'm not particularly worried right now to distinguish between `UNSUPPORTED` and `PASS`. In practice, it doesn't matter (at least for the transition phase). Repository: rL LLVM https://reviews.llvm.org/D45215 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D45215: RFC/WIP: Have lit run the lldb test suite
aprantl added a comment. So this is basically replacing the parallel test-driver functionality of dotest with lit and dotest is only used to invoke one test at a time. This way we (as the LLVM project) can avoid maintaining to test drivers implemented in python. That clearly sounds like the right direction forward! I wonder if there is anything more automatic we could do instead of requiring a .test file in every directory. For example: could we have lit recognize .py files and stick the RUN line into the py files? Repository: rL LLVM https://reviews.llvm.org/D45215 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D45215: RFC/WIP: Have lit run the lldb test suite
JDevlieghere added a comment. In https://reviews.llvm.org/D45215#1055832, @aprantl wrote: > So this is basically replacing the parallel test-driver functionality of > dotest with lit and dotest is only used to invoke one test at a time. This > way we (as the LLVM project) can avoid maintaining to test drivers > implemented in python. That clearly sounds like the right direction forward! > > I wonder if there is anything more automatic we could do instead of requiring > a .test file in every directory. For example: could we have lit recognize .py > files and stick the RUN line into the py files? That's an excellent idea, let me give that a shot! Repository: rL LLVM https://reviews.llvm.org/D45215 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D45215: RFC/WIP: Have lit run the lldb test suite
JDevlieghere updated this revision to Diff 140826. JDevlieghere added a comment. - Add few more examples as per Davide's request. - Add run line to the python file. Because the `.py` suffix is currently specified in the root of the `TestSuite` directory, we end up with a bunch of unresolved tests. One alternative is having a local config in each subdirectory, but that kind of defeats the point of moving the run line into the python files. Either way we'll have to come up with some kind of solution, because not all `.py` files are test cases. LMKWYT! https://reviews.llvm.org/D45215 Files: lit/TestSuite packages/Python/lldbsuite/test/lit.local.cfg packages/Python/lldbsuite/test/source-manager/TestSourceManager.py packages/Python/lldbsuite/test/terminal/TestSTTYBeforeAndAfter.py packages/Python/lldbsuite/test/types/TestFloatTypes.py packages/Python/lldbsuite/test/warnings/uuid/TestAddDsymCommand.py Index: packages/Python/lldbsuite/test/warnings/uuid/TestAddDsymCommand.py === --- packages/Python/lldbsuite/test/warnings/uuid/TestAddDsymCommand.py +++ packages/Python/lldbsuite/test/warnings/uuid/TestAddDsymCommand.py @@ -1,4 +1,8 @@ -"""Test that the 'add-dsym', aka 'target symbols add', command informs the user about success or failure.""" +""" +Test that the 'add-dsym', aka 'target symbols add', command informs the user about success or failure. + +RUN: lldb-dotest %S -p AddDsymCommand +""" from __future__ import print_function Index: packages/Python/lldbsuite/test/types/TestFloatTypes.py === --- packages/Python/lldbsuite/test/types/TestFloatTypes.py +++ packages/Python/lldbsuite/test/types/TestFloatTypes.py @@ -1,5 +1,7 @@ """ Test that variables of floating point types are displayed correctly. + +RUN: lldb-dotest %S -p TestFloatTypes """ from __future__ import print_function Index: packages/Python/lldbsuite/test/terminal/TestSTTYBeforeAndAfter.py === --- packages/Python/lldbsuite/test/terminal/TestSTTYBeforeAndAfter.py +++ packages/Python/lldbsuite/test/terminal/TestSTTYBeforeAndAfter.py @@ -1,5 +1,7 @@ """ Test that 'stty -a' displays the same output before and after running the lldb command. + +RUN: lldb-dotest %S -p TestSTTYBeforeAndAfter """ from __future__ import print_function Index: packages/Python/lldbsuite/test/source-manager/TestSourceManager.py === --- packages/Python/lldbsuite/test/source-manager/TestSourceManager.py +++ packages/Python/lldbsuite/test/source-manager/TestSourceManager.py @@ -7,6 +7,8 @@ Test display of source using the SBSourceManager API. o test_modify_source_file_while_debugging: Test the caching mechanism of the source manager. + +RUN: lldb-dotest %S -p TestSourceManager """ from __future__ import print_function Index: packages/Python/lldbsuite/test/lit.local.cfg === --- /dev/null +++ packages/Python/lldbsuite/test/lit.local.cfg @@ -0,0 +1 @@ +config.suffixes = ['.py'] Index: lit/TestSuite === --- /dev/null +++ lit/TestSuite @@ -0,0 +1 @@ +../packages/Python/lldbsuite/test/ \ No newline at end of file Index: packages/Python/lldbsuite/test/warnings/uuid/TestAddDsymCommand.py === --- packages/Python/lldbsuite/test/warnings/uuid/TestAddDsymCommand.py +++ packages/Python/lldbsuite/test/warnings/uuid/TestAddDsymCommand.py @@ -1,4 +1,8 @@ -"""Test that the 'add-dsym', aka 'target symbols add', command informs the user about success or failure.""" +""" +Test that the 'add-dsym', aka 'target symbols add', command informs the user about success or failure. + +RUN: lldb-dotest %S -p AddDsymCommand +""" from __future__ import print_function Index: packages/Python/lldbsuite/test/types/TestFloatTypes.py === --- packages/Python/lldbsuite/test/types/TestFloatTypes.py +++ packages/Python/lldbsuite/test/types/TestFloatTypes.py @@ -1,5 +1,7 @@ """ Test that variables of floating point types are displayed correctly. + +RUN: lldb-dotest %S -p TestFloatTypes """ from __future__ import print_function Index: packages/Python/lldbsuite/test/terminal/TestSTTYBeforeAndAfter.py === --- packages/Python/lldbsuite/test/terminal/TestSTTYBeforeAndAfter.py +++ packages/Python/lldbsuite/test/terminal/TestSTTYBeforeAndAfter.py @@ -1,5 +1,7 @@ """ Test that 'stty -a' displays the same output before and after running the lldb command. + +RUN: lldb-dotest %S -p TestSTTYBeforeAndAfter """ from __future__ import print_function Index: packages/Python/lldbsuite/test/source-manager/Te
[Lldb-commits] [PATCH] D45224: [SymbolFilePDB] Add support for resolving variable symbols
asmith created this revision.
asmith added reviewers: rnk, zturner, lldb-commits.
Herald added subscribers: llvm-commits, JDevlieghere, aprantl.
Implement FindGlobalVariables and ParseVariableContext methods.
Compile unit information is necessary for resolving variable context, however
some PDB symbols do not have this information. For now an empty DWARFExpression
is used to construct a lldb::Variable instance with the limitation that using
lldb to lookup the value of a global or local variable is not available.
This commit may slow down lit/SymbolFile/PDB/compilands.test since the test
includes MS specific modules that spend more time parsing variables.
Repository:
rL LLVM
https://reviews.llvm.org/D45224
Files:
lit/SymbolFile/PDB/Inputs/VariablesTest.cpp
lit/SymbolFile/PDB/variables.test
source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
source/Plugins/SymbolFile/PDB/SymbolFilePDB.h
Index: source/Plugins/SymbolFile/PDB/SymbolFilePDB.h
===
--- source/Plugins/SymbolFile/PDB/SymbolFilePDB.h
+++ source/Plugins/SymbolFile/PDB/SymbolFilePDB.h
@@ -12,6 +12,7 @@
#include "lldb/Core/UniqueCStringMap.h"
#include "lldb/Symbol/SymbolFile.h"
+#include "lldb/Symbol/VariableList.h"
#include "lldb/Utility/UserID.h"
#include "llvm/ADT/DenseMap.h"
@@ -181,6 +182,16 @@
void FindTypesByName(const std::string &name, uint32_t max_matches,
lldb_private::TypeMap &types);
+ std::string GetMangledForPDBData(const llvm::pdb::PDBSymbolData &pdb_data);
+
+ lldb::VariableSP
+ ParseVariableForPDBData(const lldb_private::SymbolContext &sc,
+ const llvm::pdb::PDBSymbolData &pdb_data);
+
+ size_t ParseVariables(const lldb_private::SymbolContext &sc,
+const llvm::pdb::PDBSymbol &pdb_data,
+lldb_private::VariableList *variable_list = nullptr);
+
lldb::CompUnitSP
GetCompileUnitContainsAddress(const lldb_private::Address &so_addr);
@@ -217,6 +228,7 @@
llvm::DenseMap m_comp_units;
llvm::DenseMap m_types;
+ llvm::DenseMap m_variables;
std::vector m_builtin_types;
std::unique_ptr m_session_up;
Index: source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
===
--- source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
+++ source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
@@ -21,6 +21,7 @@
#include "lldb/Symbol/SymbolVendor.h"
#include "lldb/Symbol/TypeList.h"
#include "lldb/Symbol/TypeMap.h"
+#include "lldb/Symbol/Variable.h"
#include "lldb/Utility/RegularExpression.h"
#include "llvm/DebugInfo/PDB/GenericError.h"
@@ -483,8 +484,51 @@
size_t
SymbolFilePDB::ParseVariablesForContext(const lldb_private::SymbolContext &sc) {
- // TODO: Implement this
- return size_t();
+ if (!sc.comp_unit)
+return 0;
+
+ size_t num_added = 0;
+ if (sc.function) {
+auto pdb_func = m_session_up->getConcreteSymbolById(
+sc.function->GetID());
+if (!pdb_func)
+ return 0;
+
+num_added += ParseVariables(sc, *pdb_func);
+sc.function->GetBlock(false).SetDidParseVariables(true, true);
+ } else if (sc.comp_unit) {
+auto compiland = GetPDBCompilandByUID(sc.comp_unit->GetID());
+if (!compiland)
+ return 0;
+
+if (sc.comp_unit->GetVariableList(false))
+ return 0;
+
+auto results = m_global_scope_up->findAllChildren();
+if (results && results->getChildCount()) {
+ while (auto result = results->getNext()) {
+auto cu_id = result->getCompilandId();
+// FIXME: We are not able to determine variable's compile unit.
+if (cu_id == 0)
+ continue;
+
+if (cu_id == sc.comp_unit->GetID())
+ num_added += ParseVariables(sc, *result);
+ }
+}
+
+// FIXME: A `file static` or `global constant` variable appears both in
+// compiland's children and global scope's children with unexpectedly
+// different symbol's Id making it ambiguous.
+
+// FIXME: 'local constant', for example, const char var[] = "abc", declared
+// in a function scope, can't be found in PDB.
+
+// Parse variables in this compiland.
+num_added += ParseVariables(sc, *compiland);
+ }
+
+ return num_added;
}
lldb_private::Type *SymbolFilePDB::ResolveTypeUID(lldb::user_id_t type_uid) {
@@ -713,18 +757,270 @@
return sc_list.GetSize() - old_size;
}
+std::string SymbolFilePDB::GetMangledForPDBData(const PDBSymbolData &pdb_data) {
+ std::string decorated_name;
+ auto vm_addr = pdb_data.getVirtualAddress();
+ if (vm_addr != LLDB_INVALID_ADDRESS && vm_addr) {
+auto result_up =
+m_global_scope_up->findAllChildren(PDB_SymType::PublicSymbol);
+if (result_up) {
+ while (auto symbol_up = result_up->getNext()) {
+if (symbol_up->getRawSymbol().getVirtualAddress() == vm_addr) {
+ decorated_name = symbol_up->getRawSymbol().getName();
+ break;
+}
+
[Lldb-commits] [PATCH] D45215: RFC/WIP: Have lit run the lldb test suite
labath added a comment. I don't think this is going in a good direction TBH. You are building another layer on top of everything, whereas I think we should be cutting layers out. Besides the issues already pointed out (not being able to differentiate PASS/XFAIL/SKIP, not all .py files being test files), I see one more problem: a single file does not contain a single test -- some of our test files have dozens of tests, and this would bunch them together. I think the solution here is to invent a new lit test format, instead of trying to fit our very square tests into the round ShTest boxes. Of the existing test formats, I think that actually the googletest format is closest to what we need here, and that's because it supports the notion of a "test" being different from a "file" -- gtest executables typically contain dozens if not hundreds of test, and yet googletest format is able to recognize each one individually. The only difference is that instead of running something like "my_google_test_exec --gtest_list_all_tests" you would use some python introspection to figure out the list of tests within a file. Besides this, having our own test format would allow us to resolve the other problems of this approach as well: - since it's the test format who determines the result of the test, it would be trivial to come up with some sort of a protocol (or reusing an existing one) to notify lit of the full range of test results (pass, fail, xfail, unsupported) - the test format could know that a "test file" is everything ending in ".py" **and** starting with Test (which is exactly the rules that we follow now), so no special or new conventions would be needed. - it would give us full isolation between individual test methods in a file, while still having the convenience of being able to factor out common code into utility functions I know this is a bit more up-front work, but I think this will result in a much nicer final product, and will allow us to remove a lot more code more easily (maybe even all of unittest2 eventually). (I apologise for the rashness of my response, I can go into this in more detail tomorrow). https://reviews.llvm.org/D45215 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
