[Lldb-commits] [PATCH] D42145: [lldb] Use vFlash commands when writing to target's flash memory regions
labath added a comment.
First, I'd like to thank you for taking the time to create a method for testing
patches like these. I think this will be very valuable for all out-of-tree stub
support patches we will get in the future. Could I ask that you split out the
generic test-suite-stuff part of this into a separate patch. This will make it
easier to review and make sure it runs on the various buildbots that we have.
My first batch of comments is below, but I'll need to take a closer look at
this one more time.
Comment at: include/lldb/Target/Process.h:1916
+ //--
+ virtual bool BeginWriteMemoryBatch() { return true; }
+
Instead of this begin/end combo, what would you think about a WriteMemory
overload that takes a list of memory regions?
Something like:
```
struct WriteEntry { addr_t Dest; llvm::ArrayRef Contents; };
Status WriteMemory(llvm::ArrayRef);
```
Then the default implementation can just lower this into regular `WriteMemory`
sequence, and the gdb-remote class can add the extra packets around it when
needed.
Comment at:
packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestGDBRemoteLoad.py:43
+
+MEMORY_MAP = """
+
We will need a way to skip this test when lldb is compiled without libxml
support. This will be a bit tricky, as right now we don't have a mechanism for
passing build-configuration from cmake into dotest. I guess we will need some
equivalent of `lit.site.cfg.in`.
The thing that makes this tricky is that this will need to work from xcode as
well. As a transitional measure we could probably assume "true" if we don't
have that file, as I think the Xcode project is always configured to use libxml.
Comment at:
packages/Python/lldbsuite/test/functionalities/gdb_remote_client/gdbclientutils.py:13
+# Tries to find yaml2obj at the same folder as the lldb
+path = os.path.join(os.path.dirname(lldbtest_config.lldbExec), "yaml2obj")
+if os.path.exists(path):
We should also add yaml2obj as a dependency of the check-lldb target in cmake.
Comment at:
packages/Python/lldbsuite/test/functionalities/gdb_remote_client/gdbclientutils.py:301
+
+mydir = TestBase.compute_mydir(__file__)
+server = None
You can set `NO_DEBUG_INFO_TESTCASE = True` here, and avoid the decorators on
every test case.
Comment at: source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp:2962
+packet.Printf("vFlashWrite:%" PRIx64 ":", addr);
+GDBRemoteCommunication::WriteEscapedBinary(packet, buf, size);
+ } else {
This function is unnecessary. You should use StreamGDBRemote::PutEscapedBytes.
Comment at: source/Symbol/ObjectFile.cpp:671
+ continue;
+// We can skip sections like bss
+if (section_sp->GetFileSize() == 0)
You're not actually changing this part, but it caught my eye, and you may care
about this:
Is it true that we can ignore .bss here? Programs generally assume that .bss is
zero-initialized, and if you just ignore it here, it can contain whatever
garbage was in the memory before you loaded (?)
https://reviews.llvm.org/D42145
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D42083: [lldb][PPC64] Fixed long double variables dump
labath accepted this revision. labath added a comment. This revision is now accepted and ready to land. Awesome, thanks. https://reviews.llvm.org/D42083 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D42083: [lldb][PPC64] Fixed long double variables dump
luporl added a comment. @labath, can you please commit the changes for me? (I don't have permission to do it) https://reviews.llvm.org/D42083 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r322653 - Simplify some LogTest tests
Author: labath
Date: Wed Jan 17 05:46:06 2018
New Revision: 322653
URL: http://llvm.org/viewvc/llvm-project?rev=322653&view=rev
Log:
Simplify some LogTest tests
This removes boilerplate for setting up a log channel and capturing the
output from some of the tests. I do this by moving the setup code into a
test fixture and adding a logAndTakeOutput utility function to log some
string and then retrieve it from the log.
I also use some googlemock goodies to simplify a couple of assertions.
Modified:
lldb/trunk/unittests/Utility/LogTest.cpp
Modified: lldb/trunk/unittests/Utility/LogTest.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/unittests/Utility/LogTest.cpp?rev=322653&r1=322652&r2=322653&view=diff
==
--- lldb/trunk/unittests/Utility/LogTest.cpp (original)
+++ lldb/trunk/unittests/Utility/LogTest.cpp Wed Jan 17 05:46:06 2018
@@ -7,6 +7,7 @@
//
//===--===//
+#include "gmock/gmock.h"
#include "gtest/gtest.h"
#include "lldb/Utility/Log.h"
@@ -26,19 +27,6 @@ static constexpr uint32_t default_flags
static Log::Channel test_channel(test_categories, default_flags);
-struct LogChannelTest : public ::testing::Test {
- void TearDown() override { Log::DisableAllLogChannels(); }
-
- static void SetUpTestCase() {
-Log::Register("chan", test_channel);
- }
-
- static void TearDownTestCase() {
-Log::Unregister("chan");
-llvm::llvm_shutdown();
- }
-};
-
// Wrap enable, disable and list functions to make them easier to test.
static bool EnableChannel(std::shared_ptr stream_sp,
uint32_t log_options, llvm::StringRef channel,
@@ -64,6 +52,63 @@ static bool ListCategories(llvm::StringR
return Log::ListChannelCategories(channel, result_stream);
}
+namespace {
+// A test fixture which provides tests with a pre-registered channel.
+struct LogChannelTest : public ::testing::Test {
+ void TearDown() override { Log::DisableAllLogChannels(); }
+
+ static void SetUpTestCase() {
+Log::Register("chan", test_channel);
+ }
+
+ static void TearDownTestCase() {
+Log::Unregister("chan");
+llvm::llvm_shutdown();
+ }
+};
+
+// A test fixture which provides tests with a pre-registered and pre-enabled
+// channel. Additionally, the messages written to that channel are captured and
+// made available via getMessage().
+class LogChannelEnabledTest : public LogChannelTest {
+ llvm::SmallString<0> m_messages;
+ std::shared_ptr m_stream_sp =
+ std::make_shared(m_messages);
+ Log *m_log;
+ size_t m_consumed_bytes = 0;
+
+protected:
+ std::shared_ptr getStream() { return m_stream_sp; }
+ Log *getLog() { return m_log; }
+ llvm::StringRef takeOutput();
+ llvm::StringRef logAndTakeOutput(llvm::StringRef Message);
+
+public:
+ void SetUp() override;
+};
+} // end anonymous namespace
+
+void LogChannelEnabledTest::SetUp() {
+ LogChannelTest::SetUp();
+
+ std::string error;
+ ASSERT_TRUE(EnableChannel(m_stream_sp, 0, "chan", {}, error));
+
+ m_log = test_channel.GetLogIfAll(FOO);
+ ASSERT_NE(nullptr, m_log);
+}
+
+llvm::StringRef LogChannelEnabledTest::takeOutput() {
+ llvm::StringRef result = m_stream_sp->str().drop_front(m_consumed_bytes);
+ m_consumed_bytes+= result.size();
+ return result;
+}
+
+llvm::StringRef LogChannelEnabledTest::logAndTakeOutput(llvm::StringRef
Message) {
+ LLDB_LOG(m_log, "{0}", Message);
+ return takeOutput();
+}
+
TEST(LogTest, LLDB_LOG_nullptr) {
Log *log = nullptr;
LLDB_LOG(log, "{0}", 0); // Shouldn't crash
@@ -165,116 +210,83 @@ TEST_F(LogChannelTest, List) {
EXPECT_EQ("Invalid log channel 'chanchan'.\n", list);
}
-static std::string GetLogString(uint32_t log_options, const char *format,
-int arg) {
- std::string message;
- std::shared_ptr stream_sp(
- new llvm::raw_string_ostream(message));
- std::string error;
- llvm::raw_string_ostream error_stream(error);
- EXPECT_TRUE(
- Log::EnableLogChannel(stream_sp, log_options, "chan", {}, error_stream));
-
- Log *log = test_channel.GetLogIfAll(FOO);
- EXPECT_NE(nullptr, log);
-
- LLDB_LOG(log, format, arg);
- EXPECT_TRUE(Log::DisableLogChannel("chan", {}, error_stream));
-
- return stream_sp->str();
-}
-
-TEST_F(LogChannelTest, log_options) {
- EXPECT_EQ("Hello World 47\n", GetLogString(0, "Hello World {0}", 47));
- EXPECT_EQ("Hello World 47\n",
-GetLogString(LLDB_LOG_OPTION_THREADSAFE, "Hello World {0}", 47));
+TEST_F(LogChannelEnabledTest, log_options) {
+ std::string Err;
+ EXPECT_EQ("Hello World\n", logAndTakeOutput("Hello World"));
+ EXPECT_TRUE(EnableChannel(getStream(), LLDB_LOG_OPTION_THREADSAFE, "chan",
{},
+Err));
+ EXPECT_EQ("Hello World\n", logAndTakeOutput("Hello World"));
{
-std::string msg =
-GetLogString(LLDB_LOG_OPTION_PREPEND_SEQUENCE, "Hello World {0}", 47);
+EXPECT_TR
[Lldb-commits] [lldb] r322664 - Fix assertion in ObjectFileELF
Author: labath
Date: Wed Jan 17 06:40:25 2018
New Revision: 322664
URL: http://llvm.org/viewvc/llvm-project?rev=322664&view=rev
Log:
Fix assertion in ObjectFileELF
In D40616 I (mistakenly) assumed that logging an llvm::Error would clear
it. This of course is only true if logging is actually enabled.
This fixes the assertion by manually clearing the error, but it raises
the point of whether we need a special error-clearing logging primitive.
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=322664&r1=322663&r2=322664&view=diff
==
--- lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp (original)
+++ lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp Wed Jan 17
06:40:25 2018
@@ -3493,6 +3493,7 @@ size_t ObjectFileELF::ReadSectionData(Se
if (!Decompressor) {
LLDB_LOG(log, "Unable to initialize decompressor for section {0}: {1}",
section->GetName(), llvm::toString(Decompressor.takeError()));
+consumeError(Decompressor.takeError());
return result;
}
auto buffer_sp =
@@ -3502,6 +3503,7 @@ size_t ObjectFileELF::ReadSectionData(Se
size_t(buffer_sp->GetByteSize())})) {
LLDB_LOG(log, "Decompression of section {0} failed: {1}",
section->GetName(), llvm::toString(std::move(Error)));
+consumeError(std::move(Error));
return result;
}
section_data.SetData(buffer_sp);
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D42182: Add LLDB_LOG_ERROR (?)
labath created this revision.
labath added reviewers: davide, zturner, jingham, clayborg.
Herald added a subscriber: emaste.
The difference between this and regular LLDB_LOG is that this one clears
the error object unconditionally. This was inspired by the
ObjectFileELF bug (r322664), where the error object was being cleared
only if logging was enabled.
Of course, one could argue that since our logging is optional, it does
not really qualify as "handling" the error and we should leave it up to
the programmer to explicitly clear it if he really wants to.
It's not really clear to me which position is better. What do you think?
https://reviews.llvm.org/D42182
Files:
include/lldb/Utility/Log.h
source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
unittests/Utility/LogTest.cpp
Index: unittests/Utility/LogTest.cpp
===
--- unittests/Utility/LogTest.cpp
+++ unittests/Utility/LogTest.cpp
@@ -240,6 +240,23 @@
logAndTakeOutput("Hello World"));
}
+TEST_F(LogChannelEnabledTest, LLDB_LOG_ERROR) {
+ LLDB_LOG_ERROR(getLog(), llvm::Error::success(), "Foo failed: {0}");
+ ASSERT_EQ("", takeOutput());
+
+ LLDB_LOG_ERROR(getLog(),
+ llvm::make_error(
+ "My Error", llvm::inconvertibleErrorCode()),
+ "Foo failed: {0}");
+ ASSERT_EQ("Foo failed: My Error\n", takeOutput());
+
+ // Doesn't log, but doesn't assert either
+ LLDB_LOG_ERROR(nullptr,
+ llvm::make_error(
+ "My Error", llvm::inconvertibleErrorCode()),
+ "Foo failed: {0}");
+}
+
TEST_F(LogChannelEnabledTest, LogThread) {
// Test that we are able to concurrently write to a log channel and disable
// it.
Index: source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
===
--- source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -3491,19 +3491,18 @@
size_t(section_data.GetByteSize())},
GetByteOrder() == eByteOrderLittle, GetAddressByteSize() == 8);
if (!Decompressor) {
-LLDB_LOG(log, "Unable to initialize decompressor for section {0}: {1}",
- section->GetName(), llvm::toString(Decompressor.takeError()));
-consumeError(Decompressor.takeError());
+LLDB_LOG_ERROR(log, Decompressor.takeError(),
+ "Unable to initialize decompressor for section {0}",
+ section->GetName());
return result;
}
auto buffer_sp =
std::make_shared(Decompressor->getDecompressedSize(), 0);
if (auto Error = Decompressor->decompress(
{reinterpret_cast(buffer_sp->GetBytes()),
size_t(buffer_sp->GetByteSize())})) {
-LLDB_LOG(log, "Decompression of section {0} failed: {1}",
- section->GetName(), llvm::toString(std::move(Error)));
-consumeError(std::move(Error));
+LLDB_LOG_ERROR(log, std::move(Error), "Decompression of section {0} failed",
+ section->GetName());
return result;
}
section_data.SetData(buffer_sp);
Index: include/lldb/Utility/Log.h
===
--- include/lldb/Utility/Log.h
+++ include/lldb/Utility/Log.h
@@ -17,6 +17,7 @@
#include "llvm/ADT/ArrayRef.h"
#include "llvm/ADT/StringMap.h" // for StringMap
#include "llvm/ADT/StringRef.h" // for StringRef, StringLiteral
+#include "llvm/Support/Error.h"
#include "llvm/Support/FormatVariadic.h"
#include "llvm/Support/ManagedStatic.h"
#include "llvm/Support/RWMutex.h"
@@ -140,6 +141,15 @@
Format(file, function, llvm::formatv(format, std::forward(args)...));
}
+ template
+ void FormatError(llvm::Error error, llvm::StringRef file,
+ llvm::StringRef function, const char *format,
+ Args &&... args) {
+Format(file, function,
+ llvm::formatv(format, llvm::toString(std::move(error)),
+ std::forward(args)...));
+ }
+
void Printf(const char *format, ...) __attribute__((format(printf, 2, 3)));
void VAPrintf(const char *format, va_list args);
@@ -218,4 +228,17 @@
log_private->Format(__FILE__, __FUNCTION__, __VA_ARGS__);\
} while (0)
+// Write message to log, if error is set. In the log message refer to the error
+// with {0}. Error is cleared regardless of whether logging is enabled.
+#define LLDB_LOG_ERROR(log, error, ...)\
+ do { \
+::lldb_private::Log *log_private = (log); \
+::llvm::Error error_private = (error); \
+if (log_private && error_private) {\
+ log_private->FormatError(::std::move(error_private), __FILE__, \
+ __FUNCTION__, __V
[Lldb-commits] [lldb] r322666 - [lldb][PPC64] Fixed long double variables dump
Author: labath
Date: Wed Jan 17 07:11:20 2018
New Revision: 322666
URL: http://llvm.org/viewvc/llvm-project?rev=322666&view=rev
Log:
[lldb][PPC64] Fixed long double variables dump
Summary:
LLDB's DumpDataExtractor was not prepared to handle PowerPC's long double type:
PPCDoubleDouble.
As it is somewhat special, treating it as other regular float types resulted in
getting wrong information about it.
In this particular case, llvm::APFloat::getSizeInBits(PPCDoubleDouble) was
returning 0.
This caused the TestSetValues.py test to fail, because lldb would abort on an
assertion failure on APInt(), because of the invalid size.
Since in the PPC case the value of item_byte_size was correct and the
getSizeInBits call was only added to support x87DoubleExtended
semantics, this restricts the usage of getSizeInBits to the x87
semantics.
Reviewers: labath, clayborg
Reviewed By: labath
Subscribers: llvm-commits, anajuliapc, alexandreyy, lbianc, lldb-commits
Differential Revision: https://reviews.llvm.org/D42083
Author: Leandro Lupori
Modified:
lldb/trunk/source/Core/DumpDataExtractor.cpp
Modified: lldb/trunk/source/Core/DumpDataExtractor.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/DumpDataExtractor.cpp?rev=322666&r1=322665&r2=322666&view=diff
==
--- lldb/trunk/source/Core/DumpDataExtractor.cpp (original)
+++ lldb/trunk/source/Core/DumpDataExtractor.cpp Wed Jan 17 07:11:20 2018
@@ -583,8 +583,10 @@ lldb::offset_t lldb_private::DumpDataExt
} else if (item_bit_size == ast->getTypeSize(ast->LongDoubleTy)) {
const auto &semantics =
ast->getFloatTypeSemantics(ast->LongDoubleTy);
- const auto byte_size =
- (llvm::APFloat::getSizeInBits(semantics) + 7) / 8;
+
+ offset_t byte_size = item_byte_size;
+ if (&semantics == &llvm::APFloatBase::x87DoubleExtended())
+byte_size = (llvm::APFloat::getSizeInBits(semantics) + 7) / 8;
llvm::APInt apint;
if (GetAPInt(DE, &offset, byte_size, apint)) {
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D42083: [lldb][PPC64] Fixed long double variables dump
This revision was automatically updated to reflect the committed changes.
Closed by commit rL322666: [lldb][PPC64] Fixed long double variables dump
(authored by labath, committed by ).
Repository:
rL LLVM
https://reviews.llvm.org/D42083
Files:
lldb/trunk/source/Core/DumpDataExtractor.cpp
Index: lldb/trunk/source/Core/DumpDataExtractor.cpp
===
--- lldb/trunk/source/Core/DumpDataExtractor.cpp
+++ lldb/trunk/source/Core/DumpDataExtractor.cpp
@@ -583,8 +583,10 @@
} else if (item_bit_size == ast->getTypeSize(ast->LongDoubleTy)) {
const auto &semantics =
ast->getFloatTypeSemantics(ast->LongDoubleTy);
- const auto byte_size =
- (llvm::APFloat::getSizeInBits(semantics) + 7) / 8;
+
+ offset_t byte_size = item_byte_size;
+ if (&semantics == &llvm::APFloatBase::x87DoubleExtended())
+byte_size = (llvm::APFloat::getSizeInBits(semantics) + 7) / 8;
llvm::APInt apint;
if (GetAPInt(DE, &offset, byte_size, apint)) {
Index: lldb/trunk/source/Core/DumpDataExtractor.cpp
===
--- lldb/trunk/source/Core/DumpDataExtractor.cpp
+++ lldb/trunk/source/Core/DumpDataExtractor.cpp
@@ -583,8 +583,10 @@
} else if (item_bit_size == ast->getTypeSize(ast->LongDoubleTy)) {
const auto &semantics =
ast->getFloatTypeSemantics(ast->LongDoubleTy);
- const auto byte_size =
- (llvm::APFloat::getSizeInBits(semantics) + 7) / 8;
+
+ offset_t byte_size = item_byte_size;
+ if (&semantics == &llvm::APFloatBase::x87DoubleExtended())
+byte_size = (llvm::APFloat::getSizeInBits(semantics) + 7) / 8;
llvm::APInt apint;
if (GetAPInt(DE, &offset, byte_size, apint)) {
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D41702: Add SysV Abi for PPC64le
alexandreyy updated this revision to Diff 130180.
alexandreyy added a comment.
Herald added a subscriber: JDevlieghere.
Merged ppc64le and ppc64 plugins.
https://reviews.llvm.org/D41702
Files:
source/Plugins/ABI/SysV-ppc64/ABISysV_ppc64.cpp
source/Plugins/ABI/SysV-ppc64/ABISysV_ppc64.h
source/Plugins/Process/Utility/RegisterInfos_ppc64.h
source/Plugins/Process/Utility/lldb-ppc64-register-enums.h
source/Utility/PPC64_DWARF_Registers.h
Index: source/Utility/PPC64_DWARF_Registers.h
===
--- /dev/null
+++ source/Utility/PPC64_DWARF_Registers.h
@@ -0,0 +1,127 @@
+//===-- PPC64_DWARF_Registers.h -*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef utility_PPC64_DWARF_Registers_h_
+#define utility_PPC64_DWARF_Registers_h_
+
+#include "lldb/lldb-private.h"
+
+namespace ppc64_dwarf {
+
+enum {
+ dwarf_r0_ppc64 = 0,
+ dwarf_r1_ppc64,
+ dwarf_r2_ppc64,
+ dwarf_r3_ppc64,
+ dwarf_r4_ppc64,
+ dwarf_r5_ppc64,
+ dwarf_r6_ppc64,
+ dwarf_r7_ppc64,
+ dwarf_r8_ppc64,
+ dwarf_r9_ppc64,
+ dwarf_r10_ppc64,
+ dwarf_r11_ppc64,
+ dwarf_r12_ppc64,
+ dwarf_r13_ppc64,
+ dwarf_r14_ppc64,
+ dwarf_r15_ppc64,
+ dwarf_r16_ppc64,
+ dwarf_r17_ppc64,
+ dwarf_r18_ppc64,
+ dwarf_r19_ppc64,
+ dwarf_r20_ppc64,
+ dwarf_r21_ppc64,
+ dwarf_r22_ppc64,
+ dwarf_r23_ppc64,
+ dwarf_r24_ppc64,
+ dwarf_r25_ppc64,
+ dwarf_r26_ppc64,
+ dwarf_r27_ppc64,
+ dwarf_r28_ppc64,
+ dwarf_r29_ppc64,
+ dwarf_r30_ppc64,
+ dwarf_r31_ppc64,
+ dwarf_f0_ppc64,
+ dwarf_f1_ppc64,
+ dwarf_f2_ppc64,
+ dwarf_f3_ppc64,
+ dwarf_f4_ppc64,
+ dwarf_f5_ppc64,
+ dwarf_f6_ppc64,
+ dwarf_f7_ppc64,
+ dwarf_f8_ppc64,
+ dwarf_f9_ppc64,
+ dwarf_f10_ppc64,
+ dwarf_f11_ppc64,
+ dwarf_f12_ppc64,
+ dwarf_f13_ppc64,
+ dwarf_f14_ppc64,
+ dwarf_f15_ppc64,
+ dwarf_f16_ppc64,
+ dwarf_f17_ppc64,
+ dwarf_f18_ppc64,
+ dwarf_f19_ppc64,
+ dwarf_f20_ppc64,
+ dwarf_f21_ppc64,
+ dwarf_f22_ppc64,
+ dwarf_f23_ppc64,
+ dwarf_f24_ppc64,
+ dwarf_f25_ppc64,
+ dwarf_f26_ppc64,
+ dwarf_f27_ppc64,
+ dwarf_f28_ppc64,
+ dwarf_f29_ppc64,
+ dwarf_f30_ppc64,
+ dwarf_f31_ppc64,
+ dwarf_cr_ppc64 = 64,
+ dwarf_fpscr_ppc64,
+ dwarf_msr_ppc64,
+ dwarf_xer_ppc64 = 100,
+ dwarf_lr_ppc64 = 108,
+ dwarf_ctr_ppc64,
+ dwarf_vscr_ppc64,
+ dwarf_vrsave_ppc64 = 356,
+ dwarf_pc_ppc64,
+ dwarf_vr0_ppc64 = 1124,
+ dwarf_vr1_ppc64,
+ dwarf_vr2_ppc64,
+ dwarf_vr3_ppc64,
+ dwarf_vr4_ppc64,
+ dwarf_vr5_ppc64,
+ dwarf_vr6_ppc64,
+ dwarf_vr7_ppc64,
+ dwarf_vr8_ppc64,
+ dwarf_vr9_ppc64,
+ dwarf_vr10_ppc64,
+ dwarf_vr11_ppc64,
+ dwarf_vr12_ppc64,
+ dwarf_vr13_ppc64,
+ dwarf_vr14_ppc64,
+ dwarf_vr15_ppc64,
+ dwarf_vr16_ppc64,
+ dwarf_vr17_ppc64,
+ dwarf_vr18_ppc64,
+ dwarf_vr19_ppc64,
+ dwarf_vr20_ppc64,
+ dwarf_vr21_ppc64,
+ dwarf_vr22_ppc64,
+ dwarf_vr23_ppc64,
+ dwarf_vr24_ppc64,
+ dwarf_vr25_ppc64,
+ dwarf_vr26_ppc64,
+ dwarf_vr27_ppc64,
+ dwarf_vr28_ppc64,
+ dwarf_vr29_ppc64,
+ dwarf_vr30_ppc64,
+ dwarf_vr31_ppc64,
+};
+
+} // namespace ppc64_dwarf
+
+#endif // utility_PPC64_DWARF_Registers_h_
Index: source/Plugins/Process/Utility/lldb-ppc64-register-enums.h
===
--- /dev/null
+++ source/Plugins/Process/Utility/lldb-ppc64-register-enums.h
@@ -0,0 +1,139 @@
+//===-- lldb-ppc64-register-enums.h ---*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef lldb_ppc64_register_enums_h
+#define lldb_ppc64_register_enums_h
+
+// LLDB register codes (e.g. RegisterKind == eRegisterKindLLDB)
+
+// ---
+// Internal codes for all ppc64 registers.
+// ---
+enum {
+ k_first_gpr_ppc64,
+ gpr_r0_ppc64 = k_first_gpr_ppc64,
+ gpr_r1_ppc64,
+ gpr_r2_ppc64,
+ gpr_r3_ppc64,
+ gpr_r4_ppc64,
+ gpr_r5_ppc64,
+ gpr_r6_ppc64,
+ gpr_r7_ppc64,
+ gpr_r8_ppc64,
+ gpr_r9_ppc64,
+ gpr_r10_ppc64,
+ gpr_r11_ppc64,
+ gpr_r12_ppc64,
+ gpr_r13_ppc64,
+ gpr_r14_ppc64,
+ gpr_r15_ppc64,
+ gpr_r16_ppc64,
+ gpr_r17_ppc64,
+ gpr_r18_ppc64,
+ gpr_r19_ppc64,
+ gpr_r20_ppc64,
+ gpr_r21_ppc64,
+ gpr_r22_ppc64,
+ gpr_r23_ppc64,
+ gpr_r24_ppc64,
+ gpr_r25_ppc64,
+ gpr_r26_ppc64,
+ gpr_r27_ppc64,
+ gpr_r28_ppc64,
+ gpr_r29_ppc64,
+ gpr_r30_ppc64,
+ gpr_r31_ppc64,
+ gpr_cr_ppc64,
+ gpr_msr_ppc64,
+ gpr_xer_ppc64,
+ gpr_lr_ppc64,
+ gpr_ctr_ppc64,
+
[Lldb-commits] [PATCH] D42182: Add LLDB_LOG_ERROR (?)
davide added a comment. I think this is fine, but I'll defer to Zachary. https://reviews.llvm.org/D42182 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D42182: Add LLDB_LOG_ERROR (?)
Looks fine to me too On Wed, Jan 17, 2018 at 8:56 AM Davide Italiano via Phabricator < revi...@reviews.llvm.org> wrote: > davide added a comment. > > I think this is fine, but I'll defer to Zachary. > > > https://reviews.llvm.org/D42182 > > > > ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D42182: Add LLDB_LOG_ERROR (?)
davide accepted this revision. davide added a comment. This revision is now accepted and ready to land. Forgot to click accept. https://reviews.llvm.org/D42182 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D42145: [lldb] Use vFlash commands when writing to target's flash memory regions
clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.
Very nice overall. See inlined comments. Big issues are:
- GDBRemoteCommunication::WriteEscapedBinary() is not needed as
StreamGDBRemote::PutEscapedBytes() does this already
- Remove the batch start and end functions in process if possible and have
ProcessGDBRemote::DoWriteMemory() just "do the right thing"
- Can we actually cache the results of the qXfer:memory-map for the entire
process lifetime?
- Remove the new ProcessGDBRemote::GetMemoryMapRegion() and fold into
GDBRemoteCommunicationClient::GetMemoryRegionInfo() as needed
Comment at: include/lldb/Target/Process.h:1916
+ //--
+ virtual bool BeginWriteMemoryBatch() { return true; }
+
labath wrote:
> Instead of this begin/end combo, what would you think about a WriteMemory
> overload that takes a list of memory regions?
> Something like:
> ```
> struct WriteEntry { addr_t Dest; llvm::ArrayRef Contents; };
> Status WriteMemory(llvm::ArrayRef);
> ```
> Then the default implementation can just lower this into regular
> `WriteMemory` sequence, and the gdb-remote class can add the extra packets
> around it when needed.
Do we really need this? Can't we just take care of it inside of the standard
Process::WriteMemory()? This doesn't seem like something that a user should
have to worry about. The process plug-in should just make the write happen
IMHO. Let me know.
Comment at: include/lldb/Target/Process.h:1931
+ //--
+ virtual bool EndWriteMemoryBatch() { return true; }
+
Ditto
Comment at: source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp:277-293
+void GDBRemoteCommunication::WriteEscapedBinary(StreamString &stream,
+const void *buf,
+size_t size) {
+ const uint8_t *bytes = (const uint8_t *)buf;
+ const uint8_t *end = bytes + size;
+ const uint8_t escape = 0x7d;
+ for (; bytes != end; ++bytes) {
Remove and use StreamGDBRemote::PutEscapedBytes(). Any special encodings for
packets should be added to StreamGDBRemote.
Comment at: source/Plugins/Process/gdb-remote/GDBRemoteCommunication.h:152-153
+ //--
+ static void WriteEscapedBinary(StreamString &stream, const void *buf,
+ size_t size);
+
StreamGDBRemote::PutEscapedBytes(...) does exactly this. If you are encoding a
packet, use StreamGDBRemote if you are not already, and then use
PutEscapedBytes(...).
Comment at: source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp:2803-2810
+MemoryRegionInfoSP ProcessGDBRemote::GetMemoryMapRegion(lldb::addr_t addr) {
+ if (m_memory_map.empty())
+GetMemoryMap(m_memory_map);
+ for (const auto ®ion : m_memory_map)
+if (region->GetRange().Contains(addr))
+ return region;
+ return nullptr;
Note we already have:
```
Status ProcessGDBRemote::GetMemoryRegionInfo(addr_t load_addr, MemoryRegionInfo
®ion_info);
```
Remove this function and merge your logic into
GDBRemoteCommunicationClient::GetMemoryRegionInfo(...).
Also: can you cache the results of the memory map for the entire process
lifetime? GDBRemoteCommunicationClient::GetMemoryRegionInfo() queries each time
since it can detect new regions that were just allocated at any time. I believe
the linux version will check the process memory map in "/proc/$pid/maps" so it
is always up to date. Maybe these results can be cached, but we need to ensure
we catch changes in memory layout and mapping.
Comment at: source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp:2812-2815
+bool ProcessGDBRemote::BeginWriteMemoryBatch() {
+ m_is_batched_memory_write = true;
+ return true;
+}
clayborg wrote:
> Remove and make ProcessGDBRemote::DoWriteMemory() just handle things.
Remove and make ProcessGDBRemote::DoWriteMemory() just handle things.
Comment at: source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp:2812-2821
+bool ProcessGDBRemote::BeginWriteMemoryBatch() {
+ m_is_batched_memory_write = true;
+ return true;
+}
+
+bool ProcessGDBRemote::EndWriteMemoryBatch() {
+ m_is_batched_memory_write = false;
Remove and make ProcessGDBRemote::DoWriteMemory() just handle things.
Comment at: source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp:2962
+packet.Printf("vFlashWrite:%" PRIx64 ":", addr);
+GDBRemoteCommunication::WriteEscapedBinary(packet, buf, size);
+ } else {
labath wrote:
> This function is unnecessary. You should use StreamGDBRemote::PutEscapedBytes.
In
[Lldb-commits] [PATCH] D41702: Add SysV Abi for PPC64le
clayborg added a comment.
Looks nice. Only nit is we probably don't need the m_endian member variable.
See inlined comment.
Comment at: source/Plugins/ABI/SysV-ppc64/ABISysV_ppc64.h:114
+
+ lldb::ByteOrder m_endian;
};
Most other code uses "m_byte_order" as the name. That being said, you can
always just ask the process since it is store in the lldb_private::ABI class so
you really don't need to store it here if you don't want to, you could add an
accessor:
```
lldb::ByteOrder GetByteOrder() const { return GetProcessSP()->GetByteOrder(); }
```
https://reviews.llvm.org/D41702
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D39969: Set error status in ObjectFile::LoadInMemory if it is not set
tatyana-krasnukha added a comment. Herald added a subscriber: llvm-commits. ping Greg, Abid, if you disagree with the changes, let me know and I'll close the revision. Repository: rL LLVM https://reviews.llvm.org/D39969 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D42182: Add LLDB_LOG_ERROR (?)
jingham added a comment. This seems fine as a bit of functionality but I'm worried about the name. There's nothing in "LLDB_LOG_ERROR" that indicates that the error gets cleared, but that's actually a pretty important piece of its business. Before this propagates further is there a better name we can come up with that's not too horrible to type or scan but conveys this? LLDB_LOG_AND_CLEAR_ERROR is not too bad, though if there's a better single word that conveys logging & handling that would be nicer. But I can't think of one off the top of my head. https://reviews.llvm.org/D42182 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D42182: Add LLDB_LOG_ERROR (?)
zturner added a comment. In a way it's kind of built into the semantics of `llvm::Error` that this is the only way it could possibly work, since it's a move only type. If you do this, for example: Error E = doSomething(); LLDB_LOG_ERROR(E); you'd get a compilation failure. The only way to make it compile would be to do this: Error E = doSomething(); LLDB_LOG_ERROR(std::move(E)); And since you've written `std::move(E)` you already can't use it again anyway. And if you had written it as one line: LLDB_LOG_ERROR(doSomething()); Then you weren't holding onto the error anyway and it shouldn't matter whether or not it was cleared. So I'm not sold on the idea of lengthening the name, because you couldn't have used the Error anyway after calling this. https://reviews.llvm.org/D42182 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r322728 - Skip a flaky test (TestRdar12408181.py)
Author: vedantk Date: Wed Jan 17 10:53:42 2018 New Revision: 322728 URL: http://llvm.org/viewvc/llvm-project?rev=322728&view=rev Log: Skip a flaky test (TestRdar12408181.py) This test frequently times out on our bots. While we're investigating the issue, mark the test as skipped so the builds aren't impacted as much. rdar://36417163 Modified: lldb/trunk/packages/Python/lldbsuite/test/lang/objc/rdar-12408181/TestRdar12408181.py Modified: lldb/trunk/packages/Python/lldbsuite/test/lang/objc/rdar-12408181/TestRdar12408181.py URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/objc/rdar-12408181/TestRdar12408181.py?rev=322728&r1=322727&r2=322728&view=diff == --- lldb/trunk/packages/Python/lldbsuite/test/lang/objc/rdar-12408181/TestRdar12408181.py (original) +++ lldb/trunk/packages/Python/lldbsuite/test/lang/objc/rdar-12408181/TestRdar12408181.py Wed Jan 17 10:53:42 2018 @@ -13,7 +13,9 @@ from lldbsuite.test.lldbtest import * from lldbsuite.test import lldbutil -@skipUnlessDarwin +# TODO: Switch back to @skipUnlessDarwin when the bug preventing the test app +# from launching is resolved. +@skipIf class Rdar12408181TestCase(TestBase): mydir = TestBase.compute_mydir(__file__) ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D42145: [lldb] Use vFlash commands when writing to target's flash memory regions
owenpshaw added a comment.
Thanks for the feedback, I'm working on splitting out the testing base into
another patch and making the requested changes. My main unresolved question is
about the write batching, with details below.
Comment at: include/lldb/Target/Process.h:1916
+ //--
+ virtual bool BeginWriteMemoryBatch() { return true; }
+
clayborg wrote:
> labath wrote:
> > Instead of this begin/end combo, what would you think about a WriteMemory
> > overload that takes a list of memory regions?
> > Something like:
> > ```
> > struct WriteEntry { addr_t Dest; llvm::ArrayRef Contents; };
> > Status WriteMemory(llvm::ArrayRef);
> > ```
> > Then the default implementation can just lower this into regular
> > `WriteMemory` sequence, and the gdb-remote class can add the extra packets
> > around it when needed.
> Do we really need this? Can't we just take care of it inside of the standard
> Process::WriteMemory()? This doesn't seem like something that a user should
> have to worry about. The process plug-in should just make the write happen
> IMHO. Let me know.
Maybe I'm misunderstanding the flash commands, but I couldn't figure a way
around the need to somehow indicate that several writes are batched together.
The reason has to do with how vFlashErase must erase an entire block at a time.
ObjectFile::LoadInMemory makes one Process::WriteMemory call per section. If
each WriteMemory call was self-contained, and two sections are in the same
flash block, it would go something like this:
# WriteMemory (section 1)
## DoWriteMemory
### vFlashErase (block 1)
### vFlashWrite (section 1)
### vFlashDone
# WriteMemory (section 2)
## DoWriteMemory
### vFlashErase (block 1, again)
### vFlashWrite (section 2)
### vFlashDone
Wouldn't the second erase undo the first write?
I found the begin/end to be the least intrusive way around, but I'm open to
other options.
Comment at: source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp:4612-4613
+bool ProcessGDBRemote::GetMemoryMap(
+std::vector ®ion_list) {
+
clayborg wrote:
> Can we cache this value permanently? If so we should read it once and then
> the GDBRemoteCommunicationClient::GetMemoryRegionInfo() should try the
> qMemoryRegionInfo packet (if supported) and possibly augment the memory
> region results with this info?
>
> This should be pushed down into GDBRemoteCommunicationClient and it should
> keep a member variable that caches these results.
>
> Any reason we are using shared pointers to lldb::MemoryRegionInfo? They are
> simple structs. No need to indirect through shared pointers IMHO.
I can merge the results in GetMemoryRegionInfo().
I put the xml parsing in ProcessGDBRemote because it seemed similar to the
logic in ProcessGDBRemote::GetGDBServerRegisterInfo, which also uses
ReadExtFeature. Figured there must have been a reason for that. Easy to move
it.
And shared pointers were only because I was mimicking the
Process::GetMemoryRegions api.
Comment at: source/Symbol/ObjectFile.cpp:671
+ continue;
+// We can skip sections like bss
+if (section_sp->GetFileSize() == 0)
clayborg wrote:
> labath wrote:
> > You're not actually changing this part, but it caught my eye, and you may
> > care about this:
> >
> > Is it true that we can ignore .bss here? Programs generally assume that
> > .bss is zero-initialized, and if you just ignore it here, it can contain
> > whatever garbage was in the memory before you loaded (?)
> Very important to zero out bss
For the embedded projects I've worked on, ignoring .bss here is fine and
expected because the code always starts by zeroing out the .bss memory (and
also copying the .data section contents from ROM to RAM, which is related to
the physical address change).
For comparison, gdb doesn't try to load the bss section either.
https://reviews.llvm.org/D42145
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D42182: Add LLDB_LOG_ERROR (?)
jingham added a comment. Seems important to me that a name tells what it does without having to know the implementation details of what it acts on. Particularly for folks new to the code, having to know one less thing to understand how something that's important to the logic flow of the program behaves will make comprehending the code easier. It's only a little bump to understanding, but the fewer of those we have the better, IMO. https://reviews.llvm.org/D42182 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D42145: [lldb] Use vFlash commands when writing to target's flash memory regions
clayborg added inline comments.
Comment at: include/lldb/Target/Process.h:1916
+ //--
+ virtual bool BeginWriteMemoryBatch() { return true; }
+
owenpshaw wrote:
> clayborg wrote:
> > labath wrote:
> > > Instead of this begin/end combo, what would you think about a WriteMemory
> > > overload that takes a list of memory regions?
> > > Something like:
> > > ```
> > > struct WriteEntry { addr_t Dest; llvm::ArrayRef Contents; };
> > > Status WriteMemory(llvm::ArrayRef);
> > > ```
> > > Then the default implementation can just lower this into regular
> > > `WriteMemory` sequence, and the gdb-remote class can add the extra
> > > packets around it when needed.
> > Do we really need this? Can't we just take care of it inside of the
> > standard Process::WriteMemory()? This doesn't seem like something that a
> > user should have to worry about. The process plug-in should just make the
> > write happen IMHO. Let me know.
> Maybe I'm misunderstanding the flash commands, but I couldn't figure a way
> around the need to somehow indicate that several writes are batched together.
> The reason has to do with how vFlashErase must erase an entire block at a
> time.
>
> ObjectFile::LoadInMemory makes one Process::WriteMemory call per section. If
> each WriteMemory call was self-contained, and two sections are in the same
> flash block, it would go something like this:
>
> # WriteMemory (section 1)
> ## DoWriteMemory
> ### vFlashErase (block 1)
> ### vFlashWrite (section 1)
> ### vFlashDone
> # WriteMemory (section 2)
> ## DoWriteMemory
> ### vFlashErase (block 1, again)
> ### vFlashWrite (section 2)
> ### vFlashDone
>
> Wouldn't the second erase undo the first write?
>
> I found the begin/end to be the least intrusive way around, but I'm open to
> other options.
Seems like any block write that isn't writing an entire block should read the
contents that won't be overwritten, create a block's worth of data to write by
using the pre-existing data and adding any new data, then erase the block and
and rewrite the entire block. Then in ObjectFile::Load() it would batch up any
consecutive writes to minimize any block erasing...
Comment at: source/Symbol/ObjectFile.cpp:671
+ continue;
+// We can skip sections like bss
+if (section_sp->GetFileSize() == 0)
owenpshaw wrote:
> clayborg wrote:
> > labath wrote:
> > > You're not actually changing this part, but it caught my eye, and you may
> > > care about this:
> > >
> > > Is it true that we can ignore .bss here? Programs generally assume that
> > > .bss is zero-initialized, and if you just ignore it here, it can contain
> > > whatever garbage was in the memory before you loaded (?)
> > Very important to zero out bss
> For the embedded projects I've worked on, ignoring .bss here is fine and
> expected because the code always starts by zeroing out the .bss memory (and
> also copying the .data section contents from ROM to RAM, which is related to
> the physical address change).
>
> For comparison, gdb doesn't try to load the bss section either.
Sounds good, if gdb doesn't do it, then I am fine if we don't do it
https://reviews.llvm.org/D42145
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r322740 - Try again to mark TestRdar12408181.py as skipped
Author: vedantk Date: Wed Jan 17 11:25:12 2018 New Revision: 322740 URL: http://llvm.org/viewvc/llvm-project?rev=322740&view=rev Log: Try again to mark TestRdar12408181.py as skipped rdar://36417163 Modified: lldb/trunk/packages/Python/lldbsuite/test/lang/objc/rdar-12408181/TestRdar12408181.py Modified: lldb/trunk/packages/Python/lldbsuite/test/lang/objc/rdar-12408181/TestRdar12408181.py URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/objc/rdar-12408181/TestRdar12408181.py?rev=322740&r1=322739&r2=322740&view=diff == --- lldb/trunk/packages/Python/lldbsuite/test/lang/objc/rdar-12408181/TestRdar12408181.py (original) +++ lldb/trunk/packages/Python/lldbsuite/test/lang/objc/rdar-12408181/TestRdar12408181.py Wed Jan 17 11:25:12 2018 @@ -13,9 +13,13 @@ from lldbsuite.test.lldbtest import * from lldbsuite.test import lldbutil -# TODO: Switch back to @skipUnlessDarwin when the bug preventing the test app -# from launching is resolved. -@skipIf +# TODO: The Jenkins testers on OS X fail running this test because they don't +# have access to WindowServer so NSWindow doesn't work. We should disable this +# test if WindowServer isn't available. +# Note: Simply applying the @skipIf decorator here confuses the test harness +# and gives a spurious failure. +@skipUnlessDarwin +@skipIfDarwin class Rdar12408181TestCase(TestBase): mydir = TestBase.compute_mydir(__file__) ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D41702: Add SysV Abi for PPC64le
alexandreyy updated this revision to Diff 130236.
alexandreyy added a comment.
Removed m_endian variable.
https://reviews.llvm.org/D41702
Files:
source/Plugins/ABI/SysV-ppc64/ABISysV_ppc64.cpp
source/Plugins/ABI/SysV-ppc64/ABISysV_ppc64.h
source/Plugins/Process/Utility/RegisterInfos_ppc64.h
source/Plugins/Process/Utility/lldb-ppc64-register-enums.h
source/Utility/PPC64_DWARF_Registers.h
Index: source/Utility/PPC64_DWARF_Registers.h
===
--- /dev/null
+++ source/Utility/PPC64_DWARF_Registers.h
@@ -0,0 +1,127 @@
+//===-- PPC64_DWARF_Registers.h -*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef utility_PPC64_DWARF_Registers_h_
+#define utility_PPC64_DWARF_Registers_h_
+
+#include "lldb/lldb-private.h"
+
+namespace ppc64_dwarf {
+
+enum {
+ dwarf_r0_ppc64 = 0,
+ dwarf_r1_ppc64,
+ dwarf_r2_ppc64,
+ dwarf_r3_ppc64,
+ dwarf_r4_ppc64,
+ dwarf_r5_ppc64,
+ dwarf_r6_ppc64,
+ dwarf_r7_ppc64,
+ dwarf_r8_ppc64,
+ dwarf_r9_ppc64,
+ dwarf_r10_ppc64,
+ dwarf_r11_ppc64,
+ dwarf_r12_ppc64,
+ dwarf_r13_ppc64,
+ dwarf_r14_ppc64,
+ dwarf_r15_ppc64,
+ dwarf_r16_ppc64,
+ dwarf_r17_ppc64,
+ dwarf_r18_ppc64,
+ dwarf_r19_ppc64,
+ dwarf_r20_ppc64,
+ dwarf_r21_ppc64,
+ dwarf_r22_ppc64,
+ dwarf_r23_ppc64,
+ dwarf_r24_ppc64,
+ dwarf_r25_ppc64,
+ dwarf_r26_ppc64,
+ dwarf_r27_ppc64,
+ dwarf_r28_ppc64,
+ dwarf_r29_ppc64,
+ dwarf_r30_ppc64,
+ dwarf_r31_ppc64,
+ dwarf_f0_ppc64,
+ dwarf_f1_ppc64,
+ dwarf_f2_ppc64,
+ dwarf_f3_ppc64,
+ dwarf_f4_ppc64,
+ dwarf_f5_ppc64,
+ dwarf_f6_ppc64,
+ dwarf_f7_ppc64,
+ dwarf_f8_ppc64,
+ dwarf_f9_ppc64,
+ dwarf_f10_ppc64,
+ dwarf_f11_ppc64,
+ dwarf_f12_ppc64,
+ dwarf_f13_ppc64,
+ dwarf_f14_ppc64,
+ dwarf_f15_ppc64,
+ dwarf_f16_ppc64,
+ dwarf_f17_ppc64,
+ dwarf_f18_ppc64,
+ dwarf_f19_ppc64,
+ dwarf_f20_ppc64,
+ dwarf_f21_ppc64,
+ dwarf_f22_ppc64,
+ dwarf_f23_ppc64,
+ dwarf_f24_ppc64,
+ dwarf_f25_ppc64,
+ dwarf_f26_ppc64,
+ dwarf_f27_ppc64,
+ dwarf_f28_ppc64,
+ dwarf_f29_ppc64,
+ dwarf_f30_ppc64,
+ dwarf_f31_ppc64,
+ dwarf_cr_ppc64 = 64,
+ dwarf_fpscr_ppc64,
+ dwarf_msr_ppc64,
+ dwarf_xer_ppc64 = 100,
+ dwarf_lr_ppc64 = 108,
+ dwarf_ctr_ppc64,
+ dwarf_vscr_ppc64,
+ dwarf_vrsave_ppc64 = 356,
+ dwarf_pc_ppc64,
+ dwarf_vr0_ppc64 = 1124,
+ dwarf_vr1_ppc64,
+ dwarf_vr2_ppc64,
+ dwarf_vr3_ppc64,
+ dwarf_vr4_ppc64,
+ dwarf_vr5_ppc64,
+ dwarf_vr6_ppc64,
+ dwarf_vr7_ppc64,
+ dwarf_vr8_ppc64,
+ dwarf_vr9_ppc64,
+ dwarf_vr10_ppc64,
+ dwarf_vr11_ppc64,
+ dwarf_vr12_ppc64,
+ dwarf_vr13_ppc64,
+ dwarf_vr14_ppc64,
+ dwarf_vr15_ppc64,
+ dwarf_vr16_ppc64,
+ dwarf_vr17_ppc64,
+ dwarf_vr18_ppc64,
+ dwarf_vr19_ppc64,
+ dwarf_vr20_ppc64,
+ dwarf_vr21_ppc64,
+ dwarf_vr22_ppc64,
+ dwarf_vr23_ppc64,
+ dwarf_vr24_ppc64,
+ dwarf_vr25_ppc64,
+ dwarf_vr26_ppc64,
+ dwarf_vr27_ppc64,
+ dwarf_vr28_ppc64,
+ dwarf_vr29_ppc64,
+ dwarf_vr30_ppc64,
+ dwarf_vr31_ppc64,
+};
+
+} // namespace ppc64_dwarf
+
+#endif // utility_PPC64_DWARF_Registers_h_
Index: source/Plugins/Process/Utility/lldb-ppc64-register-enums.h
===
--- /dev/null
+++ source/Plugins/Process/Utility/lldb-ppc64-register-enums.h
@@ -0,0 +1,139 @@
+//===-- lldb-ppc64-register-enums.h ---*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef lldb_ppc64_register_enums_h
+#define lldb_ppc64_register_enums_h
+
+// LLDB register codes (e.g. RegisterKind == eRegisterKindLLDB)
+
+// ---
+// Internal codes for all ppc64 registers.
+// ---
+enum {
+ k_first_gpr_ppc64,
+ gpr_r0_ppc64 = k_first_gpr_ppc64,
+ gpr_r1_ppc64,
+ gpr_r2_ppc64,
+ gpr_r3_ppc64,
+ gpr_r4_ppc64,
+ gpr_r5_ppc64,
+ gpr_r6_ppc64,
+ gpr_r7_ppc64,
+ gpr_r8_ppc64,
+ gpr_r9_ppc64,
+ gpr_r10_ppc64,
+ gpr_r11_ppc64,
+ gpr_r12_ppc64,
+ gpr_r13_ppc64,
+ gpr_r14_ppc64,
+ gpr_r15_ppc64,
+ gpr_r16_ppc64,
+ gpr_r17_ppc64,
+ gpr_r18_ppc64,
+ gpr_r19_ppc64,
+ gpr_r20_ppc64,
+ gpr_r21_ppc64,
+ gpr_r22_ppc64,
+ gpr_r23_ppc64,
+ gpr_r24_ppc64,
+ gpr_r25_ppc64,
+ gpr_r26_ppc64,
+ gpr_r27_ppc64,
+ gpr_r28_ppc64,
+ gpr_r29_ppc64,
+ gpr_r30_ppc64,
+ gpr_r31_ppc64,
+ gpr_cr_ppc64,
+ gpr_msr_ppc64,
+ gpr_xer_ppc64,
+ gpr_lr_ppc64,
+ gpr_ctr_ppc64,
+ gpr_pc_ppc64,
+ k_last_gpr_ppc64 = gpr_pc_ppc64
[Lldb-commits] [PATCH] D41702: Add SysV Abi for PPC64le
alexandreyy added a comment. In https://reviews.llvm.org/D41702#978836, @clayborg wrote: > Looks nice. Only nit is we probably don't need the m_endian member variable. > See inlined comment. Thanks. I have changed the code to get the byte order. https://reviews.llvm.org/D41702 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D42195: [lldb] Generic base for testing gdb-remote behavior
owenpshaw created this revision.
owenpshaw added reviewers: clayborg, labath.
Adds new utilities that make it easier to write test cases for lldb acting as a
client over a gdb-remote connection.
- A GDBRemoteTestBase class that starts a mock GDB server and provides an easy
way to check client packets
- A MockGDBServer that, via MockGDBServerResponder, can be made to issue server
responses that test client behavior.
- Utility functions for handling common data encoding/decoding
- Utility functions for creating dummy targets from YAML files
Split from the review at https://reviews.llvm.org/D42145, which was a new
feature that necessitated the new testing capabilities.
https://reviews.llvm.org/D42195
Files:
packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestGDBRemoteClient.py
packages/Python/lldbsuite/test/functionalities/gdb_remote_client/a.yaml
packages/Python/lldbsuite/test/functionalities/gdb_remote_client/gdbclientutils.py
Index: packages/Python/lldbsuite/test/functionalities/gdb_remote_client/gdbclientutils.py
===
--- /dev/null
+++ packages/Python/lldbsuite/test/functionalities/gdb_remote_client/gdbclientutils.py
@@ -0,0 +1,432 @@
+import os
+import os.path
+import subprocess
+import threading
+import socket
+import lldb
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbtest_config
+
+
+def yaml2obj_executable():
+"""
+Get the path to the yaml2obj executable, which can be used to create test
+object files from easy to write yaml instructions.
+
+Throws an Exception if the executable cannot be found.
+"""
+# Tries to find yaml2obj at the same folder as the lldb
+path = os.path.join(os.path.dirname(lldbtest_config.lldbExec), "yaml2obj")
+if os.path.exists(path):
+return path
+raise Exception("yaml2obj executable not found")
+
+
+def yaml2elf(yaml_path, elf_path):
+"""
+Create an ELF file at the given path from a yaml file at the given path.
+
+Throws a subprocess.CalledProcessError if the ELF could not be created.
+"""
+yaml2obj = yaml2obj_executable()
+command = [yaml2obj, "-o=%s" % elf_path, yaml_path]
+system([command])
+
+
+def checksum(message):
+"""
+Calculate the GDB server protocol checksum of the message.
+
+The GDB server protocol uses a simple modulo 256 sum.
+"""
+check = 0
+for c in message:
+check += ord(c)
+return check % 256
+
+
+def frame_packet(message):
+"""
+Create a framed packet that's ready to send over the GDB connection
+channel.
+
+Framing includes surrounding the message between $ and #, and appending
+a two character hex checksum.
+"""
+return "$%s#%02x" % (message, checksum(message))
+
+
+def escape_binary(message):
+"""
+Escape the binary message using the process described in the GDB server
+protocol documentation.
+
+Most bytes are sent through as-is, but $, #, and { are escaped by writing
+a { followed by the original byte mod 0x20.
+"""
+out = ""
+for c in message:
+d = ord(c)
+if d in (0x23, 0x24, 0x7d):
+out += chr(0x7d)
+out += chr(d ^ 0x20)
+else:
+out += c
+return out
+
+
+def hex_encode_bytes(message):
+"""
+Encode the binary message by converting each byte into a two-character
+hex string.
+"""
+out = ""
+for c in message:
+out += "%02x" % ord(c)
+return out
+
+
+def hex_decode_bytes(hex_bytes):
+"""
+Decode the hex string into a binary message by converting each two-character
+hex string into a single output byte.
+"""
+out = ""
+hex_len = len(hex_bytes)
+while i < hex_len - 1:
+out += chr(int(hex_bytes[i:i + 2]), 16)
+i += 2
+return out
+
+
+class MockGDBServerResponder:
+"""
+A base class for handing client packets and issuing server responses for
+GDB tests.
+
+This handles many typical situations, while still allowing subclasses to
+completely customize their responses.
+
+Most subclasses will be interested in overriding the other() method, which
+handles any packet not recognized in the common packet handling code.
+"""
+
+registerCount = 40
+packetLog = None
+
+def __init__(self):
+self.packetLog = []
+
+def respond(self, packet):
+"""
+Return the unframed packet data that the server should issue in response
+to the given packet received from the client.
+"""
+self.packetLog.append(packet)
+if packet == "g":
+return self.readRegisters()
+if packet[0] == "G":
+return self.writeRegisters(packet[1:])
+if packet[0] == "p":
+return self.readRegister(int(packet[1:], 16))
+if packet[0] == "P":
+register, value = packet[1:].split("=")
+return sel
[Lldb-commits] [lldb] r322756 - A third attempt to mark TestRdar12408181.py as skipped
Author: vedantk
Date: Wed Jan 17 12:54:39 2018
New Revision: 322756
URL: http://llvm.org/viewvc/llvm-project?rev=322756&view=rev
Log:
A third attempt to mark TestRdar12408181.py as skipped
Due to an unfortunate difference between the open source test harness
and our internal harness, applying two @skip... decorators to this test
works in the internal build but not in the open source build.
I've tried another approach to skipping this test and tested it out with
the open source harness. Hopefully this sticks!
rdar://36417163
Modified:
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/rdar-12408181/TestRdar12408181.py
Modified:
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/rdar-12408181/TestRdar12408181.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/objc/rdar-12408181/TestRdar12408181.py?rev=322756&r1=322755&r2=322756&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/rdar-12408181/TestRdar12408181.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/rdar-12408181/TestRdar12408181.py
Wed Jan 17 12:54:39 2018
@@ -19,7 +19,6 @@ from lldbsuite.test import lldbutil
# Note: Simply applying the @skipIf decorator here confuses the test harness
# and gives a spurious failure.
@skipUnlessDarwin
-@skipIfDarwin
class Rdar12408181TestCase(TestBase):
mydir = TestBase.compute_mydir(__file__)
@@ -35,6 +34,9 @@ class Rdar12408181TestCase(TestBase):
def test_nswindow_count(self):
"""Test that we are able to find out how many children NSWindow has."""
+
+self.skipTest("Skipping this test due to timeout flakiness")
+
d = {'EXE': self.exe_name}
self.build(dictionary=d)
self.setTearDownCleanup(dictionary=d)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D42145: [lldb] Use vFlash commands when writing to target's flash memory regions
owenpshaw updated this revision to Diff 130258.
owenpshaw added a comment.
- Split testing base into separate review https://reviews.llvm.org/D42195
- Use StreamGDBRemote instead of duplicate new function
- Move qXfer:memory-map xml parsing into GDBRemoteCommunicationClient
- Include qXfer:memory-map data in GetMemoryRegionInfo, instead of creating a
separate API
I've left the batch write as-is for now because I'm not quite sold on the
solution of writing entire blocks of flash memory at time. While I agree it
could work, it feels like an overly complicated code solution that will also
generate a lot of unnecessary commands between the client and server.
Can you help me understand the objection to the begin/end design? I can't
really think of scenario besides object file load where the begin/end batching
calls would be used. So perhaps instead of ObjectFile::LoadInMemory using
Process::WriteMemory, it instead calls something like a new
Process::WriteObjectSections(std::vector, SectionLoadList) method
that's clearly only intended for object writing. The GDB process could
override and do the begin/end batching privately.
https://reviews.llvm.org/D42145
Files:
include/lldb/Host/XML.h
include/lldb/Target/MemoryRegionInfo.h
include/lldb/Target/Process.h
packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestGDBRemoteLoad.py
source/Host/common/XML.cpp
source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
source/Plugins/ObjectFile/ELF/ObjectFileELF.h
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h
source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
source/Symbol/ObjectFile.cpp
Index: source/Symbol/ObjectFile.cpp
===
--- source/Symbol/ObjectFile.cpp
+++ source/Symbol/ObjectFile.cpp
@@ -659,22 +659,47 @@
SectionList *section_list = GetSectionList();
if (!section_list)
return Status("No section in object file");
+
+ // Filter the list of loadable sections
+ std::vector loadable_sections;
size_t section_count = section_list->GetNumSections(0);
for (size_t i = 0; i < section_count; ++i) {
SectionSP section_sp = section_list->GetSectionAtIndex(i);
addr_t addr = target.GetSectionLoadList().GetSectionLoadAddress(section_sp);
-if (addr != LLDB_INVALID_ADDRESS) {
- DataExtractor section_data;
- // We can skip sections like bss
- if (section_sp->GetFileSize() == 0)
-continue;
- section_sp->GetSectionData(section_data);
- lldb::offset_t written = process->WriteMemory(
- addr, section_data.GetDataStart(), section_data.GetByteSize(), error);
- if (written != section_data.GetByteSize())
-return error;
+if (addr == LLDB_INVALID_ADDRESS)
+ continue;
+// We can skip sections like bss
+if (section_sp->GetFileSize() == 0)
+ continue;
+loadable_sections.push_back(section_sp);
+ }
+
+ // Sort the sections by address because some writes, like those to flash
+ // memory, must happen in order of increasing address.
+ std::stable_sort(std::begin(loadable_sections), std::end(loadable_sections),
+ [&target](const SectionSP a, const SectionSP b){
+addr_t addr_a = target.GetSectionLoadList().GetSectionLoadAddress(a);
+addr_t addr_b = target.GetSectionLoadList().GetSectionLoadAddress(b);
+return addr_a < addr_b;
+ });
+
+ // Do a batch memory write to the process
+ if (!process->BeginWriteMemoryBatch())
+return Status("Could not start write memory batch");
+ for (auto §ion_sp : loadable_sections) {
+DataExtractor section_data;
+section_sp->GetSectionData(section_data);
+addr_t addr = target.GetSectionLoadList().GetSectionLoadAddress(section_sp);
+lldb::offset_t written = process->WriteMemory(
+addr, section_data.GetDataStart(), section_data.GetByteSize(), error);
+if (written != section_data.GetByteSize()) {
+ process->EndWriteMemoryBatch();
+ return error;
}
}
+ if (!process->EndWriteMemoryBatch())
+return Status("Could not end write memory batch");
+
if (set_pc) {
ThreadList &thread_list = process->GetThreadList();
ThreadSP curr_thread(thread_list.GetSelectedThread());
Index: source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
===
--- source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
+++ source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
@@ -144,6 +144,10 @@
size_t DoReadMemory(lldb::addr_t addr, void *buf, size_t size,
Status &error) override;
+ bool BeginWriteMemoryBatch() override;
+
+ bool EndWriteMemoryBatch() override;
+
size_t DoWriteMemory(lldb::addr_t addr, const void *buf, size_t size,
Status &error) override;
@@ -302,6 +306,11 @@
[Lldb-commits] [PATCH] D42195: [lldb] Generic base for testing gdb-remote behavior
clayborg added a comment. Looks fine to me. Wait for Pavel to give it the OK since he did more of the lldb-server testing stuff. https://reviews.llvm.org/D42195 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D41997: Build virtual override tables in DWARFASTParserClang::CompleteTypeFromDWARF
lhames updated this revision to Diff 130284.
lhames added a comment.
Updated to address review comments:
- assert changed to lldbassert
- comments added
- test case breakpoint comment simplified
- unused import removed from testcase
- testcase Makefile cleaned up
Repository:
rL LLVM
https://reviews.llvm.org/D41997
Files:
Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
Python/lldbsuite/test/expression_command/call-overridden-method/Makefile
Python/lldbsuite/test/expression_command/call-overridden-method/TestCallOverriddenMethod.py
Python/lldbsuite/test/expression_command/call-overridden-method/main.cpp
Index: Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
===
--- Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
+++ Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
@@ -40,6 +40,7 @@
#include "lldb/Utility/Log.h"
#include "lldb/Utility/StreamString.h"
+#include "clang/AST/CXXInheritance.h"
#include "clang/AST/DeclCXX.h"
#include "clang/AST/DeclObjC.h"
@@ -2099,6 +2100,92 @@
return template_param_infos.args.size() == template_param_infos.names.size();
}
+// Checks whether m1 is an overload of m2 (as opposed to an override).
+// This is called by addOverridesForMethod to distinguish overrides (which share
+// a vtable entry) from overloads (which require distinct entries).
+static bool isOverload(clang::CXXMethodDecl *m1, clang::CXXMethodDecl *m2) {
+ // FIXME: This should detect covariant return types, but currently doesn't.
+ lldbassert(&m1->getASTContext() == &m2->getASTContext() &&
+ "Methods should have the same AST context");
+ clang::ASTContext &context = m1->getASTContext();
+
+ const auto *m1Type =
+llvm::cast(
+ context.getCanonicalType(m1->getType()));
+
+ const auto *m2Type =
+llvm::cast(
+ context.getCanonicalType(m2->getType()));
+
+ auto compareArgTypes =
+[&context](const clang::QualType &m1p, const clang::QualType &m2p) {
+ return context.hasSameType(m1p.getUnqualifiedType(),
+ m2p.getUnqualifiedType());
+};
+
+ return !std::equal(m1Type->param_type_begin(), m1Type->param_type_end(),
+ m2Type->param_type_begin(), compareArgTypes);
+}
+
+// If decl is a virtual method, walk the base classes looking for methods that
+// decl overrides. This table of overridden methods is used by IRGen to determine
+// the vtable layout for decl's parent class.
+static void addOverridesForMethod(clang::CXXMethodDecl *decl) {
+ if (!decl->isVirtual())
+return;
+
+ clang::CXXBasePaths paths;
+
+ auto find_overridden_methods =
+[decl](const clang::CXXBaseSpecifier *specifier, clang::CXXBasePath &path) {
+ if (auto *base_record =
+ llvm::dyn_cast(
+specifier->getType()->getAs()->getDecl())) {
+
+clang::DeclarationName name = decl->getDeclName();
+
+// If this is a destructor, check whether the base class destructor is
+// virtual.
+if (name.getNameKind() == clang::DeclarationName::CXXDestructorName)
+ if (auto *baseDtorDecl = base_record->getDestructor()) {
+if (baseDtorDecl->isVirtual()) {
+ path.Decls = baseDtorDecl;
+ return true;
+} else
+ return false;
+ }
+
+// Otherwise, search for name in the base class.
+for (path.Decls = base_record->lookup(name); !path.Decls.empty();
+ path.Decls = path.Decls.slice(1)) {
+ if (auto *method_decl =
+llvm::dyn_cast(path.Decls.front()))
+if (method_decl->isVirtual() && !isOverload(decl, method_decl)) {
+ path.Decls = method_decl;
+ return true;
+}
+}
+ }
+
+ return false;
+};
+
+ if (decl->getParent()->lookupInBases(find_overridden_methods, paths)) {
+for (auto *overridden_decl : paths.found_decls())
+ decl->addOverriddenMethod(
+llvm::cast(overridden_decl));
+ }
+}
+
+// If clang_type is a CXXRecordDecl, builds the method override list for each
+// of its virtual methods.
+static void addMethodOverrides(ClangASTContext &ast, CompilerType &clang_type) {
+ if (auto *record =
+ ast.GetAsCXXRecordDecl(clang_type.GetOpaqueQualType()))
+for (auto *method : record->methods())
+ addOverridesForMethod(method);
+}
+
bool DWARFASTParserClang::CompleteTypeFromDWARF(const DWARFDIE &die,
lldb_private::Type *type,
CompilerType &clang_type) {
@@ -2311,6 +2398,7 @@
}
}
+addMethodOverrides(m_ast, clang_type);
ClangASTContext::BuildIndirectFields(clang_type);
ClangASTContext::CompleteTagDeclarationDefinition(clang_type);
Index: Python/lldbsuite/test/expression_command/call-overridden-method/main.cpp
===
---
[Lldb-commits] [PATCH] D42145: [lldb] Use vFlash commands when writing to target's flash memory regions
clayborg added a comment. My objection to the BeginWriteMemoryBatch and EndWriteMemoryBatch is users must know to emit these calls when they really just want to call process.WriteMemory() and not worry about how it is done. Much like writing to read only code when setting breakpoints, we don't require the user to know that they must check the memory permissions first, set permissions to be writable and then revert them back after writing to a memory location. If we have the ability to do things correctly, then we should and we shouldn't require people to know about calls that are specific to flash. Just make it happen if you can, else return an error. So I would rather see the ObjectFile::Load become more process aware where it gets the memory region info and efficiently loads memory as needed by watching the m_blocksize than require everyone else that might want to write memory to know to start a batch and end a batch. It comes down to keeping the API simple. Comment at: include/lldb/Target/MemoryRegionInfo.h:109-110 ConstString m_name; + OptionalBool m_flash; + lldb::offset_t m_blocksize; }; Could these two be combined into one entry? Could "m_blocksize" be "m_flash_block_size" and if the value is zero, then it isn't flash? https://reviews.llvm.org/D42145 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D41997: Build virtual override tables in DWARFASTParserClang::CompleteTypeFromDWARF
clayborg accepted this revision.
clayborg added inline comments.
This revision is now accepted and ready to land.
Comment at: Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp:2106
+// a vtable entry) from overloads (which require distinct entries).
+static bool isOverload(clang::CXXMethodDecl *m1, clang::CXXMethodDecl *m2) {
+ // FIXME: This should detect covariant return types, but currently doesn't.
I don't like things that can crash when asserts are off. I don't see why we
wouldn't just check this, If someone does pass in a method from on AST and
another from another AST, what will happen? Crash somewhere else? Why would we
risk crashing or misbehaving here when it is so easy to check and avoid. I'll
leave it at your discretion to do what you think is right though since I know
clang does this all over.
Repository:
rL LLVM
https://reviews.llvm.org/D41997
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D42206: If kevent() is interrupted by signal (or is being debugged) and we get EINTR, retry
jasonmolenda created this revision.
jasonmolenda added a reviewer: davide.
jasonmolenda added a project: LLDB.
Herald added subscribers: llvm-commits, JDevlieghere.
I hit this while trying to debug lldb-server. When lldb-server is waiting for
connections, it will be in MainLoop::RunImpl::Poll(), in the kevent() call. On
darwin systems, attaching to the process (or interrupting it to add a
breakpoint or detach) will interrupt the system call it is sitting in. We will
get back an error return value (-1) and errno will be set to EINTR.
Currently we flag this as an error and lldb-server exits with
error: IO object is not valid.
which makes it a bit difficult to debug.
This section of code is only used on the *BSD systems and Darwin (it's
#ifdef'ed HAVE_SYS_EVENT_H). I tested it on Darwin and on Linux (before
noticing that linux doesn't have sys/event.h) but don't have access to a *BSD
system. I don't expect any problems handling the interrupted kevent() call on
those systems as I'm doing here.
Repository:
rLLD LLVM Linker
https://reviews.llvm.org/D42206
Files:
source/Host/common/MainLoop.cpp
Index: source/Host/common/MainLoop.cpp
===
--- source/Host/common/MainLoop.cpp
+++ source/Host/common/MainLoop.cpp
@@ -105,8 +105,11 @@
for (auto &fd : loop.m_read_fds)
EV_SET(&in_events[i++], fd.first, EVFILT_READ, EV_ADD, 0, 0, 0);
- num_events = kevent(loop.m_kqueue, in_events.data(), in_events.size(),
- out_events, llvm::array_lengthof(out_events), nullptr);
+ do {
+errno = 0;
+num_events = kevent(loop.m_kqueue, in_events.data(), in_events.size(),
+out_events, llvm::array_lengthof(out_events), nullptr);
+ } while (num_events == -1 && errno == EINTR);
if (num_events < 0)
return Status("kevent() failed with error %d\n", num_events);
Index: source/Host/common/MainLoop.cpp
===
--- source/Host/common/MainLoop.cpp
+++ source/Host/common/MainLoop.cpp
@@ -105,8 +105,11 @@
for (auto &fd : loop.m_read_fds)
EV_SET(&in_events[i++], fd.first, EVFILT_READ, EV_ADD, 0, 0, 0);
- num_events = kevent(loop.m_kqueue, in_events.data(), in_events.size(),
- out_events, llvm::array_lengthof(out_events), nullptr);
+ do {
+errno = 0;
+num_events = kevent(loop.m_kqueue, in_events.data(), in_events.size(),
+out_events, llvm::array_lengthof(out_events), nullptr);
+ } while (num_events == -1 && errno == EINTR);
if (num_events < 0)
return Status("kevent() failed with error %d\n", num_events);
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D42206: If kevent() is interrupted by signal (or is being debugged) and we get EINTR, retry
davide requested changes to this revision. davide added a comment. This revision now requires changes to proceed. I think this one is reasonable, but please wait for another opinion before committing (and write a test). Pavel touched this code very recently and added tests for this so it should be possible to extend. @labath, what do you think? Repository: rLLD LLVM Linker https://reviews.llvm.org/D42206 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D42206: If kevent() is interrupted by signal (or is being debugged) and we get EINTR, retry
clayborg accepted this revision. clayborg added a comment. This is a very common unix thing. Repository: rLLD LLVM Linker https://reviews.llvm.org/D42206 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D42206: If kevent() is interrupted by signal (or is being debugged) and we get EINTR, retry
jasonmolenda added a comment. Hmmm, testing this would require launching lldb-server, attaching to it from a debugger, detaching, and seeing if lldb-server is still running. Repository: rLLD LLVM Linker https://reviews.llvm.org/D42206 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D42210: Re-enable logging on the child side of a fork() in lldb-server platform mode
jasonmolenda created this revision.
jasonmolenda added a reviewer: labath.
jasonmolenda added a project: LLDB.
Herald added a subscriber: llvm-commits.
When lldb-server is in platform mode and waiting for a connection, when it
receives a connection it fork()'s and then runs an lldb-server/debugserver to
respond to that connection. The amount of things done between a fork() and an
exec() should be very small, but if there is a bug in lldb-server and you're
trying to use logging to debug it, the fact that logging does not happen in the
child process makes it challenging to understand what is going on.
The fact that the logging re-enablement in the child will only happen when done
by hand makes me more comfortable with this.
Pavel, do you think you're the best person to talk to about this? I've tested
this on darwin and on ubuntu and both exhibit the same behavior. e.g.
terminal1% ./a.out
terminal2% bin/lldb-server platform --verbose --log-channels 'lldb
all:gdb-remote all' --server --listen '*:0' -m 11120 -M 11250
terminal3% lldb
(lldb) pla sel remote-linux
(lldb) pla connect connect://localhost:0
(lldb) pla pro att -n a.out
without this patch, the only logging you'll see is lldb-server waiting for a
connection, receiving a connection, and that's about it.
Repository:
rL LLVM
https://reviews.llvm.org/D42210
Files:
tools/lldb-server/lldb-platform.cpp
Index: tools/lldb-server/lldb-platform.cpp
===
--- tools/lldb-server/lldb-platform.cpp
+++ tools/lldb-server/lldb-platform.cpp
@@ -328,6 +328,10 @@
// Parent will continue to listen for new connections.
continue;
} else {
+// We lose the logging on the child side of the fork, re-enable it.
+if (!LLDBServerUtilities::SetupLogging(log_file, log_channels, 0))
+ return -1;
+
// Child process will handle the connection and exit.
g_server = 0;
// Listening socket is owned by parent process.
Index: tools/lldb-server/lldb-platform.cpp
===
--- tools/lldb-server/lldb-platform.cpp
+++ tools/lldb-server/lldb-platform.cpp
@@ -328,6 +328,10 @@
// Parent will continue to listen for new connections.
continue;
} else {
+// We lose the logging on the child side of the fork, re-enable it.
+if (!LLDBServerUtilities::SetupLogging(log_file, log_channels, 0))
+ return -1;
+
// Child process will handle the connection and exit.
g_server = 0;
// Listening socket is owned by parent process.
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D42206: If kevent() is interrupted by signal (or is being debugged) and we get EINTR, retry
vsk requested changes to this revision. vsk added a comment. Why not take an approach similar to the one in https://reviews.llvm.org/D41008? It looks like it's possible to set up a poll loop, call signal(), and verify that the loop is still running. Repository: rLLD LLVM Linker https://reviews.llvm.org/D42206 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D42206: If kevent() is interrupted by signal (or is being debugged) and we get EINTR, retry
davide added a comment. In https://reviews.llvm.org/D42206#979566, @vsk wrote: > Why not take an approach similar to the one in > https://reviews.llvm.org/D41008? It looks like it's possible to set up a poll > loop, call signal(), and verify that the loop is still running. Yes, that was what I had in mind. Repository: rLLD LLVM Linker https://reviews.llvm.org/D42206 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D42206: If kevent() is interrupted by signal (or is being debugged) and we get EINTR, retry
jasonmolenda added a comment. I tried sending signals to lldb-server via kill() and the signal handler caught them, the bit of code I had printing out the return value & errno value never got executed. The only way I was able to repo this was by debugging lldb-server. Repository: rLLD LLVM Linker https://reviews.llvm.org/D42206 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D42206: If kevent() is interrupted by signal (or is being debugged) and we get EINTR, retry
davide added a comment. In https://reviews.llvm.org/D42206#979570, @jasonmolenda wrote: > I tried sending signals to lldb-server via kill() and the signal handler > caught them, the bit of code I had printing out the return value & errno > value never got executed. The only way I was able to repo this was by > debugging lldb-server. I think Pavel might have ideas on how to test this. Let's wait for him and see. We could all learn something :) Repository: rLLD LLVM Linker https://reviews.llvm.org/D42206 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D42206: If kevent() is interrupted by signal (or is being debugged) and we get EINTR, retry
vsk added a comment. In https://reviews.llvm.org/D42206#979570, @jasonmolenda wrote: > I tried sending signals to lldb-server via kill() and the signal handler > caught them, the bit of code I had printing out the return value & errno > value never got executed. The only way I was able to repo this was by > debugging lldb-server. Is it possible to unregister the handler within the unit test? Repository: rLLD LLVM Linker https://reviews.llvm.org/D42206 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D42210: Re-enable logging on the child side of a fork() in lldb-server platform mode
davide requested changes to this revision. davide added a comment. This revision now requires changes to proceed. I took a look and I think this is a sensible change, but we should really test it. Repository: rL LLVM https://reviews.llvm.org/D42210 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D42206: If kevent() is interrupted by signal (or is being debugged) and we get EINTR, retry
clayborg added a comment. Are we going to test each unix call that can fail with EINTR? Seems a bit overkill. Repository: rLLD LLVM Linker https://reviews.llvm.org/D42206 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D42210: Re-enable logging on the child side of a fork() in lldb-server platform mode
jasonmolenda added a comment. Jim remembers some problem with logging across a fork()'ed process, Pavel does this ring a bell? This change might be completely bogus -- but it's very difficult to debug the child side of an lldb-server platform today. Repository: rL LLVM https://reviews.llvm.org/D42210 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D42206: If kevent() is interrupted by signal (or is being debugged) and we get EINTR, retry
vsk added a comment. In https://reviews.llvm.org/D42206#979607, @clayborg wrote: > Are we going to test each unix call that can fail with EINTR? Seems a bit > overkill. I think going forward, we should test all functional changes unless it really is prohibitively expensive to do so. Useful changes like this shouldn't be lost to accidental/unrelated commits, and having a regression test is a good way to ensure that. Repository: rLLD LLVM Linker https://reviews.llvm.org/D42206 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D42145: [lldb] Use vFlash commands when writing to target's flash memory regions
owenpshaw added a comment. I'm not envisioning that anything else needs to change to use begin/end or care it's there. I guess the way I look at it, having ObjectFile::LoadInMemory do begin/end is basically the same as what you're saying about having it be more process aware. If Process is going to introduce new concepts for ObjectFile to use either way, isn't a high level of abstraction (batched writes) preferable to ObjectFile needing to know the fine details of flash memory blocks or that flash is even used? And doesn't keeping the heavy lifting in ProcessGDB make it reusable should another case come along? Hope you don't mind the pushback. I think we're looking at this from different angles, and I'm genuinely asking to help my understanding of your thinking so hopefully we can converge on the same view. Comment at: include/lldb/Target/MemoryRegionInfo.h:109-110 ConstString m_name; + OptionalBool m_flash; + lldb::offset_t m_blocksize; }; clayborg wrote: > Could these two be combined into one entry? Could "m_blocksize" be > "m_flash_block_size" and if the value is zero, then it isn't flash? Sure, I can change that. Almost went that way initially, but thought the two fields made it a little clearer, and allowed for an error condition when flash is true, but the blocksize is invalid (0). Collapsing to one field means falling back to a regular memory write rather than an error. Not sure if it's a big deal either way. https://reviews.llvm.org/D42145 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D42215: [CMake] Make check-lldb work with LLDB_CODESIGN_IDENTITY=''
vsk created this revision.
vsk added reviewers: davide, aprantl, jasonmolenda.
Herald added a subscriber: mgorny.
On Darwin, if a test machine isn't set up for code-signing (see
docs/code-signing.txt), running check-lldb should use the system
debugserver instead of the unsigned one built in-tree. This makes it
possible to run lldb's test suite without having code-signing set up,
which is really convenient.
https://reviews.llvm.org/D42215
Files:
docs/code-signing.txt
test/CMakeLists.txt
Index: test/CMakeLists.txt
===
--- test/CMakeLists.txt
+++ test/CMakeLists.txt
@@ -25,7 +25,9 @@
endif()
if(TARGET debugserver)
- list(APPEND LLDB_TEST_DEPS debugserver)
+ if(NOT CMAKE_HOST_APPLE OR LLDB_CODESIGN_IDENTITY)
+list(APPEND LLDB_TEST_DEPS debugserver)
+ endif()
endif()
if(TARGET lldb-mi)
@@ -95,7 +97,17 @@
endif()
if(CMAKE_HOST_APPLE)
- list(APPEND LLDB_TEST_COMMON_ARGS --server $)
+ if(LLDB_CODESIGN_IDENTITY)
+list(APPEND LLDB_TEST_COMMON_ARGS --server $)
+ else()
+execute_process(
+ COMMAND xcode-select -p
+ OUTPUT_VARIABLE XCODE_DEV_DIR)
+string(STRIP ${XCODE_DEV_DIR} XCODE_DEV_DIR)
+set(SYSTEM_DEBUGSERVER
+
"${XCODE_DEV_DIR}/../SharedFrameworks/LLDB.framework/Resources/debugserver")
+list(APPEND LLDB_TEST_COMMON_ARGS --server ${SYSTEM_DEBUGSERVER})
+ endif()
endif()
set(LLDB_DOTEST_ARGS ${LLDB_TEST_COMMON_ARGS};${LLDB_TEST_USER_ARGS})
Index: docs/code-signing.txt
===
--- docs/code-signing.txt
+++ docs/code-signing.txt
@@ -1,6 +1,11 @@
-On MacOSX lldb needs to be code signed. The Debug, DebugClang and Release
-builds are set to code sign using a code signing certificate named
-"lldb_codesign".
+To use the in-tree debug server on macOS, lldb needs to be code signed. The
+Debug, DebugClang and Release builds are set to code sign using a code signing
+certificate named "lldb_codesign". This document explains how to set up the
+signing certificate.
+
+Note that it is possible build and use lldb on macOS without setting up code
+signing by using the system's debug server. To configure lldb in this way with
+cmake, specify -DLLDB_CODESIGN_IDENTITY=''.
If you have re-installed a new OS, please delete all old lldb_codesign items
from your keychain. There will be a code signing certification and a public
Index: test/CMakeLists.txt
===
--- test/CMakeLists.txt
+++ test/CMakeLists.txt
@@ -25,7 +25,9 @@
endif()
if(TARGET debugserver)
- list(APPEND LLDB_TEST_DEPS debugserver)
+ if(NOT CMAKE_HOST_APPLE OR LLDB_CODESIGN_IDENTITY)
+list(APPEND LLDB_TEST_DEPS debugserver)
+ endif()
endif()
if(TARGET lldb-mi)
@@ -95,7 +97,17 @@
endif()
if(CMAKE_HOST_APPLE)
- list(APPEND LLDB_TEST_COMMON_ARGS --server $)
+ if(LLDB_CODESIGN_IDENTITY)
+list(APPEND LLDB_TEST_COMMON_ARGS --server $)
+ else()
+execute_process(
+ COMMAND xcode-select -p
+ OUTPUT_VARIABLE XCODE_DEV_DIR)
+string(STRIP ${XCODE_DEV_DIR} XCODE_DEV_DIR)
+set(SYSTEM_DEBUGSERVER
+ "${XCODE_DEV_DIR}/../SharedFrameworks/LLDB.framework/Resources/debugserver")
+list(APPEND LLDB_TEST_COMMON_ARGS --server ${SYSTEM_DEBUGSERVER})
+ endif()
endif()
set(LLDB_DOTEST_ARGS ${LLDB_TEST_COMMON_ARGS};${LLDB_TEST_USER_ARGS})
Index: docs/code-signing.txt
===
--- docs/code-signing.txt
+++ docs/code-signing.txt
@@ -1,6 +1,11 @@
-On MacOSX lldb needs to be code signed. The Debug, DebugClang and Release
-builds are set to code sign using a code signing certificate named
-"lldb_codesign".
+To use the in-tree debug server on macOS, lldb needs to be code signed. The
+Debug, DebugClang and Release builds are set to code sign using a code signing
+certificate named "lldb_codesign". This document explains how to set up the
+signing certificate.
+
+Note that it is possible build and use lldb on macOS without setting up code
+signing by using the system's debug server. To configure lldb in this way with
+cmake, specify -DLLDB_CODESIGN_IDENTITY=''.
If you have re-installed a new OS, please delete all old lldb_codesign items
from your keychain. There will be a code signing certification and a public
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D42215: [CMake] Make check-lldb work with LLDB_CODESIGN_IDENTITY=''
aprantl added a comment. How about printing a message (if CMAKE_HOST_APPLE) that the system debugserver is being used at configure time? https://reviews.llvm.org/D42215 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D42215: [CMake] Make check-lldb work with LLDB_CODESIGN_IDENTITY=''
jasonmolenda added a comment. That's a good suggestion. We have some bots using the system debugserver -- and once in a while there's a change to both lldb and debugserver, and the bots running the older prebuilt debugserver will fail any tests for that patchset. https://reviews.llvm.org/D42215 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D42215: [CMake] Make check-lldb work with LLDB_CODESIGN_IDENTITY=''
vsk updated this revision to Diff 130325.
vsk added a comment.
Thanks for the feedback!
-Print out the path to the debug server as a status message
https://reviews.llvm.org/D42215
Files:
docs/code-signing.txt
test/CMakeLists.txt
Index: test/CMakeLists.txt
===
--- test/CMakeLists.txt
+++ test/CMakeLists.txt
@@ -25,7 +25,9 @@
endif()
if(TARGET debugserver)
- list(APPEND LLDB_TEST_DEPS debugserver)
+ if(NOT CMAKE_HOST_APPLE OR LLDB_CODESIGN_IDENTITY)
+list(APPEND LLDB_TEST_DEPS debugserver)
+ endif()
endif()
if(TARGET lldb-mi)
@@ -95,7 +97,18 @@
endif()
if(CMAKE_HOST_APPLE)
- list(APPEND LLDB_TEST_COMMON_ARGS --server $)
+ if(LLDB_CODESIGN_IDENTITY)
+set(DEBUGSERVER_PATH $)
+ else()
+execute_process(
+ COMMAND xcode-select -p
+ OUTPUT_VARIABLE XCODE_DEV_DIR)
+string(STRIP ${XCODE_DEV_DIR} XCODE_DEV_DIR)
+set(DEBUGSERVER_PATH
+
"${XCODE_DEV_DIR}/../SharedFrameworks/LLDB.framework/Resources/debugserver")
+ endif()
+ message(STATUS "Path to the lldb debugserver: ${DEBUGSERVER_PATH}")
+ list(APPEND LLDB_TEST_COMMON_ARGS --server ${DEBUGSERVER_PATH})
endif()
set(LLDB_DOTEST_ARGS ${LLDB_TEST_COMMON_ARGS};${LLDB_TEST_USER_ARGS})
Index: docs/code-signing.txt
===
--- docs/code-signing.txt
+++ docs/code-signing.txt
@@ -1,6 +1,11 @@
-On MacOSX lldb needs to be code signed. The Debug, DebugClang and Release
-builds are set to code sign using a code signing certificate named
-"lldb_codesign".
+To use the in-tree debug server on macOS, lldb needs to be code signed. The
+Debug, DebugClang and Release builds are set to code sign using a code signing
+certificate named "lldb_codesign". This document explains how to set up the
+signing certificate.
+
+Note that it is possible build and use lldb on macOS without setting up code
+signing by using the system's debug server. To configure lldb in this way with
+cmake, specify -DLLDB_CODESIGN_IDENTITY=''.
If you have re-installed a new OS, please delete all old lldb_codesign items
from your keychain. There will be a code signing certification and a public
Index: test/CMakeLists.txt
===
--- test/CMakeLists.txt
+++ test/CMakeLists.txt
@@ -25,7 +25,9 @@
endif()
if(TARGET debugserver)
- list(APPEND LLDB_TEST_DEPS debugserver)
+ if(NOT CMAKE_HOST_APPLE OR LLDB_CODESIGN_IDENTITY)
+list(APPEND LLDB_TEST_DEPS debugserver)
+ endif()
endif()
if(TARGET lldb-mi)
@@ -95,7 +97,18 @@
endif()
if(CMAKE_HOST_APPLE)
- list(APPEND LLDB_TEST_COMMON_ARGS --server $)
+ if(LLDB_CODESIGN_IDENTITY)
+set(DEBUGSERVER_PATH $)
+ else()
+execute_process(
+ COMMAND xcode-select -p
+ OUTPUT_VARIABLE XCODE_DEV_DIR)
+string(STRIP ${XCODE_DEV_DIR} XCODE_DEV_DIR)
+set(DEBUGSERVER_PATH
+ "${XCODE_DEV_DIR}/../SharedFrameworks/LLDB.framework/Resources/debugserver")
+ endif()
+ message(STATUS "Path to the lldb debugserver: ${DEBUGSERVER_PATH}")
+ list(APPEND LLDB_TEST_COMMON_ARGS --server ${DEBUGSERVER_PATH})
endif()
set(LLDB_DOTEST_ARGS ${LLDB_TEST_COMMON_ARGS};${LLDB_TEST_USER_ARGS})
Index: docs/code-signing.txt
===
--- docs/code-signing.txt
+++ docs/code-signing.txt
@@ -1,6 +1,11 @@
-On MacOSX lldb needs to be code signed. The Debug, DebugClang and Release
-builds are set to code sign using a code signing certificate named
-"lldb_codesign".
+To use the in-tree debug server on macOS, lldb needs to be code signed. The
+Debug, DebugClang and Release builds are set to code sign using a code signing
+certificate named "lldb_codesign". This document explains how to set up the
+signing certificate.
+
+Note that it is possible build and use lldb on macOS without setting up code
+signing by using the system's debug server. To configure lldb in this way with
+cmake, specify -DLLDB_CODESIGN_IDENTITY=''.
If you have re-installed a new OS, please delete all old lldb_codesign items
from your keychain. There will be a code signing certification and a public
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D42215: [CMake] Make check-lldb work with LLDB_CODESIGN_IDENTITY=''
davide accepted this revision. davide added a comment. This revision is now accepted and ready to land. LGTM with Adrian's suggestion applied, thanks for doing this! https://reviews.llvm.org/D42215 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r322803 - [CMake] Make check-lldb work with LLDB_CODESIGN_IDENTITY=''
Author: vedantk
Date: Wed Jan 17 17:16:30 2018
New Revision: 322803
URL: http://llvm.org/viewvc/llvm-project?rev=322803&view=rev
Log:
[CMake] Make check-lldb work with LLDB_CODESIGN_IDENTITY=''
On Darwin, if a test machine isn't set up for code-signing (see
docs/code-signing.txt), running check-lldb should use the system
debugserver instead of the unsigned one built in-tree. This makes it
possible to run lldb's test suite without having code-signing set up,
which is really convenient.
Differential Revision: https://reviews.llvm.org/D42215
Modified:
lldb/trunk/docs/code-signing.txt
lldb/trunk/test/CMakeLists.txt
Modified: lldb/trunk/docs/code-signing.txt
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/docs/code-signing.txt?rev=322803&r1=322802&r2=322803&view=diff
==
--- lldb/trunk/docs/code-signing.txt (original)
+++ lldb/trunk/docs/code-signing.txt Wed Jan 17 17:16:30 2018
@@ -1,6 +1,11 @@
-On MacOSX lldb needs to be code signed. The Debug, DebugClang and Release
-builds are set to code sign using a code signing certificate named
-"lldb_codesign".
+To use the in-tree debug server on macOS, lldb needs to be code signed. The
+Debug, DebugClang and Release builds are set to code sign using a code signing
+certificate named "lldb_codesign". This document explains how to set up the
+signing certificate.
+
+Note that it's possible to build and use lldb on macOS without setting up code
+signing by using the system's debug server. To configure lldb in this way with
+cmake, specify -DLLDB_CODESIGN_IDENTITY=''.
If you have re-installed a new OS, please delete all old lldb_codesign items
from your keychain. There will be a code signing certification and a public
Modified: lldb/trunk/test/CMakeLists.txt
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/test/CMakeLists.txt?rev=322803&r1=322802&r2=322803&view=diff
==
--- lldb/trunk/test/CMakeLists.txt (original)
+++ lldb/trunk/test/CMakeLists.txt Wed Jan 17 17:16:30 2018
@@ -25,7 +25,9 @@ if(TARGET lldb-server)
endif()
if(TARGET debugserver)
- list(APPEND LLDB_TEST_DEPS debugserver)
+ if(NOT CMAKE_HOST_APPLE OR LLDB_CODESIGN_IDENTITY)
+list(APPEND LLDB_TEST_DEPS debugserver)
+ endif()
endif()
if(TARGET lldb-mi)
@@ -95,7 +97,18 @@ if (NOT ${CMAKE_SYSTEM_NAME} MATCHES "Wi
endif()
if(CMAKE_HOST_APPLE)
- list(APPEND LLDB_TEST_COMMON_ARGS --server $)
+ if(LLDB_CODESIGN_IDENTITY)
+set(DEBUGSERVER_PATH $)
+ else()
+execute_process(
+ COMMAND xcode-select -p
+ OUTPUT_VARIABLE XCODE_DEV_DIR)
+string(STRIP ${XCODE_DEV_DIR} XCODE_DEV_DIR)
+set(DEBUGSERVER_PATH
+
"${XCODE_DEV_DIR}/../SharedFrameworks/LLDB.framework/Resources/debugserver")
+ endif()
+ message(STATUS "Path to the lldb debugserver: ${DEBUGSERVER_PATH}")
+ list(APPEND LLDB_TEST_COMMON_ARGS --server ${DEBUGSERVER_PATH})
endif()
set(LLDB_DOTEST_ARGS ${LLDB_TEST_COMMON_ARGS};${LLDB_TEST_USER_ARGS})
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D42215: [CMake] Make check-lldb work with LLDB_CODESIGN_IDENTITY=''
This revision was automatically updated to reflect the committed changes.
Closed by commit rL322803: [CMake] Make check-lldb work with
LLDB_CODESIGN_IDENTITY='' (authored by vedantk, committed by ).
Herald added a subscriber: llvm-commits.
Changed prior to commit:
https://reviews.llvm.org/D42215?vs=130325&id=130332#toc
Repository:
rL LLVM
https://reviews.llvm.org/D42215
Files:
lldb/trunk/docs/code-signing.txt
lldb/trunk/test/CMakeLists.txt
Index: lldb/trunk/docs/code-signing.txt
===
--- lldb/trunk/docs/code-signing.txt
+++ lldb/trunk/docs/code-signing.txt
@@ -1,6 +1,11 @@
-On MacOSX lldb needs to be code signed. The Debug, DebugClang and Release
-builds are set to code sign using a code signing certificate named
-"lldb_codesign".
+To use the in-tree debug server on macOS, lldb needs to be code signed. The
+Debug, DebugClang and Release builds are set to code sign using a code signing
+certificate named "lldb_codesign". This document explains how to set up the
+signing certificate.
+
+Note that it's possible to build and use lldb on macOS without setting up code
+signing by using the system's debug server. To configure lldb in this way with
+cmake, specify -DLLDB_CODESIGN_IDENTITY=''.
If you have re-installed a new OS, please delete all old lldb_codesign items
from your keychain. There will be a code signing certification and a public
Index: lldb/trunk/test/CMakeLists.txt
===
--- lldb/trunk/test/CMakeLists.txt
+++ lldb/trunk/test/CMakeLists.txt
@@ -25,7 +25,9 @@
endif()
if(TARGET debugserver)
- list(APPEND LLDB_TEST_DEPS debugserver)
+ if(NOT CMAKE_HOST_APPLE OR LLDB_CODESIGN_IDENTITY)
+list(APPEND LLDB_TEST_DEPS debugserver)
+ endif()
endif()
if(TARGET lldb-mi)
@@ -95,7 +97,18 @@
endif()
if(CMAKE_HOST_APPLE)
- list(APPEND LLDB_TEST_COMMON_ARGS --server $)
+ if(LLDB_CODESIGN_IDENTITY)
+set(DEBUGSERVER_PATH $)
+ else()
+execute_process(
+ COMMAND xcode-select -p
+ OUTPUT_VARIABLE XCODE_DEV_DIR)
+string(STRIP ${XCODE_DEV_DIR} XCODE_DEV_DIR)
+set(DEBUGSERVER_PATH
+
"${XCODE_DEV_DIR}/../SharedFrameworks/LLDB.framework/Resources/debugserver")
+ endif()
+ message(STATUS "Path to the lldb debugserver: ${DEBUGSERVER_PATH}")
+ list(APPEND LLDB_TEST_COMMON_ARGS --server ${DEBUGSERVER_PATH})
endif()
set(LLDB_DOTEST_ARGS ${LLDB_TEST_COMMON_ARGS};${LLDB_TEST_USER_ARGS})
Index: lldb/trunk/docs/code-signing.txt
===
--- lldb/trunk/docs/code-signing.txt
+++ lldb/trunk/docs/code-signing.txt
@@ -1,6 +1,11 @@
-On MacOSX lldb needs to be code signed. The Debug, DebugClang and Release
-builds are set to code sign using a code signing certificate named
-"lldb_codesign".
+To use the in-tree debug server on macOS, lldb needs to be code signed. The
+Debug, DebugClang and Release builds are set to code sign using a code signing
+certificate named "lldb_codesign". This document explains how to set up the
+signing certificate.
+
+Note that it's possible to build and use lldb on macOS without setting up code
+signing by using the system's debug server. To configure lldb in this way with
+cmake, specify -DLLDB_CODESIGN_IDENTITY=''.
If you have re-installed a new OS, please delete all old lldb_codesign items
from your keychain. There will be a code signing certification and a public
Index: lldb/trunk/test/CMakeLists.txt
===
--- lldb/trunk/test/CMakeLists.txt
+++ lldb/trunk/test/CMakeLists.txt
@@ -25,7 +25,9 @@
endif()
if(TARGET debugserver)
- list(APPEND LLDB_TEST_DEPS debugserver)
+ if(NOT CMAKE_HOST_APPLE OR LLDB_CODESIGN_IDENTITY)
+list(APPEND LLDB_TEST_DEPS debugserver)
+ endif()
endif()
if(TARGET lldb-mi)
@@ -95,7 +97,18 @@
endif()
if(CMAKE_HOST_APPLE)
- list(APPEND LLDB_TEST_COMMON_ARGS --server $)
+ if(LLDB_CODESIGN_IDENTITY)
+set(DEBUGSERVER_PATH $)
+ else()
+execute_process(
+ COMMAND xcode-select -p
+ OUTPUT_VARIABLE XCODE_DEV_DIR)
+string(STRIP ${XCODE_DEV_DIR} XCODE_DEV_DIR)
+set(DEBUGSERVER_PATH
+ "${XCODE_DEV_DIR}/../SharedFrameworks/LLDB.framework/Resources/debugserver")
+ endif()
+ message(STATUS "Path to the lldb debugserver: ${DEBUGSERVER_PATH}")
+ list(APPEND LLDB_TEST_COMMON_ARGS --server ${DEBUGSERVER_PATH})
endif()
set(LLDB_DOTEST_ARGS ${LLDB_TEST_COMMON_ARGS};${LLDB_TEST_USER_ARGS})
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
