[Lldb-commits] [lldb] r285992 - Fix GDBRemoteCommunicationClientTest.TestPacketSpeedJSON
Author: labath
Date: Fri Nov 4 06:49:06 2016
New Revision: 285992
URL: http://llvm.org/viewvc/llvm-project?rev=285992&view=rev
Log:
Fix GDBRemoteCommunicationClientTest.TestPacketSpeedJSON
The mock server was listening for only one packet (I forgot to put a loop around
it), which caused the client to stall in debug builds, as the timeout there is
1000 seconds. In case of a release builds the test would just silently succeed
as
the tested function does not check or report errors (which should be fixed).
This fixes the test by adding the server loop. Since the test was taking quite a
long time now (8s), I have added a parameter to control the amount of data sent
(default 4MB), and call it with a smaller value in the test, to make the test
run
faster.
Modified:
lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h
lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
lldb/trunk/unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp
Modified:
lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp?rev=285992&r1=285991&r2=285992&view=diff
==
---
lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
(original)
+++
lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
Fri Nov 4 06:49:06 2016
@@ -2148,8 +2148,9 @@ std::chrono::duration calculate_s
void GDBRemoteCommunicationClient::TestPacketSpeed(const uint32_t num_packets,
uint32_t max_send,
- uint32_t max_recv, bool
json,
- Stream &strm) {
+ uint32_t max_recv,
+ uint64_t recv_amount,
+ bool json, Stream &strm) {
using namespace std::chrono;
uint32_t i;
@@ -2215,13 +2216,11 @@ void GDBRemoteCommunicationClient::TestP
}
}
-const uint64_t k_recv_amount = 4 * 1024 * 1024; // Receive amount in bytes
-
-const float k_recv_amount_mb = (float)k_recv_amount / (1024.0f * 1024.0f);
+const float k_recv_amount_mb = (float)recv_amount / (1024.0f * 1024.0f);
if (json)
strm.Printf("\n]\n },\n \"download_speed\" : {\n\"byte_size\" "
": %" PRIu64 ",\n\"results\" : [",
- k_recv_amount);
+ recv_amount);
else
strm.Printf("Testing receiving %2.1fMB of data using varying receive "
"packet sizes:\n",
@@ -2238,7 +2237,7 @@ void GDBRemoteCommunicationClient::TestP
const auto start_time = steady_clock::now();
uint32_t bytes_read = 0;
uint32_t packet_count = 0;
-while (bytes_read < k_recv_amount) {
+while (bytes_read < recv_amount) {
StringExtractorGDBRemote response;
SendPacketAndWaitForResponse(packet.GetString(), response, false);
bytes_read += recv_size;
@@ -2246,7 +2245,7 @@ void GDBRemoteCommunicationClient::TestP
}
const auto end_time = steady_clock::now();
const auto total_time = end_time - start_time;
-float mb_second = ((float)k_recv_amount) /
+float mb_second = ((float)recv_amount) /
duration(total_time).count() /
(1024.0 * 1024.0);
float packets_per_second =
Modified:
lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h?rev=285992&r1=285991&r2=285992&view=diff
==
--- lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h
(original)
+++ lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h
Fri Nov 4 06:49:06 2016
@@ -323,7 +323,8 @@ public:
bool SetNonStopMode(const bool enable);
void TestPacketSpeed(const uint32_t num_packets, uint32_t max_send,
- uint32_t max_recv, bool json, Stream &strm);
+ uint32_t max_recv, uint64_t recv_amount, bool json,
+ Stream &strm);
// This packet is for testing the speed of the interface only. Both
// the client and server need to support it, but this allows us to
Modified: lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp?rev=285992&r1=285991&r2=285992
Re: [Lldb-commits] GDBRemoteCommunicationClientTest.TestPacketSpeedJSON unit test hanging for anyone else?
Hi Jason, Sorry about that. The problem was in the present in the debug builds only. r285992 should fix it. pl On 4 November 2016 at 02:45, Jason Molenda wrote: > Is anyone else seeing a hang in > GDBRemoteCommunicationClientTest.TestPacketSpeedJSON when running the unit > tests? It was a new test added in r285602, it always hangs for me on my > system, a macOS 10.12.something machine. Attaching to it with lldb, it's > waiting to get a packet down in > > thread #1: tid = 0x62358 com.apple.main-thread > 0 0x7fffbf8a3f4a libsystem_kernel`__select + 10 > 1 0x000105feb733 lldb-gtest`SelectHelper::Select + 4323 > SelectHelper.cpp:221 > 2 0x000105d8c6c5 > lldb-gtest`lldb_private::ConnectionFileDescriptor::BytesAvailable + 565 > ConnectionFileDescriptorPosix.cpp:594 > 3 0x000105d8be48 > lldb-gtest`lldb_private::ConnectionFileDescriptor::Read + 552 > ConnectionFileDescriptorPosix.cpp:394 > 4 0x000105378038 lldb-gtest`lldb_private::Communication::Read + 1416 > Communication.cpp:164 > 5 0x0001057e82bd > lldb-gtest`lldb_private::process_gdb_remote::GDBRemoteCommunication::WaitForPacketWithTimeoutMicroSecondsNoLock > + 381 GDBRemoteCommunication.cpp:355 > 6 0x0001057e7b5c > lldb-gtest`lldb_private::process_gdb_remote::GDBRemoteCommunication::ReadPacket > + 204 GDBRemoteCommunication.cpp:286 > 7 0x000105de0636 > lldb-gtest`lldb_private::process_gdb_remote::GDBRemoteClientBase::SendPacketAndWaitForResponseNoLock > + 502 GDBRemoteClientBase.cpp:191 > 8 0x000105de03fe > lldb-gtest`lldb_private::process_gdb_remote::GDBRemoteClientBase::SendPacketAndWaitForResponse > + 430 GDBRemoteClientBase.cpp:179 > 9 0x000105d1e2b3 > lldb-gtest`lldb_private::process_gdb_remote::GDBRemoteCommunicationClient::TestPacketSpeed > + 1667 GDBRemoteCommunicationClient.cpp:2183 > 10 0x000102a4d29d > lldb-gtest`GDBRemoteCommunicationClientTest_TestPacketSpeedJSON_Test::TestBody > + 269 GDBRemoteCommunicationClientTest.cpp:287 > > > > with frame 10 being, > > frame #10: 0x000102a4d29d > lldb-gtest`GDBRemoteCommunicationClientTest_TestPacketSpeedJSON_Test::TestBody(this=0x7fb687d0d530) > + 269 at GDBRemoteCommunicationClientTest.cpp:287 >284}); >285 >286StreamString ss; > -> 287client.TestPacketSpeed(10, 32, 32, true, ss); >288client.Disconnect(); >289server_thread.join(); >290 > > > The most unusual thing I saw in a quick stack crawl is in > GDBRemoteCommunication::WaitForPacketWithTimeoutMicroSecondsNoLock where it's > being told to wait for 10 microseconds, I think that's 1000 seconds > or 16 minutes. So maybe it would complete if I waited 15 minutes longer than > I have been. ;) The 1000 seconds is the default timeout for a debug build (GDBRemoteCommunication.cpp:136). Things may behave differently for a release build, where the timeout is 1, but I don't think that will make the test pass. I will > > I'll try to build this up & test it on my more common external-mac setup at > home, but I don't think this one would be impacted by our internal OS > installs. > > >> On Oct 31, 2016, at 10:19 AM, Pavel Labath via lldb-commits >> wrote: >> >> Author: labath >> Date: Mon Oct 31 12:19:42 2016 >> New Revision: 285602 >> >> URL: http://llvm.org/viewvc/llvm-project?rev=285602&view=rev >> Log: >> Remove usages of TimeValue from gdb-remote process plugin >> >> Summary: >> Most of the changes are very straight-forward, the only tricky part was the >> "packet speed-test" function, which is very time-heavy. As the function was >> completely untested, I added a quick unit smoke test for it. >> >> Reviewers: clayborg, zturner >> >> Subscribers: lldb-commits >> >> Differential Revision: https://reviews.llvm.org/D25391 >> >> Modified: >>lldb/trunk/source/Plugins/Platform/gdb-server/PlatformRemoteGDBServer.cpp >>lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteClientBase.cpp >>lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp >>lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.h >> >> lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp >> >> lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h >> >> lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp >>lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp >> >> lldb/trunk/unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp >> >> Modified: >> lldb/trunk/source/Plugins/Platform/gdb-server/PlatformRemoteGDBServer.cpp >> URL: >> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Platform/gdb-server/PlatformRemoteGDBServer.cpp?rev=285602&r1=285601&r2=285602&view=diff >> == >> --- >> lldb/trunk/source/Plugins/Platform/gdb-server/PlatformRemoteGDBServer.cpp >> (original)
[Lldb-commits] [PATCH] D26295: Change UnwindAssemblyInstEmulation to remove a register location instead of marking it as IsSame()
tberghammer added a comment. My understanding (can be wrong) is that there IS a difference between not specifying a register in the unwind info versus specifying it as "is same" for volatile (caller saved) registers. I think for volatile registers not specifying them means that we can't access their current value in the parent frame (because they are lost) while specifying them as "is same" means we know that their value in the parent frame is the same as in the current one so we can display them. If "is same" and "not specified" would be equivalent then we should just completely get rid of the "is same" case (as it is useless) but as far as I know they have subtle differences. Repository: rL LLVM https://reviews.llvm.org/D26295 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D26300: ELF core: Adding parsing of the floating-point and SSE registers on x86 32/64 bit elf core files
dvlahovski created this revision.
dvlahovski added a reviewer: labath.
dvlahovski added a subscriber: lldb-commits.
The floating-point and SSE registers could be present in the elf-core
file in the note NT_FPREGSET for 64 bit ones, and in the note
NT_PRXFPREG for 32 bit ones.
The entire note is a binary blob matching the layout of the x87 save
area that gets generated by the FXSAVE instruction (see Intel developers
manual for more information).
This CL mainly modifies the RegisterRead function in
RegisterContextPOSIXCore_x86_64 for it to return the correct data both
for GPR and FPR/SSE registers, and return false (meaning "this register
is not available") for other registers.
I added a test to TestElfCore.py that tests reading FPR/SSE registers
both from a 32 and 64 bit elf-core file and I have inluded the source
which I used to generate the core files.
I tried to also add support for the AVX registers, because this info could
also be present in the elf-core file (note NT_X86_XSTATE - that is the result of
the newer XSAVE instruction). Parsing the contents from the file is
easy. The problem is that the ymm registers are split into two halves
and they are in different places in the note. For making this work one
would either make a "hacky" approach, because there won't be
any other way with the current state of the register contexts - they
assume that "this register is of size N and at offset M" and
don't have the notion of discontinuos registers.
https://reviews.llvm.org/D26300
Files:
packages/Python/lldbsuite/test/functionalities/postmortem/linux-core/TestLinuxCore.py
packages/Python/lldbsuite/test/functionalities/postmortem/linux-core/fpr_sse.cpp
packages/Python/lldbsuite/test/functionalities/postmortem/linux-core/fpr_sse_i386.core
packages/Python/lldbsuite/test/functionalities/postmortem/linux-core/fpr_sse_x86_64.core
source/Plugins/Process/Utility/RegisterContextLinux_i386.cpp
source/Plugins/Process/Utility/RegisterContextLinux_i386.h
source/Plugins/Process/Utility/RegisterContextLinux_x86_64.cpp
source/Plugins/Process/Utility/RegisterContextLinux_x86_64.h
source/Plugins/Process/Utility/RegisterContextPOSIX_x86.cpp
source/Plugins/Process/Utility/RegisterContextPOSIX_x86.h
source/Plugins/Process/Utility/RegisterInfoInterface.h
source/Plugins/Process/elf-core/ProcessElfCore.cpp
source/Plugins/Process/elf-core/RegisterContextPOSIXCore_x86_64.cpp
source/Plugins/Process/elf-core/RegisterContextPOSIXCore_x86_64.h
Index: source/Plugins/Process/elf-core/RegisterContextPOSIXCore_x86_64.h
===
--- source/Plugins/Process/elf-core/RegisterContextPOSIXCore_x86_64.h
+++ source/Plugins/Process/elf-core/RegisterContextPOSIXCore_x86_64.h
@@ -24,8 +24,6 @@
const lldb_private::DataExtractor &gpregset,
const lldb_private::DataExtractor &fpregset);
- ~RegisterContextCorePOSIX_x86_64() override;
-
bool ReadRegister(const lldb_private::RegisterInfo *reg_info,
lldb_private::RegisterValue &value) override;
@@ -48,7 +46,8 @@
bool WriteFPR() override;
private:
- uint8_t *m_gpregset;
+ std::shared_ptr m_gpregset;
+ std::shared_ptr m_fpregset;
};
#endif // liblldb_RegisterContextCorePOSIX_x86_64_h_
Index: source/Plugins/Process/elf-core/RegisterContextPOSIXCore_x86_64.cpp
===
--- source/Plugins/Process/elf-core/RegisterContextPOSIXCore_x86_64.cpp
+++ source/Plugins/Process/elf-core/RegisterContextPOSIXCore_x86_64.cpp
@@ -21,18 +21,27 @@
size_t size, len;
size = GetGPRSize();
- m_gpregset = new uint8_t[size];
- len = gpregset.ExtractBytes(0, size, lldb::eByteOrderLittle, m_gpregset);
- assert(len == size);
-}
+ m_gpregset.reset(new uint8_t[size], std::default_delete());
+ len =
+ gpregset.ExtractBytes(0, size, lldb::eByteOrderLittle, m_gpregset.get());
+ if (len != size)
+m_gpregset.reset();
-RegisterContextCorePOSIX_x86_64::~RegisterContextCorePOSIX_x86_64() {
- delete[] m_gpregset;
+ size = sizeof(FXSAVE);
+ m_fpregset.reset(new uint8_t[size], std::default_delete());
+ len =
+ fpregset.ExtractBytes(0, size, lldb::eByteOrderLittle, m_fpregset.get());
+ if (len != size)
+m_fpregset.reset();
}
-bool RegisterContextCorePOSIX_x86_64::ReadGPR() { return m_gpregset != NULL; }
+bool RegisterContextCorePOSIX_x86_64::ReadGPR() {
+ return m_gpregset != nullptr;
+}
-bool RegisterContextCorePOSIX_x86_64::ReadFPR() { return false; }
+bool RegisterContextCorePOSIX_x86_64::ReadFPR() {
+ return m_fpregset != nullptr;
+}
bool RegisterContextCorePOSIX_x86_64::WriteGPR() {
assert(0);
@@ -46,15 +55,27 @@
bool RegisterContextCorePOSIX_x86_64::ReadRegister(const RegisterInfo *reg_info,
RegisterValue &value) {
- switch (reg_info->byte_size) {
- case 4:
-value = *(uint32_t *)(m_gpregset + reg_info->byte_offset);
-return
[Lldb-commits] [lldb] r286003 - Preliminary plumbing work to make 'parray' able to take offset and stride options
Author: enrico
Date: Fri Nov 4 13:15:39 2016
New Revision: 286003
URL: http://llvm.org/viewvc/llvm-project?rev=286003&view=rev
Log:
Preliminary plumbing work to make 'parray' able to take offset and stride
options
Modified:
lldb/trunk/include/lldb/DataFormatters/DumpValueObjectOptions.h
lldb/trunk/source/DataFormatters/DumpValueObjectOptions.cpp
lldb/trunk/source/DataFormatters/ValueObjectPrinter.cpp
Modified: lldb/trunk/include/lldb/DataFormatters/DumpValueObjectOptions.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/DataFormatters/DumpValueObjectOptions.h?rev=286003&r1=286002&r2=286003&view=diff
==
--- lldb/trunk/include/lldb/DataFormatters/DumpValueObjectOptions.h (original)
+++ lldb/trunk/include/lldb/DataFormatters/DumpValueObjectOptions.h Fri Nov 4
13:15:39 2016
@@ -42,6 +42,22 @@ public:
ValueObject *valobj, const std::string &summary);
};
+ struct PointerAsArraySettings {
+size_t m_element_count;
+size_t m_base_element;
+size_t m_stride;
+
+PointerAsArraySettings()
+: m_element_count(0), m_base_element(0), m_stride() {}
+
+PointerAsArraySettings(size_t elem_count, size_t base_elem = 0,
+ size_t stride = 1)
+: m_element_count(elem_count), m_base_element(base_elem),
+ m_stride(stride) {}
+
+operator bool() { return m_element_count > 0; }
+ };
+
typedef std::function
DeclPrintingHelper;
@@ -116,6 +132,9 @@ public:
DumpValueObjectOptions &SetElementCount(uint32_t element_count = 0);
+ DumpValueObjectOptions &
+ SetPointerAsArray(const PointerAsArraySettings &ptr_array);
+
public:
uint32_t m_max_depth = UINT32_MAX;
lldb::DynamicValueType m_use_dynamic = lldb::eNoDynamicValues;
@@ -126,7 +145,7 @@ public:
lldb::LanguageType m_varformat_language = lldb::eLanguageTypeUnknown;
PointerDepth m_max_ptr_depth;
DeclPrintingHelper m_decl_printing_helper;
- uint32_t m_element_count = 0;
+ PointerAsArraySettings m_pointer_as_array;
bool m_use_synthetic : 1;
bool m_scope_already_checked : 1;
bool m_flat_output : 1;
Modified: lldb/trunk/source/DataFormatters/DumpValueObjectOptions.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/DataFormatters/DumpValueObjectOptions.cpp?rev=286003&r1=286002&r2=286003&view=diff
==
--- lldb/trunk/source/DataFormatters/DumpValueObjectOptions.cpp (original)
+++ lldb/trunk/source/DataFormatters/DumpValueObjectOptions.cpp Fri Nov 4
13:15:39 2016
@@ -22,7 +22,7 @@ using namespace lldb_private;
DumpValueObjectOptions::DumpValueObjectOptions()
: m_summary_sp(), m_root_valobj_name(),
m_max_ptr_depth(PointerDepth{PointerDepth::Mode::Default, 0}),
- m_decl_printing_helper(), m_use_synthetic(true),
+ m_decl_printing_helper(), m_pointer_as_array(), m_use_synthetic(true),
m_scope_already_checked(false), m_flat_output(false),
m_ignore_cap(false),
m_show_types(false), m_show_location(false), m_use_objc(false),
m_hide_root_type(false), m_hide_name(false), m_hide_value(false),
@@ -195,6 +195,12 @@ DumpValueObjectOptions::SetRevealEmptyAg
DumpValueObjectOptions &
DumpValueObjectOptions::SetElementCount(uint32_t element_count) {
- m_element_count = element_count;
+ m_pointer_as_array = PointerAsArraySettings(element_count);
+ return *this;
+}
+
+DumpValueObjectOptions &DumpValueObjectOptions::SetPointerAsArray(
+const PointerAsArraySettings &ptr_array) {
+ m_pointer_as_array = ptr_array;
return *this;
}
Modified: lldb/trunk/source/DataFormatters/ValueObjectPrinter.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/DataFormatters/ValueObjectPrinter.cpp?rev=286003&r1=286002&r2=286003&view=diff
==
--- lldb/trunk/source/DataFormatters/ValueObjectPrinter.cpp (original)
+++ lldb/trunk/source/DataFormatters/ValueObjectPrinter.cpp Fri Nov 4 13:15:39
2016
@@ -359,7 +359,7 @@ void ValueObjectPrinter::GetValueSummary
lldb::Format format = m_options.m_format;
// if I am printing synthetized elements, apply the format to those elements
// only
- if (m_options.m_element_count > 0)
+ if (m_options.m_pointer_as_array)
m_valobj->GetValueAsCString(lldb::eFormatDefault, value);
else if (format != eFormatDefault && format != m_valobj->GetFormat())
m_valobj->GetValueAsCString(format, value);
@@ -449,7 +449,7 @@ bool ValueObjectPrinter::PrintObjectDesc
if (ShouldPrintValueObject()) {
// let's avoid the overly verbose no description error for a nil thing
if (m_options.m_use_objc && !IsNil() && !IsUninitialized() &&
-(m_options.m_element_count == 0)) {
+(!m_options.m_pointer_as_array)) {
if (!m_options.m_hide_value || !m_options.m_hide_name)
m_stream-
[Lldb-commits] [PATCH] D26300: ELF core: Adding parsing of the floating-point and SSE registers on x86 32/64 bit elf core files
emaste added a comment. We need to make sure this does not regress FreeBSD core handling -- I will test as soon as I can, and add FXSAVE parsing for FreeBSD. I'll use fpr_sse.cpp to generate FreeBSD core files as well (although note that we get ~2.5MB cores with default configuration, so tweaking malloc options will be necessary). Please document how the core files were created (e.g. compiler invocation), perhaps as a comment in the source file. Comment at: packages/Python/lldbsuite/test/functionalities/postmortem/linux-core/TestLinuxCore.py:107 +@skipIf(oslist=['windows']) +@skipIf(triple='^mips') Curious, why are these skipped only on windows? https://reviews.llvm.org/D26300 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D26300: ELF core: Adding parsing of the floating-point and SSE registers on x86 32/64 bit elf core files
labath added a comment. I was very successful in creating tiny core files by avoiding linking with the standard library (you don't really need a full libc to crash :P ). I think this file should use the same approach as well (see the other core files in this directory, and the make-core.sh script). Ed, maybe you could start by tweaking that script to work on FreeBSD as well? Depending on how similar it ends up, we may want to keep it here (and rename the folder to just "elf-core", or we can create a separate "freebsd-core" folder instead... https://reviews.llvm.org/D26300 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D26295: Change UnwindAssemblyInstEmulation to remove a register location instead of marking it as IsSame()
jasonmolenda added a comment. Ah, interesting point, I didn't think of that. However, this touches on another thing I've been thinking about as I look at the assembly inspection unwind plan generators. In the x86 unwind inspector, I've hardcoded the SysV-x86_64 ABI and the unwind plan generator ignores any saves/restores of volatile registers. It's a poor choice and it's the kind of thing that surely won't be correct when a Windows port is up & running. I'm thinking the unwind plan generators should treat all registers as non-volatile. When UnwindLLDB / RegisterContextLLDB run the UnwindPlan, they can ask the ABI if a register is volatile or not - and refuse to retrieve a volatile register for a stack frame in the middle of the stack. (it SHOULD be doing that already) The problem with tracking a register that is volatile is that as soon as the function makes a call into another function, we have to assume the register value is overwritten. So if we have 0xfff021f7bd80 <+0>:stpx28, x27, [sp, #-0x60]! 0xfff021f7bd84 <+4>:stpx26, x25, [sp, #0x10] 0xfff021f7bd88 <+8>:stpx24, x23, [sp, #0x20] 0xfff021f7bd8c <+12>: stpx22, x21, [sp, #0x30] 0xfff021f7bd90 <+16>: stpx20, x19, [sp, #0x40] 0xfff021f7bd94 <+20>: stpx29, x30, [sp, #0x50] 0xfff021f7bd98 <+24>: addx29, sp, #0x50; =0x50 0xfff021f7bd9c <+28>: subsp, sp, #0xe0 ; =0xe0 0xfff021f7bdd4 <+84>: bl 0xfff021f8af70 0xfff021f7c334 <+1460>: strw9, [sp, #0x60] x9 is volatile in the AAPCS64 ABI, so at this offset in the assembly the value has already been overwritten by the call instruction at +84. If I later see a load of x9 and mark the register as "IsSame", now we've got a problem because we're saying it has the original value. If we were going to follow the IsSame-means-unmodified thinking through, we'd want to mark every register as IsSame on function entry and only remove that markup when the register is modified. I guess I'm trying to say two things. (1) I'd really like to get rid of IsSame so that the unwind plan dumps are easier for me to read ;) and (2) I think the instruction profiler unwind plan generators should track all registers without knowledge of the ABI, and leave it to the runtime code to decide which registers we will allow to be looked up. Repository: rL LLVM https://reviews.llvm.org/D26295 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D26315: make-core.sh: add FreeBSD support
emaste created this revision.
emaste added a reviewer: labath.
emaste added a subscriber: lldb-commits.
https://reviews.llvm.org/D26315
Files:
packages/Python/lldbsuite/test/functionalities/postmortem/linux-core/make-core.sh
Index:
packages/Python/lldbsuite/test/functionalities/postmortem/linux-core/make-core.sh
===
---
packages/Python/lldbsuite/test/functionalities/postmortem/linux-core/make-core.sh
+++
packages/Python/lldbsuite/test/functionalities/postmortem/linux-core/make-core.sh
@@ -1,4 +1,30 @@
-#! /bin/bash
+#! /bin/sh
+
+linux_check_core_pattern()
+{
+if grep -q '^|' &2
+exit 1
+;;
+esac
set -e -x
@@ -10,13 +36,8 @@
exit 1
fi
-if grep -q '^|' smaller core files.
Index: packages/Python/lldbsuite/test/functionalities/postmortem/linux-core/make-core.sh
===
--- packages/Python/lldbsuite/test/functionalities/postmortem/linux-core/make-core.sh
+++ packages/Python/lldbsuite/test/functionalities/postmortem/linux-core/make-core.sh
@@ -1,4 +1,30 @@
-#! /bin/bash
+#! /bin/sh
+
+linux_check_core_pattern()
+{
+if grep -q '^|' &2
+exit 1
+;;
+esac
set -e -x
@@ -10,13 +36,8 @@
exit 1
fi
-if grep -q '^|' smaller core files.
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D26315: make-core.sh: add FreeBSD support
emaste added a comment. Output on FreeBSD, with the patch: % sh make-core.sh main.c + file=main.c + [ -z main.c ] + [ FreeBSD '=' Linux ] + ulimit -c 1000 + ulimit -c + real_limit=1000 + [ 1000 -lt 100 ] + cc -nostdlib -static -g main.c -o a.out + cat Executable file is in a.out. Core file will be saved according to pattern %N.core. + ulimit -s 8 + exec ./a.out zsh: segmentation fault (core dumped) sh make-core.sh main.c https://reviews.llvm.org/D26315 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D26300: ELF core: Adding parsing of the floating-point and SSE registers on x86 32/64 bit elf core files
emaste added a comment. Good point. https://reviews.llvm.org/D26315 has the change to add FreeBSD support to make-core.sh -- just avoiding /bin/bash, and the core file handler check. I think we should be able to rename this directory to elf-core, and rename the individual cores to e.g. linux-i386.core, etc. https://reviews.llvm.org/D26300 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D26249: [unittests] Split DWARF tests out of PDB, fix standalone build
zturner accepted this revision. zturner added a comment. This revision is now accepted and ready to land. looks good, sorry for the delay was busy with the LLVM dev conference. Comment at: unittests/SymbolFile/DWARF/SymbolFileDWARFTests.cpp:33-36 +#if defined(_MSC_VER) +#include "lldb/Host/windows/windows.h" +#include +#endif This can go away, along with all the other preprocessor definitions. (only for the dwarf-specific test file). https://reviews.llvm.org/D26249 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
