[Lldb-commits] [lldb] r284114 - [lldb] Improve identification of Linux core dumps. Fix for bug #30485.
Author: rnchamberlain
Date: Thu Oct 13 07:11:00 2016
New Revision: 284114
URL: http://llvm.org/viewvc/llvm-project?rev=284114&view=rev
Log:
[lldb] Improve identification of Linux core dumps. Fix for bug #30485.
Summary:
ObjectFileELF::RefineModuleDetailsFromNote() identifies Linux core dumps by
searching for
library paths starting with /lib/x86_64-linux-gnu or /lib/i386-linux-gnu. This
change widens the
test to allow for linux installations which have addition directories in the
path.
Reviewers: ted, hhellyer, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D25179
Modified:
lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
Modified: lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp?rev=284114&r1=284113&r2=284114&view=diff
==
--- lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp (original)
+++ lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp Thu Oct 13
07:11:00 2016
@@ -1405,8 +1405,7 @@ ObjectFileELF::RefineModuleDetailsFromNo
return error;
}
llvm::StringRef path(cstr);
- if (path.startswith("/lib/x86_64-linux-gnu") ||
- path.startswith("/lib/i386-linux-gnu")) {
+ if (path.contains("/lib/x86_64-linux-gnu") ||
path.contains("/lib/i386-linux-gnu")) {
arch_spec.GetTriple().setOS(llvm::Triple::OSType::Linux);
break;
}
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] Instruction emulation of arm64 'stp d8, d9, [sp, #-0x70]!' style instruction
In case of Linux and Android we are using the qRegisterInfo packet and
lldb-server fills it in based on the register definitions inside LLDB so
for those targets it would be important to have all of the alias registers
available.
I don't have an AArch64-BE target at hand but I am pretty sure you are
right about the different register offsets. To handle both big and little
endian I think we will either have to create 2 separate copy of the
RegisterInfos or make it endian aware to correctly represent the offsets
because of the different offsets. I am pretty sure we currently handle it
incorrectly in case of ARM (where we have the alias registers) as we don't
have separate register contexts so if we find a way to fix the AArch64 case
then we should fix ARM as well. My preferred solution would be try to clean
up the large amount of code duplication from the RegisterInfo files and
then create correct data including all alias registers and endian aware
offsets using runtime loops instead of the current static arrays.
What do you think?
Tamas
On Thu, Oct 13, 2016 at 2:53 AM Jason Molenda wrote:
But if I attach to an arm64 core file, where lldb is using it's own
register definitions, then lldb has no idea what s0 is.
My concern about defining these subset registers in RegisterInfos_arm64.h
is that the offsets are in a target-endian register context buffer. My
example below was little-endian so the start of v0 was 268 bytes into the
register file and the offset of s0 is also 268 bytes. But in a BE target,
I think s0 would be at offset 280 in the buffer.
> On Oct 12, 2016, at 6:38 PM, Jason Molenda wrote:
>
> Yeah, it's incorrectly grabbing the stack pointer reg number (31) from
the Rn bits and using that as the register # being saved, instead of the Rt
and Rt2 register numbers, and saying that v31 is being pushed twice. It's
an easy bug in EmulateInstructionARM64::EmulateLDPSTP but fixing that just
presents us with the next problem so I haven't fixed it.
>
> When I connect to debugserver on an arm64 device, it tells lldb about the
pseudo regs on the device, like
>
>
>
>
>
>
>
>
>
>
>
>
> (this is the reply to the "qXfer:features:read:target.xml" packet that
lldb sends to debugserver at the startup of the debug session) so the user
can refer to these by name:
>
> (lldb) reg read -f x s0
> s0 = 0x404e809d
> (lldb) reg read -f x d0
> d0 = 0x41bdaf19404e809d
> (lldb) reg read -f x v0
> v0 = 0x41bdaf19404e809d
> (lldb)
>
>
> J
>
>> On Oct 12, 2016, at 6:23 PM, Tamas Berghammer
wrote:
>>
>> I am a bit surprised that we don't define the smaller floating point
registers on AArch64 the same way we do it on x86/x86_64/Arm (have no idea
about MIPS) and I would consider this as a bug what we should fix (will
gave it a try when I have a few free cycles) because currently it is very
difficult to get a 64bit double value out of the data we are displaying.
>>
>> Considering the fact that based on the ABI only the bottom 64bit have to
be saved I start to like the idea of teaching our unwinder about the
smaller floating point registers because that will mean that we can inspect
float and double variables from the parent stack frame while we never show
some corrupted data for variables occupying the full 128 bit vector
register.
>>
>> "...the unwind plan generated currently records this as v31 being
saved...": I don't understand this part. The code never references v31 nor
d31 so if the unwind plan records it as we saved v31 then something is
clearly wrong there. Does it treat all d0-d31 register as v31 because of
some instruction decoding reason?
>>
>> Tamas
>>
>> On Wed, Oct 12, 2016 at 4:30 PM Jason Molenda wrote:
>> Hi Tamas, sorry for that last email being a mess, I was doing something
else while writing it and only saw how unclear it was after I sent it. You
understood everything I was trying to say.
>>
>> I looked at the AAPCS64 again. It says v8-v15 are callee saved, but
says, "Additionally, only the bottom 64-bits of each value stored in v8-v15
need to be preserved[1]; it is the responsibility of the caller to preserve
larger values." so we're never going to have a full 128-bit value that we
can get off the stack (for targets following this ABI).
>>
>> DWARF can get away with only defining register numbers for v0-v31
because their use in DWARF always includes a byte size. Having lldb
register numbers and using that numbering scheme instead of DWARF is an
interesting one. It looks like all of the arm64 targets are using the
definitions from Plugins/Process/Utility/RegisterInfos_arm64.h. It also
only defines v0-v31 but the x86_64 RegisterInfos file defines pseudo
registers ("eax") which are a subset of real registers ("rax") - maybe we
could do something like that.
>>
>> I'm looking at this right now, but fwiw I wrote a small C program that
uses enough fp registers that the compiler will spill all of the preserved
registers (d8-d15) when I compile it with clang and -O
[Lldb-commits] [PATCH] D25487: Fix building tests without system headers on Darwin
tfiala added a comment. (Retro) yep, this looked fine. Repository: rL LLVM https://reviews.llvm.org/D25487 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D25488: Fix test suite lookup path for LLDB.h
tfiala added a comment. (Retro) LGTM. Repository: rL LLVM https://reviews.llvm.org/D25488 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D25489: Use LLDB_SRC for relative paths
tfiala added a comment. (Retro) LGTM. Repository: rL LLVM https://reviews.llvm.org/D25489 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D25490: [CMake] Cleanup check-lldb targets
tfiala added a comment. (Retro) Ah nice, I like the generator expression you put in there. Repository: rL LLVM https://reviews.llvm.org/D25490 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D25569: Minidump plugin: memory stuff and filtering module list
dvlahovski created this revision.
dvlahovski added reviewers: labath, zturner.
dvlahovski added subscribers: amccarth, lldb-commits.
Herald added subscribers: modocache, mgorny, beanz.
Now the Minidump parser can parse the:
1. MemoryInfoList - containing region info about memory ranges (readable,
writeable, executable)
2. Memory64List - this is the stuct used when the Minidump is a
full-memory one.
3. Adding filtering of the module list (shared libraries list) - there
can be mutliple records in the module list under the same name but with
different load address (e.g. when the binary has non contigious
sections). FilterModuleList eliminates the duplicated modules, leaving
the one with the lowest load addr.
Added unit tests for everything.
https://reviews.llvm.org/D25569
Files:
source/Plugins/Process/minidump/MinidumpParser.cpp
source/Plugins/Process/minidump/MinidumpParser.h
source/Plugins/Process/minidump/MinidumpTypes.cpp
source/Plugins/Process/minidump/MinidumpTypes.h
unittests/Process/minidump/CMakeLists.txt
unittests/Process/minidump/Inputs/fizzbuzz_wow64.dmp
unittests/Process/minidump/Inputs/linux-x86_64_not_crashed.dmp
unittests/Process/minidump/MinidumpParserTest.cpp
Index: unittests/Process/minidump/MinidumpParserTest.cpp
===
--- unittests/Process/minidump/MinidumpParserTest.cpp
+++ unittests/Process/minidump/MinidumpParserTest.cpp
@@ -19,6 +19,7 @@
#include "lldb/Core/ArchSpec.h"
#include "lldb/Core/DataExtractor.h"
#include "lldb/Host/FileSpec.h"
+#include "lldb/Target/MemoryRegionInfo.h"
#include "llvm/ADT/ArrayRef.h"
#include "llvm/ADT/Optional.h"
@@ -68,7 +69,11 @@
ASSERT_EQ(1UL, thread_list.size());
const MinidumpThread thread = thread_list[0];
- ASSERT_EQ(16001UL, thread.thread_id);
+
+ EXPECT_EQ(16001UL, thread.thread_id);
+
+ llvm::ArrayRef context = parser->GetThreadContext(thread);
+ EXPECT_EQ(1232UL, context.size());
}
TEST_F(MinidumpParserTest, GetThreadsTruncatedFile) {
@@ -131,14 +136,96 @@
}
}
+TEST_F(MinidumpParserTest, FilterModuleList) {
+ SetUpData("linux-x86_64_not_crashed.dmp");
+ llvm::ArrayRef modules = parser->GetModuleList();
+ std::vector filtered_modules = parser->FilterModuleList(modules);
+ EXPECT_GT(modules.size(), filtered_modules.size());
+ bool found = false;
+ for (size_t i = 0; i < filtered_modules.size(); ++i) {
+llvm::Optional name =
+parser->GetMinidumpString(filtered_modules[i]->module_name_rva);
+ASSERT_TRUE(name.hasValue());
+if (name.getValue() == "/tmp/test/linux-x86_64_not_crashed") {
+ ASSERT_FALSE(found) << "There should be only one module with this name in the filtered module list";
+ found = true;
+ ASSERT_EQ(0x40UL, filtered_modules[i]->base_of_image);
+}
+ }
+}
+
TEST_F(MinidumpParserTest, GetExceptionStream) {
SetUpData("linux-x86_64.dmp");
const MinidumpExceptionStream *exception_stream =
parser->GetExceptionStream();
ASSERT_NE(nullptr, exception_stream);
ASSERT_EQ(11UL, exception_stream->exception_record.exception_code);
}
+
+void check_mem_range_exists(std::unique_ptr &parser, const uint64_t range_start, const uint64_t range_size) {
+ llvm::Optional range = parser->FindMemoryRange(range_start);
+ ASSERT_TRUE(range.hasValue()) << "There is no range containing this address";
+ EXPECT_EQ(range_start, range->start);
+ EXPECT_EQ(range_start + range_size, range->start + range->range_ref.size());
+}
+
+TEST_F(MinidumpParserTest, GetMemoryRange) {
+ SetUpData("linux-x86_64.dmp");
+ // There are two memory ranges in the file (size is in bytes, decimal):
+ // 1) 0x401d46 256
+ // 2) 0x7ffceb34a000 12288
+ EXPECT_FALSE(parser->FindMemoryRange(0x00).hasValue());
+ EXPECT_FALSE(parser->FindMemoryRange(0x2a).hasValue());
+
+ check_mem_range_exists(parser, 0x401d46, 256);
+ EXPECT_FALSE(parser->FindMemoryRange(0x401d46 + 256).hasValue());
+
+ check_mem_range_exists(parser, 0x7ffceb34a000, 12288);
+ EXPECT_FALSE(parser->FindMemoryRange(0x7ffceb34a000 + 12288).hasValue());
+}
+
+TEST_F(MinidumpParserTest, GetMemoryRangeWithFullMemoryMinidump) {
+ SetUpData("fizzbuzz_wow64.dmp");
+
+ // There are a lot of ranges in the file, just testing with some of them
+ EXPECT_FALSE(parser->FindMemoryRange(0x00).hasValue());
+ EXPECT_FALSE(parser->FindMemoryRange(0x2a).hasValue());
+ check_mem_range_exists(parser, 0x1, 65536); // first range
+ check_mem_range_exists(parser, 0x4, 4096);
+ EXPECT_FALSE(parser->FindMemoryRange(0x4 + 4096).hasValue());
+ check_mem_range_exists(parser, 0x7ffe, 4096);
+ check_mem_range_exists(parser, 0x77c12000, 8192);
+ check_mem_range_exists(parser, 0x7ffe, 4096); // last range
+ EXPECT_FALSE(parser->FindMemoryRange(0x7ffe + 4096).hasValue());
+}
+
+void check_region_info(std::unique_ptr &parser, const uint64_t addr, bool read, bool write, bool exec) {
+ lldb_private::MemoryRegionInfo range_info;
+ Error
[Lldb-commits] [PATCH] D25570: [CMake] Populate LLDB.framework's headers directory
beanz created this revision.
beanz added reviewers: tfiala, zturner, spyffe.
beanz added a subscriber: lldb-commits.
Herald added a subscriber: mgorny.
This patch adds support for installing public headers in LLDB.framework, and
symlinking the headers into the build directory.
While writing the patch I discovered a bug in CMake that prevents applying
POST_BUILD steps to framework targets
(https://gitlab.kitware.com/cmake/cmake/issues/16363).
I've implemented the support using POST_BUILD steps wrapped under a CMake
version check with a TODO so that we can track the fix.
https://reviews.llvm.org/D25570
Files:
source/API/CMakeLists.txt
Index: source/API/CMakeLists.txt
===
--- source/API/CMakeLists.txt
+++ source/API/CMakeLists.txt
@@ -135,10 +135,26 @@
target_link_libraries(liblldb PRIVATE ${LLDB_SYSTEM_LIBS})
if(LLDB_BUILD_FRAMEWORK)
+ file(GLOB public_headers ${LLDB_SOURCE_DIR}/include/lldb/API/*.h)
set_target_properties(liblldb PROPERTIES
OUTPUT_NAME LLDB
FRAMEWORK On
FRAMEWORK_VERSION ${LLDB_FRAMEWORK_VERSION}
-LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/${LLDB_FRAMEWORK_INSTALL_DIR})
+LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/${LLDB_FRAMEWORK_INSTALL_DIR}
+PUBLIC_HEADER "${public_headers}")
+
+ # Due to a bug in CMake (https://gitlab.kitware.com/cmake/cmake/issues/16363)
+ # we can't actually put a POST_BUILD step on Framework targets.
+ # TODO: Once the bug linked above is fixed we can update the version check to
+ # a valid CMake version.
+ if(CMAKE_VERSION VERSION_GREATER 99.9)
+add_custom_command(TARGET liblldb POST_BUILD
+ COMMAND ${CMAKE_COMMAND} -E create_symlink
${LLDB_SOURCE_DIR}/include/lldb/API $/Headers)
+ else()
+add_custom_command(OUTPUT
${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/${LLDB_FRAMEWORK_INSTALL_DIR}/LLDB.framework/Versions/${LLDB_FRAMEWORK_VERSION}/Headers
+ COMMAND ${CMAKE_COMMAND} -E create_symlink
${LLDB_SOURCE_DIR}/include/lldb/API $/Headers)
+add_custom_target(lldb_header_symlink
+ DEPENDS
${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/${LLDB_FRAMEWORK_INSTALL_DIR}/LLDB.framework/Versions/${LLDB_FRAMEWORK_VERSION}/Headers)
+ endif()
endif()
Index: source/API/CMakeLists.txt
===
--- source/API/CMakeLists.txt
+++ source/API/CMakeLists.txt
@@ -135,10 +135,26 @@
target_link_libraries(liblldb PRIVATE ${LLDB_SYSTEM_LIBS})
if(LLDB_BUILD_FRAMEWORK)
+ file(GLOB public_headers ${LLDB_SOURCE_DIR}/include/lldb/API/*.h)
set_target_properties(liblldb PROPERTIES
OUTPUT_NAME LLDB
FRAMEWORK On
FRAMEWORK_VERSION ${LLDB_FRAMEWORK_VERSION}
-LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/${LLDB_FRAMEWORK_INSTALL_DIR})
+LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/${LLDB_FRAMEWORK_INSTALL_DIR}
+PUBLIC_HEADER "${public_headers}")
+
+ # Due to a bug in CMake (https://gitlab.kitware.com/cmake/cmake/issues/16363)
+ # we can't actually put a POST_BUILD step on Framework targets.
+ # TODO: Once the bug linked above is fixed we can update the version check to
+ # a valid CMake version.
+ if(CMAKE_VERSION VERSION_GREATER 99.9)
+add_custom_command(TARGET liblldb POST_BUILD
+ COMMAND ${CMAKE_COMMAND} -E create_symlink ${LLDB_SOURCE_DIR}/include/lldb/API $/Headers)
+ else()
+add_custom_command(OUTPUT ${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/${LLDB_FRAMEWORK_INSTALL_DIR}/LLDB.framework/Versions/${LLDB_FRAMEWORK_VERSION}/Headers
+ COMMAND ${CMAKE_COMMAND} -E create_symlink ${LLDB_SOURCE_DIR}/include/lldb/API $/Headers)
+add_custom_target(lldb_header_symlink
+ DEPENDS ${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/${LLDB_FRAMEWORK_INSTALL_DIR}/LLDB.framework/Versions/${LLDB_FRAMEWORK_VERSION}/Headers)
+ endif()
endif()
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D25569: Minidump plugin: memory stuff and filtering module list
dvlahovski updated this revision to Diff 74551.
dvlahovski added a comment.
Forgot to run clang-format. Also changed a helper function in the tests to make
it simpler.
https://reviews.llvm.org/D25569
Files:
source/Plugins/Process/minidump/MinidumpParser.cpp
source/Plugins/Process/minidump/MinidumpParser.h
source/Plugins/Process/minidump/MinidumpTypes.cpp
source/Plugins/Process/minidump/MinidumpTypes.h
unittests/Process/minidump/CMakeLists.txt
unittests/Process/minidump/Inputs/fizzbuzz_wow64.dmp
unittests/Process/minidump/Inputs/linux-x86_64_not_crashed.dmp
unittests/Process/minidump/MinidumpParserTest.cpp
Index: unittests/Process/minidump/MinidumpParserTest.cpp
===
--- unittests/Process/minidump/MinidumpParserTest.cpp
+++ unittests/Process/minidump/MinidumpParserTest.cpp
@@ -19,6 +19,7 @@
#include "lldb/Core/ArchSpec.h"
#include "lldb/Core/DataExtractor.h"
#include "lldb/Host/FileSpec.h"
+#include "lldb/Target/MemoryRegionInfo.h"
#include "llvm/ADT/ArrayRef.h"
#include "llvm/ADT/Optional.h"
@@ -68,7 +69,11 @@
ASSERT_EQ(1UL, thread_list.size());
const MinidumpThread thread = thread_list[0];
- ASSERT_EQ(16001UL, thread.thread_id);
+
+ EXPECT_EQ(16001UL, thread.thread_id);
+
+ llvm::ArrayRef context = parser->GetThreadContext(thread);
+ EXPECT_EQ(1232UL, context.size());
}
TEST_F(MinidumpParserTest, GetThreadsTruncatedFile) {
@@ -131,14 +136,98 @@
}
}
+TEST_F(MinidumpParserTest, FilterModuleList) {
+ SetUpData("linux-x86_64_not_crashed.dmp");
+ llvm::ArrayRef modules = parser->GetModuleList();
+ std::vector filtered_modules =
+ parser->FilterModuleList(modules);
+ EXPECT_GT(modules.size(), filtered_modules.size());
+ bool found = false;
+ for (size_t i = 0; i < filtered_modules.size(); ++i) {
+llvm::Optional name =
+parser->GetMinidumpString(filtered_modules[i]->module_name_rva);
+ASSERT_TRUE(name.hasValue());
+if (name.getValue() == "/tmp/test/linux-x86_64_not_crashed") {
+ ASSERT_FALSE(found) << "There should be only one module with this name "
+ "in the filtered module list";
+ found = true;
+ ASSERT_EQ(0x40UL, filtered_modules[i]->base_of_image);
+}
+ }
+}
+
TEST_F(MinidumpParserTest, GetExceptionStream) {
SetUpData("linux-x86_64.dmp");
const MinidumpExceptionStream *exception_stream =
parser->GetExceptionStream();
ASSERT_NE(nullptr, exception_stream);
ASSERT_EQ(11UL, exception_stream->exception_record.exception_code);
}
+void check_mem_range_exists(std::unique_ptr &parser,
+const uint64_t range_start,
+const uint64_t range_size) {
+ llvm::Optional range = parser->FindMemoryRange(range_start);
+ ASSERT_TRUE(range.hasValue()) << "There is no range containing this address";
+ EXPECT_EQ(range_start, range->start);
+ EXPECT_EQ(range_start + range_size, range->start + range->range_ref.size());
+}
+
+TEST_F(MinidumpParserTest, GetMemoryRange) {
+ SetUpData("linux-x86_64.dmp");
+ // There are two memory ranges in the file (size is in bytes, decimal):
+ // 1) 0x401d46 256
+ // 2) 0x7ffceb34a000 12288
+ EXPECT_FALSE(parser->FindMemoryRange(0x00).hasValue());
+ EXPECT_FALSE(parser->FindMemoryRange(0x2a).hasValue());
+
+ check_mem_range_exists(parser, 0x401d46, 256);
+ EXPECT_FALSE(parser->FindMemoryRange(0x401d46 + 256).hasValue());
+
+ check_mem_range_exists(parser, 0x7ffceb34a000, 12288);
+ EXPECT_FALSE(parser->FindMemoryRange(0x7ffceb34a000 + 12288).hasValue());
+}
+
+TEST_F(MinidumpParserTest, GetMemoryRangeWithFullMemoryMinidump) {
+ SetUpData("fizzbuzz_wow64.dmp");
+
+ // There are a lot of ranges in the file, just testing with some of them
+ EXPECT_FALSE(parser->FindMemoryRange(0x00).hasValue());
+ EXPECT_FALSE(parser->FindMemoryRange(0x2a).hasValue());
+ check_mem_range_exists(parser, 0x1, 65536); // first range
+ check_mem_range_exists(parser, 0x4, 4096);
+ EXPECT_FALSE(parser->FindMemoryRange(0x4 + 4096).hasValue());
+ check_mem_range_exists(parser, 0x77c12000, 8192);
+ check_mem_range_exists(parser, 0x7ffe, 4096); // last range
+ EXPECT_FALSE(parser->FindMemoryRange(0x7ffe + 4096).hasValue());
+}
+
+void check_region_info(std::unique_ptr &parser,
+ const uint64_t addr, MemoryRegionInfo::OptionalBool read,
+ MemoryRegionInfo::OptionalBool write,
+ MemoryRegionInfo::OptionalBool exec) {
+ lldb_private::MemoryRegionInfo range_info;
+ Error error = parser->GetMemoryRegionInfo(addr, range_info);
+ ASSERT_TRUE(error.Success());
+ EXPECT_EQ(read, range_info.GetReadable());
+ EXPECT_EQ(write, range_info.GetWritable());
+ EXPECT_EQ(exec, range_info.GetExecutable());
+}
+
+TEST_F(MinidumpParserTest, GetMemoryRegionInfo) {
+ SetUpData("fizzbuzz_wow64.dmp");
+
+ const auto yes = MemoryRegionInfo::eYes;
+ const auto no = MemoryR
[Lldb-commits] [PATCH] D25570: [CMake] Populate LLDB.framework's headers directory
beanz added a comment. Worth noting, the CMake bug now has a fix in a pull request: https://gitlab.kitware.com/cmake/cmake/merge_requests/172 https://reviews.llvm.org/D25570 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D25570: [CMake] Populate LLDB.framework's headers directory
tfiala accepted this revision. tfiala added a comment. This revision is now accepted and ready to land. LGTM. https://reviews.llvm.org/D25570 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D23977: Support of lldb on Kfreebsd
tfiala requested changes to this revision. tfiala added a comment. This revision now requires changes to proceed. Okay. I think we need a minor tweak, to drop the REQUIRED on the Backtrace usage. https://reviews.llvm.org/D23977 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r284182 - This test is passing on i386 now.
Author: jingham Date: Thu Oct 13 20:03:03 2016 New Revision: 284182 URL: http://llvm.org/viewvc/llvm-project?rev=284182&view=rev Log: This test is passing on i386 now. Modified: lldb/trunk/packages/Python/lldbsuite/test/lang/objc/objc-class-method/TestObjCClassMethod.py Modified: lldb/trunk/packages/Python/lldbsuite/test/lang/objc/objc-class-method/TestObjCClassMethod.py URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/objc/objc-class-method/TestObjCClassMethod.py?rev=284182&r1=284181&r2=284182&view=diff == --- lldb/trunk/packages/Python/lldbsuite/test/lang/objc/objc-class-method/TestObjCClassMethod.py (original) +++ lldb/trunk/packages/Python/lldbsuite/test/lang/objc/objc-class-method/TestObjCClassMethod.py Thu Oct 13 20:03:03 2016 @@ -24,9 +24,7 @@ class TestObjCClassMethod(TestBase): self.main_source, '// Set breakpoint here.') @skipUnlessDarwin -@expectedFailureAll(archs=["i[3-6]86"]) @add_test_categories(['pyapi']) -# rdar://problem/9745789 "expression" can't call functions in class methods def test_with_python_api(self): """Test calling functions in class methods.""" self.build() ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r284183 - This test passes on i386 now.
Author: jingham
Date: Thu Oct 13 20:11:19 2016
New Revision: 284183
URL: http://llvm.org/viewvc/llvm-project?rev=284183&view=rev
Log:
This test passes on i386 now.
Modified:
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/ivar-IMP/TestObjCiVarIMP.py
Modified:
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/ivar-IMP/TestObjCiVarIMP.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/objc/ivar-IMP/TestObjCiVarIMP.py?rev=284183&r1=284182&r2=284183&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/ivar-IMP/TestObjCiVarIMP.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/ivar-IMP/TestObjCiVarIMP.py
Thu Oct 13 20:11:19 2016
@@ -33,10 +33,6 @@ class ObjCiVarIMPTestCase(TestBase):
@no_debug_info_test
def test_imp_ivar_type(self):
"""Test that dynamically discovered ivars of type IMP do not crash
LLDB"""
-if self.getArchitecture() == 'i386':
-# rdar://problem/9946499
-self.skipTest("Dynamic types for ObjC V1 runtime not implemented")
-
execute_command("make repro")
def cleanup():
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D25592: [LLDB-MI] Minor cleanup of CMICmnLLDBUtilSBValue class
enlight created this revision.
enlight added reviewers: ki.stfu, abidh.
enlight added a subscriber: LLDB.
enlight set the repository for this revision to rL LLVM.
Placeholder c-strings don't need to be instance variables.
Repository:
rL LLVM
https://reviews.llvm.org/D25592
Files:
tools/lldb-mi/MICmnLLDBUtilSBValue.cpp
tools/lldb-mi/MICmnLLDBUtilSBValue.h
Index: tools/lldb-mi/MICmnLLDBUtilSBValue.h
===
--- tools/lldb-mi/MICmnLLDBUtilSBValue.h
+++ tools/lldb-mi/MICmnLLDBUtilSBValue.h
@@ -70,8 +70,6 @@
// Attributes:
private:
lldb::SBValue &m_rValue;
- const char *m_pUnkwn;
- const char *m_pComposite;
bool m_bValidSBValue; // True = SBValue is a valid object, false = not valid.
bool m_bHandleCharType; // True = Yes return text molding to char type, false
// = just return data.
Index: tools/lldb-mi/MICmnLLDBUtilSBValue.cpp
===
--- tools/lldb-mi/MICmnLLDBUtilSBValue.cpp
+++ tools/lldb-mi/MICmnLLDBUtilSBValue.cpp
@@ -18,6 +18,9 @@
#include "MICmnMIValueTuple.h"
#include "MIUtilString.h"
+static const char *kUnknownValue = "??";
+static const char *kCompositeValuePlaceholder = "{...}";
+
//++
//
// Details: CMICmnLLDBUtilSBValue constructor.
@@ -32,8 +35,8 @@
CMICmnLLDBUtilSBValue::CMICmnLLDBUtilSBValue(
const lldb::SBValue &vrValue, const bool vbHandleCharType /* = false */,
const bool vbHandleArrayType /* = true */)
-: m_rValue(const_cast(vrValue)), m_pUnkwn("??"),
- m_pComposite("{...}"), m_bHandleCharType(vbHandleCharType),
+: m_rValue(const_cast(vrValue)),
+ m_bHandleCharType(vbHandleCharType),
m_bHandleArrayType(vbHandleArrayType) {
m_bValidSBValue = m_rValue.IsValid();
}
@@ -80,7 +83,7 @@
CMIUtilString CMICmnLLDBUtilSBValue::GetValue(
const bool vbExpandAggregates /* = false */) const {
if (!m_bValidSBValue)
-return m_pUnkwn;
+return kUnknownValue;
CMICmnLLDBDebugSessionInfo &rSessionInfo(
CMICmnLLDBDebugSessionInfo::Instance());
@@ -98,7 +101,7 @@
return value;
if (!vbExpandAggregates && !bPrintExpandAggregates)
-return m_pComposite;
+return kCompositeValuePlaceholder;
bool bPrintAggregateFieldNames = false;
bPrintAggregateFieldNames =
@@ -110,7 +113,7 @@
CMICmnMIValueTuple miValueTuple;
const bool bOk = GetCompositeValue(bPrintAggregateFieldNames, miValueTuple);
if (!bOk)
-return m_pUnkwn;
+return kUnknownValue;
value = miValueTuple.GetString();
return value;
@@ -131,11 +134,11 @@
CMIUtilString &vwrValue) const {
const MIuint nChildren = m_rValue.GetNumChildren();
if (nChildren == 0) {
-vwrValue = GetValueSummary(!m_bHandleCharType && IsCharType(), m_pUnkwn);
+vwrValue = GetValueSummary(!m_bHandleCharType && IsCharType(), kUnknownValue);
return MIstatus::success;
} else if (IsPointerType()) {
vwrValue =
-GetValueSummary(!m_bHandleCharType && IsPointeeCharType(), m_pUnkwn);
+GetValueSummary(!m_bHandleCharType && IsPointeeCharType(), kUnknownValue);
return MIstatus::success;
} else if (IsArrayType()) {
CMICmnLLDBDebugSessionInfo &rSessionInfo(
@@ -187,13 +190,13 @@
miValueTuple, vnDepth + 1);
if (!bOk)
// Can't obtain composite type
-value = m_pUnkwn;
+value = kUnknownValue;
else
// OK. Value is composite and was successfully got
value = miValueTuple.GetString();
} else {
// Need to get value from composite type, but vnMaxDepth is reached
- value = m_pComposite;
+ value = kCompositeValuePlaceholder;
}
const bool bNoQuotes = true;
const CMICmnMIValueConst miValueConst(value, bNoQuotes);
@@ -404,7 +407,7 @@
const MIuint64 nReadBytes =
process.ReadMemory(addr, &ch, sizeof(ch), error);
if (error.Fail() || nReadBytes != sizeof(ch))
- return m_pUnkwn;
+ return kUnknownValue;
else if (ch == 0)
break;
result.append(
@@ -425,7 +428,7 @@
//--
bool CMICmnLLDBUtilSBValue::IsNameUnknown() const {
const CMIUtilString name(GetName());
- return (name == m_pUnkwn);
+ return (name == kUnknownValue);
}
//++
@@ -438,7 +441,7 @@
//--
bool CMICmnLLDBUtilSBValue::IsValueUnknown() const {
const CMIUtilString value(GetValue());
- return (value == m_pUnkwn);
+ return (value == kUnknownValue);
}
//++
@@ -451,7 +454,7 @@
//--
CMIUtilString CMICmnLLDBUtilSBValue::GetTypeName() const {
const char *pName = m_bValidSBValue ? m_rValue.GetTypeName() : nullptr;
- const CMIUtilString text((pName != nullptr) ? pName : m_pUnkwn);
+ const CMIUtilString text((pName != nullptr) ? pName : kUnknownValue);
return text;
}
@@ -466,7 +469,7 @@
[Lldb-commits] [PATCH] D25592: [LLDB-MI] Minor cleanup of CMICmnLLDBUtilSBValue class
ki.stfu requested changes to this revision.
ki.stfu added inline comments.
This revision now requires changes to proceed.
Comment at: tools/lldb-mi/MICmnLLDBUtilSBValue.cpp:21-22
+static const char *kUnknownValue = "??";
+static const char *kCompositeValuePlaceholder = "{...}";
+
use unnamed namespace here
Comment at: tools/lldb-mi/MICmnLLDBUtilSBValue.cpp:22
+static const char *kUnknownValue = "??";
+static const char *kCompositeValuePlaceholder = "{...}";
+
I dislike Placeholder suffix because the previous one is also a placeholder for
unknown values. How about renaming to
kUnresolvedValue/kUnresolvedCompositeValue?
Repository:
rL LLVM
https://reviews.llvm.org/D25592
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D25592: [LLDB-MI] Minor cleanup of CMICmnLLDBUtilSBValue class
enlight added inline comments.
Comment at: tools/lldb-mi/MICmnLLDBUtilSBValue.cpp:21-22
+static const char *kUnknownValue = "??";
+static const char *kCompositeValuePlaceholder = "{...}";
+
ki.stfu wrote:
> use unnamed namespace here
I would like to use an anonymous namespace but the [[
http://llvm.org/docs/CodingStandards.html#anonymous-namespaces | LLVM coding
standards ]] say
> make anonymous namespaces as small as possible, and only use them for class
> declarations
I don't really buy their reasoning, but we are supposed to be following their
style now aren't we?
kUnresolvedValue/kUnresolvedCompositeValue does sound better, I'll rename them.
Repository:
rL LLVM
https://reviews.llvm.org/D25592
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
