[Lldb-commits] [PATCH] D32271: Patch to Attach pid successfully from different dir
krytarowski added a comment. I have plan to revisit corresponding files in NetBSD and switch from kvm(3) to sysctl(3). But this is lower priority than Process Plugin right now. https://reviews.llvm.org/D32271 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32421: Fix segfault resulting from empty print prompt
xiaobai created this revision.
I have found a way to segfault lldb in 7 keystrokes! Steps to reproduce:
1. Launch lldb
2. Type `print` and hit enter. lldb will now prompt you to type a list of
expressions, followed by an empty line.
3. Hit enter, indicating the end of your input.
4. Segfault!
After some investigation, I've found the issue in Host/common/Editline.cpp.
Editline::MoveCursor() relies on m_input_lines not being empty when the `to`
argument is CursorPosition::BlockEnd. This scenario, as far as I can tell,
occurs in one specific instance: In Editline::EndOrAddLineCommand() when the
list of lines being processed contains exactly one string (""). Meeting this
condition is fairly simple, I have posted steps to reproduce above.
I see two options: check if the state of m_input_lines is valid while inside
Editline::MoveCursor(), or validate the state of m_input_lines before calling
Editline::MoveCursor(). I have chosen to do the latter, for these 2 reason:
1. This happens in one spot in under very specific conditions. Check for it
when it could occur, not every time you call Editline::MoveCursor().
2. I'm not sure how Editline::MoveCursor() should behave when m_input_lines is
empty, nor am I sure if it should be called. I have roughly 4-5 hours
experience with the code in Editline.cpp over the course of about 2 days, so
I'm treating this as a learning opportunity. :)
Let me know what you think and/or if you want more context. Thanks!
https://reviews.llvm.org/D32421
Files:
source/Host/common/Editline.cpp
Index: source/Host/common/Editline.cpp
===
--- source/Host/common/Editline.cpp
+++ source/Host/common/Editline.cpp
@@ -637,7 +637,11 @@
}
}
}
- MoveCursor(CursorLocation::EditingCursor, CursorLocation::BlockEnd);
+ // If the only line in m_input_lines was the empty string, m_input_lines
+ // will be empty.
+ if (!m_input_lines.empty()) {
+MoveCursor(CursorLocation::EditingCursor, CursorLocation::BlockEnd);
+ }
fprintf(m_output_file, "\n");
m_editor_status = EditorStatus::Complete;
return CC_NEWLINE;
Index: source/Host/common/Editline.cpp
===
--- source/Host/common/Editline.cpp
+++ source/Host/common/Editline.cpp
@@ -637,7 +637,11 @@
}
}
}
- MoveCursor(CursorLocation::EditingCursor, CursorLocation::BlockEnd);
+ // If the only line in m_input_lines was the empty string, m_input_lines
+ // will be empty.
+ if (!m_input_lines.empty()) {
+MoveCursor(CursorLocation::EditingCursor, CursorLocation::BlockEnd);
+ }
fprintf(m_output_file, "\n");
m_editor_status = EditorStatus::Complete;
return CC_NEWLINE;
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r301168 - Add more arguments to SocketAddress::GetAddressInfo
Author: labath
Date: Mon Apr 24 04:39:56 2017
New Revision: 301168
URL: http://llvm.org/viewvc/llvm-project?rev=301168&view=rev
Log:
Add more arguments to SocketAddress::GetAddressInfo
Summary:
the reason for this is two-fold:
- getaddrinfo without the extra arguments will return the same
(network-level) address multiple times, once for each supported
transport protocol, which is not what is usually intended (it certainly
wasn't in D31823)
- it enables us to rewrite the getaddrinfo member function in terms of
the static GetAddressInfo function.
Reviewers: beanz, tberghammer
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D32357
Modified:
lldb/trunk/include/lldb/Host/SocketAddress.h
lldb/trunk/source/Host/common/SocketAddress.cpp
lldb/trunk/unittests/Host/SocketAddressTest.cpp
Modified: lldb/trunk/include/lldb/Host/SocketAddress.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Host/SocketAddress.h?rev=301168&r1=301167&r2=301168&view=diff
==
--- lldb/trunk/include/lldb/Host/SocketAddress.h (original)
+++ lldb/trunk/include/lldb/Host/SocketAddress.h Mon Apr 24 04:39:56 2017
@@ -41,8 +41,9 @@ public:
//
// Static method to get all address information for a host and/or service
//
- static std::vector GetAddressInfo(const char *hostname,
- const char *servname);
+ static std::vector
+ GetAddressInfo(const char *hostname, const char *servname, int ai_family,
+ int ai_socktype, int ai_protocol, int ai_flags = 0);
//--
// Constructors and Destructors
Modified: lldb/trunk/source/Host/common/SocketAddress.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Host/common/SocketAddress.cpp?rev=301168&r1=301167&r2=301168&view=diff
==
--- lldb/trunk/source/Host/common/SocketAddress.cpp (original)
+++ lldb/trunk/source/Host/common/SocketAddress.cpp Mon Apr 24 04:39:56 2017
@@ -227,6 +227,18 @@ bool SocketAddress::getaddrinfo(const ch
int ai_flags) {
Clear();
+ auto addresses = GetAddressInfo(host, service, ai_family, ai_socktype,
ai_protocol, ai_flags);
+ if (!addresses.empty())
+*this = addresses[0];
+ return IsValid();
+}
+
+std::vector
+SocketAddress::GetAddressInfo(const char *hostname, const char *servname,
+ int ai_family, int ai_socktype, int ai_protocol,
+ int ai_flags) {
+ std::vector addr_list;
+
struct addrinfo hints;
memset(&hints, 0, sizeof(hints));
hints.ai_family = ai_family;
@@ -234,26 +246,8 @@ bool SocketAddress::getaddrinfo(const ch
hints.ai_protocol = ai_protocol;
hints.ai_flags = ai_flags;
- bool result = false;
- struct addrinfo *service_info_list = NULL;
- int err = ::getaddrinfo(host, service, &hints, &service_info_list);
- if (err == 0 && service_info_list) {
-*this = service_info_list;
-result = IsValid();
- }
-
- if (service_info_list)
-::freeaddrinfo(service_info_list);
-
- return result;
-}
-
-std::vector SocketAddress::GetAddressInfo(const char *hostname,
- const char *servname) {
- std::vector addr_list;
-
struct addrinfo *service_info_list = NULL;
- int err = ::getaddrinfo(hostname, servname, NULL, &service_info_list);
+ int err = ::getaddrinfo(hostname, servname, &hints, &service_info_list);
if (err == 0 && service_info_list) {
for (struct addrinfo *service_ptr = service_info_list; service_ptr != NULL;
service_ptr = service_ptr->ai_next) {
Modified: lldb/trunk/unittests/Host/SocketAddressTest.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/unittests/Host/SocketAddressTest.cpp?rev=301168&r1=301167&r2=301168&view=diff
==
--- lldb/trunk/unittests/Host/SocketAddressTest.cpp (original)
+++ lldb/trunk/unittests/Host/SocketAddressTest.cpp Mon Apr 24 04:39:56 2017
@@ -11,13 +11,9 @@
#include "lldb/Host/SocketAddress.h"
-namespace {
-class SocketAddressTest : public ::testing::Test {};
-}
-
using namespace lldb_private;
-TEST_F(SocketAddressTest, Set) {
+TEST(SocketAddressTest, Set) {
SocketAddress sa;
ASSERT_TRUE(sa.SetToLocalhost(AF_INET, 1138));
ASSERT_STREQ("127.0.0.1", sa.GetIPAddress().c_str());
@@ -34,12 +30,20 @@ TEST_F(SocketAddressTest, Set) {
ASSERT_EQ(1139, sa.GetPort());
}
+TEST(SocketAddressTest, GetAddressInfo) {
+ auto addr = SocketAddress::GetAddressInfo("127.0.0.1", nullptr, AF_UNSPEC,
+SOCK_STRE
[Lldb-commits] [PATCH] D32357: Add more arguments to SocketAddress::GetAddressInfo
This revision was automatically updated to reflect the committed changes.
Closed by commit rL301168: Add more arguments to SocketAddress::GetAddressInfo
(authored by labath).
Changed prior to commit:
https://reviews.llvm.org/D32357?vs=96160&id=96363#toc
Repository:
rL LLVM
https://reviews.llvm.org/D32357
Files:
lldb/trunk/include/lldb/Host/SocketAddress.h
lldb/trunk/source/Host/common/SocketAddress.cpp
lldb/trunk/unittests/Host/SocketAddressTest.cpp
Index: lldb/trunk/include/lldb/Host/SocketAddress.h
===
--- lldb/trunk/include/lldb/Host/SocketAddress.h
+++ lldb/trunk/include/lldb/Host/SocketAddress.h
@@ -41,8 +41,9 @@
//
// Static method to get all address information for a host and/or service
//
- static std::vector GetAddressInfo(const char *hostname,
- const char *servname);
+ static std::vector
+ GetAddressInfo(const char *hostname, const char *servname, int ai_family,
+ int ai_socktype, int ai_protocol, int ai_flags = 0);
//--
// Constructors and Destructors
Index: lldb/trunk/unittests/Host/SocketAddressTest.cpp
===
--- lldb/trunk/unittests/Host/SocketAddressTest.cpp
+++ lldb/trunk/unittests/Host/SocketAddressTest.cpp
@@ -11,13 +11,9 @@
#include "lldb/Host/SocketAddress.h"
-namespace {
-class SocketAddressTest : public ::testing::Test {};
-}
-
using namespace lldb_private;
-TEST_F(SocketAddressTest, Set) {
+TEST(SocketAddressTest, Set) {
SocketAddress sa;
ASSERT_TRUE(sa.SetToLocalhost(AF_INET, 1138));
ASSERT_STREQ("127.0.0.1", sa.GetIPAddress().c_str());
@@ -34,12 +30,20 @@
ASSERT_EQ(1139, sa.GetPort());
}
+TEST(SocketAddressTest, GetAddressInfo) {
+ auto addr = SocketAddress::GetAddressInfo("127.0.0.1", nullptr, AF_UNSPEC,
+SOCK_STREAM, IPPROTO_TCP);
+ ASSERT_EQ(1u, addr.size());
+ EXPECT_EQ(AF_INET, addr[0].GetFamily());
+ EXPECT_EQ("127.0.0.1", addr[0].GetIPAddress());
+}
+
#ifdef _WIN32
// we need to test our inet_ntop implementation for Windows XP
const char *inet_ntop(int af, const void *src, char *dst, socklen_t size);
-TEST_F(SocketAddressTest, inet_ntop) {
+TEST(SocketAddressTest, inet_ntop) {
const uint8_t address4[4] = {255, 0, 1, 100};
const uint8_t address6[16] = {0, 1, 2, 3, 4, 5, 6, 7,
8, 9, 10, 11, 12, 13, 255, 0};
Index: lldb/trunk/source/Host/common/SocketAddress.cpp
===
--- lldb/trunk/source/Host/common/SocketAddress.cpp
+++ lldb/trunk/source/Host/common/SocketAddress.cpp
@@ -227,33 +227,27 @@
int ai_flags) {
Clear();
+ auto addresses = GetAddressInfo(host, service, ai_family, ai_socktype, ai_protocol, ai_flags);
+ if (!addresses.empty())
+*this = addresses[0];
+ return IsValid();
+}
+
+std::vector
+SocketAddress::GetAddressInfo(const char *hostname, const char *servname,
+ int ai_family, int ai_socktype, int ai_protocol,
+ int ai_flags) {
+ std::vector addr_list;
+
struct addrinfo hints;
memset(&hints, 0, sizeof(hints));
hints.ai_family = ai_family;
hints.ai_socktype = ai_socktype;
hints.ai_protocol = ai_protocol;
hints.ai_flags = ai_flags;
- bool result = false;
- struct addrinfo *service_info_list = NULL;
- int err = ::getaddrinfo(host, service, &hints, &service_info_list);
- if (err == 0 && service_info_list) {
-*this = service_info_list;
-result = IsValid();
- }
-
- if (service_info_list)
-::freeaddrinfo(service_info_list);
-
- return result;
-}
-
-std::vector SocketAddress::GetAddressInfo(const char *hostname,
- const char *servname) {
- std::vector addr_list;
-
struct addrinfo *service_info_list = NULL;
- int err = ::getaddrinfo(hostname, servname, NULL, &service_info_list);
+ int err = ::getaddrinfo(hostname, servname, &hints, &service_info_list);
if (err == 0 && service_info_list) {
for (struct addrinfo *service_ptr = service_info_list; service_ptr != NULL;
service_ptr = service_ptr->ai_next) {
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32340: [LLDB][MIPS] Fix TestMiExec.py failure
nitesh.jain updated this revision to Diff 96368.
nitesh.jain added a comment.
Update diff as per suggestion.
https://reviews.llvm.org/D32340
Files:
packages/Python/lldbsuite/test/tools/lldb-mi/control/TestMiExec.py
Index: packages/Python/lldbsuite/test/tools/lldb-mi/control/TestMiExec.py
===
--- packages/Python/lldbsuite/test/tools/lldb-mi/control/TestMiExec.py
+++ packages/Python/lldbsuite/test/tools/lldb-mi/control/TestMiExec.py
@@ -319,8 +319,14 @@
# -exec-step can keep us in the g_MyFunction for gcc
self.runCmd("-exec-finish --frame 0")
self.expect("\^running")
-self.expect(
-
"\*stopped,reason=\"end-stepping-range\".+?main\.cpp\",line=\"30\"")
+it =
self.expect(["\*stopped,reason=\"end-stepping-range\".+?main\.cpp\",line=\"30\"",
+
"\*stopped,reason=\"end-stepping-range\".+?main\.cpp\",line=\"29\""])
+
+if it == 1:
+# Call to s_MyFunction may not follow immediately after
g_MyFunction.
+# There might be some instructions in between to restore
caller-saved registers.
+# We need to get past these instructions with a step to reach call
to s_MyFunction.
+self.runCmd("-exec-step --thread 1")
# Test that -exec-step steps into s_MyFunction
# (and that --frame is optional)
Index: packages/Python/lldbsuite/test/tools/lldb-mi/control/TestMiExec.py
===
--- packages/Python/lldbsuite/test/tools/lldb-mi/control/TestMiExec.py
+++ packages/Python/lldbsuite/test/tools/lldb-mi/control/TestMiExec.py
@@ -319,8 +319,14 @@
# -exec-step can keep us in the g_MyFunction for gcc
self.runCmd("-exec-finish --frame 0")
self.expect("\^running")
-self.expect(
-"\*stopped,reason=\"end-stepping-range\".+?main\.cpp\",line=\"30\"")
+it = self.expect(["\*stopped,reason=\"end-stepping-range\".+?main\.cpp\",line=\"30\"",
+ "\*stopped,reason=\"end-stepping-range\".+?main\.cpp\",line=\"29\""])
+
+if it == 1:
+# Call to s_MyFunction may not follow immediately after g_MyFunction.
+# There might be some instructions in between to restore caller-saved registers.
+# We need to get past these instructions with a step to reach call to s_MyFunction.
+self.runCmd("-exec-step --thread 1")
# Test that -exec-step steps into s_MyFunction
# (and that --frame is optional)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32340: [LLDB][MIPS] Fix TestMiExec.py failure
nitesh.jain marked an inline comment as done. nitesh.jain added a comment. In https://reviews.llvm.org/D32340#733387, @ki.stfu wrote: > Thanks for catching this! Could you update this CL to let me commit it? Yes , Please commit it. https://reviews.llvm.org/D32340 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32366: Set "success" status correctly
labath added a comment. Thanks for the patch. Could you please also add an appropriate test for it? Doing something similar to what `packages/Python/lldbsuite/test/functionalities/frame_var/TestFrameVar.py` does should be the easiest way to test this. Repository: rL LLVM https://reviews.llvm.org/D32366 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32125: [LLVM][MIPS] Fix different definition of off_t in LLDB and LLVM
nitesh.jain added a comment. In https://reviews.llvm.org/D32125#734500, @emaste wrote: > In https://reviews.llvm.org/D32125#728166, @krytarowski wrote: > > > Is this just GNU specific? BSD moved to 64-bit off_t on 32-bit platforms > > 20+ years ago. > > > > It's perhaps no-op, but it might be noted in the commit message what > > platforms are supposed to be improved. > > > I'd say it's better to put a comment in the source where it's set. Added comment in the source. https://reviews.llvm.org/D32125 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32125: [LLVM][MIPS] Fix different definition of off_t in LLDB and LLVM
This revision was automatically updated to reflect the committed changes. Closed by commit rL301171: [LLVM][MIPS] Fix different definition of off_t in LLDB and LLVM. (authored by nitesh.jain). Changed prior to commit: https://reviews.llvm.org/D32125?vs=95573&id=96374#toc Repository: rL LLVM https://reviews.llvm.org/D32125 Files: llvm/trunk/cmake/modules/HandleLLVMOptions.cmake Index: llvm/trunk/cmake/modules/HandleLLVMOptions.cmake === --- llvm/trunk/cmake/modules/HandleLLVMOptions.cmake +++ llvm/trunk/cmake/modules/HandleLLVMOptions.cmake @@ -222,6 +222,13 @@ endif( LLVM_BUILD_32_BITS ) endif( CMAKE_SIZEOF_VOID_P EQUAL 8 AND NOT WIN32 ) +# If building on a GNU specific 32-bit system, make sure off_t is 64 bits +# so that off_t can stored offset > 2GB +if( CMAKE_SIZEOF_VOID_P EQUAL 4 ) + add_definitions( -D_LARGEFILE_SOURCE ) + add_definitions( -D_FILE_OFFSET_BITS=64 ) +endif() + if( XCODE ) # For Xcode enable several build settings that correspond to # many warnings that are on by default in Clang but are Index: llvm/trunk/cmake/modules/HandleLLVMOptions.cmake === --- llvm/trunk/cmake/modules/HandleLLVMOptions.cmake +++ llvm/trunk/cmake/modules/HandleLLVMOptions.cmake @@ -222,6 +222,13 @@ endif( LLVM_BUILD_32_BITS ) endif( CMAKE_SIZEOF_VOID_P EQUAL 8 AND NOT WIN32 ) +# If building on a GNU specific 32-bit system, make sure off_t is 64 bits +# so that off_t can stored offset > 2GB +if( CMAKE_SIZEOF_VOID_P EQUAL 4 ) + add_definitions( -D_LARGEFILE_SOURCE ) + add_definitions( -D_FILE_OFFSET_BITS=64 ) +endif() + if( XCODE ) # For Xcode enable several build settings that correspond to # many warnings that are on by default in Clang but are ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r301172 - [LLDB][MIPS] Move it into HandleLLVMOptions.cmake.
Author: nitesh.jain
Date: Mon Apr 24 05:56:01 2017
New Revision: 301172
URL: http://llvm.org/viewvc/llvm-project?rev=301172&view=rev
Log:
[LLDB][MIPS] Move it into HandleLLVMOptions.cmake.
The revison https://reviews.llvm.org/D32125 will fixed the off_t for GNU
specific 32 bit platform. This fixed the difference in definition of off_t in
LLDB and LLVM
Subscribers: jaydeep, bhushan, lldb-commits, slthakur, llvm-commits,
krytarowski, emaste, zturner
Modified:
lldb/trunk/cmake/modules/LLDBConfig.cmake
Modified: lldb/trunk/cmake/modules/LLDBConfig.cmake
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/cmake/modules/LLDBConfig.cmake?rev=301172&r1=301171&r2=301172&view=diff
==
--- lldb/trunk/cmake/modules/LLDBConfig.cmake (original)
+++ lldb/trunk/cmake/modules/LLDBConfig.cmake Mon Apr 24 05:56:01 2017
@@ -250,12 +250,6 @@ endif()
set(LLDB_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR})
set(LLDB_BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR})
-# If building on a 32-bit system, make sure off_t can store offsets > 2GB
-if( CMAKE_SIZEOF_VOID_P EQUAL 4 )
- add_definitions( -D_LARGEFILE_SOURCE )
- add_definitions( -D_FILE_OFFSET_BITS=64 )
-endif()
-
if (CMAKE_SOURCE_DIR STREQUAL CMAKE_BINARY_DIR)
message(FATAL_ERROR "In-source builds are not allowed. CMake would overwrite
"
"the makefiles distributed with LLDB. Please create a directory and run cmake "
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r301179 - Fix the new SocketAddressTest on Windows
Author: labath
Date: Mon Apr 24 08:34:35 2017
New Revision: 301179
URL: http://llvm.org/viewvc/llvm-project?rev=301179&view=rev
Log:
Fix the new SocketAddressTest on Windows
we need to call WSAStartup before we can use getaddrinfo.
Modified:
lldb/trunk/unittests/Host/SocketAddressTest.cpp
Modified: lldb/trunk/unittests/Host/SocketAddressTest.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/unittests/Host/SocketAddressTest.cpp?rev=301179&r1=301178&r2=301179&view=diff
==
--- lldb/trunk/unittests/Host/SocketAddressTest.cpp (original)
+++ lldb/trunk/unittests/Host/SocketAddressTest.cpp Mon Apr 24 08:34:35 2017
@@ -11,9 +11,26 @@
#include "lldb/Host/SocketAddress.h"
+namespace {
+class SocketAddressTest : public testing::Test {
+public:
+ static void SetUpTestCase() {
+#ifdef _MSC_VER
+WSADATA data;
+ASSERT_EQ(0, WSAStartup(MAKEWORD(2, 2), &data));
+#endif
+ }
+ static void TearDownTestCase() {
+#ifdef _MSC_VER
+ASSERT_EQ(0, WSACleanup());
+#endif
+ }
+};
+} // namespace
+
using namespace lldb_private;
-TEST(SocketAddressTest, Set) {
+TEST_F(SocketAddressTest, Set) {
SocketAddress sa;
ASSERT_TRUE(sa.SetToLocalhost(AF_INET, 1138));
ASSERT_STREQ("127.0.0.1", sa.GetIPAddress().c_str());
@@ -30,7 +47,7 @@ TEST(SocketAddressTest, Set) {
ASSERT_EQ(1139, sa.GetPort());
}
-TEST(SocketAddressTest, GetAddressInfo) {
+TEST_F(SocketAddressTest, GetAddressInfo) {
auto addr = SocketAddress::GetAddressInfo("127.0.0.1", nullptr, AF_UNSPEC,
SOCK_STREAM, IPPROTO_TCP);
ASSERT_EQ(1u, addr.size());
@@ -43,7 +60,7 @@ TEST(SocketAddressTest, GetAddressInfo)
// we need to test our inet_ntop implementation for Windows XP
const char *inet_ntop(int af, const void *src, char *dst, socklen_t size);
-TEST(SocketAddressTest, inet_ntop) {
+TEST_F(SocketAddressTest, inet_ntop) {
const uint8_t address4[4] = {255, 0, 1, 100};
const uint8_t address6[16] = {0, 1, 2, 3, 4, 5, 6, 7,
8, 9, 10, 11, 12, 13, 255, 0};
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32271: Patch to Attach pid successfully from different dir
emaste added a comment. In https://reviews.llvm.org/D32271#735098, @krytarowski wrote: > I have plan to revisit corresponding files in NetBSD and switch from kvm(3) > to sysctl(3). But this is lower priority than Process Plugin right now. Thanks for the note. I wasn't aware that you had that planned, but I incorporated the improvements you made in NetBSD's Host.cpp (early returns etc.) in order to reduce diffs and facilitate shared effort on these bits at some point. https://reviews.llvm.org/D32271 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32434: ObjectFileELF: Fix symbol lookup in bss section
labath created this revision.
Herald added a subscriber: mgorny.
If we have symbol information in a separate file, we need to be very
careful about presenting a unified section view of module to the rest of
the debugger. ObjectFileELF had code to handle that, but it was being
overly cautious -- the section->GetFileSize()!=0 meant that the
unification would fail for sections which do not occupy any space in the
object file (e.g., .bss). In my case, that manifested itself as not
being able to display the values of .bss variables properly as the
section associated with the variable did not have it's load address set
(because it was not present in the unified section list).
I test this by making sure the unified section list and the variables
refer to the same section.
https://reviews.llvm.org/D32434
Files:
source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
unittests/ObjectFile/ELF/CMakeLists.txt
unittests/ObjectFile/ELF/Inputs/test.c
unittests/ObjectFile/ELF/Inputs/test.dbg
unittests/ObjectFile/ELF/Inputs/test.strip
unittests/ObjectFile/ELF/TestObjectFileELF.cpp
Index: unittests/ObjectFile/ELF/TestObjectFileELF.cpp
===
--- /dev/null
+++ unittests/ObjectFile/ELF/TestObjectFileELF.cpp
@@ -0,0 +1,82 @@
+//===-- TestObjectFileELF.cpp ---*- C++ -*-===//
+//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "llvm/Support/Path.h"
+#include "Plugins/ObjectFile/ELF/ObjectFileELF.h"
+#include "lldb/Core/ModuleSpec.h"
+#include "lldb/Core/Module.h"
+#include "lldb/Core/Section.h"
+#include "lldb/Host/HostInfo.h"
+#include "gtest/gtest.h"
+
+#include "Plugins/SymbolVendor/ELF/SymbolVendorELF.h"
+
+extern const char *TestMainArgv0;
+
+using namespace lldb_private;
+using namespace lldb;
+
+class ObjectFileELFTest : public testing::Test {
+public:
+ void SetUp() override {
+HostInfo::Initialize();
+ObjectFileELF::Initialize();
+SymbolVendorELF::Initialize();
+
+llvm::StringRef exe_folder = llvm::sys::path::parent_path(TestMainArgv0);
+llvm::SmallString<128> inputs_folder = exe_folder;
+llvm::sys::path::append(inputs_folder, "Inputs");
+
+m_exe_stripped = m_exe_debug = inputs_folder;
+llvm::sys::path::append(m_exe_stripped, "test.strip");
+llvm::sys::path::append(m_exe_debug, "test.dbg");
+ }
+
+ void TearDown() override {
+SymbolVendorELF::Terminate();
+ObjectFileELF::Terminate();
+HostInfo::Terminate();
+ }
+
+protected:
+ llvm::SmallString<128> m_exe_stripped;
+ llvm::SmallString<128> m_exe_debug;
+};
+
+
+TEST_F(ObjectFileELFTest, SectionsResolveConsistently) {
+ ModuleSpec spec{FileSpec(m_exe_stripped, false)};
+ spec.GetSymbolFileSpec().SetFile(m_exe_debug, false);
+ auto module_sp = std::make_shared(spec);
+ SectionList *list = module_sp->GetSectionList();
+ ASSERT_NE(nullptr, list);
+
+ auto bss_sp = list->FindSectionByName(ConstString(".bss"));
+ ASSERT_NE(nullptr, bss_sp);
+ auto data_sp = list->FindSectionByName(ConstString(".data"));
+ ASSERT_NE(nullptr, data_sp);
+ auto text_sp = list->FindSectionByName(ConstString(".text"));
+ ASSERT_NE(nullptr, text_sp);
+
+ const Symbol *X = module_sp->FindFirstSymbolWithNameAndType(ConstString("X"),
+ eSymbolTypeAny);
+ ASSERT_NE(nullptr, X);
+ EXPECT_EQ(bss_sp, X->GetAddress().GetSection());
+
+ const Symbol *Y = module_sp->FindFirstSymbolWithNameAndType(ConstString("Y"),
+ eSymbolTypeAny);
+ ASSERT_NE(nullptr, Y);
+ EXPECT_EQ(data_sp, Y->GetAddress().GetSection());
+
+ const Symbol *start = module_sp->FindFirstSymbolWithNameAndType(
+ ConstString("_start"), eSymbolTypeAny);
+ ASSERT_NE(nullptr, start);
+ EXPECT_EQ(text_sp, start->GetAddress().GetSection());
+}
Index: unittests/ObjectFile/ELF/Inputs/test.c
===
--- /dev/null
+++ unittests/ObjectFile/ELF/Inputs/test.c
@@ -0,0 +1,5 @@
+// compile with: $CC test.c -nostdlib -g -o test.dbg
+// strip: objcopy --strip-debug test.dbg test.strip
+int X;
+int Y = 47;
+void _start() { X = Y; }
Index: unittests/ObjectFile/ELF/CMakeLists.txt
===
--- unittests/ObjectFile/ELF/CMakeLists.txt
+++ unittests/ObjectFile/ELF/CMakeLists.txt
@@ -1,7 +1,15 @@
add_lldb_unittest(ObjectFileELFTests
TestELFHeader.cpp
+ TestObjectFileELF.cpp
LINK_LIBS
lldbPluginObjectFileELF
+lldbPluginSymbolVendorELF
lldbCore
)
+
+set(test_inputs
+ test.strip
+ test.dbg
+ )
+add_unittest_inputs(ObjectFileELFTests "${test_inputs}")
Index: source/Plugins/ObjectFile/ELF/ObjectFileELF.
[Lldb-commits] [lldb] r301186 - Update two android XFAILS
Author: labath Date: Mon Apr 24 10:23:21 2017 New Revision: 301186 URL: http://llvm.org/viewvc/llvm-project?rev=301186&view=rev Log: Update two android XFAILS - XFAIL on TestNoreturnUnwind on all architectures - TestStaticVariables fails with clang-3.8 as well Modified: lldb/trunk/packages/Python/lldbsuite/test/functionalities/unwind/noreturn/TestNoreturnUnwind.py lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/class_static/TestStaticVariables.py Modified: lldb/trunk/packages/Python/lldbsuite/test/functionalities/unwind/noreturn/TestNoreturnUnwind.py URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/unwind/noreturn/TestNoreturnUnwind.py?rev=301186&r1=301185&r2=301186&view=diff == --- lldb/trunk/packages/Python/lldbsuite/test/functionalities/unwind/noreturn/TestNoreturnUnwind.py (original) +++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/unwind/noreturn/TestNoreturnUnwind.py Mon Apr 24 10:23:21 2017 @@ -17,7 +17,7 @@ class NoreturnUnwind(TestBase): mydir = TestBase.compute_mydir(__file__) @skipIfWindows # clang-cl does not support gcc style attributes. -@expectedFailureAndroid(bugnumber="llvm.org/pr31192", archs=["x86_64"]) +@expectedFailureAndroid(bugnumber="llvm.org/pr31192") @expectedFailureAll(bugnumber="llvm.org/pr31192", oslist=['linux'], compiler="gcc", archs=['arm']) def test(self): """Test that we can backtrace correctly with 'noreturn' functions on the stack""" Modified: lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/class_static/TestStaticVariables.py URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/class_static/TestStaticVariables.py?rev=301186&r1=301185&r2=301186&view=diff == --- lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/class_static/TestStaticVariables.py (original) +++ lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/class_static/TestStaticVariables.py Mon Apr 24 10:23:21 2017 @@ -61,7 +61,7 @@ class StaticVariableTestCase(TestBase): bugnumber="Compiler emits incomplete debug info") @expectedFailureAll( compiler=["clang"], -compiler_version=["<", "3.8"], +compiler_version=["<", "3.9"], bugnumber='llvm.org/pr20550') @add_test_categories(['pyapi']) def test_with_python_api(self): ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32441: Remove the home-grown android toolchain file and all references to it
labath created this revision. Herald added subscribers: mgorny, srhines. The toolchain file has been deprecated in favor of the "official" toolchain file present in the Android NDK. Also update the web build instructions to reflect this. https://reviews.llvm.org/D32441 Files: cmake/platforms/Android.cmake www/build.html Index: www/build.html === --- www/build.html +++ www/build.html @@ -354,9 +354,8 @@ the target architecture. Since you already have a checkout of clang and lldb, you can compile a host version of clang in a separate folder and use that. Alternatively you can use system clang or even cross-gcc if your distribution - provides such packages (e.g., g++-aarch64-linux-gnu on Ubuntu). On - Android, a working toolchain can be produced by downloading the Android NDK and - running the contained make-standalone-toolchain.sh script. + provides such packages (e.g., g++-aarch64-linux-gnu + on Ubuntu). @@ -381,11 +380,6 @@ - In the case of Android, all required headers and libraries are provided by the - aforementioned make-standalone-toolchain.sh script. - - - Once all of the dependencies are in place, it's just a matter of configuring the build system with the locations and arguments of all the necessary tools. The most important cmake options here are: @@ -472,38 +466,36 @@ Example 2: Cross-compiling for Android on Linux - All tools needed to build LLDB for android are available in the Android NDK. For - example, we can produce an x86 toolchain along with all the libraries and headers - by running + In the case of Android, the toolchain and all required headers and + libraries are available in the Android NDK. - - ./build/tools/make-standalone-toolchain.sh \ - --platform=android-21 \ - --toolchain=x86-4.9 \ - --install-dir=$HOME/Toolchains/x86-android-toolchain - + - from inside the unzipped NDK. Toolchains for other architectures can be produced in - a similar manner. + The NDK also contains a cmake toolchain file, which makes configuring the build much simpler. + The compiler, include and library paths will be configured by the + toolchain file and all you need to do is to select the + architecture (ANDROID_ABI) and platform level (ANDROID_PLATFORM, + should be at least 21). You will also need to set + ANDROID_ALLOW_UNDEFINED_SYMBOLS=On, as the toolchain file defaults + to "no undefined symbols in shared libraries", which is not + compatible with some llvm libraries. - - For Android we provide a Android.cmake script which sets a lot of the required - options automatically. A cmake build can therefore be prepared with the following parameters: + For example, the following arguments are sufficient to configure + an android arm64 build: - -DCMAKE_TOOLCHAIN_FILE=cmake/platforms/Android.cmake \ - -DANDROID_TOOLCHAIN_DIR=$HOME/Toolchains/x86-android-toolchain \ - -DANDROID_ABI=x86 \ - -DLLVM_HOST_TRIPLE=i386-unknown-linux-android \ - -DLLVM_TABLEGEN=/bin/llvm-tblgen \ - -DCLANG_TABLEGEN= /bin/clang-tblgen + -DCMAKE_TOOLCHAIN_FILE=$ANDROID_NDK_HOME/build/cmake/android.toolchain.cmake \ + -DANDROID_ABI=arm64-v8a \ + -DANDROID_PLATFORM=android-21 \ + -DANDROID_ALLOW_UNDEFINED_SYMBOLS=On \ + -DLLVM_HOST_TRIPLE=aarch64-unknown-linux-android \ + -DCROSS_TOOLCHAIN_FLAGS_NATIVE='-DCMAKE_C_COMPILER=cc;-DCMAKE_CXX_COMPILER=c++' - Note that the full LLVM build is not functional on android yet, so simply running - ninja will not work. You will need to manually specify the target you - want to build: lldb, lldb-server, etc. + Note that currently only lldb-server is functional on android. The + lldb client is supported and unlikely to work. Index: cmake/platforms/Android.cmake === --- cmake/platforms/Android.cmake +++ /dev/null @@ -1,155 +0,0 @@ -# Toolchain config for Android standalone NDK. -# -# Usage: -# build host llvm and clang first -# cmake -DCMAKE_TOOLCHAIN_FILE=../lldb/cmake/pl
[Lldb-commits] [PATCH] D32441: Remove the home-grown android toolchain file and all references to it
tberghammer added inline comments. Comment at: www/build.html:474-475 - from inside the unzipped NDK. Toolchains for other architectures can be produced in - a similar manner. + The NDK also contains a cmake toolchain file, which makes configuring the build much simpler. + The compiler, include and library paths will be configured by the + toolchain file and all you need to do is to select the Can you mention the minimum version of the NDK supported by this approach? Comment at: www/build.html:488-493 + -DCMAKE_TOOLCHAIN_FILE=$ANDROID_NDK_HOME/build/cmake/android.toolchain.cmake \ + -DANDROID_ABI=arm64-v8a \ + -DANDROID_PLATFORM=android-21 \ + -DANDROID_ALLOW_UNDEFINED_SYMBOLS=On \ + -DLLVM_HOST_TRIPLE=aarch64-unknown-linux-android \ + -DCROSS_TOOLCHAIN_FLAGS_NATIVE='-DCMAKE_C_COMPILER=cc;-DCMAKE_CXX_COMPILER=c++' Can you add some instructions about the supported ANDROID_ABI and LLVM_HOST_TRIPLE pairs? I would find it a bit hard to figure them out on my own (especially the correct triple) Comment at: www/build.html:488-493 + -DCMAKE_TOOLCHAIN_FILE=$ANDROID_NDK_HOME/build/cmake/android.toolchain.cmake \ + -DANDROID_ABI=arm64-v8a \ + -DANDROID_PLATFORM=android-21 \ + -DANDROID_ALLOW_UNDEFINED_SYMBOLS=On \ + -DLLVM_HOST_TRIPLE=aarch64-unknown-linux-android \ + -DCROSS_TOOLCHAIN_FLAGS_NATIVE='-DCMAKE_C_COMPILER=cc;-DCMAKE_CXX_COMPILER=c++' tberghammer wrote: > Can you add some instructions about the supported ANDROID_ABI and > LLVM_HOST_TRIPLE pairs? I would find it a bit hard to figure them out on my > own (especially the correct triple) Shouldn't we specify LLVM_TARGETS_TO_BUILD as well to reduce the size of the executable? Comment at: www/build.html:488-493 + -DCMAKE_TOOLCHAIN_FILE=$ANDROID_NDK_HOME/build/cmake/android.toolchain.cmake \ + -DANDROID_ABI=arm64-v8a \ + -DANDROID_PLATFORM=android-21 \ + -DANDROID_ALLOW_UNDEFINED_SYMBOLS=On \ + -DLLVM_HOST_TRIPLE=aarch64-unknown-linux-android \ + -DCROSS_TOOLCHAIN_FLAGS_NATIVE='-DCMAKE_C_COMPILER=cc;-DCMAKE_CXX_COMPILER=c++' tberghammer wrote: > tberghammer wrote: > > Can you add some instructions about the supported ANDROID_ABI and > > LLVM_HOST_TRIPLE pairs? I would find it a bit hard to figure them out on my > > own (especially the correct triple) > Shouldn't we specify LLVM_TARGETS_TO_BUILD as well to reduce the size of the > executable? Previously we specified LLVM_TARGET_ARCH as well. Is it not needed anymore? Comment at: www/build.html:498 + Note that currently only lldb-server is functional on android. The + lldb client is supported and unlikely to work. is *not* supported https://reviews.llvm.org/D32441 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32375: [DWARF] Fix lookup in the abstract origins of inlined blocks/functions
jingham added a comment.
Except for the comment about FindFirstChildWithAbstractOrigin, this seems fine.
Comment at: source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp:3723-3742
+static DWARFDIE FindAnyChildWithAbstractOrigin(const DWARFDIE &context) {
+ for (DWARFDIE candidate = context.GetFirstChild(); candidate.IsValid();
+ candidate = candidate.GetSibling()) {
+if (candidate.GetReferencedDIE(DW_AT_abstract_origin)) {
+ return candidate;
+}
+ }
The second of these functions seems dangerous since it doesn't check that
`block` is contained in `function`. As such, I'm not sure it's worth breaking
it out into a separate function rather than inlining it in
GetDeclContextForBlock, where that relationship is already known.
Repository:
rL LLVM
https://reviews.llvm.org/D32375
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32316: Change UniqueCStringMap to use ConstString as the key
scott.smith added a comment.
At a high level, I think there might be a misunderstanding on what I'm
attempting to do. It isn't to convert things that weren't ConstString into
things that are. It is instead to utilize the fact that we have all these
ConstString in order to improve the performance of various operations by
retaining the fact that they are ConstString. While a conversion from
ConstString to StringRef is relatively cheap (at least after a separate change
I have to remove the hashing of the string and the lock operation), the
conversion back to ConstString is expensive. If we pass around StringRef to
functions that need ConstString, then the performance will remain poor.
Comment at: include/lldb/Interpreter/Property.h:43
+ ConstString GetName() const { return m_name; }
+ ConstString GetDescription() const { return m_description; }
clayborg wrote:
> This shouldn't be const-ified, Only names of things like variables,
> enumerators, typenames, paths, and other strings that are going to be uniqued
> should go into the ConstStringPool
ok but note the original code - it's already storing m_name and m_description
as ConstString. All I'm doing is exposing the underlying type. Would you
prefer I change m_name and m_description to be std::string instead? Otherwise
it won't actually save anything.
Also note that later uses take the names are put into m_name_to_index in the
option parser, which is a UniqueCString, which requires ConstString. I don't
know the code well enough to know whether all options or only some options go
through this, so I could see it being worth it to only convert to ConstString
at that point (for example, see source/Interpreter/OptionValueProperties.cpp in
this review).
Comment at: include/lldb/Symbol/ObjectFile.h:808-811
+ virtual ConstString
+ StripLinkerSymbolAnnotations(ConstString symbol_name) const {
+return symbol_name;
}
clayborg wrote:
> This actually doesn't need to change. Since it is merely stripping off parts
> of the string, this should really stay as a StringRef and it should return a
> StringRef. Change to use StringRef for return and for argument, or revert.
>
The only user of StripLinkerSymbolAnnotations immediately converts it to a
ConstString. Changing this back to using StringRef would mean an extra lookup
for architectures that do not override this function.
Comment at: include/lldb/Utility/ConstString.h:481
+ char operator[](size_t Index) const {
+assert(Index < GetLength() && "Invalid index!");
+return m_string[Index];
clayborg wrote:
> I really don't like the prospect of crashing the debugger if someone calls
> this with an invalid index. Many people ship with asserts on. I would either
> make it safe if it is indeed just for reporting or remove the assert.
This code is copied from StringRef, which is what lldb used before this change.
Do you still want me to revert the assert?
Though IMO it should be changed to <=, not <, so that the null terminator can
be read safely.
Comment at: source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp:324-326
+ ConstString key_cstr = m_impl.GetCStringAtIndex(item);
+ if (strstr(type_name.GetCString(), key_cstr.GetCString())) {
+count += AppendReplacements(type_name, key_cstr, equivalents);
clayborg wrote:
> StringRef is better to use for modifying simple strings and looking for
> things. Actually looking at this class it is using ConstString all over the
> place for putting strings together. For creating strings we should use
> lldb_private::StreamString. For stripping stuff off and grabbing just part of
> a string, seeing if a string starts with, ends with, contains, etc,
> llvm::StringRef. So I would vote to just change it back, or fix the entire
> class to use lldb_private::StreamString
I can revert this fragment, but just note this won't affect the number of
ConstStrings that are generated. m_impl has ConstStrings in it, and type_name
is a ConstString, so yes they can be converted to StringRef just to call
StringRef::contains, or we can leave them as ConstString and utilize strstr.
Or, I can add ConstString::contains so the interface to ConstString and
StringRef is more similar.
Comment at: source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp:345-348
+ uint32_t AppendReplacements(ConstString original,
+ ConstString matching_key,
std::vector &equivalents) {
+std::string matching_key_str(matching_key.GetCString());
clayborg wrote:
> Ditto
In line 352 below, m_impl is a UniqueCStringMap, so all keys are ConstString.
The only way to look up in a UnqiueCStringMap is using ConstString, so
matching_key should remain a ConstString to prevent an unnecessary lookup.
Everything else is fo
[Lldb-commits] [PATCH] D32434: ObjectFileELF: Fix symbol lookup in bss section
eugene added a comment. Is it really necessary to check in binary ELF files? I understand that we don't always have a C compiler capable of producing ELF files, but maybe it's ok to skip this test on those platforms. https://reviews.llvm.org/D32434 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32375: [DWARF] Fix lookup in the abstract origins of inlined blocks/functions
spyffe added inline comments.
Comment at: source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp:3723-3742
+static DWARFDIE FindAnyChildWithAbstractOrigin(const DWARFDIE &context) {
+ for (DWARFDIE candidate = context.GetFirstChild(); candidate.IsValid();
+ candidate = candidate.GetSibling()) {
+if (candidate.GetReferencedDIE(DW_AT_abstract_origin)) {
+ return candidate;
+}
+ }
jingham wrote:
> The second of these functions seems dangerous since it doesn't check that
> `block` is contained in `function`. As such, I'm not sure it's worth
> breaking it out into a separate function rather than inlining it in
> GetDeclContextForBlock, where that relationship is already known.
I'll put in an `assert()` that `context` is a `DW_TAG_subprogram` or
`DW_TAG_inlined_subroutine` iff it is `== function` to make sure people use it
right.
Repository:
rL LLVM
https://reviews.llvm.org/D32375
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32434: ObjectFileELF: Fix symbol lookup in bss section
labath added a comment. In https://reviews.llvm.org/D32434#735877, @eugene wrote: > Is it really necessary to check in binary ELF files? > I understand that we don't always have a C compiler capable of producing ELF > files, but maybe it's ok to skip this test on those platforms. That is something very I am very much trying to avoid, as that means people on those platforms cannot validate their changes. (And I'm not sure if I even want to be running a compiler for a test at this level, as that introduces a level of nondeterminism.) That said, I do agree we should be carefully about adding lots of binary bloat. I have been trying to put this off until we have more of these, but maybe I could try integrating this with obj2yaml -- it does not seem to preserve program headers, but I don't actually need those for this test. https://reviews.llvm.org/D32434 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D32434: ObjectFileELF: Fix symbol lookup in bss section
Which C compilers do we have that are not capable of producing ELF binaries? GCC on Windows maybe? That's not even a supported test configuration. On Mon, Apr 24, 2017 at 2:29 PM Pavel Labath via Phabricator < revi...@reviews.llvm.org> wrote: > labath added a comment. > > In https://reviews.llvm.org/D32434#735877, @eugene wrote: > > > Is it really necessary to check in binary ELF files? > > I understand that we don't always have a C compiler capable of > producing ELF files, but maybe it's ok to skip this test on those platforms. > > > That is something very I am very much trying to avoid, as that means > people on those platforms cannot validate their changes. (And I'm not sure > if I even want to be running a compiler for a test at this level, as that > introduces a level of nondeterminism.) > > That said, I do agree we should be carefully about adding lots of binary > bloat. I have been trying to put this off until we have more of these, but > maybe I could try integrating this with obj2yaml -- it does not seem to > preserve program headers, but I don't actually need those for this test. > > > https://reviews.llvm.org/D32434 > > > > ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D32434: ObjectFileELF: Fix symbol lookup in bss section
Microsoft Visual C++ first comes to my mind. On Mon, Apr 24, 2017 at 2:31 PM, Zachary Turner wrote: > Which C compilers do we have that are not capable of producing ELF > binaries? GCC on Windows maybe? That's not even a supported test > configuration. > > On Mon, Apr 24, 2017 at 2:29 PM Pavel Labath via Phabricator < > revi...@reviews.llvm.org> wrote: > >> labath added a comment. >> >> In https://reviews.llvm.org/D32434#735877, @eugene wrote: >> >> > Is it really necessary to check in binary ELF files? >> > I understand that we don't always have a C compiler capable of >> producing ELF files, but maybe it's ok to skip this test on those platforms. >> >> >> That is something very I am very much trying to avoid, as that means >> people on those platforms cannot validate their changes. (And I'm not sure >> if I even want to be running a compiler for a test at this level, as that >> introduces a level of nondeterminism.) >> >> That said, I do agree we should be carefully about adding lots of binary >> bloat. I have been trying to put this off until we have more of these, but >> maybe I could try integrating this with obj2yaml -- it does not seem to >> preserve program headers, but I don't actually need those for this test. >> >> >> https://reviews.llvm.org/D32434 >> >> >> >> -- Thanks, Eugene Zemtsov. ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D32434: ObjectFileELF: Fix symbol lookup in bss section
We don't support running the test suite on Windows with MSVC. We run it with clang targeting windows instead. So anyone running the test suite on Windows is already using clang, and we can just specify a linux triple to get an ELF binary. On Mon, Apr 24, 2017 at 2:47 PM Eugene Zemtsov wrote: > Microsoft Visual C++ first comes to my mind. > > On Mon, Apr 24, 2017 at 2:31 PM, Zachary Turner > wrote: > >> Which C compilers do we have that are not capable of producing ELF >> binaries? GCC on Windows maybe? That's not even a supported test >> configuration. >> >> On Mon, Apr 24, 2017 at 2:29 PM Pavel Labath via Phabricator < >> revi...@reviews.llvm.org> wrote: >> >>> labath added a comment. >>> >>> In https://reviews.llvm.org/D32434#735877, @eugene wrote: >>> >>> > Is it really necessary to check in binary ELF files? >>> > I understand that we don't always have a C compiler capable of >>> producing ELF files, but maybe it's ok to skip this test on those platforms. >>> >>> >>> That is something very I am very much trying to avoid, as that means >>> people on those platforms cannot validate their changes. (And I'm not sure >>> if I even want to be running a compiler for a test at this level, as that >>> introduces a level of nondeterminism.) >>> >>> That said, I do agree we should be carefully about adding lots of binary >>> bloat. I have been trying to put this off until we have more of these, but >>> maybe I could try integrating this with obj2yaml -- it does not seem to >>> preserve program headers, but I don't actually need those for this test. >>> >>> >>> https://reviews.llvm.org/D32434 >>> >>> >>> >>> > > > -- > Thanks, > Eugene Zemtsov. > ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32434: ObjectFileELF: Fix symbol lookup in bss section
labath added a comment. > We don't support running the test suite on Windows with MSVC. We run it > with clang targeting windows instead. So anyone running the test suite on > Windows is already using clang, and we can just specify a linux triple to > get an ELF binary. You'll need a linker as well, which we do have in the form of lld, but I don't really want to pull in lld for the sake of this test. And I also used objcopy, although for this particular test we could probably do without it. However, my main question is: can you still call this a unit test if it calls out to a compiler to produce an object file? https://reviews.llvm.org/D32434 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D32434: ObjectFileELF: Fix symbol lookup in bss section
I suppose that's a reasonable concern. I also didn't notice that this was a unittest, I assumed it was a lit test. If that's the case, is there any way to use llvm/Object to construct a minimal ELF file in memory with a hardcoded symbol in the BSS section. It can even be missing certain critical things that would be normally required by an ELF file, and contain nothing but a single BSS section. Write it to some memory buffer, and then use ObjectFileELF to try to do a lookup on it. This way there's no input files of *any* kind. Is this possible? On Mon, Apr 24, 2017 at 3:09 PM Pavel Labath via Phabricator < revi...@reviews.llvm.org> wrote: > labath added a comment. > > > We don't support running the test suite on Windows with MSVC. We run it > > with clang targeting windows instead. So anyone running the test suite > on > > Windows is already using clang, and we can just specify a linux triple > to > > get an ELF binary. > > You'll need a linker as well, which we do have in the form of lld, but I > don't really want to pull in lld for the sake of this test. And I also used > objcopy, although for this particular test we could probably do without it. > > However, my main question is: can you still call this a unit test if it > calls out to a compiler to produce an object file? > > > https://reviews.llvm.org/D32434 > > > > ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32375: [DWARF] Fix lookup in the abstract origins of inlined blocks/functions
This revision was automatically updated to reflect the committed changes.
Closed by commit rL301263: [DWARF] Fix lookup in the abstract origins of
inlined blocks/functions (authored by spyffe).
Changed prior to commit:
https://reviews.llvm.org/D32375?vs=96229&id=96477#toc
Repository:
rL LLVM
https://reviews.llvm.org/D32375
Files:
lldb/trunk/packages/Python/lldbsuite/test/lang/c/inlines/main.c
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.h
lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
Index: lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
===
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
@@ -3682,7 +3682,7 @@
break;
case DW_TAG_lexical_block:
- decl_ctx = (clang::DeclContext *)ResolveBlockDIE(die);
+ decl_ctx = GetDeclContextForBlock(die);
try_parsing_type = false;
break;
@@ -3704,6 +3704,69 @@
return nullptr;
}
+static bool IsSubroutine(const DWARFDIE &die) {
+ switch (die.Tag()) {
+ case DW_TAG_subprogram:
+ case DW_TAG_inlined_subroutine:
+return true;
+ default:
+return false;
+ }
+}
+
+static DWARFDIE GetContainingFunctionWithAbstractOrigin(const DWARFDIE &die) {
+ for (DWARFDIE candidate = die; candidate; candidate = candidate.GetParent()) {
+if (IsSubroutine(candidate)) {
+ if (candidate.GetReferencedDIE(DW_AT_abstract_origin)) {
+return candidate;
+ } else {
+return DWARFDIE();
+ }
+}
+ }
+ assert(!"Shouldn't call GetContainingFunctionWithAbstractOrigin on something "
+ "not in a function");
+ return DWARFDIE();
+}
+
+static DWARFDIE FindAnyChildWithAbstractOrigin(const DWARFDIE &context) {
+ for (DWARFDIE candidate = context.GetFirstChild(); candidate.IsValid();
+ candidate = candidate.GetSibling()) {
+if (candidate.GetReferencedDIE(DW_AT_abstract_origin)) {
+ return candidate;
+}
+ }
+ return DWARFDIE();
+}
+
+static DWARFDIE FindFirstChildWithAbstractOrigin(const DWARFDIE &block,
+ const DWARFDIE &function) {
+ assert(IsSubroutine(function));
+ for (DWARFDIE context = block; context != function.GetParent();
+ context = context.GetParent()) {
+assert(!IsSubroutine(context) || context == function);
+if (DWARFDIE child = FindAnyChildWithAbstractOrigin(context)) {
+ return child;
+}
+ }
+ return DWARFDIE();
+}
+
+clang::DeclContext *
+DWARFASTParserClang::GetDeclContextForBlock(const DWARFDIE &die) {
+ assert(die.Tag() == DW_TAG_lexical_block);
+ DWARFDIE containing_function_with_abstract_origin =
+ GetContainingFunctionWithAbstractOrigin(die);
+ if (!containing_function_with_abstract_origin) {
+return (clang::DeclContext *)ResolveBlockDIE(die);
+ }
+ DWARFDIE child = FindFirstChildWithAbstractOrigin(
+ die, containing_function_with_abstract_origin);
+ CompilerDeclContext decl_context =
+ GetDeclContextContainingUIDFromDWARF(child);
+ return (clang::DeclContext *)decl_context.GetOpaqueDeclContext();
+}
+
clang::BlockDecl *DWARFASTParserClang::ResolveBlockDIE(const DWARFDIE &die) {
if (die && die.Tag() == DW_TAG_lexical_block) {
clang::BlockDecl *decl =
Index: lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.h
===
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.h
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.h
@@ -66,6 +66,8 @@
class DelayedAddObjCClassProperty;
typedef std::vector DelayedPropertyList;
+ clang::DeclContext *GetDeclContextForBlock(const DWARFDIE &die);
+
clang::BlockDecl *ResolveBlockDIE(const DWARFDIE &die);
clang::NamespaceDecl *ResolveNamespaceDIE(const DWARFDIE &die);
Index: lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
===
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -3051,7 +3051,13 @@
case DW_TAG_lexical_block:
case DW_TAG_subprogram:
return die;
-
+case DW_TAG_inlined_subroutine: {
+ DWARFDIE abs_die = die.GetReferencedDIE(DW_AT_abstract_origin);
+ if (abs_die) {
+return abs_die;
+ }
+ break;
+}
default:
break;
}
Index: lldb/trunk/packages/Python/lldbsuite/test/lang/c/inlines/main.c
===
--- lldb/trunk/packages/Python/lldbsuite/test/lang/c/inlines/main.c
+++ lldb/trunk/packages/Python/lldbsuite/test/lang/c/inlines/main.c
@@ -5,6 +5,11 @@
void test2(int b) {
[Lldb-commits] [lldb] r301263 - [DWARF] Fix lookup in the abstract origins of inlined blocks/functions
Author: spyffe
Date: Mon Apr 24 17:11:10 2017
New Revision: 301263
URL: http://llvm.org/viewvc/llvm-project?rev=301263&view=rev
Log:
[DWARF] Fix lookup in the abstract origins of inlined blocks/functions
LLDB uses clang::DeclContexts for lookups, and variables get put into
the DeclContext for their abstract origin. (The abstract origin is a
DWARF pointer that indicates the unique definition of inlined code.)
When the expression parser is looking for variables, it locates the
DeclContext for the current context. This needs to be done carefully,
though, e.g.:
__attribute__ ((always_inline)) void f(int a) {
{
int b = a * 2;
}
}
void g() {
f(3);
}
Here, if we're stopped in the inlined copy of f, we have to find the
DeclContext corresponding to the definition of f – its abstract
origin. Clang doesn't allow multiple functions with the same name and
arguments to exist. It also means that any variables we see must be
placed in the appropriate DeclContext.
[Bug 1]: When stopped in an inline block, the function
GetDeclContextDIEContainingDIE for that block doesn't properly
construct a DeclContext for the abstract origin for inlined
subroutines. That means we get duplicated function DeclContexts, but
function arguments only get put in the abstract origin's DeclContext,
and as a result when we try to look for them in nested contexts they
aren't found.
[Bug 2]: When stopped in an inline block, the DWARF (for space
reasons) doesn't explicitly point to the abstract origin for that
block. This means that the function GetClangDeclContextForDIE returns
a different DeclContext for each place the block is inlined. However,
any variables defined in the block have abstract origins, so they
will only get placed in the DeclContext for their abstract origin.
In this fix, I've introduced a test covering both of these issues,
and fixed them.
Bug 1 could be resolved simply by making sure we look up the abstract
origin for inlined functions when looking up their DeclContexts on
behalf of nested blocks.
For Bug 2, I've implemented an algorithm that makes the DeclContext
for a block be the containing DeclContext for the closest entity we
would find during lookup that has an abstract origin pointer. That
means that in the following situation:
{ // block 1
int a;
{ // block 2
int b;
}
}
if we looked up the DeclContext for block 2, we'd find the block
containing the abstract origin of b, and lookup would proceed
correctly because we'd see b and a. However, in the situation
{ // block 1
int a;
{ // block 2
}
}
since there isn't anything to look up in block 2, we can't determine
its abstract origin (and there is no such pointer in the DWARF for
blocks). However, we can walk up the parent chain and find a, and its
abstract origin lives in the abstract origin of block 1. So we simply
say that the DeclContext for block 2 is the same as the DeclContext
for block 1, which contains a. Lookups will return the same results.
Thanks to Jim Ingham for review and suggestions.
Differential revision: https://reviews.llvm.org/D32375
Modified:
lldb/trunk/packages/Python/lldbsuite/test/lang/c/inlines/main.c
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.h
lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
Modified: lldb/trunk/packages/Python/lldbsuite/test/lang/c/inlines/main.c
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/c/inlines/main.c?rev=301263&r1=301262&r2=301263&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/lang/c/inlines/main.c (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/lang/c/inlines/main.c Mon Apr 24
17:11:10 2017
@@ -5,6 +5,11 @@ inline void test2(int) __attribute__ ((a
void test2(int b) {
printf("test2(%d)\n", b); //% self.expect("expression b",
DATA_TYPES_DISPLAYED_CORRECTLY, substrs = ["42"])
+{
+ int c = b * 2;
+ printf("c=%d\n", c); //% self.expect("expression b",
DATA_TYPES_DISPLAYED_CORRECTLY, substrs = ["42"])
+ //% self.expect("expression c",
DATA_TYPES_DISPLAYED_CORRECTLY, substrs = ["84"])
+}
}
void test1(int a) {
Modified: lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp?rev=301263&r1=301262&r2=301263&view=diff
==
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
(original)
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp Mon Apr
24 17:11:10 2017
@@ -3682,7 +3682,7 @@ DWARFASTParserClang::GetClangDeclContext
break;
case DW_TAG_lexical_block:
- decl_ctx = (clang::DeclContext *)ResolveBlockDIE(die);
[Lldb-commits] [lldb] r301273 - [Expression parser] Return both types and variables
Author: spyffe
Date: Mon Apr 24 18:14:04 2017
New Revision: 301273
URL: http://llvm.org/viewvc/llvm-project?rev=301273&view=rev
Log:
[Expression parser] Return both types and variables
Many times a user wants to access a type when there's a variable of
the same name, or a variable when there's a type of the same name.
Depending on the precise context, currently the expression parser
can fail to resolve one or the other.
This is because ClangExpressionDeclMap has logic to limit the
amount of information it searches, and that logic sometimes cuts
down the search prematurely. This patch removes some of those early
exits.
In that sense, this patch trades performance (early exit is faster)
for correctness.
I've also included two new test cases showing examples of this
behavior – as well as modifying an existing test case that gets it
wrong.
Added:
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/llvm-style/
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/llvm-style/Makefile
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/llvm-style/TestLLVMStyle.py
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/llvm-style/main.cc
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/symbols/
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/symbols/Makefile
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/symbols/TestSymbols.py
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/symbols/main.cc
Modified:
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/nsimport/TestCppNsImport.py
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
Added: lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/llvm-style/Makefile
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/llvm-style/Makefile?rev=301273&view=auto
==
--- lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/llvm-style/Makefile
(added)
+++ lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/llvm-style/Makefile Mon
Apr 24 18:14:04 2017
@@ -0,0 +1,3 @@
+LEVEL = ../../../make
+C_SOURCES := main.c
+include $(LEVEL)/Makefile.rules
\ No newline at end of file
Added:
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/llvm-style/TestLLVMStyle.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/llvm-style/TestLLVMStyle.py?rev=301273&view=auto
==
---
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/llvm-style/TestLLVMStyle.py
(added)
+++
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/llvm-style/TestLLVMStyle.py
Mon Apr 24 18:14:04 2017
@@ -0,0 +1,7 @@
+from lldbsuite.test import lldbinline
+from lldbsuite.test import decorators
+
+lldbinline.MakeInlineTest(
+__file__, globals(), [
+decorators.expectedFailureAll(
+oslist=["windows"], bugnumber="llvm.org/pr24764")])
\ No newline at end of file
Added: lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/llvm-style/main.cc
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/llvm-style/main.cc?rev=301273&view=auto
==
--- lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/llvm-style/main.cc
(added)
+++ lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/llvm-style/main.cc Mon
Apr 24 18:14:04 2017
@@ -0,0 +1,36 @@
+//===-- main.cc -*- C++
-*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LIDENSE.TXT for details.
+//
+//===--===//
+
+namespace n {
+struct D {
+int i;
+static int anInt() { return 2; }
+int dump() { return i; }
+};
+
+class C {
+public:
+int foo(D *D);
+};
+}
+
+using namespace n;
+
+int C::foo(D* D) {
+return D->dump(); //% self.expect("expression -- D->dump()",
DATA_TYPES_DISPLAYED_CORRECTLY, substrs = ["int", "2"])
+ //% self.expect("expression -- D::anInt()",
DATA_TYPES_DISPLAYED_CORRECTLY, substrs = ["int", "2"])
+
+}
+
+int main (int argc, char const *argv[])
+{
+D myD { D::anInt() };
+C().foo(&myD);
+return 0;
+}
Modified:
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/nsimport/TestCppNsImport.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/nsimport/TestCppNsImport.py?rev=301273&r1=301272&r2=301273&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/nsimport/TestCppNsImport.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/nsimport/TestCppNsImport.py
Mon Apr 24 18:14:04 2017
[Lldb-commits] [PATCH] D32100: [Expression parser] Return both types and variables
spyffe closed this revision. spyffe added a comment. Closed by r301273 https://reviews.llvm.org/D32100 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32306: Remove lock from ConstString::GetLength
scott.smith added a comment. In https://reviews.llvm.org/D32306#733316, @labath wrote: > Looks good, thank you. > > Out of curiosity, have you observed any performance improvements resulting > from this? 10.2% reduction in # of instructions executed, 9.1% reduction in # of cycles, as measured by 'perf stat' in single threaded mode (I disabled TaskPool in order to get more repeatable results). Can you commit this for me? I don't have commit access. Thank you! Repository: rL LLVM https://reviews.llvm.org/D32306 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r301277 - Fixed two bad Makefiles that might be breaking Linux.
Author: spyffe Date: Mon Apr 24 18:49:06 2017 New Revision: 301277 URL: http://llvm.org/viewvc/llvm-project?rev=301277&view=rev Log: Fixed two bad Makefiles that might be breaking Linux. Modified: lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/llvm-style/Makefile lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/symbols/Makefile Modified: lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/llvm-style/Makefile URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/llvm-style/Makefile?rev=301277&r1=301276&r2=301277&view=diff == --- lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/llvm-style/Makefile (original) +++ lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/llvm-style/Makefile Mon Apr 24 18:49:06 2017 @@ -1,3 +1,3 @@ LEVEL = ../../../make -C_SOURCES := main.c +CXX_SOURCES := main.cpp include $(LEVEL)/Makefile.rules \ No newline at end of file Modified: lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/symbols/Makefile URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/symbols/Makefile?rev=301277&r1=301276&r2=301277&view=diff == --- lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/symbols/Makefile (original) +++ lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/symbols/Makefile Mon Apr 24 18:49:06 2017 @@ -1,3 +1,3 @@ LEVEL = ../../../make -C_SOURCES := main.c +CXX_SOURCES := main.cpp include $(LEVEL)/Makefile.rules ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D32271: Patch to Attach pid successfully from different dir
krytarowski added a comment. In https://reviews.llvm.org/D32271#735354, @emaste wrote: > In https://reviews.llvm.org/D32271#735098, @krytarowski wrote: > > > I have plan to revisit corresponding files in NetBSD and switch from kvm(3) > > to sysctl(3). But this is lower priority than Process Plugin right now. > > > Thanks for the note. I wasn't aware that you had that planned, but I > incorporated the improvements you made in NetBSD's Host.cpp (early returns > etc.) in order to reduce diffs and facilitate shared effort on these bits at > some point. At the moment at least attach to pid isn't functional on NetBSD. However good that the NetBSD code helped to improve FreeBSD. https://reviews.llvm.org/D32271 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r301280 - Name the C++ source files for two tests correctly.
Author: spyffe
Date: Mon Apr 24 18:58:36 2017
New Revision: 301280
URL: http://llvm.org/viewvc/llvm-project?rev=301280&view=rev
Log:
Name the C++ source files for two tests correctly.
Added:
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/llvm-style/main.cpp
- copied, changed from r301279,
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/llvm-style/main.cc
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/symbols/main.cpp
- copied, changed from r301279,
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/symbols/main.cc
Removed:
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/llvm-style/main.cc
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/symbols/main.cc
Removed: lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/llvm-style/main.cc
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/llvm-style/main.cc?rev=301279&view=auto
==
--- lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/llvm-style/main.cc
(original)
+++ lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/llvm-style/main.cc
(removed)
@@ -1,36 +0,0 @@
-//===-- main.cc -*- C++
-*-===//
-//
-// The LLVM Compiler Infrastructure
-//
-// This file is distributed under the University of Illinois Open Source
-// License. See LIDENSE.TXT for details.
-//
-//===--===//
-
-namespace n {
-struct D {
-int i;
-static int anInt() { return 2; }
-int dump() { return i; }
-};
-
-class C {
-public:
-int foo(D *D);
-};
-}
-
-using namespace n;
-
-int C::foo(D* D) {
-return D->dump(); //% self.expect("expression -- D->dump()",
DATA_TYPES_DISPLAYED_CORRECTLY, substrs = ["int", "2"])
- //% self.expect("expression -- D::anInt()",
DATA_TYPES_DISPLAYED_CORRECTLY, substrs = ["int", "2"])
-
-}
-
-int main (int argc, char const *argv[])
-{
-D myD { D::anInt() };
-C().foo(&myD);
-return 0;
-}
Copied: lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/llvm-style/main.cpp
(from r301279,
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/llvm-style/main.cc)
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/llvm-style/main.cpp?p2=lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/llvm-style/main.cpp&p1=lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/llvm-style/main.cc&r1=301279&r2=301280&rev=301280&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/llvm-style/main.cc
(original)
+++ lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/llvm-style/main.cpp Mon
Apr 24 18:58:36 2017
@@ -1,4 +1,4 @@
-//===-- main.cc -*- C++
-*-===//
+//===-- main.cpp *- C++
-*-===//
//
// The LLVM Compiler Infrastructure
//
Removed: lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/symbols/main.cc
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/symbols/main.cc?rev=301279&view=auto
==
--- lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/symbols/main.cc
(original)
+++ lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/symbols/main.cc (removed)
@@ -1,40 +0,0 @@
-//===-- main.cc -*- C++
-*-===//
-//
-// The LLVM Compiler Infrastructure
-//
-// This file is distributed under the University of Illinois Open Source
-// License. See LIDENSE.TXT for details.
-//
-//===--===//
-
-void *D = 0;
-
-class D {
-static int i;
-};
-
-int D::i = 3;
-
-namespace errno {
-int j = 4;
-};
-
-int twice(int n)
-{
-return n * 2; //% self.expect("expression -- D::i",
DATA_TYPES_DISPLAYED_CORRECTLY, substrs = ["int", "3"])
- //% self.expect("expression -- D",
DATA_TYPES_DISPLAYED_CORRECTLY, substrs = ["void"])
- //% self.expect("expression -- errno::j",
DATA_TYPES_DISPLAYED_CORRECTLY, substrs = ["int", "4"])
-}
-
-const char getAChar()
-{
-const char D[] = "Hello world";
-return D[0]; //% self.expect("expression -- D::i",
DATA_TYPES_DISPLAYED_CORRECTLY, substrs = ["int", "3"])
- //% self.expect("expression -- D",
DATA_TYPES_DISPLAYED_CORRECTLY, substrs = ["char", "Hello"])
-}
-
-int main (int argc, char const *argv[])
-{
-int six = twice(3);
-return 0;
-}
Copied: lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/symbols/main.cpp
(from r301279,
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/symbols/main.cc)
URL:
http://llvm.org/viewvc/l
[Lldb-commits] [PATCH] D32306: Remove lock from ConstString::GetLength
zturner added inline comments. Comment at: source/Utility/ConstString.cpp:49 + // pointer, we don't need the lock. const StringPoolEntryType &entry = GetStringMapEntryFromKeyData(ccstr); return entry.getKey().size(); Why do we even have this function which digs into the `StringMap` internals rather than just calling existing `StringMap` member functions? Can Can we just delete `GetStringMapEntryFromKeyData` entirely and use `StringMap::find`? Repository: rL LLVM https://reviews.llvm.org/D32306 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r301295 - [LLDB][MIPS] Fix typo in TestStepOverWatchpoint.py.
Author: nitesh.jain Date: Tue Apr 25 01:12:59 2017 New Revision: 301295 URL: http://llvm.org/viewvc/llvm-project?rev=301295&view=rev Log: [LLDB][MIPS] Fix typo in TestStepOverWatchpoint.py. Subscribers: jaydeep, bhushan, lldb-commits, slthakur Modified: lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/step_over_watchpoint/TestStepOverWatchpoint.py Modified: lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/step_over_watchpoint/TestStepOverWatchpoint.py URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/step_over_watchpoint/TestStepOverWatchpoint.py?rev=301295&r1=301294&r2=301295&view=diff == --- lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/step_over_watchpoint/TestStepOverWatchpoint.py (original) +++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/step_over_watchpoint/TestStepOverWatchpoint.py Tue Apr 25 01:12:59 2017 @@ -89,7 +89,7 @@ class TestStepOverWatchpoint(TestBase): # resolve_location=True, read=False, write=True write_watchpoint = write_value.Watch(True, False, True, error) -self.assertTrue(read_watchpoint, "Failed to set write watchpoint.") +self.assertTrue(write_watchpoint, "Failed to set write watchpoint.") self.assertTrue(error.Success(), "Error while setting watchpoint: %s" % error.GetCString()) ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
