[Lldb-commits] LLGS for Free/NetBSD (was: Re: [PATCH] D25756: FreeBSD ARM support for software single step.)
Moving the discussion to lldb-dev. On 21 October 2016 at 18:55, Dmitry Mikulin wrote: > Thanks Pavel! I'll start working on it. Do you know when lldb-server Linux > changes were committed? I want to use those patches as a template, but it's > hard to locate them digging through thousands of commit log entries... The original remote debug support for linux came as a long series of patches in February 2015, between r227909 and r227933. However, it has gone through quite a bit of rewrite since then, so I'd be wary of using it as an inspiration. I think you'd be better off using the current state of the linux support instead. You can also find r240543 interesting as well, which removes the old local debug path. That can be useful to figure out how to setup lldb to launch lldb-server for debugging (generally, it boils down to returning "true" from PlatformXXX::CanDebugProcess()). On 21 October 2016 at 20:12, Kamil Rytarowski wrote: > krytarowski added a comment. > > I just scrolled the discussion so it's not really started. Thanks. > > My plan is to work on ptrace(2) for about a month. > > Then I will take the FreeBSD code as it is and port to NetBSD trying to make > it functional. This is difficult part as there is everywhere OS specific > interfaces and behavior. I hope to get it to some usable point after a month. > > Then ,I will start working on remote debugging, as my previous patch for > process tracing (it was buggy) was rejected without this property. I planned > to merge my previous work with master as I was forced to keep catching up > after the project changes and it was time expensive, and move my focus on > proper platform support. It's not my place to tell you how to work, but I'd recommend a different approach to this. If you base your work on the current FreeBSD in-process plugin, then when you get around to actually implementing remote support, you will find that you will have to rewrite most of what you have already done to work with lldb-server, as it uses completely different class hierarchies and everything. I'd recommend starting with lldb-server right away. It's going to be a bit more work as (I assume) freebsd implementation is closer to what you need than linux, but I think it will save you time in the long run. I can help you with factoring out any linux-specific code that you encounter. cheers, pl ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D25905: Minidump plugin: Adding ProcessMinidump, ThreadMinidump and register the plugin in SystemInitializerFull
dvlahovski created this revision.
dvlahovski added reviewers: labath, zturner.
dvlahovski added subscribers: amccarth, lldb-commits.
Herald added subscribers: modocache, mgorny, beanz.
This plugin resembles the already existing Windows-only Minidump plugin.
The WinMinidumpPlugin uses the Windows API for parsing Minidumps
while this plugin is cross-platform because it includes a Minidump
parser (which is already commited)
It is able to produce a backtrace, to read the general puprose regiters,
inspect local variables, show image list, do memory reads, etc.
For now the only arches that this supports are x86_32 and x86_64.
This is because I have only written register contexts for those.
Others will come in next CLs.
I copied the WinMinidump tests and adapted them a little bit for them to
work with the new plugin (and they pass)
I will add more tests, aiming for better code coverage.
There is still functionality to be added, see TODOs in code.
https://reviews.llvm.org/D25905
Files:
packages/Python/lldbsuite/test/functionalities/postmortem/minidump-new/TestMiniDumpNew.py
packages/Python/lldbsuite/test/functionalities/postmortem/minidump-new/install_breakpad.cpp
packages/Python/lldbsuite/test/functionalities/postmortem/minidump-new/linux-x86_64
packages/Python/lldbsuite/test/functionalities/postmortem/minidump-new/linux-x86_64.cpp
packages/Python/lldbsuite/test/functionalities/postmortem/minidump-new/linux-x86_64.dmp
packages/Python/lldbsuite/test/functionalities/postmortem/minidump-new/linux-x86_64_not_crashed
packages/Python/lldbsuite/test/functionalities/postmortem/minidump-new/linux-x86_64_not_crashed.cpp
packages/Python/lldbsuite/test/functionalities/postmortem/minidump-new/linux-x86_64_not_crashed.dmp
packages/Python/lldbsuite/test/functionalities/postmortem/minidump-new/makefile.txt
source/API/SystemInitializerFull.cpp
source/Plugins/Process/minidump/CMakeLists.txt
source/Plugins/Process/minidump/MinidumpParser.cpp
source/Plugins/Process/minidump/MinidumpParser.h
source/Plugins/Process/minidump/MinidumpTypes.h
source/Plugins/Process/minidump/NtStructures.h
source/Plugins/Process/minidump/ProcessMinidump.cpp
source/Plugins/Process/minidump/ProcessMinidump.h
source/Plugins/Process/minidump/ThreadMinidump.cpp
source/Plugins/Process/minidump/ThreadMinidump.h
unittests/Process/minidump/MinidumpParserTest.cpp
Index: unittests/Process/minidump/MinidumpParserTest.cpp
===
--- unittests/Process/minidump/MinidumpParserTest.cpp
+++ unittests/Process/minidump/MinidumpParserTest.cpp
@@ -134,7 +134,7 @@
llvm::Optional name =
parser->GetMinidumpString(modules[i].module_name_rva);
ASSERT_TRUE(name.hasValue());
-ASSERT_EQ(module_names[i], name.getValue());
+EXPECT_EQ(module_names[i], name.getValue());
}
}
@@ -275,8 +275,46 @@
ASSERT_EQ(4440UL, pid.getValue());
}
-// Register stuff
-// TODO probably split register stuff tests into different file?
+// wow64
+TEST_F(MinidumpParserTest, GetPidWow64) {
+ SetUpData("fizzbuzz_wow64.dmp");
+ llvm::Optional pid = parser->GetPid();
+ ASSERT_TRUE(pid.hasValue());
+ ASSERT_EQ(7836UL, pid.getValue());
+}
+
+TEST_F(MinidumpParserTest, GetModuleListWow64) {
+ SetUpData("fizzbuzz_wow64.dmp");
+ llvm::ArrayRef modules = parser->GetModuleList();
+ ASSERT_EQ(16UL, modules.size());
+ std::string module_names[16] = {
+ "D:"
+ "\\src\\llvm\\llvm\\tools\\lldb\\packages\\Python\\lldbsuite\\test\\funct"
+ "ionalities\\postmortem\\wow64_minidump\\fizzbuzz.exe",
+ "C:\\Windows\\System32\\ntdll.dll", "C:\\Windows\\System32\\wow64.dll",
+ "C:\\Windows\\System32\\wow64win.dll",
+ "C:\\Windows\\System32\\wow64cpu.dll",
+ "D:"
+ "\\src\\llvm\\llvm\\tools\\lldb\\packages\\Python\\lldbsuite\\test\\funct"
+ "ionalities\\postmortem\\wow64_minidump\\fizzbuzz.exe",
+ "C:\\Windows\\SysWOW64\\ntdll.dll", "C:\\Windows\\SysWOW64\\kernel32.dll",
+ "C:\\Windows\\SysWOW64\\KERNELBASE.dll",
+ "C:\\Windows\\SysWOW64\\advapi32.dll",
+ "C:\\Windows\\SysWOW64\\msvcrt.dll", "C:\\Windows\\SysWOW64\\sechost.dll",
+ "C:\\Windows\\SysWOW64\\rpcrt4.dll", "C:\\Windows\\SysWOW64\\sspicli.dll",
+ "C:\\Windows\\SysWOW64\\CRYPTBASE.dll",
+ "C:\\Windows\\System32\\api-ms-win-core-synch-l1-2-0.DLL",
+ };
+
+ for (int i = 0; i < 16; ++i) {
+llvm::Optional name =
+parser->GetMinidumpString(modules[i].module_name_rva);
+ASSERT_TRUE(name.hasValue());
+EXPECT_EQ(module_names[i], name.getValue());
+ }
+}
+
+// Register tests
#define REG_VAL32(x) *(reinterpret_cast(x))
#define REG_VAL64(x) *(reinterpret_cast(x))
@@ -371,3 +409,45 @@
}
}
}
+
+TEST_F(MinidumpParserTest, ConvertMinidumpContext_x86_32_WithRegIface_wow64) {
+ SetUpData("fizzbuzz_wow64.dmp");
+ llvm::ArrayRef thread_list = parser->GetThreads();
+ const MinidumpThread thread = thread_list[0];
+ llv
[Lldb-commits] [lldb] r284970 - Add the new arm64 sub-register definitions to NativeRegisterContextLinux
Author: labath
Date: Mon Oct 24 07:59:20 2016
New Revision: 284970
URL: http://llvm.org/viewvc/llvm-project?rev=284970&view=rev
Log:
Add the new arm64 sub-register definitions to NativeRegisterContextLinux
It's quite sad that we have to edit so many files just to add a register. I am
going to investigate how to merge these definitions somehow, but for now this
should at least get arm64 linux working again.
Modified:
lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
lldb/trunk/source/Plugins/Process/Utility/RegisterContextPOSIX_arm64.cpp
lldb/trunk/source/Plugins/Process/Utility/lldb-arm64-register-enums.h
Modified:
lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp?rev=284970&r1=284969&r2=284970&view=diff
==
---
lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
(original)
+++
lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
Mon Oct 24 07:59:20 2016
@@ -52,7 +52,14 @@ static const uint32_t g_gpr_regnums_arm6
gpr_x20_arm64, gpr_x21_arm64, gpr_x22_arm64, gpr_x23_arm64,
gpr_x24_arm64, gpr_x25_arm64, gpr_x26_arm64, gpr_x27_arm64,
gpr_x28_arm64, gpr_fp_arm64, gpr_lr_arm64, gpr_sp_arm64,
-gpr_pc_arm64, gpr_cpsr_arm64,
+gpr_pc_arm64, gpr_cpsr_arm64, gpr_w0_arm64, gpr_w1_arm64,
+gpr_w2_arm64, gpr_w3_arm64, gpr_w4_arm64, gpr_w5_arm64,
+gpr_w6_arm64, gpr_w7_arm64, gpr_w8_arm64, gpr_w9_arm64,
+gpr_w10_arm64, gpr_w11_arm64, gpr_w12_arm64, gpr_w13_arm64,
+gpr_w14_arm64, gpr_w15_arm64, gpr_w16_arm64, gpr_w17_arm64,
+gpr_w18_arm64, gpr_w19_arm64, gpr_w20_arm64, gpr_w21_arm64,
+gpr_w22_arm64, gpr_w23_arm64, gpr_w24_arm64, gpr_w25_arm64,
+gpr_w26_arm64, gpr_w27_arm64, gpr_w28_arm64,
LLDB_INVALID_REGNUM // register sets need to end with this flag
};
static_assert(((sizeof g_gpr_regnums_arm64 / sizeof g_gpr_regnums_arm64[0]) -
@@ -69,6 +76,23 @@ static const uint32_t g_fpu_regnums_arm6
fpu_v20_arm64, fpu_v21_arm64, fpu_v22_arm64, fpu_v23_arm64,
fpu_v24_arm64, fpu_v25_arm64, fpu_v26_arm64, fpu_v27_arm64,
fpu_v28_arm64, fpu_v29_arm64, fpu_v30_arm64, fpu_v31_arm64,
+fpu_s0_arm64, fpu_s1_arm64, fpu_s2_arm64, fpu_s3_arm64,
+fpu_s4_arm64, fpu_s5_arm64, fpu_s6_arm64, fpu_s7_arm64,
+fpu_s8_arm64, fpu_s9_arm64, fpu_s10_arm64, fpu_s11_arm64,
+fpu_s12_arm64, fpu_s13_arm64, fpu_s14_arm64, fpu_s15_arm64,
+fpu_s16_arm64, fpu_s17_arm64, fpu_s18_arm64, fpu_s19_arm64,
+fpu_s20_arm64, fpu_s21_arm64, fpu_s22_arm64, fpu_s23_arm64,
+fpu_s24_arm64, fpu_s25_arm64, fpu_s26_arm64, fpu_s27_arm64,
+fpu_s28_arm64, fpu_s29_arm64, fpu_s30_arm64, fpu_s31_arm64,
+
+fpu_d0_arm64, fpu_d1_arm64, fpu_d2_arm64, fpu_d3_arm64,
+fpu_d4_arm64, fpu_d5_arm64, fpu_d6_arm64, fpu_d7_arm64,
+fpu_d8_arm64, fpu_d9_arm64, fpu_d10_arm64, fpu_d11_arm64,
+fpu_d12_arm64, fpu_d13_arm64, fpu_d14_arm64, fpu_d15_arm64,
+fpu_d16_arm64, fpu_d17_arm64, fpu_d18_arm64, fpu_d19_arm64,
+fpu_d20_arm64, fpu_d21_arm64, fpu_d22_arm64, fpu_d23_arm64,
+fpu_d24_arm64, fpu_d25_arm64, fpu_d26_arm64, fpu_d27_arm64,
+fpu_d28_arm64, fpu_d29_arm64, fpu_d30_arm64, fpu_d31_arm64,
fpu_fpsr_arm64, fpu_fpcr_arm64,
LLDB_INVALID_REGNUM // register sets need to end with this flag
};
Modified:
lldb/trunk/source/Plugins/Process/Utility/RegisterContextPOSIX_arm64.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/Utility/RegisterContextPOSIX_arm64.cpp?rev=284970&r1=284969&r2=284970&view=diff
==
--- lldb/trunk/source/Plugins/Process/Utility/RegisterContextPOSIX_arm64.cpp
(original)
+++ lldb/trunk/source/Plugins/Process/Utility/RegisterContextPOSIX_arm64.cpp
Mon Oct 24 07:59:20 2016
@@ -36,7 +36,14 @@ const uint32_t g_gpr_regnums_arm64[] = {
gpr_x20_arm64, gpr_x21_arm64, gpr_x22_arm64, gpr_x23_arm64,
gpr_x24_arm64, gpr_x25_arm64, gpr_x26_arm64, gpr_x27_arm64,
gpr_x28_arm64, gpr_fp_arm64, gpr_lr_arm64, gpr_sp_arm64,
-gpr_pc_arm64, gpr_cpsr_arm64,
+gpr_pc_arm64, gpr_cpsr_arm64, gpr_w0_arm64, gpr_w1_arm64,
+gpr_w2_arm64, gpr_w3_arm64, gpr_w4_arm64, gpr_w5_arm64,
+gpr_w6_arm64, gpr_w7_arm64, gpr_w8_arm64, gpr_w9_arm64,
+gpr_w10_arm64, gpr_w11_arm64, gpr_w12_arm64, gpr_w13_arm64,
+gpr_w14_arm64, gpr_w15_arm64, gpr_w16_arm64, gpr_w17_arm64,
+gpr_w18_arm64, gpr_w19_arm64, gpr_w20_arm64, gpr_w21_arm64,
+gpr_w22_arm64, gpr_w
[Lldb-commits] [lldb] r284976 - Reformat RegisterInfos_arm64 into a table. NFC
Author: labath
Date: Mon Oct 24 09:01:52 2016
New Revision: 284976
URL: http://llvm.org/viewvc/llvm-project?rev=284976&view=rev
Log:
Reformat RegisterInfos_arm64 into a table. NFC
Modified:
lldb/trunk/source/Plugins/Process/Utility/RegisterInfos_arm64.h
Modified: lldb/trunk/source/Plugins/Process/Utility/RegisterInfos_arm64.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/Utility/RegisterInfos_arm64.h?rev=284976&r1=284975&r2=284976&view=diff
==
--- lldb/trunk/source/Plugins/Process/Utility/RegisterInfos_arm64.h (original)
+++ lldb/trunk/source/Plugins/Process/Utility/RegisterInfos_arm64.h Mon Oct 24
09:01:52 2016
@@ -462,1991 +462,187 @@ static uint32_t g_d30_invalidates[] = {f
static uint32_t g_d31_invalidates[] = {fpu_v31, fpu_s31, LLDB_INVALID_REGNUM};
static lldb_private::RegisterInfo g_register_infos_arm64_le[] = {
-// General purpose registers
-// NAMEALT SZ OFFSET ENCODING
-// FORMAT EH_FRAME DWARF
-// GENERIC PROCESS PLUGIN LLDB NATIVE VALUE
-// REGSINVALIDATE REGS
-// == === == = =
-// === ===
-// = = =
-// =====
-{"x0",
- nullptr,
- 8,
- GPR_OFFSET(0),
- lldb::eEncodingUint,
- lldb::eFormatHex,
- {arm64_ehframe::x0, arm64_dwarf::x0, LLDB_REGNUM_GENERIC_ARG1,
- LLDB_INVALID_REGNUM, gpr_x0},
- g_x0_contains,
- nullptr,
- nullptr,
- 0},
-{"x1",
- nullptr,
- 8,
- GPR_OFFSET(1),
- lldb::eEncodingUint,
- lldb::eFormatHex,
- {arm64_ehframe::x1, arm64_dwarf::x1, LLDB_REGNUM_GENERIC_ARG2,
- LLDB_INVALID_REGNUM, gpr_x1},
- g_x1_contains,
- nullptr,
- nullptr,
- 0},
-{"x2",
- nullptr,
- 8,
- GPR_OFFSET(2),
- lldb::eEncodingUint,
- lldb::eFormatHex,
- {arm64_ehframe::x2, arm64_dwarf::x2, LLDB_REGNUM_GENERIC_ARG3,
- LLDB_INVALID_REGNUM, gpr_x2},
- g_x2_contains,
- nullptr,
- nullptr,
- 0},
-{"x3",
- nullptr,
- 8,
- GPR_OFFSET(3),
- lldb::eEncodingUint,
- lldb::eFormatHex,
- {arm64_ehframe::x3, arm64_dwarf::x3, LLDB_REGNUM_GENERIC_ARG4,
- LLDB_INVALID_REGNUM, gpr_x3},
- g_x3_contains,
- nullptr,
- nullptr,
- 0},
-{"x4",
- nullptr,
- 8,
- GPR_OFFSET(4),
- lldb::eEncodingUint,
- lldb::eFormatHex,
- {arm64_ehframe::x4, arm64_dwarf::x4, LLDB_REGNUM_GENERIC_ARG5,
- LLDB_INVALID_REGNUM, gpr_x4},
- g_x4_contains,
- nullptr,
- nullptr,
- 0},
-{"x5",
- nullptr,
- 8,
- GPR_OFFSET(5),
- lldb::eEncodingUint,
- lldb::eFormatHex,
- {arm64_ehframe::x5, arm64_dwarf::x5, LLDB_REGNUM_GENERIC_ARG6,
- LLDB_INVALID_REGNUM, gpr_x5},
- g_x5_contains,
- nullptr,
- nullptr,
- 0},
-{"x6",
- nullptr,
- 8,
- GPR_OFFSET(6),
- lldb::eEncodingUint,
- lldb::eFormatHex,
- {arm64_ehframe::x6, arm64_dwarf::x6, LLDB_REGNUM_GENERIC_ARG7,
- LLDB_INVALID_REGNUM, gpr_x6},
- g_x6_contains,
- nullptr,
- nullptr,
- 0},
-{"x7",
- nullptr,
- 8,
- GPR_OFFSET(7),
- lldb::eEncodingUint,
- lldb::eFormatHex,
- {arm64_ehframe::x7, arm64_dwarf::x7, LLDB_REGNUM_GENERIC_ARG8,
- LLDB_INVALID_REGNUM, gpr_x7},
- g_x7_contains,
- nullptr,
- nullptr,
- 0},
-{"x8",
- nullptr,
- 8,
- GPR_OFFSET(8),
- lldb::eEncodingUint,
- lldb::eFormatHex,
- {arm64_ehframe::x8, arm64_dwarf::x8, LLDB_INVALID_REGNUM,
- LLDB_INVALID_REGNUM, gpr_x8},
- g_x8_contains,
- nullptr,
- nullptr,
- 0},
-{"x9",
- nullptr,
- 8,
- GPR_OFFSET(9),
- lldb::eEncodingUint,
- lldb::eFormatHex,
- {arm64_ehframe::x9, arm64_dwarf::x9, LLDB_INVALID_REGNUM,
- LLDB_INVALID_REGNUM, gpr_x9},
- g_x9_contains,
- nullptr,
- nullptr,
- 0},
-{"x10",
- nullptr,
- 8,
- GPR_OFFSET(10),
- lldb::eEncodingUint,
- lldb::eFormatHex,
- {arm64_ehframe::x10, arm64_dwarf::x10, LLDB_INVALID_REGNUM,
- LLDB_INVALID_REGNUM, gpr_x10},
- g_x10_contains,
- nullptr,
- nullptr,
- 0},
-{"x11",
- nullptr,
- 8,
- GPR_OFFSET(11),
- lldb::eEncodingUint,
- lldb::eFormatHex,
- {arm64_ehframe::x11, arm64_dwarf::x11, LLDB_INVALID_REGNUM,
- LLDB_INVALID_REGNUM, gpr_x11},
- g_x11_contains,
- nullptr,
- nullptr,
- 0},
-{"x12",
- nullptr,
- 8,
- GPR_OFFSET(12),
- lldb::eEncodingUint,
- lldb::eFormatHex,
- {arm64_ehframe::x12, arm64_dwarf::x12, LLDB_INVALID_REGNUM,
- LLDB_INVALID_REGNUM, gpr_x12},
- g_
[Lldb-commits] [PATCH] D25832: Minidump plugin: Adding x86_32 register context converter
labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.
looks good, minor comments below.
Comment at: source/Plugins/Process/minidump/RegisterContextMinidump_x86_32.h:37
+// This way we can reuse the already existing register contexts
+lldb::DataBufferSP ConvertMinidumpContext_x86_32_WithRegIface(
+llvm::ArrayRef source_data,
You don't need the `WithRegIface` suffix. That's an ObjC style, which we don't
use in LLVM
Comment at: source/Plugins/Process/minidump/RegisterContextMinidump_x86_32.h:52
+ enum {
+RegisteAreaSize = 80,
+ };
typo
Comment at: source/Plugins/Process/minidump/RegisterContextMinidump_x86_32.h:115
+
+// For context_flags. These values indicate the type of
+// context stored in the structure. The high 24 bits identify the CPU, the
This comment doesn't seem to apply to the macro below it.
Comment at: unittests/Process/minidump/MinidumpParserTest.cpp:279
// Register stuff
// TODO probably split register stuff tests into different file?
+#define REG_VAL32(x) *(reinterpret_cast(x))
If you want to split them off to a different file, do it now. If not, remove
the todo. (I don't see a reason for the split btw)
https://reviews.llvm.org/D25832
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D25832: Minidump plugin: Adding x86_32 register context converter
dvlahovski updated this revision to Diff 75578.
dvlahovski marked 3 inline comments as done.
dvlahovski added a comment.
Fixes regarding Pavel's comments
https://reviews.llvm.org/D25832
Files:
source/Plugins/Process/minidump/CMakeLists.txt
source/Plugins/Process/minidump/RegisterContextMinidump_x86_32.cpp
source/Plugins/Process/minidump/RegisterContextMinidump_x86_32.h
source/Plugins/Process/minidump/RegisterContextMinidump_x86_64.cpp
source/Plugins/Process/minidump/RegisterContextMinidump_x86_64.h
unittests/Process/minidump/CMakeLists.txt
unittests/Process/minidump/Inputs/linux-i386.dmp
unittests/Process/minidump/MinidumpParserTest.cpp
Index: unittests/Process/minidump/MinidumpParserTest.cpp
===
--- unittests/Process/minidump/MinidumpParserTest.cpp
+++ unittests/Process/minidump/MinidumpParserTest.cpp
@@ -8,9 +8,11 @@
//===--===//
// Project includes
+#include "Plugins/Process/Utility/RegisterContextLinux_i386.h"
#include "Plugins/Process/Utility/RegisterContextLinux_x86_64.h"
#include "Plugins/Process/minidump/MinidumpParser.h"
#include "Plugins/Process/minidump/MinidumpTypes.h"
+#include "Plugins/Process/minidump/RegisterContextMinidump_x86_32.h"
#include "Plugins/Process/minidump/RegisterContextMinidump_x86_64.h"
// Other libraries and framework includes
@@ -61,7 +63,7 @@
std::unique_ptr parser;
};
-TEST_F(MinidumpParserTest, GetThreads) {
+TEST_F(MinidumpParserTest, GetThreadsAndGetThreadContext) {
SetUpData("linux-x86_64.dmp");
llvm::ArrayRef thread_list;
@@ -275,58 +277,97 @@
// Register stuff
// TODO probably split register stuff tests into different file?
-#define REG_VAL(x) *(reinterpret_cast(x))
+#define REG_VAL32(x) *(reinterpret_cast(x))
+#define REG_VAL64(x) *(reinterpret_cast(x))
-TEST_F(MinidumpParserTest, ConvertRegisterContext) {
+TEST_F(MinidumpParserTest, ConvertMinidumpContext_x86_32) {
+ SetUpData("linux-i386.dmp");
+ llvm::ArrayRef thread_list = parser->GetThreads();
+ const MinidumpThread thread = thread_list[0];
+ llvm::ArrayRef registers(parser->GetThreadContext(thread));
+
+ ArchSpec arch = parser->GetArchitecture();
+ RegisterInfoInterface *reg_interface = new RegisterContextLinux_i386(arch);
+ lldb::DataBufferSP buf =
+ ConvertMinidumpContext_x86_32(registers, reg_interface);
+ ASSERT_EQ(reg_interface->GetGPRSize(), buf->GetByteSize());
+
+ const RegisterInfo *reg_info = reg_interface->GetRegisterInfo();
+
+ std::map reg_values;
+
+ reg_values[lldb_eax_i386] = 0x;
+ reg_values[lldb_ebx_i386] = 0xf7778000;
+ reg_values[lldb_ecx_i386] = 0x0001;
+ reg_values[lldb_edx_i386] = 0xff9dd4a3;
+ reg_values[lldb_edi_i386] = 0x080482a8;
+ reg_values[lldb_esi_i386] = 0xff9dd55c;
+ reg_values[lldb_ebp_i386] = 0xff9dd53c;
+ reg_values[lldb_esp_i386] = 0xff9dd52c;
+ reg_values[lldb_eip_i386] = 0x080482a0;
+ reg_values[lldb_eflags_i386] = 0x00010282;
+ reg_values[lldb_cs_i386] = 0x0023;
+ reg_values[lldb_fs_i386] = 0x;
+ reg_values[lldb_gs_i386] = 0x0063;
+ reg_values[lldb_ss_i386] = 0x002b;
+ reg_values[lldb_ds_i386] = 0x002b;
+ reg_values[lldb_es_i386] = 0x002b;
+
+ for (uint32_t reg_index = 0; reg_index < reg_interface->GetRegisterCount();
+ ++reg_index) {
+if (reg_values.find(reg_index) != reg_values.end()) {
+ EXPECT_EQ(reg_values[reg_index],
+REG_VAL32(buf->GetBytes() + reg_info[reg_index].byte_offset));
+}
+ }
+}
+
+TEST_F(MinidumpParserTest, ConvertMinidumpContext_x86_64) {
SetUpData("linux-x86_64.dmp");
llvm::ArrayRef thread_list = parser->GetThreads();
const MinidumpThread thread = thread_list[0];
- llvm::ArrayRef registers(parser->GetData().data() +
-thread.thread_context.rva,
-thread.thread_context.data_size);
+ llvm::ArrayRef registers(parser->GetThreadContext(thread));
ArchSpec arch = parser->GetArchitecture();
RegisterInfoInterface *reg_interface = new RegisterContextLinux_x86_64(arch);
lldb::DataBufferSP buf =
- ConvertMinidumpContextToRegIface(registers, reg_interface);
+ ConvertMinidumpContext_x86_64(registers, reg_interface);
ASSERT_EQ(reg_interface->GetGPRSize(), buf->GetByteSize());
const RegisterInfo *reg_info = reg_interface->GetRegisterInfo();
std::map reg_values;
- // clang-format off
- reg_values[lldb_rax_x86_64]= 0x;
- reg_values[lldb_rbx_x86_64]= 0x;
- reg_values[lldb_rcx_x86_64]= 0x0010;
- reg_values[lldb_rdx_x86_64]= 0x;
- reg_values[lldb_rdi_x86_64]= 0x7ffceb349cf0;
- reg_values[lldb_rsi_x86_64]= 0x;
- reg_values[lldb_rbp_x86_64]= 0x7ffceb34a210;
- reg_values[lldb_rsp_x86_64]= 0x7ffceb34a210;
- reg_values[lldb_r8_x86_64]
[Lldb-commits] [PATCH] D25832: Minidump plugin: Adding x86_32 register context converter
dvlahovski added inline comments. Comment at: unittests/Process/minidump/MinidumpParserTest.cpp:279 // Register stuff // TODO probably split register stuff tests into different file? +#define REG_VAL32(x) *(reinterpret_cast(x)) labath wrote: > If you want to split them off to a different file, do it now. If not, remove > the todo. (I don't see a reason for the split btw) Yes, I removed the TODO in my next CL. I'll leave the tests here. https://reviews.llvm.org/D25832 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r284981 - Fix arm64 sub-register definitions
Author: labath
Date: Mon Oct 24 09:57:50 2016
New Revision: 284981
URL: http://llvm.org/viewvc/llvm-project?rev=284981&view=rev
Log:
Fix arm64 sub-register definitions
The "value regs" field was filled incorrectly. It is supposed to list the
registers that *this* register is a sub-register of, not the other way around.
This manifested itself in "register read" showing only the smaller sub-registers
(and a bunch of tests not passing). I am not sure if the "invalidates" field is
correct either, but it's usage seems to be inconsistent, so I'll leave that
as-is
for now.
Modified:
lldb/trunk/source/Plugins/Process/Utility/RegisterInfos_arm64.h
Modified: lldb/trunk/source/Plugins/Process/Utility/RegisterInfos_arm64.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/Utility/RegisterInfos_arm64.h?rev=284981&r1=284980&r2=284981&view=diff
==
--- lldb/trunk/source/Plugins/Process/Utility/RegisterInfos_arm64.h (original)
+++ lldb/trunk/source/Plugins/Process/Utility/RegisterInfos_arm64.h Mon Oct 24
09:57:50 2016
@@ -302,35 +302,35 @@ enum {
k_num_registers
};
-static uint32_t g_x0_contains[] = {gpr_w0, LLDB_INVALID_REGNUM};
-static uint32_t g_x1_contains[] = {gpr_w1, LLDB_INVALID_REGNUM};
-static uint32_t g_x2_contains[] = {gpr_w2, LLDB_INVALID_REGNUM};
-static uint32_t g_x3_contains[] = {gpr_w3, LLDB_INVALID_REGNUM};
-static uint32_t g_x4_contains[] = {gpr_w4, LLDB_INVALID_REGNUM};
-static uint32_t g_x5_contains[] = {gpr_w5, LLDB_INVALID_REGNUM};
-static uint32_t g_x6_contains[] = {gpr_w6, LLDB_INVALID_REGNUM};
-static uint32_t g_x7_contains[] = {gpr_w7, LLDB_INVALID_REGNUM};
-static uint32_t g_x8_contains[] = {gpr_w8, LLDB_INVALID_REGNUM};
-static uint32_t g_x9_contains[] = {gpr_w9, LLDB_INVALID_REGNUM};
-static uint32_t g_x10_contains[] = {gpr_w10, LLDB_INVALID_REGNUM};
-static uint32_t g_x11_contains[] = {gpr_w11, LLDB_INVALID_REGNUM};
-static uint32_t g_x12_contains[] = {gpr_w12, LLDB_INVALID_REGNUM};
-static uint32_t g_x13_contains[] = {gpr_w13, LLDB_INVALID_REGNUM};
-static uint32_t g_x14_contains[] = {gpr_w14, LLDB_INVALID_REGNUM};
-static uint32_t g_x15_contains[] = {gpr_w15, LLDB_INVALID_REGNUM};
-static uint32_t g_x16_contains[] = {gpr_w16, LLDB_INVALID_REGNUM};
-static uint32_t g_x17_contains[] = {gpr_w17, LLDB_INVALID_REGNUM};
-static uint32_t g_x18_contains[] = {gpr_w18, LLDB_INVALID_REGNUM};
-static uint32_t g_x19_contains[] = {gpr_w19, LLDB_INVALID_REGNUM};
-static uint32_t g_x20_contains[] = {gpr_w20, LLDB_INVALID_REGNUM};
-static uint32_t g_x21_contains[] = {gpr_w21, LLDB_INVALID_REGNUM};
-static uint32_t g_x22_contains[] = {gpr_w22, LLDB_INVALID_REGNUM};
-static uint32_t g_x23_contains[] = {gpr_w23, LLDB_INVALID_REGNUM};
-static uint32_t g_x24_contains[] = {gpr_w24, LLDB_INVALID_REGNUM};
-static uint32_t g_x25_contains[] = {gpr_w25, LLDB_INVALID_REGNUM};
-static uint32_t g_x26_contains[] = {gpr_w26, LLDB_INVALID_REGNUM};
-static uint32_t g_x27_contains[] = {gpr_w27, LLDB_INVALID_REGNUM};
-static uint32_t g_x28_contains[] = {gpr_w28, LLDB_INVALID_REGNUM};
+static uint32_t g_contained_x0[] = {gpr_x0, LLDB_INVALID_REGNUM};
+static uint32_t g_contained_x1[] = {gpr_x1, LLDB_INVALID_REGNUM};
+static uint32_t g_contained_x2[] = {gpr_x2, LLDB_INVALID_REGNUM};
+static uint32_t g_contained_x3[] = {gpr_x3, LLDB_INVALID_REGNUM};
+static uint32_t g_contained_x4[] = {gpr_x4, LLDB_INVALID_REGNUM};
+static uint32_t g_contained_x5[] = {gpr_x5, LLDB_INVALID_REGNUM};
+static uint32_t g_contained_x6[] = {gpr_x6, LLDB_INVALID_REGNUM};
+static uint32_t g_contained_x7[] = {gpr_x7, LLDB_INVALID_REGNUM};
+static uint32_t g_contained_x8[] = {gpr_x8, LLDB_INVALID_REGNUM};
+static uint32_t g_contained_x9[] = {gpr_x9, LLDB_INVALID_REGNUM};
+static uint32_t g_contained_x10[] = {gpr_x10, LLDB_INVALID_REGNUM};
+static uint32_t g_contained_x11[] = {gpr_x11, LLDB_INVALID_REGNUM};
+static uint32_t g_contained_x12[] = {gpr_x12, LLDB_INVALID_REGNUM};
+static uint32_t g_contained_x13[] = {gpr_x13, LLDB_INVALID_REGNUM};
+static uint32_t g_contained_x14[] = {gpr_x14, LLDB_INVALID_REGNUM};
+static uint32_t g_contained_x15[] = {gpr_x15, LLDB_INVALID_REGNUM};
+static uint32_t g_contained_x16[] = {gpr_x16, LLDB_INVALID_REGNUM};
+static uint32_t g_contained_x17[] = {gpr_x17, LLDB_INVALID_REGNUM};
+static uint32_t g_contained_x18[] = {gpr_x18, LLDB_INVALID_REGNUM};
+static uint32_t g_contained_x19[] = {gpr_x19, LLDB_INVALID_REGNUM};
+static uint32_t g_contained_x20[] = {gpr_x20, LLDB_INVALID_REGNUM};
+static uint32_t g_contained_x21[] = {gpr_x21, LLDB_INVALID_REGNUM};
+static uint32_t g_contained_x22[] = {gpr_x22, LLDB_INVALID_REGNUM};
+static uint32_t g_contained_x23[] = {gpr_x23, LLDB_INVALID_REGNUM};
+static uint32_t g_contained_x24[] = {gpr_x24, LLDB_INVALID_REGNUM};
+static uint32_t g_contained_x25[] = {gpr_x25, LLDB_INVALID_REGNUM};
+static uint32_t g_contained_x26[] = {gpr_x26, LLDB_INVALID_REGNUM};
+static uint32_t g_co
[Lldb-commits] [lldb] r284987 - Use shorter names in TestConcurrentEvents tests
Author: labath Date: Mon Oct 24 11:20:43 2016 New Revision: 284987 URL: http://llvm.org/viewvc/llvm-project?rev=284987&view=rev Log: Use shorter names in TestConcurrentEvents tests Otherwise, they tend to generate filename too long errors. They already contain the same test name in the directory, file, and class names, so no information is really lost here. Modified: lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/breakpoint_delay_breakpoint_one_signal/TestConcurrentBreakpointDelayBreakpointOneSignal.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/breakpoint_one_delay_breakpoint_threads/TestConcurrentBreakpointOneDelayBreakpointThreads.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/breakpoints_delayed_breakpoint_one_watchpoint/TestConcurrentBreakpointsDelayedBreakpointOneWatchpoint.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/crash_with_break/TestConcurrentCrashWithBreak.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/crash_with_signal/TestConcurrentCrashWithSignal.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/crash_with_watchpoint/TestConcurrentCrashWithWatchpoint.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/crash_with_watchpoint_breakpoint_signal/TestConcurrentCrashWithWatchpointBreakpointSignal.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/delay_signal_break/TestConcurrentDelaySignalBreak.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/delay_signal_watch/TestConcurrentDelaySignalWatch.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/delay_watch_break/TestConcurrentDelayWatchBreak.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/delayed_crash_with_breakpoint_signal/TestConcurrentDelayedCrashWithBreakpointSignal.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/delayed_crash_with_breakpoint_watchpoint/TestConcurrentDelayedCrashWithBreakpointWatchpoint.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/many_breakpoints/TestConcurrentManyBreakpoints.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/many_crash/TestConcurrentManyCrash.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/many_signals/TestConcurrentManySignals.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/many_watchpoints/TestConcurrentManyWatchpoints.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/n_watch_n_break/TestConcurrentNWatchNBreak.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/signal_break/TestConcurrentSignalBreak.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/signal_delay_break/TestConcurrentSignalDelayBreak.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/signal_delay_watch/TestConcurrentSignalDelayWatch.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/signal_n_watch_n_break/TestConcurrentSignalNWatchNBreak.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/signal_watch/TestConcurrentSignalWatch.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/signal_watch_break/TestConcurrentSignalWatchBreak.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/two_breakpoint_threads/TestConcurrentTwoBreakpointThreads.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/two_breakpoints_one_delay_signal/TestConcurrentTwoBreakpointsOneDelaySignal.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/two_breakpoints_one_signal/TestConcurrentTwoBreakpointsOneSignal.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/two_breakpoints_one_watchpoint/TestConcurrentTwoBreakpointsOneWatchpoint.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/two_watchpoint_threads/TestConcurrentTwoWatchpointThreads.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/two_watchpoints_one_breakpoint/TestConcurrentTwoWatchpointsOneBreakpoint.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/two_watchpoints_one_delay_breakpoint/TestConcurrentTwoWatchpointsOneDelayBreakpoint.py lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread
[Lldb-commits] [PATCH] D25905: Minidump plugin: Adding ProcessMinidump, ThreadMinidump and register the plugin in SystemInitializerFull
labath added a comment.
first round of comments. I will give this another look tomorrow.
Comment at:
packages/Python/lldbsuite/test/functionalities/postmortem/minidump-new/linux-x86_64_not_crashed.cpp:7
+int
+bar(int x)
+{
Please format these consistently (llvm-style). clang-format will not work by
default as we are still ignoring the test folder.
Comment at: source/Plugins/Process/minidump/NtStructures.h:18
+// only about the position of the tls_slots.
+struct TEB64 {
+ llvm::support::ulittle64_t reserved1[12];
Please put this inside the lldb_private::minidump namespace.
Comment at: source/Plugins/Process/minidump/ProcessMinidump.cpp:73
+
+ return lldb::ProcessSP(new ProcessMinidump(
+ target_sp, listener_sp, *crash_file, minidump_parser.getValue()));
return std::make_shared(...
Comment at: source/Plugins/Process/minidump/ProcessMinidump.cpp:274
+// 64 bit windows
+std::string name_tolower = name.getValue();
+std::transform(name_tolower.begin(), name_tolower.end(),
llvm::StringRef(*name).endswith_lower("wow64.dll")
Comment at: source/Plugins/Process/minidump/ProcessMinidump.cpp:278
+if (name_tolower.find("wow64.dll") != std::string::npos) {
+ m_is_wow64 = true;
+}
There is a hidden assumption here that ReadModuleList() will be called before
any other function that depends on the value of `m_is_wow64`. (I am not even
sure if this is true in case of GetArchitecture().) I think we should make this
more robust. Maybe you could initialize this (along with the filtered_modules
list, I guess) in the constructor? It's not really doing extra work, as you're
going to need to parse the module list at some very early point anyway.
Comment at: unittests/Process/minidump/MinidumpParserTest.cpp:291
+ std::string module_names[16] = {
+ "D:"
+
"\\src\\llvm\\llvm\\tools\\lldb\\packages\\Python\\lldbsuite\\test\\funct"
Did clang-format break this in such an ugly way? What will happen if you use
raw strings instead: `R"(D:\no\double\back\slash)"` ?
https://reviews.llvm.org/D25905
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D25905: Minidump plugin: Adding ProcessMinidump, ThreadMinidump and register the plugin in SystemInitializerFull
dvlahovski updated this revision to Diff 75617.
dvlahovski marked 6 inline comments as done.
dvlahovski added a comment.
Addressed Pavel's comments.
https://reviews.llvm.org/D25905
Files:
packages/Python/lldbsuite/test/functionalities/postmortem/minidump-new/TestMiniDumpNew.py
packages/Python/lldbsuite/test/functionalities/postmortem/minidump-new/install_breakpad.cpp
packages/Python/lldbsuite/test/functionalities/postmortem/minidump-new/linux-x86_64
packages/Python/lldbsuite/test/functionalities/postmortem/minidump-new/linux-x86_64.cpp
packages/Python/lldbsuite/test/functionalities/postmortem/minidump-new/linux-x86_64.dmp
packages/Python/lldbsuite/test/functionalities/postmortem/minidump-new/linux-x86_64_not_crashed
packages/Python/lldbsuite/test/functionalities/postmortem/minidump-new/linux-x86_64_not_crashed.cpp
packages/Python/lldbsuite/test/functionalities/postmortem/minidump-new/linux-x86_64_not_crashed.dmp
packages/Python/lldbsuite/test/functionalities/postmortem/minidump-new/makefile.txt
source/API/SystemInitializerFull.cpp
source/Plugins/Process/minidump/CMakeLists.txt
source/Plugins/Process/minidump/MinidumpParser.cpp
source/Plugins/Process/minidump/MinidumpParser.h
source/Plugins/Process/minidump/MinidumpTypes.h
source/Plugins/Process/minidump/NtStructures.h
source/Plugins/Process/minidump/ProcessMinidump.cpp
source/Plugins/Process/minidump/ProcessMinidump.h
source/Plugins/Process/minidump/RegisterContextMinidump_x86_32.cpp
source/Plugins/Process/minidump/RegisterContextMinidump_x86_32.h
source/Plugins/Process/minidump/RegisterContextMinidump_x86_64.cpp
source/Plugins/Process/minidump/RegisterContextMinidump_x86_64.h
source/Plugins/Process/minidump/ThreadMinidump.cpp
source/Plugins/Process/minidump/ThreadMinidump.h
unittests/Process/minidump/CMakeLists.txt
unittests/Process/minidump/Inputs/linux-i386.dmp
unittests/Process/minidump/MinidumpParserTest.cpp
Index: unittests/Process/minidump/MinidumpParserTest.cpp
===
--- unittests/Process/minidump/MinidumpParserTest.cpp
+++ unittests/Process/minidump/MinidumpParserTest.cpp
@@ -8,9 +8,11 @@
//===--===//
// Project includes
+#include "Plugins/Process/Utility/RegisterContextLinux_i386.h"
#include "Plugins/Process/Utility/RegisterContextLinux_x86_64.h"
#include "Plugins/Process/minidump/MinidumpParser.h"
#include "Plugins/Process/minidump/MinidumpTypes.h"
+#include "Plugins/Process/minidump/RegisterContextMinidump_x86_32.h"
#include "Plugins/Process/minidump/RegisterContextMinidump_x86_64.h"
// Other libraries and framework includes
@@ -61,7 +63,7 @@
std::unique_ptr parser;
};
-TEST_F(MinidumpParserTest, GetThreads) {
+TEST_F(MinidumpParserTest, GetThreadsAndGetThreadContext) {
SetUpData("linux-x86_64.dmp");
llvm::ArrayRef thread_list;
@@ -132,7 +134,7 @@
llvm::Optional name =
parser->GetMinidumpString(modules[i].module_name_rva);
ASSERT_TRUE(name.hasValue());
-ASSERT_EQ(module_names[i], name.getValue());
+EXPECT_EQ(module_names[i], name.getValue());
}
}
@@ -273,60 +275,179 @@
ASSERT_EQ(4440UL, pid.getValue());
}
-// Register stuff
-// TODO probably split register stuff tests into different file?
-#define REG_VAL(x) *(reinterpret_cast(x))
+// wow64
+TEST_F(MinidumpParserTest, GetPidWow64) {
+ SetUpData("fizzbuzz_wow64.dmp");
+ llvm::Optional pid = parser->GetPid();
+ ASSERT_TRUE(pid.hasValue());
+ ASSERT_EQ(7836UL, pid.getValue());
+}
+
+TEST_F(MinidumpParserTest, GetModuleListWow64) {
+ SetUpData("fizzbuzz_wow64.dmp");
+ llvm::ArrayRef modules = parser->GetModuleList();
+ ASSERT_EQ(16UL, modules.size());
+ std::string module_names[16] = {
+ R"(D:\src\llvm\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\postmortem\wow64_minidump\fizzbuzz.exe)",
+ R"(C:\Windows\System32\ntdll.dll)",
+ R"(C:\Windows\System32\wow64.dll)",
+ R"(C:\Windows\System32\wow64win.dll)",
+ R"(C:\Windows\System32\wow64cpu.dll)",
+ R"(D:\src\llvm\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\postmortem\wow64_minidump\fizzbuzz.exe)",
+ R"(C:\Windows\SysWOW64\ntdll.dll)",
+ R"(C:\Windows\SysWOW64\kernel32.dll)",
+ R"(C:\Windows\SysWOW64\KERNELBASE.dll)",
+ R"(C:\Windows\SysWOW64\advapi32.dll)",
+ R"(C:\Windows\SysWOW64\msvcrt.dll)",
+ R"(C:\Windows\SysWOW64\sechost.dll)",
+ R"(C:\Windows\SysWOW64\rpcrt4.dll)",
+ R"(C:\Windows\SysWOW64\sspicli.dll)",
+ R"(C:\Windows\SysWOW64\CRYPTBASE.dll)",
+ R"(C:\Windows\System32\api-ms-win-core-synch-l1-2-0.DLL)",
+ };
+
+ for (int i = 0; i < 16; ++i) {
+llvm::Optional name =
+parser->GetMinidumpString(modules[i].module_name_rva);
+ASSERT_TRUE(name.hasValue());
+EXPECT_EQ(module_names[i], name.getValue());
+ }
+}
+
+// Register tests
+#define REG_VAL32(
Re: [Lldb-commits] LLGS for Free/NetBSD (was: Re: [PATCH] D25756: FreeBSD ARM support for software single step.)
On 24 October 2016 at 06:26, Pavel Labath wrote: > > It's not my place to tell you how to work, but I'd recommend a > different approach to this. If you base your work on the current > FreeBSD in-process plugin, then when you get around to actually > implementing remote support, you will find that you will have to > rewrite most of what you have already done to work with lldb-server, > as it uses completely different class hierarchies and everything. I'd > recommend starting with lldb-server right away. It's going to be a bit > more work as (I assume) freebsd implementation is closer to what you > need than linux, but I think it will save you time in the long run. I > can help you with factoring out any linux-specific code that you > encounter. I definitely second the approach Pavel suggests here, and am happy to work with others on refactoring the Linux lldb-server so that we can get it to support both FreeBSD and NetBSD at the same time. A direct port of the current FreeBSD support probably would result in a basic level of support running sooner, but that work would be largely thrown away in a future migration to lldb-server. ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D25905: Minidump plugin: Adding ProcessMinidump, ThreadMinidump and register the plugin in SystemInitializerFull
dvlahovski added a comment. Please ignore the `RegisterContextMinidump_x86_*` changes. Can't seem to make `arc diff` understand what I want. https://reviews.llvm.org/D25905 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] LLGS for Free/NetBSD (was: Re: [PATCH] D25756: FreeBSD ARM support for software single step.)
On 24.10.2016 20:38, Ed Maste wrote: > On 24 October 2016 at 06:26, Pavel Labath wrote: >> >> It's not my place to tell you how to work, but I'd recommend a >> different approach to this. If you base your work on the current >> FreeBSD in-process plugin, then when you get around to actually >> implementing remote support, you will find that you will have to >> rewrite most of what you have already done to work with lldb-server, >> as it uses completely different class hierarchies and everything. I'd >> recommend starting with lldb-server right away. It's going to be a bit >> more work as (I assume) freebsd implementation is closer to what you >> need than linux, but I think it will save you time in the long run. I >> can help you with factoring out any linux-specific code that you >> encounter. > > I definitely second the approach Pavel suggests here, and am happy to > work with others on refactoring the Linux lldb-server so that we can > get it to support both FreeBSD and NetBSD at the same time. > > A direct port of the current FreeBSD support probably would result in > a basic level of support running sooner, but that work would be > largely thrown away in a future migration to lldb-server. > I will take your recommended path as it will lead to the same goal. I will try to shorten my initial work on ptrace(2) leaving additional features+tests for later and jump to lldb-server as soon as possible. For start, before switching to process plugin stage is to extend NetBSD ptrace(2) with the following features: - PT_LWPINFO extend struct ptrace_lwpinfo with additional fields used in LLDB in the current FreeBSD process code (pl_flags, pl_child_pid, pl_siginfo), - PT_GETNUMLWPS - number of kernel threads associated with the traced process, - PT_GETLWPLIST - get the current thread list, - PT_SUSPEND - suspend the specified thread, - PT_RESUME - resume the specified thread. I need to add basic tests for new ptrace(2) calls in our automated test infrastructure in order to get this code accepted. I will reschedule debug registers and additional ptrace(2) calls for the end, if time will permit. I will also add support in LLDB for handling NetBSD Real-Time signals (SIGRTMIN..SIGRTMAX) as it was already implemented during the latest GSoC for NetBSD (thanks Google!). I might need some guidance from LLDB developers (I prefer via IRC and the dedicated LLDB channel) and maybe proof reading of patches and debugging issues. I consider that the difficult part is not adapting FreBSD or Linux specific implementation for NetBSD, but taking everything to work. My ultimate deadline for the overall LLDB work is February 28th, 2017 - as I'm switching to Swift port for NetBSD *. This work is sponsored by The NetBSD Foundation. If you like it, please consider supporting it by making a donation. * http://blog.netbsd.org/tnf/entry/funded_contract_2016_2017 signature.asc Description: OpenPGP digital signature ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D25922: Test infra: expose CFLAGS_NO_ARCH for use by test custom build rules
tfiala created this revision. tfiala added reviewers: jingham, labath. tfiala added a subscriber: lldb-commits. The TestUniversal.py test was attempting to build its own CFLAGS unreliably. Essentially it just wanted the prevailing CFLAGS without the arch spec. This change does the following: - introduces a new makefile variable CFLAGS_NO_ARCH, which custom build rules can use to grab the prevailing CFLAGS for the build without the arch-specific flags, and - uses this new flag in TestUniversal.py's Makefile, eliminating the divergence it had from the CFLAGS used for standard test inferiors. https://reviews.llvm.org/D25922 Files: Python/lldbsuite/test/macosx/universal/Makefile Python/lldbsuite/test/make/Makefile.rules Index: Python/lldbsuite/test/make/Makefile.rules === --- Python/lldbsuite/test/make/Makefile.rules +++ Python/lldbsuite/test/make/Makefile.rules @@ -193,13 +193,10 @@ DEBUG_INFO_FLAG ?= -g CFLAGS ?= $(DEBUG_INFO_FLAG) -O0 -fno-builtin -ifeq "$(OS)" "Darwin" - CFLAGS += $(ARCHFLAG) $(ARCH) $(FRAMEWORK_INCLUDES) $(CFLAGS_EXTRAS) -I$(LLDB_BASE_DIR)include -else - CFLAGS += $(ARCHFLAG)$(ARCH) $(FRAMEWORK_INCLUDES) $(CFLAGS_EXTRAS) -I$(LLDB_BASE_DIR)include -endif +CFLAGS += $(FRAMEWORK_INCLUDES) $(CFLAGS_EXTRAS) -I$(LLDB_BASE_DIR)include -include $(THIS_FILE_DIR)test_common.h $(TRIPLE_CFLAGS) +CFLAGS_NO_ARCH := $(CFLAGS) -CFLAGS += -include $(THIS_FILE_DIR)test_common.h $(TRIPLE_CFLAGS) +CFLAGS += $(ARCHFLAG)$(ARCH) # Use this one if you want to build one part of the result without debug information: ifeq "$(OS)" "Darwin" Index: Python/lldbsuite/test/macosx/universal/Makefile === --- Python/lldbsuite/test/macosx/universal/Makefile +++ Python/lldbsuite/test/macosx/universal/Makefile @@ -1,5 +1,14 @@ CC ?= clang +all: testit + +LEVEL = ../../make + +C_SOURCES := main.c + +include $(LEVEL)/Makefile.rules + + testit: testit.i386 testit.x86_64 lipo -create -o testit testit.i386 testit.x86_64 @@ -10,10 +19,10 @@ $(CC) -arch x86_64 -o testit.x86_64 testit.x86_64.o testit.i386.o: main.c - $(CC) -g -O0 -arch i386 -c -o testit.i386.o main.c + $(CC) $(CFLAGS_NO_ARCH) -arch i386 -c -o testit.i386.o main.c testit.x86_64.o: main.c - $(CC) -g -O0 -arch x86_64 -c -o testit.x86_64.o main.c + $(CC) $(CFLAGS_NO_ARCH) -arch x86_64 -c -o testit.x86_64.o main.c -clean: +clean:: rm -rf $(wildcard testit* *~) Index: Python/lldbsuite/test/make/Makefile.rules === --- Python/lldbsuite/test/make/Makefile.rules +++ Python/lldbsuite/test/make/Makefile.rules @@ -193,13 +193,10 @@ DEBUG_INFO_FLAG ?= -g CFLAGS ?= $(DEBUG_INFO_FLAG) -O0 -fno-builtin -ifeq "$(OS)" "Darwin" - CFLAGS += $(ARCHFLAG) $(ARCH) $(FRAMEWORK_INCLUDES) $(CFLAGS_EXTRAS) -I$(LLDB_BASE_DIR)include -else - CFLAGS += $(ARCHFLAG)$(ARCH) $(FRAMEWORK_INCLUDES) $(CFLAGS_EXTRAS) -I$(LLDB_BASE_DIR)include -endif +CFLAGS += $(FRAMEWORK_INCLUDES) $(CFLAGS_EXTRAS) -I$(LLDB_BASE_DIR)include -include $(THIS_FILE_DIR)test_common.h $(TRIPLE_CFLAGS) +CFLAGS_NO_ARCH := $(CFLAGS) -CFLAGS += -include $(THIS_FILE_DIR)test_common.h $(TRIPLE_CFLAGS) +CFLAGS += $(ARCHFLAG)$(ARCH) # Use this one if you want to build one part of the result without debug information: ifeq "$(OS)" "Darwin" Index: Python/lldbsuite/test/macosx/universal/Makefile === --- Python/lldbsuite/test/macosx/universal/Makefile +++ Python/lldbsuite/test/macosx/universal/Makefile @@ -1,5 +1,14 @@ CC ?= clang +all: testit + +LEVEL = ../../make + +C_SOURCES := main.c + +include $(LEVEL)/Makefile.rules + + testit: testit.i386 testit.x86_64 lipo -create -o testit testit.i386 testit.x86_64 @@ -10,10 +19,10 @@ $(CC) -arch x86_64 -o testit.x86_64 testit.x86_64.o testit.i386.o: main.c - $(CC) -g -O0 -arch i386 -c -o testit.i386.o main.c + $(CC) $(CFLAGS_NO_ARCH) -arch i386 -c -o testit.i386.o main.c testit.x86_64.o: main.c - $(CC) -g -O0 -arch x86_64 -c -o testit.x86_64.o main.c + $(CC) $(CFLAGS_NO_ARCH) -arch x86_64 -c -o testit.x86_64.o main.c -clean: +clean:: rm -rf $(wildcard testit* *~) ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D25926: Don't set a software stepping breakpoint at 0 on arm or mips.
jmajors created this revision.
jmajors added a reviewer: labath.
jmajors added a subscriber: lldb-commits.
Herald added subscribers: srhines, danalbert, tberghammer, rengolin, aemerson.
Added a test for the next_pc being zero before setting a software breakpoint
in arm32 and mips.
Reenabled the crash during step test for android/linux.
https://reviews.llvm.org/D25926
Files:
packages/Python/lldbsuite/test/functionalities/thread/crash_during_step/TestCrashDuringStep.py
source/Plugins/Process/Linux/NativeProcessLinux.cpp
Index: source/Plugins/Process/Linux/NativeProcessLinux.cpp
===
--- source/Plugins/Process/Linux/NativeProcessLinux.cpp
+++ source/Plugins/Process/Linux/NativeProcessLinux.cpp
@@ -1351,12 +1351,23 @@
// Arm mode
error = SetSoftwareBreakpoint(next_pc, 4);
}
+
+// If setting the breakpoint fails because next_pc is out of
+// the address space, ignore it and let the debugee segfault.
+if (error.GetError() == EIO || error.GetError() == EFAULT) {
+ error.Clear();
+}
} else if (m_arch.GetMachine() == llvm::Triple::mips64 ||
m_arch.GetMachine() == llvm::Triple::mips64el ||
m_arch.GetMachine() == llvm::Triple::mips ||
- m_arch.GetMachine() == llvm::Triple::mipsel)
+ m_arch.GetMachine() == llvm::Triple::mipsel) {
error = SetSoftwareBreakpoint(next_pc, 4);
- else {
+// If setting the breakpoint fails because next_pc is out of
+// the address space, ignore it and let the debugee segfault.
+if (error.GetError() == EIO || error.GetError() == EFAULT) {
+ error.Clear();
+}
+ } else {
// No size hint is given for the next breakpoint
error = SetSoftwareBreakpoint(next_pc, 0);
}
Index:
packages/Python/lldbsuite/test/functionalities/thread/crash_during_step/TestCrashDuringStep.py
===
---
packages/Python/lldbsuite/test/functionalities/thread/crash_during_step/TestCrashDuringStep.py
+++
packages/Python/lldbsuite/test/functionalities/thread/crash_during_step/TestCrashDuringStep.py
@@ -21,11 +21,6 @@
self.breakpoint = line_number('main.cpp', '// Set breakpoint here')
@expectedFailureAll(oslist=["windows"], bugnumber="llvm.org/pr24778")
-@expectedFailureAndroid("llvm.org/pr24497", archs=['arm', 'aarch64'])
-@expectedFailureAll(
-oslist=["linux"],
-archs=["arm"],
-bugnumber="llvm.org/pr24497")
# IO error due to breakpoint at invalid address
@expectedFailureAll(triple=re.compile('^mips'))
def test_step_inst_with(self):
Index: source/Plugins/Process/Linux/NativeProcessLinux.cpp
===
--- source/Plugins/Process/Linux/NativeProcessLinux.cpp
+++ source/Plugins/Process/Linux/NativeProcessLinux.cpp
@@ -1351,12 +1351,23 @@
// Arm mode
error = SetSoftwareBreakpoint(next_pc, 4);
}
+
+// If setting the breakpoint fails because next_pc is out of
+// the address space, ignore it and let the debugee segfault.
+if (error.GetError() == EIO || error.GetError() == EFAULT) {
+ error.Clear();
+}
} else if (m_arch.GetMachine() == llvm::Triple::mips64 ||
m_arch.GetMachine() == llvm::Triple::mips64el ||
m_arch.GetMachine() == llvm::Triple::mips ||
- m_arch.GetMachine() == llvm::Triple::mipsel)
+ m_arch.GetMachine() == llvm::Triple::mipsel) {
error = SetSoftwareBreakpoint(next_pc, 4);
- else {
+// If setting the breakpoint fails because next_pc is out of
+// the address space, ignore it and let the debugee segfault.
+if (error.GetError() == EIO || error.GetError() == EFAULT) {
+ error.Clear();
+}
+ } else {
// No size hint is given for the next breakpoint
error = SetSoftwareBreakpoint(next_pc, 0);
}
Index: packages/Python/lldbsuite/test/functionalities/thread/crash_during_step/TestCrashDuringStep.py
===
--- packages/Python/lldbsuite/test/functionalities/thread/crash_during_step/TestCrashDuringStep.py
+++ packages/Python/lldbsuite/test/functionalities/thread/crash_during_step/TestCrashDuringStep.py
@@ -21,11 +21,6 @@
self.breakpoint = line_number('main.cpp', '// Set breakpoint here')
@expectedFailureAll(oslist=["windows"], bugnumber="llvm.org/pr24778")
-@expectedFailureAndroid("llvm.org/pr24497", archs=['arm', 'aarch64'])
-@expectedFailureAll(
-oslist=["linux"],
-archs=["arm"],
-bugnumber="llvm.org/pr24497")
# IO error due to breakpoint at invalid address
@expectedFailureAll(triple=re.compile('^mips'))
def test_step_inst_with(self):
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-com
[Lldb-commits] [lldb] r285032 - remove xfail from TestObjCNewSyntax.py test_expr_gmodules()
Author: tfiala Date: Mon Oct 24 16:46:46 2016 New Revision: 285032 URL: http://llvm.org/viewvc/llvm-project?rev=285032&view=rev Log: remove xfail from TestObjCNewSyntax.py test_expr_gmodules() Fixes: rdar://27792848 Modified: lldb/trunk/packages/Python/lldbsuite/test/lang/objc/objc-new-syntax/TestObjCNewSyntax.py Modified: lldb/trunk/packages/Python/lldbsuite/test/lang/objc/objc-new-syntax/TestObjCNewSyntax.py URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/objc/objc-new-syntax/TestObjCNewSyntax.py?rev=285032&r1=285031&r2=285032&view=diff == --- lldb/trunk/packages/Python/lldbsuite/test/lang/objc/objc-new-syntax/TestObjCNewSyntax.py (original) +++ lldb/trunk/packages/Python/lldbsuite/test/lang/objc/objc-new-syntax/TestObjCNewSyntax.py Mon Oct 24 16:46:46 2016 @@ -33,10 +33,6 @@ class ObjCNewSyntaxTestCase(TestBase): compiler_version=[ '<', '7.0.0']) -@expectedFailureAll( -oslist=['macosx'], -debug_info=['gmodules'], -bugnumber='rdar://27792848') @skipIf(macos_version=["<", "10.12"]) @expectedFailureAll(archs=["i[3-6]86"]) def test_expr(self): ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] LLGS for Free/NetBSD (was: Re: [PATCH] D25756: FreeBSD ARM support for software single step.)
On Mon, Oct 24, 2016 at 11:38 AM, Ed Maste via lldb-commits < lldb-commits@lists.llvm.org> wrote: > On 24 October 2016 at 06:26, Pavel Labath wrote: > > > > It's not my place to tell you how to work, but I'd recommend a > > different approach to this. If you base your work on the current > > FreeBSD in-process plugin, then when you get around to actually > > implementing remote support, you will find that you will have to > > rewrite most of what you have already done to work with lldb-server, > > as it uses completely different class hierarchies and everything. I'd > > recommend starting with lldb-server right away. It's going to be a bit > > more work as (I assume) freebsd implementation is closer to what you > > need than linux, but I think it will save you time in the long run. I > > can help you with factoring out any linux-specific code that you > > encounter. > > I definitely second the approach Pavel suggests here, and am happy to > work with others on refactoring the Linux lldb-server so that we can > get it to support both FreeBSD and NetBSD at the same time. > > A direct port of the current FreeBSD support probably would result in > a basic level of support running sooner, but that work would be > largely thrown away in a future migration to lldb-server. > Just to throw out another option: DS2 (DebugServer2) at http://github.com/facebook/ds2 may be another option to getting remote debugging working. It already has basic BSD support, so adding NetBSD support shouldn't be too difficult. > ___ > lldb-commits mailing list > lldb-commits@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits > -- Saleem Abdulrasool compnerd (at) compnerd (dot) org ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D25864: Fix arm64 floating point register spill recording in UnwindPlan analysis
jasonmolenda added a comment. Hi Tamas, sorry for not replying earlier, something urgent came up that I needed to look at. Thanks for the review. I agree with using your existing arm64 register enums in lldb-arm64-register-enums.h. I'd like to remove the enums in RegisterInfos_arm64.h instead of having two copies that could diverge. You asked about having EmulateInstructionARM64 handle both eRegisterKindDWARF and eRegisterKindLLDB. I'm not sure how that would work - each UnwindPlan must can use only one register numbering scheme. We could use eRegisterKindDWARF if there were no floating point register save/restores - but that seems a bit complicated; we'd conditionally use eRegisterKindLLDB sometimes, eRegisterKindDWARF most of the time. As for the GetRegisterName() function in ARM64_LLDB_Registers.cpp, we could have EmulateInstructionARM64 with the register file definition (we need to define seven preprocessor symbols before we can include RegisterInfos_arm64.h and then we'll need to write a GetRegisterName() method in EmulateInstructionARM64.cpp. Wouldn't it be clearer to have a lldb-arm64-register-enums.cpp with this method? I was talking about these register numbering problems with Greg Clayton and he half-jokingly said we should switch from register numbers to using ConstString register names in the UnwindPlans. It's not a bad idea! As long as everyone can agree on the register names for an architecture, anyway. Repository: rL LLVM https://reviews.llvm.org/D25864 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
