Re: [Lldb-commits] [PATCH] D24610: LLDB Arm Watchpoints: Use single hardware watchpoint slot to watch multiple bytes where possible
labath added a comment. In https://reviews.llvm.org/D24610#554587, @omjavaid wrote: > Give this approach a rethink I dont see a lot of problems with this final > implementation unless it fails on other architectures. > We are already hacking our way to have these byte selection watchpoints > working in existing code. New code seems to be improving the hack in my > opinion. - I don't believe that the presence of one hack justifies the addition of another. If anything, then it's the opposite. - The fact that we have to fiddle with the byte selects to get the kernel to accept our watchpoints could be thought of as a "hack", but I think there it's justified, as otherwise we would be unable to watch anything that isn't dword-aligned. And most importantly, the issue is contained within the SetHardwareWatchpoint function -- noone outside of that needs to know about the fact that we are doing something funny with byte-selects. This is not the case here, as I explain below. > Can you think of any scenarios which might fail for this approach? I can. Try the following sequence of commands: - position the PC on an instruction that will write to address A (aligned) - set a byte watchpoint on A+0 - set a byte watchpoint on A+1 - clear the second watchpoint - single-step What will happen with your patch applied? (*) Nothing, as the watchpoint will not get hit because you disabled it. Now this is a pretty dubious example, but I think it demonstrates, the problems I have with this solution very nicely. **You are lying to the client about which watchpoints are enabled**. The client asked you to remove just one watchpoint, so as far as he is concerned the other one is still active. But you have disabled the other one as well. And now you make this a feature, as without it single stepping a multi-watchpoint will not work. And you are here relying on the fact that the client implements the step-over-watchpoint as a simple $z2, $s, $Z2 packet sequence. If the client decides to do anything more complicated, say evaluate an expression to get some state before the update, then your feature will break, as an intermediate $c, will reinstate your hidden watchpoint (in fact, this is maybe possible already, if a conditional breakpoint and a watchpoint are hit simultaneously). And you don't even fix the step-over-instruction-triggering-multiple-watchpoints problem definitively - this can still happen e.g., if you have a watch on 0x1000 and 0x1008, and a single instruction triggers both.(**) This is why I think this change is bad, as it is making an invisible line between the lowest levels of the server and the highest levels of the client, which now have to be kept in sync, otherwise things will unexpectedly break. I don't believe that having the ability to watch more than 4 locations at once is worth it, particularly when it can be easily worked around by the user (just set one big watchpoint instead of multiple small ones). Do you have a specific use case where this would be necessary/useful? I personally have never used more than one watchpoint per debug session in my life, and I expect this to be true for most people (I think the typical use case is "who is corrupting my variable?"), So, I believe that it is better to have support for fewer watchpoints, but have it working well, than the opposite. (*) Now when I tried this out on lldb without this change, it still did not work as expected - for some reason, after hitting and stepping over the watchpoint, lldb decided to to issue $c, and lost control of the inferior. I think that tracking this issue and fixing it would have more impact than adding the multi-watchpoint support (and it will reduce the number of corner cases, where we are wrong rather than increasing it). (**) Another issue whose solving would have more impact than this. https://reviews.llvm.org/D24610 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D25021: [LLDB][MIPS] Fix qProcessInfo to return correct pointer size based on ELF ABI
nitesh.jain created this revision.
nitesh.jain added reviewers: clayborg, labath.
nitesh.jain added subscribers: jaydeep, bhushan, slthakur, lldb-commits.
nitesh.jain set the repository for this revision to rL LLVM.
In case of MIPS64, the pointer size depends on ELF abi. The MIPS64 currently
support following abi's
1) N32 : - The pointer size is 4 byte
2) N64 :- The pointer size is 8 byte
This patch add one more key (eflags) in qProcessInfo which will be use to get
correct pointer size based on abi.
Repository:
rL LLVM
https://reviews.llvm.org/D25021
Files:
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp
Index: source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp
===
--- source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp
+++ source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp
@@ -1212,9 +1212,15 @@
// Nothing.
break;
}
-
-if (proc_triple.isArch64Bit())
- response.PutCString("ptrsize:8;");
+// In case of MIPS64, pointer size is depend on ELF ABI
+// For N32 the pointer size is 4 and for N64 it is 8
+response.Printf("eflags:%" PRIx32 ";", proc_arch.GetFlags());
+if (proc_triple.isArch64Bit()) {
+ if (proc_arch.IsMIPS()) {
+ response.Printf("ptrsize:%d;", proc_arch.GetAddressByteSize());
+ } else
+ response.PutCString("ptrsize:8;");
+}
else if (proc_triple.isArch32Bit())
response.PutCString("ptrsize:4;");
else if (proc_triple.isArch16Bit())
Index: source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
===
--- source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
+++ source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
@@ -1847,6 +1847,7 @@
std::string os_name;
std::string vendor_name;
std::string triple;
+ uint32_t proc_arch_eflags = 0;
uint32_t pointer_byte_size = 0;
StringExtractor extractor;
ByteOrder byte_order = eByteOrderInvalid;
@@ -1883,6 +1884,9 @@
} else if (name.equals("pid")) {
if (!value.getAsInteger(16, pid))
++num_keys_decoded;
+} else if (name.equals("eflags")) {
+ if (!value.getAsInteger(16,proc_arch_eflags))
+++num_keys_decoded;
}
}
if (num_keys_decoded > 0)
@@ -1895,6 +1899,7 @@
// Set the ArchSpec from the triple if we have it.
if (!triple.empty()) {
m_process_arch.SetTriple(triple.c_str());
+m_process_arch.SetFlags(proc_arch_eflags);
if (pointer_byte_size) {
assert(pointer_byte_size == m_process_arch.GetAddressByteSize());
}
Index: source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp
===
--- source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp
+++ source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp
@@ -1212,9 +1212,15 @@
// Nothing.
break;
}
-
-if (proc_triple.isArch64Bit())
- response.PutCString("ptrsize:8;");
+// In case of MIPS64, pointer size is depend on ELF ABI
+// For N32 the pointer size is 4 and for N64 it is 8
+response.Printf("eflags:%" PRIx32 ";", proc_arch.GetFlags());
+if (proc_triple.isArch64Bit()) {
+ if (proc_arch.IsMIPS()) {
+ response.Printf("ptrsize:%d;", proc_arch.GetAddressByteSize());
+ } else
+ response.PutCString("ptrsize:8;");
+}
else if (proc_triple.isArch32Bit())
response.PutCString("ptrsize:4;");
else if (proc_triple.isArch16Bit())
Index: source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
===
--- source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
+++ source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
@@ -1847,6 +1847,7 @@
std::string os_name;
std::string vendor_name;
std::string triple;
+ uint32_t proc_arch_eflags = 0;
uint32_t pointer_byte_size = 0;
StringExtractor extractor;
ByteOrder byte_order = eByteOrderInvalid;
@@ -1883,6 +1884,9 @@
} else if (name.equals("pid")) {
if (!value.getAsInteger(16, pid))
++num_keys_decoded;
+} else if (name.equals("eflags")) {
+ if (!value.getAsInteger(16,proc_arch_eflags))
+++num_keys_decoded;
}
}
if (num_keys_decoded > 0)
@@ -1895,6 +1899,7 @@
// Set the ArchSpec from the triple if we have it.
if (!triple.empty()) {
m_process_arch.SetTriple(triple.c_str());
+m_process_arch.SetFlags(proc_arch_eflags);
if (pointer_byt
Re: [Lldb-commits] [PATCH] D25021: [LLDB][MIPS] Fix qProcessInfo to return correct pointer size based on ELF ABI
labath added a comment.
Looks good as far as I am concerned. Just a couple of nits here and there.
Comment at:
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp:1887
@@ -1885,1 +1886,3 @@
++num_keys_decoded;
+} else if (name.equals("eflags")) {
+ if (!value.getAsInteger(16,proc_arch_eflags))
Why you chose this name? eflags is the name of a i386 register. How about we
use a different field name? `archflags` maybe ?
Comment at:
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp:1218
@@ +1217,3 @@
+response.Printf("eflags:%" PRIx32 ";", proc_arch.GetFlags());
+if (proc_triple.isArch64Bit()) {
+ if (proc_arch.IsMIPS()) {
Why do we have the compilcated switch here. Can't we replace that with:
`response.Printf("ptrsize:%d;", proc_arch.GetAddressByteSize());` for all sizes?
Repository:
rL LLVM
https://reviews.llvm.org/D25021
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D25021: [LLDB][MIPS] Fix qProcessInfo to return correct pointer size based on ELF ABI
clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.
We need to send each flag individually. See inlined comments.
Comment at:
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp:1887
@@ -1885,1 +1886,3 @@
++num_keys_decoded;
+} else if (name.equals("eflags")) {
+ if (!value.getAsInteger(16,proc_arch_eflags))
labath wrote:
> Why you chose this name? eflags is the name of a i386 register. How about we
> use a different field name? `archflags` maybe ?
We should avoid trying pass ArchSpec specific flags over the wire. Seems like
we should be abstracting each flag we want to send as a new key. How is some
code that isn't based on LLDB going to fill in these flags? Please add a
key/value pair for each flag you want to send. You can add a function to
ArchSpec that gets a StructuredData::Dictionary from the ArchSpec and then uses
that to populate the key/value pairs that you send back. Each architecture
defines a set of unique flags. Another issue with sending e_flags directly is
if someone changes the bit definitions of the flags and we have a new LLDB hook
up to an older lldb-server, we will get the flags wrong.
Comment at:
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp:1218
@@ +1217,3 @@
+response.Printf("eflags:%" PRIx32 ";", proc_arch.GetFlags());
+if (proc_triple.isArch64Bit()) {
+ if (proc_arch.IsMIPS()) {
labath wrote:
> Why do we have the compilcated switch here. Can't we replace that with:
> `response.Printf("ptrsize:%d;", proc_arch.GetAddressByteSize());` for all
> sizes?
labath: the default ptr size for MIPS64 is 8. We would need to modify
ArchSpec.cpp to look at the flags for MIPS64 and change the pointer size to 4
if the N32 is being used.
Repository:
rL LLVM
https://reviews.llvm.org/D25021
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r282605 - zorg Xcode python test suite target arch update
Author: tfiala
Date: Wed Sep 28 11:43:47 2016
New Revision: 282605
URL: http://llvm.org/viewvc/llvm-project?rev=282605&view=rev
Log:
zorg Xcode python test suite target arch update
This changes the Xcode target used by the Green Dragon Xcode CI.
When calling xcodebuild with LLDB_PYTHON_TESTSUITE_ARCH set, the
arch's xUnit XML output is now set to an arch-specific filename:
$(BUILD_DIR)/test-results-$(LLDB_PYTHON_TESTSUITE_ARCH).xml.
The change also ensures that the Python testsuite sees the Xcode
build settings passed in through environment variables.
Modified:
lldb/trunk/lldb.xcodeproj/project.pbxproj
Modified: lldb/trunk/lldb.xcodeproj/project.pbxproj
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/lldb.xcodeproj/project.pbxproj?rev=282605&r1=282604&r2=282605&view=diff
==
--- lldb/trunk/lldb.xcodeproj/project.pbxproj (original)
+++ lldb/trunk/lldb.xcodeproj/project.pbxproj Wed Sep 28 11:43:47 2016
@@ -6421,7 +6421,7 @@
/* Begin PBXLegacyTarget section */
2387551E1C24974600CCE8C3 /* lldb-python-test-suite */ = {
isa = PBXLegacyTarget;
- buildArgumentsString = "-u $(SRCROOT)/test/dotest.py
--apple-sdk $(PLATFORM_NAME)
--executable=$(BUILD_DIR)/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME)/lldb -C
$(LLDB_PYTHON_TESTSUITE_CC) --arch $(LLDB_PYTHON_TESTSUITE_ARCH)
--session-file-format fm --results-formatter
lldbsuite.test_event.formatter.xunit.XunitFormatter --results-file
$(BUILD_DIR)/test-results.xml --rerun-all-issues --env TERM=vt100
-O--xpass=ignore";
+ buildArgumentsString = "-u $(SRCROOT)/test/dotest.py
--apple-sdk $(PLATFORM_NAME)
--executable=$(BUILD_DIR)/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME)/lldb -C
$(LLDB_PYTHON_TESTSUITE_CC) --arch $(LLDB_PYTHON_TESTSUITE_ARCH)
--session-file-format fm --results-formatter
lldbsuite.test_event.formatter.xunit.XunitFormatter --results-file
$(BUILD_DIR)/test-results-$(LLDB_PYTHON_TESTSUITE_ARCH).xml --rerun-all-issues
--env TERM=vt100 -O--xpass=ignore";
buildConfigurationList = 238755241C24974600CCE8C3 /*
Build configuration list for PBXLegacyTarget "lldb-python-test-suite" */;
buildPhases = (
);
@@ -6430,7 +6430,7 @@
dependencies = (
);
name = "lldb-python-test-suite";
- passBuildSettingsInEnvironment = 0;
+ passBuildSettingsInEnvironment = 1;
productName = "LLDB Python Test Suite";
};
2687EAC51508110B00DD8C2E /* install-headers */ = {
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D24863: Keep dependencies separated between static and dynamic libraries. Fix for bug #28127.
Meinersbur requested changes to this revision. Meinersbur added a comment. The description of `LLVM_LINK_LLVM_DYLIB` reads: > Link tools against the libllvm dynamic library that is, its intend is what this patch would disable (for dynamic modules). I assume that you would like lldb-server to work that way even if `LLVM_LINK_LLVM_DYLIB=ON`. I suggest to document instead that lldb-server depends on dynamic objects in that configuration and therefore cannot be moved to other computer as stand-alone; their architecture might mismatch anyway. Other solutions I can think of: - The LLVM modules don't depend on libraries themselves, only the tools (opt, clang, ...) link against libllvm (note that this probably has a large impact on the build system) - Like llvm-tblgen, clang-tblgen with `LLVM_OPTIMIZED_TABLEGEN` and cross-compilation, use a sub-buildsystem that builds lldb-server with the right options (and the right target architecture) For the Polly part, you cannot just remove the `BUILD_SHARED_LIBS` condition. It will cause Polly to have the same problem of multiple command-line registrations you are observing when using `-load LLVMPolly.so`. However, I already suggested a redesign of that part in https://reviews.llvm.org/D24442. Repository: rL LLVM https://reviews.llvm.org/D24863 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [lldb] r282529 - Adding a RegisterContextMinidump_x86_64 converter
This change seems to have introduced a linker failure while building the
gtest suite:
Ld build/Release/lldb-gtest normal x86_64
cd "/Users/buildslave/jenkins/sharedspace/lldb@2/lldb"
export MACOSX_DEPLOYMENT_TARGET=10.9
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
-arch x86_64 -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
-L/Users/buildslave/jenkins/sharedspace/lldb@2/lldb/build/Release
-F/Users/buildslave/jenkins/sharedspace/lldb@2/lldb/build/Release
-F/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/PrivateFrameworks
-F/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks
-filelist
/Users/buildslave/jenkins/sharedspace/lldb@2/lldb/build/lldb.build/Release/lldb-gtest-build.build/Objects-normal/x86_64/lldb-gtest.LinkFileList
-mmacosx-version-min=10.9 -weak-lcompression -lz -filelist
/Users/buildslave/jenkins/sharedspace/lldb@2/lldb/llvm-build/Release+Asserts/archives.txt
-framework Foundation -framework DebugSymbols -framework Security
-framework CoreServices -framework ApplicationServices
/Users/buildslave/jenkins/sharedspace/lldb@2/lldb/llvm-build/Release+Asserts/x86_64/lib/libgtest.a
-L /System/Library/Frameworks/Python.framework/Versions/2.7/lib -l
python2.7 -stdlib=libc++ -lxml2.2 -lpanel -ledit -lz -lncurses
/Users/buildslave/jenkins/sharedspace/lldb@2/lldb/build/Release/liblldb-core.a
-Xlinker -dependency_info -Xlinker
/Users/buildslave/jenkins/sharedspace/lldb@2/lldb/build/lldb.build/Release/lldb-gtest-build.build/Objects-normal/x86_64/lldb-gtest_dependency_info.dat
-o /Users/buildslave/jenkins/sharedspace/lldb@2
/lldb/build/Release/lldb-gtest
Undefined symbols for architecture x86_64:
"lldb_private::minidump::ConvertMinidumpContextToRegIface(llvm::ArrayRef, lldb_private::RegisterInfoInterface*)", referenced from:
MinidumpParserTest_ConvertRegisterContext_Test::TestBody() in
MinidumpParserTest.o
ld: symbol(s) not found for architecture x86_64
It first struck yesterday afternoon:
http://lab.llvm.org:8080/green/view/LLDB/job/lldb_build_test/20745/console
and recurring through today:
http://lab.llvm.org:8080/green/view/LLDB/job/lldb_build_test/20770/console
Is there a change that needs to be made to the test suite to address this?
On Tue, Sep 27, 2016 at 12:05 PM, Dimitar Vlahovski via lldb-commits <
lldb-commits@lists.llvm.org> wrote:
> Author: dvlahovski
> Date: Tue Sep 27 14:05:55 2016
> New Revision: 282529
>
> URL: http://llvm.org/viewvc/llvm-project?rev=282529&view=rev
> Log:
> Adding a RegisterContextMinidump_x86_64 converter
>
> Summary:
> This is a register context converter from Minidump to Linux reg context.
> This knows the layout of the register context in the Minidump file
> (which is the same as in Windows FYI) and as a result emits a binary data
> buffer that matches the Linux register context binary layout.
> This way we can reuse the existing RegisterContextLinux_x86_64 and
> RegisterContextCorePOSIX_x86_64 classes.
>
> Reviewers: labath, zturner
>
> Subscribers: beanz, mgorny, lldb-commits, amccarth
>
> Differential Revision: https://reviews.llvm.org/D24919
>
> Added:
> lldb/trunk/source/Plugins/Process/minidump/
> RegisterContextMinidump_x86_64.cpp
> lldb/trunk/source/Plugins/Process/minidump/
> RegisterContextMinidump_x86_64.h
> Modified:
> lldb/trunk/include/lldb/lldb-private-types.h
> lldb/trunk/source/Plugins/Process/minidump/CMakeLists.txt
> lldb/trunk/source/Plugins/Process/minidump/MinidumpParser.cpp
> lldb/trunk/source/Plugins/Process/minidump/MinidumpParser.h
> lldb/trunk/unittests/Process/minidump/MinidumpParserTest.cpp
>
> Modified: lldb/trunk/include/lldb/lldb-private-types.h
> URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/include/
> lldb/lldb-private-types.h?rev=282529&r1=282528&r2=282529&view=diff
>
> ==
> --- lldb/trunk/include/lldb/lldb-private-types.h (original)
> +++ lldb/trunk/include/lldb/lldb-private-types.h Tue Sep 27 14:05:55 2016
> @@ -14,6 +14,8 @@
>
> #include "lldb/lldb-private.h"
>
> +#include "llvm/ADT/ArrayRef.h"
> +
> namespace llvm {
> namespace sys {
> class DynamicLibrary;
> @@ -61,6 +63,15 @@ struct RegisterInfo {
>// the byte size of this register.
>size_t dynamic_size_dwarf_len; // The length of the DWARF expression in
> bytes
> // in the dynamic_size_dwarf_expr_bytes
> member.
> +
> + llvm::ArrayRef data(const uint8_t *context_base) const {
> +return llvm::ArrayRef(context_base + byte_offset,
> byte_size);
> + }
> +
> + llvm::MutableArrayRef mutable_data(uint8_t *context_base)
> const {
> +return llvm::MutableArrayRef(context_base + byte_offset,
> +
[Lldb-commits] [lldb] r282628 - use assertEquals in TestSBTypeClassMembers
Author: tfiala
Date: Wed Sep 28 15:39:50 2016
New Revision: 282628
URL: http://llvm.org/viewvc/llvm-project?rev=282628&view=rev
Log:
use assertEquals in TestSBTypeClassMembers
This change replaces the self.assertTrue() calls with
self.assertEquals() so that test failures get more context on failure
values.
Modified:
lldb/trunk/packages/Python/lldbsuite/test/python_api/class_members/TestSBTypeClassMembers.py
Modified:
lldb/trunk/packages/Python/lldbsuite/test/python_api/class_members/TestSBTypeClassMembers.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/python_api/class_members/TestSBTypeClassMembers.py?rev=282628&r1=282627&r2=282628&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/python_api/class_members/TestSBTypeClassMembers.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/python_api/class_members/TestSBTypeClassMembers.py
Wed Sep 28 15:39:50 2016
@@ -62,39 +62,46 @@ class SBTypeMemberFunctionsTest(TestBase
Derived = variable.GetType()
Base = Derived.GetDirectBaseClassAtIndex(0).GetType()
-self.assertTrue(
-Derived.GetNumberOfMemberFunctions() == 2,
+self.assertEquals(2,
+Derived.GetNumberOfMemberFunctions(),
"Derived declares two methods")
-self.assertTrue(Derived.GetMemberFunctionAtIndex(0).GetType(
-).GetFunctionReturnType().GetName() == "int", "Derived::dImpl returns
int")
+self.assertEquals("int", Derived.GetMemberFunctionAtIndex(0).GetType(
+).GetFunctionReturnType().GetName(),
+"Derived::dImpl returns int")
-self.assertTrue(
-Base.GetNumberOfMemberFunctions() == 4,
+self.assertEquals(4,
+Base.GetNumberOfMemberFunctions(),
"Base declares three methods")
-self.assertTrue(Base.GetMemberFunctionAtIndex(3).GetType(
-).GetFunctionArgumentTypes().GetSize() == 3, "Base::sfunc takes three
arguments")
-self.assertTrue(Base.GetMemberFunctionAtIndex(
-3).GetName() == "sfunc", "Base::sfunc not found")
-self.assertTrue(Base.GetMemberFunctionAtIndex(3).GetKind(
-) == lldb.eMemberFunctionKindStaticMethod, "Base::sfunc is a static")
-self.assertTrue(Base.GetMemberFunctionAtIndex(2).GetType(
-).GetFunctionArgumentTypes().GetSize() == 0, "Base::dat takes no
arguments")
-
self.assertTrue(Base.GetMemberFunctionAtIndex(1).GetType().GetFunctionArgumentTypes(
-).GetTypeAtIndex(1).GetName() == "char", "Base::bar takes a second
'char' argument")
-self.assertTrue(Base.GetMemberFunctionAtIndex(
-1).GetName() == "bar", "Base::bar not found")
+self.assertEquals(3, Base.GetMemberFunctionAtIndex(3).GetType(
+).GetFunctionArgumentTypes().GetSize(),
+"Base::sfunc takes three arguments")
+self.assertEquals("sfunc", Base.GetMemberFunctionAtIndex(
+3).GetName(), "Base::sfunc not found")
+self.assertEquals(lldb.eMemberFunctionKindStaticMethod,
+Base.GetMemberFunctionAtIndex(3).GetKind(),
+"Base::sfunc is a static")
+self.assertEquals(0, Base.GetMemberFunctionAtIndex(2).GetType(
+).GetFunctionArgumentTypes().GetSize(),
+"Base::dat takes no arguments")
+self.assertEquals("char",
+
Base.GetMemberFunctionAtIndex(1).GetType().GetFunctionArgumentTypes(
+).GetTypeAtIndex(1).GetName(),
+"Base::bar takes a second 'char' argument")
+self.assertEquals("bar",
+Base.GetMemberFunctionAtIndex(1).GetName(), "Base::bar not found")
variable = frame0.FindVariable("thingy")
Thingy = variable.GetType()
-self.assertTrue(
-Thingy.GetNumberOfMemberFunctions() == 2,
+self.assertEquals(
+2, Thingy.GetNumberOfMemberFunctions(),
"Thingy declares two methods")
-self.assertTrue(Thingy.GetMemberFunctionAtIndex(
-0).GetReturnType().GetName() == "id", "Thingy::init returns an id")
-self.assertTrue(
-Thingy.GetMemberFunctionAtIndex(1).GetNumberOfArguments() == 2,
+self.assertEquals("id", Thingy.GetMemberFunctionAtIndex(
+0).GetReturnType().GetName(), "Thingy::init returns an id")
+self.assertEquals(2,
+Thingy.GetMemberFunctionAtIndex(1).GetNumberOfArguments(),
"Thingy::foo takes two arguments")
-
self.assertTrue(Thingy.GetMemberFunctionAtIndex(1).GetArgumentTypeAtIndex(
-0).GetName() == "int", "Thingy::foo takes an int")
+self.assertEquals("int",
+Thingy.GetMemberFunctionAtIndex(1).GetArgumentTypeAtIndex(
+0).GetName(), "Thingy::foo takes an int")
___
lldb-commits mailing list
lldb-commits@lists.llvm.o
Re: [Lldb-commits] [lldb] r282529 - Adding a RegisterContextMinidump_x86_64 converter
Looks like there was some work to address this in r282565 here:
http://lab.llvm.org:8080/green/view/LLDB/job/lldb_build_test/20756/
However, the issue occurred again on the very next run.
On Wed, Sep 28, 2016 at 1:41 PM, Tim Hammerquist wrote:
> This change seems to have introduced a linker failure while building the
> gtest suite:
>
>
> Ld build/Release/lldb-gtest normal x86_64
> cd "/Users/buildslave/jenkins/sharedspace/lldb@2/lldb"
> export MACOSX_DEPLOYMENT_TARGET=10.9
> /Applications/Xcode.app/Contents/Developer/Toolchains/
> XcodeDefault.xctoolchain/usr/bin/clang++ -arch x86_64 -isysroot
> /Applications/Xcode.app/Contents/Developer/Platforms/
> MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
> -L/Users/buildslave/jenkins/sharedspace/lldb@2/lldb/build/Release
> -F/Users/buildslave/jenkins/sharedspace/lldb@2/lldb/build/Release
> -F/Applications/Xcode.app/Contents/Developer/Platforms/
> MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/PrivateFrameworks
> -F/Applications/Xcode.app/Contents/Developer/Platforms/
> MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks/
> CoreServices.framework/Frameworks -filelist /Users/buildslave/jenkins/
> sharedspace/lldb@2/lldb/build/lldb.build/Release/lldb-gtest-
> build.build/Objects-normal/x86_64/lldb-gtest.LinkFileList
> -mmacosx-version-min=10.9 -weak-lcompression -lz -filelist
> /Users/buildslave/jenkins/sharedspace/lldb@2/lldb/llvm-
> build/Release+Asserts/archives.txt -framework Foundation -framework
> DebugSymbols -framework Security -framework CoreServices -framework
> ApplicationServices /Users/buildslave/jenkins/sharedspace/lldb@2
> /lldb/llvm-build/Release+Asserts/x86_64/lib/libgtest.a -L
> /System/Library/Frameworks/Python.framework/Versions/2.7/lib -l python2.7
> -stdlib=libc++ -lxml2.2 -lpanel -ledit -lz -lncurses
> /Users/buildslave/jenkins/sharedspace/lldb@2/lldb/build/Release/liblldb-core.a
> -Xlinker -dependency_info -Xlinker /Users/buildslave/jenkins/
> sharedspace/lldb@2/lldb/build/lldb.build/Release/lldb-gtest-
> build.build/Objects-normal/x86_64/lldb-gtest_dependency_info.dat -o
> /Users/buildslave/jenkins/sharedspace/lldb@2/lldb/build/Release/lldb-gtest
> Undefined symbols for architecture x86_64:
>
> "lldb_private::minidump::ConvertMinidumpContextToRegIface(llvm::ArrayRef char>, lldb_private::RegisterInfoInterface*)", referenced from:
> MinidumpParserTest_ConvertRegisterContext_Test::TestBody() in
> MinidumpParserTest.o
> ld: symbol(s) not found for architecture x86_64
>
>
> It first struck yesterday afternoon:
>
> http://lab.llvm.org:8080/green/view/LLDB/job/lldb_build_test/20745/console
>
> and recurring through today:
>
> http://lab.llvm.org:8080/green/view/LLDB/job/lldb_build_test/20770/console
>
> Is there a change that needs to be made to the test suite to address this?
>
>
> On Tue, Sep 27, 2016 at 12:05 PM, Dimitar Vlahovski via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
>
>> Author: dvlahovski
>> Date: Tue Sep 27 14:05:55 2016
>> New Revision: 282529
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=282529&view=rev
>> Log:
>> Adding a RegisterContextMinidump_x86_64 converter
>>
>> Summary:
>> This is a register context converter from Minidump to Linux reg context.
>> This knows the layout of the register context in the Minidump file
>> (which is the same as in Windows FYI) and as a result emits a binary data
>> buffer that matches the Linux register context binary layout.
>> This way we can reuse the existing RegisterContextLinux_x86_64 and
>> RegisterContextCorePOSIX_x86_64 classes.
>>
>> Reviewers: labath, zturner
>>
>> Subscribers: beanz, mgorny, lldb-commits, amccarth
>>
>> Differential Revision: https://reviews.llvm.org/D24919
>>
>> Added:
>> lldb/trunk/source/Plugins/Process/minidump/RegisterContextMi
>> nidump_x86_64.cpp
>> lldb/trunk/source/Plugins/Process/minidump/RegisterContextMi
>> nidump_x86_64.h
>> Modified:
>> lldb/trunk/include/lldb/lldb-private-types.h
>> lldb/trunk/source/Plugins/Process/minidump/CMakeLists.txt
>> lldb/trunk/source/Plugins/Process/minidump/MinidumpParser.cpp
>> lldb/trunk/source/Plugins/Process/minidump/MinidumpParser.h
>> lldb/trunk/unittests/Process/minidump/MinidumpParserTest.cpp
>>
>> Modified: lldb/trunk/include/lldb/lldb-private-types.h
>> URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/
>> lldb-private-types.h?rev=282529&r1=282528&r2=282529&view=diff
>>
>> ==
>> --- lldb/trunk/include/lldb/lldb-private-types.h (original)
>> +++ lldb/trunk/include/lldb/lldb-private-types.h Tue Sep 27 14:05:55 2016
>> @@ -14,6 +14,8 @@
>>
>> #include "lldb/lldb-private.h"
>>
>> +#include "llvm/ADT/ArrayRef.h"
>> +
>> namespace llvm {
>> namespace sys {
>> class DynamicLibrary;
>> @@ -61,6 +63,15 @@ struct RegisterInfo {
>>// the byte size of this register.
>>size_t dynamic_size_dwarf_len; // The length of the DWAR
Re: [Lldb-commits] [lldb] r282529 - Adding a RegisterContextMinidump_x86_64 converter
Yep, looks like r282565 fixed the llvm.org tests, but broke another bot. r282566 fixed the other bot, but broke the llvm.org tests again. http://lab.llvm.org:8080/green/view/LLDB/job/lldb_build_test/20757/ On Wed, Sep 28, 2016 at 1:48 PM, Tim Hammerquist wrote: > Looks like there was some work to address this in r282565 here: > > http://lab.llvm.org:8080/green/view/LLDB/job/lldb_build_test/20756/ > > However, the issue occurred again on the very next run. > > On Wed, Sep 28, 2016 at 1:41 PM, Tim Hammerquist wrote: > >> This change seems to have introduced a linker failure while building the >> gtest suite: >> >> >> Ld build/Release/lldb-gtest normal x86_64 >> cd "/Users/buildslave/jenkins/sharedspace/lldb@2/lldb" >> export MACOSX_DEPLOYMENT_TARGET=10.9 >> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeD >> efault.xctoolchain/usr/bin/clang++ -arch x86_64 -isysroot >> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX. >> platform/Developer/SDKs/MacOSX10.11.sdk -L/Users/buildslave/jenkins/sh >> aredspace/lldb@2/lldb/build/Release -F/Users/buildslave/jenkins/sh >> aredspace/lldb@2/lldb/build/Release -F/Applications/Xcode.app/Cont >> ents/Developer/Platforms/MacOSX.platform/Developer/SDKs/ >> MacOSX10.11.sdk/System/Library/PrivateFrameworks >> -F/Applications/Xcode.app/Contents/Developer/Platforms/MacOS >> X.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library >> /Frameworks/CoreServices.framework/Frameworks -filelist >> /Users/buildslave/jenkins/sharedspace/lldb@2/lldb/build/lldb >> .build/Release/lldb-gtest-build.build/Objects-normal/x86_64/lldb-gtest.LinkFileList >> -mmacosx-version-min=10.9 -weak-lcompression -lz -filelist >> /Users/buildslave/jenkins/sharedspace/lldb@2/lldb/llvm-build/Release+Asserts/archives.txt >> -framework Foundation -framework DebugSymbols -framework Security >> -framework CoreServices -framework ApplicationServices >> /Users/buildslave/jenkins/sharedspace/lldb@2/lldb/llvm-build >> /Release+Asserts/x86_64/lib/libgtest.a -L >> /System/Library/Frameworks/Python.framework/Versions/2.7/lib >> -l python2.7 -stdlib=libc++ -lxml2.2 -lpanel -ledit -lz -lncurses >> /Users/buildslave/jenkins/sharedspace/lldb@2/lldb/build/Release/liblldb-core.a >> -Xlinker -dependency_info -Xlinker /Users/buildslave/jenkins/shar >> edspace/lldb@2/lldb/build/lldb.build/Release/lldb-gtest-buil >> d.build/Objects-normal/x86_64/lldb-gtest_dependency_info.dat -o >> /Users/buildslave/jenkins/sharedspace/lldb@2/lldb/build/Rele >> ase/lldb-gtest >> Undefined symbols for architecture x86_64: >> >> "lldb_private::minidump::ConvertMinidumpContextToRegIface(llvm::ArrayRef> char>, lldb_private::RegisterInfoInterface*)", referenced from: >> MinidumpParserTest_ConvertRegisterContext_Test::TestBody() in >> MinidumpParserTest.o >> ld: symbol(s) not found for architecture x86_64 >> >> >> It first struck yesterday afternoon: >> >> http://lab.llvm.org:8080/green/view/LLDB/job/lldb_build_ >> test/20745/console >> >> and recurring through today: >> >> http://lab.llvm.org:8080/green/view/LLDB/job/lldb_build_ >> test/20770/console >> >> Is there a change that needs to be made to the test suite to address this? >> >> >> On Tue, Sep 27, 2016 at 12:05 PM, Dimitar Vlahovski via lldb-commits < >> lldb-commits@lists.llvm.org> wrote: >> >>> Author: dvlahovski >>> Date: Tue Sep 27 14:05:55 2016 >>> New Revision: 282529 >>> >>> URL: http://llvm.org/viewvc/llvm-project?rev=282529&view=rev >>> Log: >>> Adding a RegisterContextMinidump_x86_64 converter >>> >>> Summary: >>> This is a register context converter from Minidump to Linux reg context. >>> This knows the layout of the register context in the Minidump file >>> (which is the same as in Windows FYI) and as a result emits a binary data >>> buffer that matches the Linux register context binary layout. >>> This way we can reuse the existing RegisterContextLinux_x86_64 and >>> RegisterContextCorePOSIX_x86_64 classes. >>> >>> Reviewers: labath, zturner >>> >>> Subscribers: beanz, mgorny, lldb-commits, amccarth >>> >>> Differential Revision: https://reviews.llvm.org/D24919 >>> >>> Added: >>> lldb/trunk/source/Plugins/Process/minidump/RegisterContextMi >>> nidump_x86_64.cpp >>> lldb/trunk/source/Plugins/Process/minidump/RegisterContextMi >>> nidump_x86_64.h >>> Modified: >>> lldb/trunk/include/lldb/lldb-private-types.h >>> lldb/trunk/source/Plugins/Process/minidump/CMakeLists.txt >>> lldb/trunk/source/Plugins/Process/minidump/MinidumpParser.cpp >>> lldb/trunk/source/Plugins/Process/minidump/MinidumpParser.h >>> lldb/trunk/unittests/Process/minidump/MinidumpParserTest.cpp >>> >>> Modified: lldb/trunk/include/lldb/lldb-private-types.h >>> URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/ >>> lldb-private-types.h?rev=282529&r1=282528&r2=282529&view=diff >>> >>> == >>> --- lldb/trunk/include/lldb/lldb-private-types.h (original) >>> +
[Lldb-commits] [lldb] r282632 - Add the ability for the task port to change when a process execs.
Author: gclayton
Date: Wed Sep 28 16:07:34 2016
New Revision: 282632
URL: http://llvm.org/viewvc/llvm-project?rev=282632&view=rev
Log:
Add the ability for the task port to change when a process execs.
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/exec/TestExec.py
lldb/trunk/tools/debugserver/source/MacOSX/MachException.cpp
lldb/trunk/tools/debugserver/source/MacOSX/MachTask.h
lldb/trunk/tools/debugserver/source/MacOSX/MachTask.mm
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/exec/TestExec.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/exec/TestExec.py?rev=282632&r1=282631&r2=282632&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/functionalities/exec/TestExec.py
(original)
+++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/exec/TestExec.py
Wed Sep 28 16:07:34 2016
@@ -27,7 +27,6 @@ class ExecTestCase(TestBase):
mydir = TestBase.compute_mydir(__file__)
@skipUnlessDarwin
-@expectedFailureAll(oslist=["macosx"], bugnumber="rdar://28476369")
def test(self):
if self.getArchitecture() == 'x86_64':
source = os.path.join(os.getcwd(), "main.cpp")
Modified: lldb/trunk/tools/debugserver/source/MacOSX/MachException.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/debugserver/source/MacOSX/MachException.cpp?rev=282632&r1=282631&r2=282632&view=diff
==
--- lldb/trunk/tools/debugserver/source/MacOSX/MachException.cpp (original)
+++ lldb/trunk/tools/debugserver/source/MacOSX/MachException.cpp Wed Sep 28
16:07:34 2016
@@ -106,15 +106,30 @@ catch_mach_exception_raise(mach_port_t e
(uint64_t)(exc_data_count > 0 ? exc_data[0] : 0xBADDBADD),
(uint64_t)(exc_data_count > 1 ? exc_data[1] : 0xBADDBADD));
}
+ g_message->exc_type = 0;
+ g_message->exc_data.clear();
if (task_port == g_message->task_port) {
g_message->task_port = task_port;
g_message->thread_port = thread_port;
g_message->exc_type = exc_type;
-g_message->exc_data.resize(exc_data_count);
-::memcpy(&g_message->exc_data[0], exc_data,
- g_message->exc_data.size() * sizeof(mach_exception_data_type_t));
+for (mach_msg_type_number_t i=0; iexc_data.push_back(exc_data[i]);
return KERN_SUCCESS;
+ } else if (!MachTask::IsValid(g_message->task_port)) {
+// Our original exception port isn't valid anymore check for a SIGTRAP
+if (exc_type == EXC_SOFTWARE && exc_data_count == 2 &&
+exc_data[0] == EXC_SOFT_SIGNAL && exc_data[1] == SIGTRAP) {
+ // We got a SIGTRAP which indicates we might have exec'ed and possibly
+ // lost our old task port during the exec, so we just need to switch over
+ // to using this new task port
+ g_message->task_port = task_port;
+ g_message->thread_port = thread_port;
+ g_message->exc_type = exc_type;
+ for (mach_msg_type_number_t i=0; iexc_data.push_back(exc_data[i]);
+ return KERN_SUCCESS;
+}
}
return KERN_FAILURE;
}
Modified: lldb/trunk/tools/debugserver/source/MacOSX/MachTask.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/debugserver/source/MacOSX/MachTask.h?rev=282632&r1=282631&r2=282632&view=diff
==
--- lldb/trunk/tools/debugserver/source/MacOSX/MachTask.h (original)
+++ lldb/trunk/tools/debugserver/source/MacOSX/MachTask.h Wed Sep 28 16:07:34
2016
@@ -82,6 +82,7 @@ public:
bool IsValid() const;
static bool IsValid(task_t task);
static void *ExceptionThread(void *arg);
+ void TaskPortChanged(task_t task);
task_t TaskPort() const { return m_task; }
task_t TaskPortForProcessID(DNBError &err, bool force = false);
static task_t TaskPortForProcessID(pid_t pid, DNBError &err,
Modified: lldb/trunk/tools/debugserver/source/MacOSX/MachTask.mm
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/debugserver/source/MacOSX/MachTask.mm?rev=282632&r1=282631&r2=282632&view=diff
==
--- lldb/trunk/tools/debugserver/source/MacOSX/MachTask.mm (original)
+++ lldb/trunk/tools/debugserver/source/MacOSX/MachTask.mm Wed Sep 28 16:07:34
2016
@@ -867,6 +867,16 @@ void *MachTask::ExceptionThread(void *ar
// TODO: notify of error?
} else {
if (exception_message.CatchExceptionRaise(task)) {
+if (exception_message.state.task_port != task) {
+ if (exception_message.state.IsValid()) {
+// We exec'ed and our task port changed on us.
+DNBLogThreadedIf(LOG_EXCEPTIONS,
+ "task port changed from 0x%4.4x to 0x%4.4x",
+ task, exception_message.state.task_port);
+task
[Lldb-commits] [lldb] r282648 - Fix an issue where libc++ changed the type information we get for std::map::iterator, rendering LLDB unable to display elements vended by an iterator
Author: enrico
Date: Wed Sep 28 17:53:16 2016
New Revision: 282648
URL: http://llvm.org/viewvc/llvm-project?rev=282648&view=rev
Log:
Fix an issue where libc++ changed the type information we get for
std::map::iterator, rendering LLDB unable to display elements vended by an
iterator
Fixes
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/iterator/TestDataFormatterLibccIterator.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/iterator/main.cpp
lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxx.cpp
lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxx.h
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/iterator/TestDataFormatterLibccIterator.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/iterator/TestDataFormatterLibccIterator.py?rev=282648&r1=282647&r2=282648&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/iterator/TestDataFormatterLibccIterator.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/iterator/TestDataFormatterLibccIterator.py
Wed Sep 28 17:53:16 2016
@@ -65,9 +65,9 @@ class LibcxxIteratorDataFormatterTestCas
self.expect(
'frame variable iimI',
substrs=[
-'first = 0',
-'second = 12'])
-self.expect('expr iimI', substrs=['first = 0', 'second = 12'])
+'first = 43981',
+'second = 61681'])
+self.expect('expr iimI', substrs=['first = 43981', 'second = 61681'])
self.expect(
'frame variable simI',
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/iterator/main.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/iterator/main.cpp?rev=282648&r1=282647&r2=282648&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/iterator/main.cpp
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/iterator/main.cpp
Wed Sep 28 17:53:16 2016
@@ -20,23 +20,23 @@ typedef string_vector::iterator svter;
int main()
{
-intint_map iim;
- iim[0] = 12;
-
+ intint_map iim;
+ iim[0xABCD] = 0xF0F1;
+
strint_map sim;
sim["world"] = 42;
-
+
int_vector iv;
iv.push_back(3);
-
+
string_vector sv;
sv.push_back("hello");
iimter iimI = iim.begin();
simter simI = sim.begin();
-
+
ivter ivI = iv.begin();
svter svI = sv.begin();
-return 0; // Set break point at this line.
+ return 0; // Set break point at this line.
}
\ No newline at end of file
Modified: lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxx.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxx.cpp?rev=282648&r1=282647&r2=282648&view=diff
==
--- lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxx.cpp (original)
+++ lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxx.cpp Wed Sep 28 17:53:16
2016
@@ -27,6 +27,7 @@
#include "lldb/Host/Endian.h"
#include "lldb/Symbol/ClangASTContext.h"
#include "lldb/Target/Target.h"
+#include "lldb/Utility/ProcessStructReader.h"
using namespace lldb;
using namespace lldb_private;
@@ -247,12 +248,15 @@ lldb_private::formatters::LibcxxVectorBo
lldb_private::formatters::LibCxxMapIteratorSyntheticFrontEnd::
LibCxxMapIteratorSyntheticFrontEnd(lldb::ValueObjectSP valobj_sp)
-: SyntheticChildrenFrontEnd(*valobj_sp), m_pair_ptr() {
+: SyntheticChildrenFrontEnd(*valobj_sp), m_pair_ptr(), m_pair_sp() {
if (valobj_sp)
Update();
}
bool lldb_private::formatters::LibCxxMapIteratorSyntheticFrontEnd::Update() {
+ m_pair_sp.reset();
+ m_pair_ptr = nullptr;
+
ValueObjectSP valobj_sp = m_backend.GetSP();
if (!valobj_sp)
return false;
@@ -264,7 +268,9 @@ bool lldb_private::formatters::LibCxxMap
if (!valobj_sp)
return false;
-
+
+ static ConstString g___i_("__i_");
+
// this must be a ValueObject* because it is a child of the ValueObject we
are
// producing children for
// it if were a ValueObjectSP, we would end up with a loop (iterator ->
@@ -281,6 +287,57 @@ bool lldb_private::formatters::LibCxxMap
SyntheticChildr
Re: [Lldb-commits] [PATCH] D6127: Fix code formatting in lldbtest.py introduced with r220583.
Eugene.Zelenko added a subscriber: Eugene.Zelenko. Eugene.Zelenko closed this revision. Eugene.Zelenko added a comment. Committed in https://reviews.llvm.org/rL221467. https://reviews.llvm.org/D6127 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] Buildbot numbers for the last week of 9/18/2016 - 9/24/2016
Hello everyone, Below are some buildbot numbers for the last week of 9/18/2016 - 9/24/2016. Please see the same data in attached csv files: The longest time each builder was red during the last week; "Status change ratio" by active builder (percent of builds that changed the builder status from greed to red or from red to green); Count of commits by project; Number of completed builds, failed builds and average build time for successful builds per active builder; Average waiting time for a revision to get build result per active builder (response time). Thanks Galina The longest time each builder was red during the last week: buildername| was_red +--- sanitizer-x86_64-linux | 100:30:59 sanitizer-windows | 81:02:14 lldb-windows7-android | 41:27:41 clang-x86-win2008-selfhost | 33:29:10 clang-x64-ninja-win7 | 30:05:03 lldb-amd64-ninja-netbsd7 | 29:44:16 sanitizer-x86_64-linux-fuzzer | 21:18:27 clang-sphinx-docs | 21:08:21 libcxx-libcxxabi-libunwind-arm-linux-noexceptions | 17:35:43 libcxx-libcxxabi-libunwind-arm-linux | 14:37:42 perf-x86_64-penryn-O3-polly-before-vectorizer-detect-only | 12:23:30 clang-native-aarch64-full | 12:01:10 clang-atom-d525-fedora-rel | 08:44:43 clang-cmake-armv7-a15-selfhost-neon| 07:16:01 libcxx-libcxxabi-libunwind-x86_64-linux-debian | 07:06:45 clang-ppc64le-linux-multistage | 06:47:10 sanitizer-x86_64-linux-bootstrap | 06:22:07 clang-cmake-aarch64-full | 06:14:11 perf-x86_64-penryn-O3 | 05:53:34 sanitizer-x86_64-linux-fast| 05:16:49 clang-with-lto-ubuntu | 04:32:40 clang-cmake-aarch64-42vma | 04:23:51 clang-cmake-armv7-a15-full | 04:21:36 clang-cmake-thumbv7-a15| 04:07:36 clang-cmake-armv7-a15 | 04:07:35 sanitizer-ppc64be-linux| 04:02:48 sanitizer-ppc64le-linux| 04:01:18 clang-ppc64be-linux-multistage | 03:54:35 lldb-x86_64-darwin-13.4| 03:49:11 llvm-sphinx-docs | 03:07:32 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03 | 02:53:32 clang-bpf-build| 02:45:38 lldb-x86_64-ubuntu-14.04-buildserver | 02:43:44 llvm-mips-linux| 02:39:29 lld-x86_64-darwin13| 02:38:48 clang-x86_64-linux-selfhost-modules| 02:37:16 clang-ppc64be-linux-lnt| 02:35:48 clang-x86_64-debian-fast | 02:35:05 sanitizer-x86_64-linux-autoconf| 02:29:10 clang-ppc64le-linux| 02:02:21 clang-ppc64le-linux-lnt| 01:59:26 llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast | 01:58:14 lld-x86_64-win7| 01:53:09 clang-cmake-aarch64-quick | 01:44:28 clang-native-arm-lnt | 01:32:01 clang-3stage-ubuntu| 01:23:02 clang-cuda-build | 01:20:17 clang-ppc64be-linux| 01:18:45 clang-s390x-linux | 01:14:43 perf-x86_64-penryn-O3-polly-before-vectorizer-unprofitable | 01:08:31 lldb-x86_64-ubuntu-14.04-android | 01:07:44 lld-x86_64-freebsd | 01:01:18 perf-x86_64-penryn-O3-polly-parallel-fast | 00:59:36 lldb-x86_64-ubuntu-14.04-cmake | 00:57:15 clang-x86_64-linux-abi-test| 00:47:14 clang-x86-windows-msvc2015 | 00:39:42 llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast | 00:36:47 perf-x86_64-penryn-O3-polly-unprofitable | 00:34:56 clang-hexagon-elf | 00:29:01 polly-amd64-linux
[Lldb-commits] [lldb] r282653 - Introduced a null check to avoid a crash in a test on i386.
Author: spyffe
Date: Wed Sep 28 19:16:37 2016
New Revision: 282653
URL: http://llvm.org/viewvc/llvm-project?rev=282653&view=rev
Log:
Introduced a null check to avoid a crash in a test on i386.
Modified:
lldb/trunk/source/Target/StackFrame.cpp
Modified: lldb/trunk/source/Target/StackFrame.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Target/StackFrame.cpp?rev=282653&r1=282652&r2=282653&view=diff
==
--- lldb/trunk/source/Target/StackFrame.cpp (original)
+++ lldb/trunk/source/Target/StackFrame.cpp Wed Sep 28 19:16:37 2016
@@ -1419,6 +1419,10 @@ ValueObjectSP GetValueForDereferincingOf
Error error;
ValueObjectSP pointee = base->Dereference(error);
+
+ if (!pointee) {
+return ValueObjectSP();
+ }
if (offset >= 0 && uint64_t(offset) >= pointee->GetByteSize()) {
int64_t index = offset / pointee->GetByteSize();
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D25057: Fix ARM/AArch64 Step-Over watchpoint issue remove provision for duplicate watchpoints
omjavaid created this revision.
omjavaid added a reviewer: labath.
omjavaid added a subscriber: lldb-commits.
Herald added subscribers: samparker, srhines, danalbert, tberghammer, rengolin,
aemerson.
On ARM Linux targets watchpoints are reported by PTrace before the instruction
causing watchpoint to trigger is executed.
This means we cannot step-over watchpoint causing instruction as long as there
is watchpoint installed on that location.
For this reason we cannot have multiple watchpoint slots watching same region
word/byte/halfword etc as we have to disable watchpoint for stepping over and
only watchpoint index reported by lldb-server is disabled.
Similarly we cannot keep a single hardware watchpoint slot referring to
multiple watchpoints in LLDB. This actually means that hware watchpoint indexes
are exclusively assigned to a watchpoint and cannot be shared by other
watchpoint. Also no other watchpoint should watch same address already watched
by any other index.
More discussion on this can be found here:
https://reviews.llvm.org/D24610
This patch fixes issue with stepping over watchpoint by removing the provision
to enable multiple watchpoints referring to same hardware watchpoint slot (same
HW index). Also we restrict one watchpoint per word aligned address so
duplication of address will not be allowed to avoid any step-over failures.
I have also attached a test-case that tests this scenario.
https://reviews.llvm.org/D25057
Files:
packages/Python/lldbsuite/test/functionalities/watchpoint/multi_watchpoint_slots/Makefile
packages/Python/lldbsuite/test/functionalities/watchpoint/multi_watchpoint_slots/TestWatchpointMultipleSlots.py
packages/Python/lldbsuite/test/functionalities/watchpoint/multi_watchpoint_slots/main.c
source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.cpp
source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
Index: source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
===
--- source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
+++ source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
@@ -538,42 +538,34 @@
control_value |= ((1 << size) - 1) << 5;
control_value |= (2 << 1) | 1;
- // Iterate over stored watchpoints
- // Find a free wp_index or update reference count if duplicate.
+ // Iterate over stored watchpoints and find a free wp_index
wp_index = LLDB_INVALID_INDEX32;
for (uint32_t i = 0; i < m_max_hwp_supported; i++) {
if ((m_hwp_regs[i].control & 1) == 0) {
wp_index = i; // Mark last free slot
-} else if (m_hwp_regs[i].address == addr &&
- m_hwp_regs[i].control == control_value) {
- wp_index = i; // Mark duplicate index
- break;// Stop searching here
+}
+else if (m_hwp_regs[i].address == addr) {
+ return LLDB_INVALID_INDEX32; // We do not support duplicate watchpoints.
}
}
if (wp_index == LLDB_INVALID_INDEX32)
return LLDB_INVALID_INDEX32;
- // Add new or update existing watchpoint
- if ((m_hwp_regs[wp_index].control & 1) == 0) {
-// Update watchpoint in local cache
-m_hwp_regs[wp_index].real_addr = real_addr;
-m_hwp_regs[wp_index].address = addr;
-m_hwp_regs[wp_index].control = control_value;
-m_hwp_regs[wp_index].refcount = 1;
+ // Update watchpoint in local cache
+ m_hwp_regs[wp_index].real_addr = real_addr;
+ m_hwp_regs[wp_index].address = addr;
+ m_hwp_regs[wp_index].control = control_value;
-// PTRACE call to set corresponding watchpoint register.
-error = WriteHardwareDebugRegs(eDREGTypeWATCH);
+ // PTRACE call to set corresponding watchpoint register.
+ error = WriteHardwareDebugRegs(eDREGTypeWATCH);
-if (error.Fail()) {
- m_hwp_regs[wp_index].address = 0;
- m_hwp_regs[wp_index].control &= ~1;
- m_hwp_regs[wp_index].refcount = 0;
+ if (error.Fail()) {
+m_hwp_regs[wp_index].address = 0;
+m_hwp_regs[wp_index].control &= ~1;
- return LLDB_INVALID_INDEX32;
-}
- } else
-m_hwp_regs[wp_index].refcount++;
+return LLDB_INVALID_INDEX32;
+ }
return wp_index;
}
@@ -596,36 +588,25 @@
if (wp_index >= m_max_hwp_supported)
return false;
- // Update reference count if multiple references.
- if (m_hwp_regs[wp_index].refcount > 1) {
-m_hwp_regs[wp_index].refcount--;
-return true;
- } else if (m_hwp_regs[wp_index].refcount == 1) {
-// Create a backup we can revert to in case of failure.
-lldb::addr_t tempAddr = m_hwp_regs[wp_index].address;
-uint32_t tempControl = m_hwp_regs[wp_index].control;
-uint32_t tempRefCount = m_hwp_regs[wp_index].refcount;
+ // Create a backup we can revert to in case of failure.
+ lldb::addr_t tempAddr = m_hwp_regs[wp_index].address;
+ uint32_t tempControl = m_hwp_regs[wp_index].control;
+
+ // Update watchpoint in local cache
+ m_hwp_regs[wp_index].control &= ~1;
+ m_hwp_regs[wp_index
[Lldb-commits] [lldb] r282657 - Fixed TestObjCStructArgument/i386; expressions can now call ObjC class methods.
Author: spyffe
Date: Wed Sep 28 19:45:33 2016
New Revision: 282657
URL: http://llvm.org/viewvc/llvm-project?rev=282657&view=rev
Log:
Fixed TestObjCStructArgument/i386; expressions can now call ObjC class methods.
Modified:
lldb/trunk/source/Plugins/ExpressionParser/Clang/IRForTarget.cpp
lldb/trunk/source/Plugins/ExpressionParser/Clang/IRForTarget.h
Modified: lldb/trunk/source/Plugins/ExpressionParser/Clang/IRForTarget.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ExpressionParser/Clang/IRForTarget.cpp?rev=282657&r1=282656&r2=282657&view=diff
==
--- lldb/trunk/source/Plugins/ExpressionParser/Clang/IRForTarget.cpp (original)
+++ lldb/trunk/source/Plugins/ExpressionParser/Clang/IRForTarget.cpp Wed Sep 28
19:45:33 2016
@@ -73,7 +73,8 @@ IRForTarget::IRForTarget(lldb_private::C
const char *func_name)
: ModulePass(ID), m_resolve_vars(resolve_vars), m_func_name(func_name),
m_module(NULL), m_decl_map(decl_map), m_CFStringCreateWithBytes(NULL),
- m_sel_registerName(NULL), m_intptr_ty(NULL),
m_error_stream(error_stream),
+ m_sel_registerName(NULL), m_objc_getClass(NULL), m_intptr_ty(NULL),
+ m_error_stream(error_stream),
m_execution_unit(execution_unit), m_result_store(NULL),
m_result_is_pointer(false), m_reloc_placeholder(NULL),
m_entry_instruction_finder(FindEntryInstruction) {}
@@ -944,6 +945,172 @@ bool IRForTarget::RewriteObjCSelectors(B
return true;
}
+static bool IsObjCClassReference(Value *value) {
+ GlobalVariable *global_variable = dyn_cast(value);
+
+ if (!global_variable || !global_variable->hasName() ||
+ !global_variable->getName().startswith("OBJC_CLASS_REFERENCES_"))
+return false;
+
+ return true;
+}
+
+// This function does not report errors; its callers are responsible.
+bool IRForTarget::RewriteObjCClassReference(Instruction *class_load) {
+ lldb_private::Log *log(
+ lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_EXPRESSIONS));
+
+ LoadInst *load = dyn_cast(class_load);
+
+ if (!load)
+return false;
+
+ // Unpack the class name from the reference. In LLVM IR, a reference to an
+ // Objective-C class gets represented as
+ //
+ // %tmp = load %struct._objc_class*,
+ //%struct._objc_class** @OBJC_CLASS_REFERENCES_, align 4
+ //
+ // @"OBJC_CLASS_REFERENCES_ is a bitcast of a character array called
+ // @OBJC_CLASS_NAME_.
+ // @OBJC_CLASS_NAME contains the string.
+
+ // Find the pointer's initializer (a ConstantExpr with opcode BitCast)
+ // and get the string from its target
+
+ GlobalVariable *_objc_class_references_ =
+ dyn_cast(load->getPointerOperand());
+
+ if (!_objc_class_references_ ||
+ !_objc_class_references_->hasInitializer())
+return false;
+
+ Constant *ocr_initializer = _objc_class_references_->getInitializer();
+
+ ConstantExpr *ocr_initializer_expr = dyn_cast(ocr_initializer);
+
+ if (!ocr_initializer_expr ||
+ ocr_initializer_expr->getOpcode() != Instruction::BitCast)
+return false;
+
+ Value *ocr_initializer_base = ocr_initializer_expr->getOperand(0);
+
+ if (!ocr_initializer_base)
+return false;
+
+ // Find the string's initializer (a ConstantArray) and get the string from it
+
+ GlobalVariable *_objc_class_name_ =
+ dyn_cast(ocr_initializer_base);
+
+ if (!_objc_class_name_ || !_objc_class_name_->hasInitializer())
+return false;
+
+ Constant *ocn_initializer = _objc_class_name_->getInitializer();
+
+ ConstantDataArray *ocn_initializer_array =
+ dyn_cast(ocn_initializer);
+
+ if (!ocn_initializer_array->isString())
+return false;
+
+ std::string ocn_initializer_string = ocn_initializer_array->getAsString();
+
+ if (log)
+log->Printf("Found Objective-C class reference \"%s\"",
+ocn_initializer_string.c_str());
+
+ // Construct a call to objc_getClass
+
+ if (!m_objc_getClass) {
+lldb::addr_t objc_getClass_addr;
+
+static lldb_private::ConstString g_objc_getClass_str("objc_getClass");
+objc_getClass_addr = m_execution_unit.FindSymbol(g_objc_getClass_str);
+if (objc_getClass_addr == LLDB_INVALID_ADDRESS)
+ return false;
+
+if (log)
+ log->Printf("Found objc_getClass at 0x%" PRIx64,
+ objc_getClass_addr);
+
+// Build the function type: %struct._objc_class *objc_getClass(i8*)
+
+Type *class_type = load->getType();
+Type *type_array[1];
+type_array[0] = llvm::Type::getInt8PtrTy(m_module->getContext());
+
+ArrayRef ogC_arg_types(type_array, 1);
+
+llvm::Type *ogC_type =
+FunctionType::get(class_type, ogC_arg_types, false);
+
+// Build the constant containing the pointer to the function
+PointerType *ogC_ptr_ty = PointerType::getUnqual(ogC_type);
+Constant *ogC_addr_int =
+ConstantInt::get(m_intptr_ty, objc_getClass_addr, false);
+m_objc_getClass = Constant
Re: [Lldb-commits] [lldb] r282648 - Fix an issue where libc++ changed the type information we get for std::map::iterator, rendering LLDB unable to display elements vended by an iterator
On Wed, Sep 28, 2016 at 4:02 PM Enrico Granata via lldb-commits <
lldb-commits@lists.llvm.org> wrote:
>
> -
> +
> + static ConstString g___i_("__i_");
> +
>// this must be a ValueObject* because it is a child of the ValueObject
> we are
>// producing children for
>// it if were a ValueObjectSP, we would end up with a loop (iterator ->
> @@ -281,6 +287,57 @@ bool lldb_private::formatters::LibCxxMap
> SyntheticChildrenTraversal::None),
> nullptr)
> .get();
> +
> + if (!m_pair_ptr) {
> +m_pair_ptr = valobj_sp->GetValueForExpressionPath(".__i_.__ptr_",
> nullptr, nullptr, nullptr,
> +
> ValueObject::GetValueForExpressionPathOptions()
> +
> .DontCheckDotVsArrowSyntax()
> +
> .SetSyntheticChildrenTraversal(
> +
>ValueObject::GetValueForExpressionPathOptions::
> +
>SyntheticChildrenTraversal::None),
> + nullptr)
> +.get();
> +if (m_pair_ptr) {
> + auto __i_(valobj_sp->GetChildMemberWithName(g___i_, true));
>
Is there any reason we need to use such weird variable names? This looks
like undefined behavior to me. Variables with more than one adjacent
underscore are reserved.
> + lldb::TemplateArgumentKind kind;
> + if (!__i_) {
> +m_pair_ptr = nullptr;
> +return false;
> + }
> + CompilerType
> pair_type(__i_->GetCompilerType().GetTemplateArgument(0, kind));
> + std::string name; uint64_t bit_offset_ptr; uint32_t
> bitfield_bit_size_ptr; bool is_bitfield_ptr;
> + pair_type = pair_type.GetFieldAtIndex(0, name, &bit_offset_ptr,
> &bitfield_bit_size_ptr, &is_bitfield_ptr);
> + if (!pair_type) {
> +m_pair_ptr = nullptr;
> +return false;
> + }
> +
> + auto addr(m_pair_ptr->GetValueAsUnsigned(LLDB_INVALID_ADDRESS));
> + m_pair_ptr = nullptr;
> + if (addr && addr!=LLDB_INVALID_ADDRESS) {
>
Can you do an early return here?
> +ClangASTContext *ast_ctx =
> llvm::dyn_cast_or_null(pair_type.GetTypeSystem());
> +if (!ast_ctx)
> + return false;
> +CompilerType tree_node_type =
> ast_ctx->CreateStructForIdentifier(ConstString(), {
> +
> {"ptr0",ast_ctx->GetBasicType(lldb::eBasicTypeVoid).GetPointerType()},
> +
> {"ptr1",ast_ctx->GetBasicType(lldb::eBasicTypeVoid).GetPointerType()},
> +
> {"ptr2",ast_ctx->GetBasicType(lldb::eBasicTypeVoid).GetPointerType()},
> + {"cw",ast_ctx->GetBasicType(lldb::eBasicTypeBool)},
> + {"payload",pair_type}
> +});
> +DataBufferSP buffer_sp(new
> DataBufferHeap(tree_node_type.GetByteSize(nullptr),0));
> +ProcessSP process_sp(target_sp->GetProcessSP());
> +Error error;
> +process_sp->ReadMemory(addr, buffer_sp->GetBytes(),
> buffer_sp->GetByteSize(), error);
> +if (error.Fail())
> + return false;
> +DataExtractor extractor(buffer_sp, process_sp->GetByteOrder(),
> process_sp->GetAddressByteSize());
> +auto pair_sp = CreateValueObjectFromData("pair", extractor,
> valobj_sp->GetExecutionContextRef(), tree_node_type);
> +if (pair_sp)
> + m_pair_sp = pair_sp->GetChildAtIndex(4,true);
> + }
> +}
> + }
>
>return false;
> }
> @@ -293,9 +350,11 @@ size_t lldb_private::formatters::LibCxxM
> lldb::ValueObjectSP
>
>
> lldb_private::formatters::LibCxxMapIteratorSyntheticFrontEnd::GetChildAtIndex(
> size_t idx) {
> - if (!m_pair_ptr)
> -return lldb::ValueObjectSP();
> - return m_pair_ptr->GetChildAtIndex(idx, true);
> + if (m_pair_ptr)
> +return m_pair_ptr->GetChildAtIndex(idx, true);
> + if (m_pair_sp)
> +return m_pair_sp->GetChildAtIndex(idx, true);
> + return lldb::ValueObjectSP();
> }
>
> bool lldb_private::formatters::LibCxxMapIteratorSyntheticFrontEnd::
>
> Modified: lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxx.h
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxx.h?rev=282648&r1=282647&r2=282648&view=diff
>
> ==
> --- lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxx.h (original)
> +++ lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxx.h Wed Sep 28
> 17:53:16 2016
> @@ -81,6 +81,7 @@ public:
>
> private:
>ValueObject *m_pair_ptr;
> + lldb::ValueObjectSP m_pair_sp;
> };
>
> SyntheticChildrenFrontEnd *
>
>
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [lldb] r282657 - Fixed TestObjCStructArgument/i386; expressions can now call ObjC class methods.
On Wed, Sep 28, 2016 at 5:54 PM Sean Callanan via lldb-commits <
lldb-commits@lists.llvm.org> wrote:
> Author: spyffe
> Date: Wed Sep 28 19:45:33 2016
> New Revision: 282657
>
> URL: http://llvm.org/viewvc/llvm-project?rev=282657&view=rev
> Log:
> Fixed TestObjCStructArgument/i386; expressions can now call ObjC class
> methods.
>
>
>
> Modified:
> lldb/trunk/source/Plugins/ExpressionParser/Clang/IRForTarget.cpp
> lldb/trunk/source/Plugins/ExpressionParser/Clang/IRForTarget.h
>
> Modified: lldb/trunk/source/Plugins/ExpressionParser/Clang/IRForTarget.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ExpressionParser/Clang/IRForTarget.cpp?rev=282657&r1=282656&r2=282657&view=diff
>
> ==
> --- lldb/trunk/source/Plugins/ExpressionParser/Clang/IRForTarget.cpp
> (original)
> +++ lldb/trunk/source/Plugins/ExpressionParser/Clang/IRForTarget.cpp Wed
> Sep 28 19:45:33 2016
> @@ -73,7 +73,8 @@ IRForTarget::IRForTarget(lldb_private::C
> const char *func_name)
> : ModulePass(ID), m_resolve_vars(resolve_vars),
> m_func_name(func_name),
>m_module(NULL), m_decl_map(decl_map),
> m_CFStringCreateWithBytes(NULL),
> - m_sel_registerName(NULL), m_intptr_ty(NULL),
> m_error_stream(error_stream),
> + m_sel_registerName(NULL), m_objc_getClass(NULL), m_intptr_ty(NULL),
> + m_error_stream(error_stream),
>m_execution_unit(execution_unit), m_result_store(NULL),
>m_result_is_pointer(false), m_reloc_placeholder(NULL),
>m_entry_instruction_finder(FindEntryInstruction) {}
> @@ -944,6 +945,172 @@ bool IRForTarget::RewriteObjCSelectors(B
>return true;
> }
>
> +static bool IsObjCClassReference(Value *value) {
> + GlobalVariable *global_variable = dyn_cast(value);
>
If it's possible for value to be null, then you should use
dyn_cast_or_null. On the other hand, if it's not possible for value to be
null, then maybe it should be a reference.
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [lldb] r282659 - Re-commit the changes from r282565 that I had to back out because of
On Wed, Sep 28, 2016 at 6:09 PM Jason Molenda via lldb-commits <
lldb-commits@lists.llvm.org> wrote:
>
> +#include "x86AssemblyInspectionEngine.h"
> +
> +#include "llvm-c/Disassembler.h"
> +
> +#include "lldb/Core/Address.h"
> +#include "lldb/Symbol/UnwindPlan.h"
> +#include "lldb/Target/RegisterContext.h"
> +#include "lldb/Target/UnwindAssembly.h"
> +
> +using namespace lldb_private;
> +using namespace lldb;
> +
> +x86AssemblyInspectionEngine::x86AssemblyInspectionEngine(const ArchSpec
> &arch)
> +: m_cur_insn(nullptr), m_machine_ip_regnum(LLDB_INVALID_REGNUM),
> + m_machine_sp_regnum(LLDB_INVALID_REGNUM),
> + m_machine_fp_regnum(LLDB_INVALID_REGNUM),
> + m_lldb_ip_regnum(LLDB_INVALID_REGNUM),
> + m_lldb_sp_regnum(LLDB_INVALID_REGNUM),
> + m_lldb_fp_regnum(LLDB_INVALID_REGNUM),
>
+
> + m_reg_map(), m_arch(arch), m_cpu(k_cpu_unspecified), m_wordsize(-1),
> + m_register_map_initialized(false), m_disasm_context() {
>
You may or may not wish to take advantage of this, but since C++11 you can
initialize class members in the header file. So you could write:
uint32_t m_lldb_fp_regnum = LLDB_INVALID_REGNUM;
etc. This makes the constructors look a lot nicer, especially when you
have multiple overloads that all end up doing the same ugly initialization.
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r282683 - Add a unit test for an x86_64 assembly inspection of
Author: jmolenda
Date: Wed Sep 28 23:01:43 2016
New Revision: 282683
URL: http://llvm.org/viewvc/llvm-project?rev=282683&view=rev
Log:
Add a unit test for an x86_64 assembly inspection of
a large stack frame with lots of spilled registers.
While writing the i386 version of this test, it looks
like I found a bug in the 32-bit instruction profiler
code. I may ned to fix the assembly inspection engine
before I can finish writing that test, so I'm only
committing the 64-bit one tonight.
Modified:
lldb/trunk/unittests/UnwindAssembly/x86/Testx86AssemblyInspectionEngine.cpp
Modified:
lldb/trunk/unittests/UnwindAssembly/x86/Testx86AssemblyInspectionEngine.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/unittests/UnwindAssembly/x86/Testx86AssemblyInspectionEngine.cpp?rev=282683&r1=282682&r2=282683&view=diff
==
--- lldb/trunk/unittests/UnwindAssembly/x86/Testx86AssemblyInspectionEngine.cpp
(original)
+++ lldb/trunk/unittests/UnwindAssembly/x86/Testx86AssemblyInspectionEngine.cpp
Wed Sep 28 23:01:43 2016
@@ -43,27 +43,28 @@ protected:
// names should match the constants below. These will be the eRegisterKindLLDB
// register numbers.
-const char *x86_64_reg_names[] = {"rax", "rcx", "rdx", "rsp", "rbp", "rsi",
- "rdi", "r8", "r9", "r10", "r11", "r12",
- "r13", "r14", "r15", "rip"};
+const char *x86_64_reg_names[] = {"rax", "rbx", "rcx", "rdx", "rsp", "rbp",
+ "rsi", "rdi", "r8", "r9", "r10", "r11",
+ "r12", "r13", "r14", "r15", "rip"};
enum x86_64_regs {
k_rax = 0,
- k_rcx = 1,
- k_rdx = 2,
- k_rsp = 3,
- k_rbp = 4,
- k_rsi = 5,
- k_rdi = 6,
- k_r8 = 7,
- k_r9 = 8,
- k_r10 = 9,
- k_r11 = 10,
- k_r12 = 11,
- k_r13 = 12,
- k_r14 = 13,
- k_r15 = 14,
- k_rip = 15
+ k_rbx = 1,
+ k_rcx = 2,
+ k_rdx = 3,
+ k_rsp = 4,
+ k_rbp = 5,
+ k_rsi = 6,
+ k_rdi = 7,
+ k_r8 = 8,
+ k_r9 = 9,
+ k_r10 = 10,
+ k_r11 = 11,
+ k_r12 = 12,
+ k_r13 = 13,
+ k_r14 = 14,
+ k_r15 = 15,
+ k_rip = 16
};
// names should match the constants below. These will be the eRegisterKindLLDB
@@ -133,6 +134,7 @@ std::unique_ptr engine = Getx86_64Inspector();
+ // 'int main() { }' compiled for x86_64-apple-macosx with clang
uint8_t data[] = {
0x55, // offset 0 -- pushq %rbp
0x48, 0x89, 0xe5, // offset 1 -- movq %rsp, %rbp
@@ -208,6 +210,7 @@ TEST_F(Testx86AssemblyInspectionEngine,
TEST_F(Testx86AssemblyInspectionEngine, TestSimple32bitFrameFunction) {
std::unique_ptr engine = Geti386Inspector();
+ // 'int main() { }' compiled for i386-apple-macosx with clang
uint8_t data[] = {
0x55, // offset 0 -- pushl %ebp
0x89, 0xe5, // offset 1 -- movl %esp, %ebp
@@ -279,3 +282,159 @@ TEST_F(Testx86AssemblyInspectionEngine,
EXPECT_TRUE(regloc.IsAtCFAPlusOffset());
EXPECT_TRUE(regloc.GetOffset() == -4);
}
+
+TEST_F(Testx86AssemblyInspectionEngine, Test64bitFramelessBigStackFrame) {
+ std::unique_ptr engine = Getx86_64Inspector();
+
+ // this source file:
+ //
+ // #include
+ // int main (int argc, char **argv)
+ // {
+ //
+ // const int arrsize = 60;
+ // int buf[arrsize * arrsize];
+ // int accum = argc;
+ // for (int i = 0; i < arrsize; i++)
+ // for (int j = 0; j < arrsize; j++)
+ // {
+ // if (i > 0 && j > 0)
+ // {
+ // int n = buf[(i-1) * (j-1)] * 2;
+ // int m = buf[(i-1) * (j-1)] / 2;
+ // int j = buf[(i-1) * (j-1)] + 2;
+ // int k = buf[(i-1) * (j-1)] - 2;
+ // printf ("%d ", n + m + j + k);
+ // buf[(i-1) * (j-1)] += n - m + j - k;
+ // }
+ // buf[i*j] = accum++;
+ // }
+ //
+ // return buf[(arrsize * arrsize) - 2] + printf ("%d\n", buf[(arrsize *
+ // arrsize) - 3]);
+ // }
+ //
+ // compiled 'clang -fomit-frame-pointer -Os' for x86_64-apple-macosx
+
+ uint8_t data[] = {
+ 0x55, // offset 0 -- pushq %rbp
+ 0x41, 0x57, // offset 1 -- pushq %r15
+ 0x41, 0x56, // offset 3 -- pushq %r14
+ 0x41, 0x55, // offset 5 -- pushq %r13
+ 0x41, 0x54, // offset 7 -- pushq %r12
+ 0x53, // offset 9 -- pushq %rbx
+ 0x48, 0x81, 0xec, 0x68, 0x38, 0x00,
+ 0x00, // offset 10 -- subq $0x3868, %rsp
+
+ //
+
+ 0x48, 0x81, 0xc4, 0x68, 0x38, 0x00,
+ 0x00,// offset 17 -- addq $0x3868, %rsp
+ 0x5b,// offset 24 -- popq %rbx
+ 0x41, 0x5c, // offset 25 -- popq %r12
+ 0x41, 0x5d, // offset 27 -- popq %r13
+ 0x41, 0x5e, // offset 29 -- popq %r14
+ 0x41, 0x5f, // offset 31 -- popq %r15
+ 0x5d,
Re: [Lldb-commits] [lldb] r282683 - Add a unit test for an x86_64 assembly inspection of
On Wed, Sep 28, 2016 at 9:10 PM Jason Molenda via lldb-commits < lldb-commits@lists.llvm.org> wrote: > > + EXPECT_TRUE(regloc.GetOffset() == -8); > This should be EXPECT_EQ(-8, regloc.GetOffset()); That way if it fails, you'll get a handy error message that says: Expected: -8 Actual: -7 If you use EXPECT_TRUE, it's not going to tell you the actual value. The same goes for many other places in the file. Note that you're supposed to put the expected value *first*. The test is the same either way obviously, but it affects the printing of the above message. > + > + // these could be set to IsSame and be valid -- meaning that the > + // register value is the same as the caller's -- but I'd rather > + // they not be mentioned at all. > + EXPECT_TRUE(row_sp->GetRegisterInfo(k_rbp, regloc) == false); > + EXPECT_TRUE(row_sp->GetRegisterInfo(k_r15, regloc) == false); > + EXPECT_TRUE(row_sp->GetRegisterInfo(k_r14, regloc) == false); > + EXPECT_TRUE(row_sp->GetRegisterInfo(k_r13, regloc) == false); > + EXPECT_TRUE(row_sp->GetRegisterInfo(k_r12, regloc) == false); > + EXPECT_TRUE(row_sp->GetRegisterInfo(k_rbx, regloc) == false); > If you're using EXPECT_TRUE and EXPECT_FALSE, I think it's more intuitive to not use the comparison operator. The above is just EXPECT_FALSE(row_sp->GetRegisterInfo(k_rbx, regloc)); ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [lldb] r282683 - Add a unit test for an x86_64 assembly inspection of
Good suggestions, thanks. I'll fix those when I commit the 32-bit version of the same test. J > On Sep 28, 2016, at 9:28 PM, Zachary Turner wrote: > > > > On Wed, Sep 28, 2016 at 9:10 PM Jason Molenda via lldb-commits > wrote: > > + EXPECT_TRUE(regloc.GetOffset() == -8); > This should be > > EXPECT_EQ(-8, regloc.GetOffset()); > > That way if it fails, you'll get a handy error message that says: > > Expected: -8 > Actual: -7 > > If you use EXPECT_TRUE, it's not going to tell you the actual value. The > same goes for many other places in the file. Note that you're supposed to > put the expected value *first*. The test is the same either way obviously, > but it affects the printing of the above message. > > + > + // these could be set to IsSame and be valid -- meaning that the > + // register value is the same as the caller's -- but I'd rather > + // they not be mentioned at all. > + EXPECT_TRUE(row_sp->GetRegisterInfo(k_rbp, regloc) == false); > + EXPECT_TRUE(row_sp->GetRegisterInfo(k_r15, regloc) == false); > + EXPECT_TRUE(row_sp->GetRegisterInfo(k_r14, regloc) == false); > + EXPECT_TRUE(row_sp->GetRegisterInfo(k_r13, regloc) == false); > + EXPECT_TRUE(row_sp->GetRegisterInfo(k_r12, regloc) == false); > + EXPECT_TRUE(row_sp->GetRegisterInfo(k_rbx, regloc) == false); > If you're using EXPECT_TRUE and EXPECT_FALSE, I think it's more intuitive to > not use the comparison operator. The above is just > > EXPECT_FALSE(row_sp->GetRegisterInfo(k_rbx, regloc)); ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D25021: [LLDB][MIPS] Fix qProcessInfo to return correct pointer size based on ELF ABI
nitesh.jain added inline comments.
Comment at:
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp:1218
@@ +1217,3 @@
+response.Printf("eflags:%" PRIx32 ";", proc_arch.GetFlags());
+if (proc_triple.isArch64Bit()) {
+ if (proc_arch.IsMIPS()) {
clayborg wrote:
> labath wrote:
> > Why do we have the compilcated switch here. Can't we replace that with:
> > `response.Printf("ptrsize:%d;", proc_arch.GetAddressByteSize());` for all
> > sizes?
> labath: the default ptr size for MIPS64 is 8. We would need to modify
> ArchSpec.cpp to look at the flags for MIPS64 and change the pointer size to 4
> if the N32 is being used.
Greg: ArchSpec::GetAddressByteSize() will always return pointer size based on
abi. So for N64 (default for MIPS64) abi it will return pointer size as 8
labath: We can replace switch with ArchSpec::GetAddressByteSize().
Repository:
rL LLVM
https://reviews.llvm.org/D25021
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
