Re: [Lldb-commits] [PATCH] D23290: Added enforce-interactivity setting
labath added a comment. I would implement this logic slightly differently: Have a ternary setting, let's call it `debugger.interactive`, whose values are `never, always, auto`, with `auto` (the current behavior) being the default. I think that makes it the behavior of the debugger more predictible and understandable, and it is the pattern used in other places as well (see `grep --color=WHEN`) That said, I am slightly worried about the idea of controlling the debugger over stdio. I don't know what's your use case, but if you want to make a robust solution, I'd recommend going with scripting API. If there is something you cannot achieve using the scripting API, we'd welcome patches to add the functionality. https://reviews.llvm.org/D23290 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D20386: Correct makefile.rules to use arm/aarch64 target specific AR and OBJCOPY
labath added inline comments. Comment at: packages/Python/lldbsuite/test/make/Makefile.rules:304 @@ +303,3 @@ + $(subst $(3),$(1),$(2)), \ + $(if $(findstring ar,$(1)), \ +$(if $(findstring gcc,$(3)), \ omjavaid wrote: > labath wrote: > > I think like we should replace ar with gcc-ar always, and not just when we > > don't have a version suffix present. When I have a gcc installed to a > > custom prefix, I get `$prefix/gcc-ar`, but not `$prefix/ar`. (Previously we > > would just use `ar` unconditionally, which was probably a bug.) > > > > Next, when you specify a clang compiler as `clang-3.5`, you will produce > > `ar-3.5`, which almost certainly does not exist. I think that in case of > > clang we should just strip the version suffix (produce `XXX-ar`) and hope > > for the best (should work for all our current use cases). > > > > Finally, I don't think objcopy is ever versioned with gcc (correct me if I > > am wrong), so I think that in case of objcopy we should strip the version > > suffix unconditionally `XXX-objcopy`. > > > > So, to summarize, these are the transformations I think are wrong: > > `foo/gcc` -> `foo/ar` (should be `foo/gcc-ar`) > > `clang-3.5` -> `ar-3.5` (should be `ar`) > > `gcc-4.8` -> `objcopy-4.8` (should be `objcopy`) > > > > Let me know if these are compatible with your requirements. If we can't > > find a set of rules that work everywhere, we will have to abandon the magic > > (or maybe just leave a simple one), and require the user to specify the > > paths manually... > I checked with gcc people in my team and here is what they have to say. > omjavaid, gcc-ar is a version of ar with LTO support > omjavaid, ar is just ar > omjavaid, likewise with gcc-nm and gcc-ranlib > omjavaid, ar comes from binutils, gcc-ar comes from gcc > > I agree with all other points you raised except for using gcc-ar in all > cases. We should decide between ar (binutils) or gcc-ar (LTO support gcc > packaged). > > Also present code doesnt generate obcopy-4.8 for me when i specify gcc-4.8. > If it does for you let me know. > I agree with all other points you raised except for using gcc-ar in all > cases. We should decide between ar (binutils) or gcc-ar (LTO support gcc > packaged). Ok, makes sense. Since we presently do not care about LTO support. I propose we just go with `ar` always. It will make things predictible, as we will avoid the whole version mess (we can just strip it). It will also mean we can treat `objcopy` and `ar` the same way. I.e., the transformation rule should be: `optional-path/optional-triple-gcc-optional.version` -> `optional-path/optional-triple-$TOOL`. This will not cover all of the cases for us right now, because in case of a `gcc` installed to a custom prefix, there will not be an `ar` next to it, but I can fix that by adding a couple of symlinks. Would that work for you? > Also present code doesn't generate obcopy-4.8 for me when i specify gcc-4.8. > If it does for you let me know. It does not add the version suffix for me either. I must have got something wrong yesterday. Please ignore that remark. https://reviews.llvm.org/D20386 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [lldb] r278197 - Undid LLVM macro usage in test suite test subject files.
Zach, it looks like you have a `#define LLVM_PRETTY_FUNCTION
LLVM_PRETTY_FUNCTION` in the non-windows path in test_common.h, which
makes it a no-op. If you change the definition to __PRETTY_FUNCTION__
then it should work.
pl
On 10 August 2016 at 05:21, Todd Fiala via lldb-commits
wrote:
> That sounds fine. Feel free to give it a shot. I can have a look in the
> morning if it's broken again. I assumed initially that it was
> over-aggressive search and replace so I didn't bother to look at the
> details.
>
>
> On Tuesday, August 9, 2016, Zachary Turner wrote:
>>
>> Hmm, the common Makefile.rules configures it to be a force include from
>> the command line. It's possible this isn't being done with gcc or some
>> other compiler. I suppose I can change test_common.h to #define
>> __PRETTY_FUNCTION__ __FUNCSIG__ on windows which would also fix those tests.
>>
>> On Tue, Aug 9, 2016 at 8:26 PM Todd Fiala wrote:
>>>
>>> Maybe those tests aren't including test_common.h? Dunno.
>>>
>>> On Tue, Aug 9, 2016 at 8:25 PM, Todd Fiala wrote:
No, sorry, it does not.
Each of those got undefined macro errors on macOS.
-Todd
On Tue, Aug 9, 2016 at 7:18 PM, Zachary Turner
wrote:
>
> This will make the tests start failing again on Windows. I #defined
> these in test_common.h, it should work. Does it not?
>
> On Tue, Aug 9, 2016 at 6:45 PM Todd Fiala via lldb-commits
> wrote:
>>
>> Author: tfiala
>> Date: Tue Aug 9 20:37:27 2016
>> New Revision: 278197
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=278197&view=rev
>> Log:
>> Undid LLVM macro usage in test suite test subject files.
>>
>> Modified:
>>
>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/cpp/main.cpp
>>
>> lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/diamond/main.cpp
>>
>> lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/virtual/main.cpp
>>
>> Modified:
>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/cpp/main.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/cpp/main.cpp?rev=278197&r1=278196&r2=278197&view=diff
>>
>> ==
>> ---
>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/cpp/main.cpp
>> (original)
>> +++
>> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/cpp/main.cpp
>> Tue Aug 9 20:37:27 2016
>> @@ -16,15 +16,15 @@ namespace a {
>> ~c();
>> void func1()
>> {
>> -puts (LLVM_PRETTY_FUNCTION);
>> +puts (__PRETTY_FUNCTION__);
>> }
>> void func2()
>> {
>> -puts (LLVM_PRETTY_FUNCTION);
>> +puts (__PRETTY_FUNCTION__);
>> }
>> void func3()
>> {
>> -puts (LLVM_PRETTY_FUNCTION);
>> +puts (__PRETTY_FUNCTION__);
>> }
>> };
>>
>> @@ -39,11 +39,11 @@ namespace b {
>> ~c();
>> void func1()
>> {
>> -puts (LLVM_PRETTY_FUNCTION);
>> +puts (__PRETTY_FUNCTION__);
>> }
>> void func3()
>> {
>> -puts (LLVM_PRETTY_FUNCTION);
>> +puts (__PRETTY_FUNCTION__);
>> }
>> };
>>
>> @@ -58,11 +58,11 @@ namespace c {
>> ~d() {}
>> void func2()
>> {
>> -puts (LLVM_PRETTY_FUNCTION);
>> +puts (__PRETTY_FUNCTION__);
>> }
>> void func3()
>> {
>> -puts (LLVM_PRETTY_FUNCTION);
>> +puts (__PRETTY_FUNCTION__);
>> }
>> };
>> }
>>
>> Modified:
>> lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/diamond/main.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/diamond/main.cpp?rev=278197&r1=278196&r2=278197&view=diff
>>
>> ==
>> ---
>> lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/diamond/main.cpp
>> (original)
>> +++
>> lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/diamond/main.cpp Tue
>> Aug
>> 9 20:37:27 2016
>> @@ -17,7 +17,7 @@ public:
>> virtual ~VBase() {}
>> void Print()
>> {
>> -printf("%p: %s\n%p: m_value = 0x%8.8x\n", this,
>> LLVM_PRETTY_FUNCTION, &m_value, m_value);
>> +printf("%p: %s\n%p: m_value = 0x%8.8x\n", this,
>> __PRETTY_FUNCTION__, &m_value, m_value);
>> }
>> int m_value;
>> };
>> @@ -28,7 +28,7
Re: [Lldb-commits] [PATCH] D22914: [WIP] Add concurrent packets support to gdb-remote client
labath added a comment. In https://reviews.llvm.org/D22914#510084, @clayborg wrote: > Let me know how things look on Mac. Our lock primitives are not as fast as > linux. If all looks good on Mac speed wise, we should be good to go. These are the results on Mac. Before: Testing sending 1000 packets of various sizes: qSpeedTest(send=0 , recv=0 ) in 0.069825000 sec for 14321.52 packets/sec ( 0.069825 ms per packet) with standard deviation of 0.072367 ms qSpeedTest(send=0 , recv=4 ) in 0.059877000 sec for 16700.90 packets/sec ( 0.059877 ms per packet) with standard deviation of 0.052829 ms qSpeedTest(send=0 , recv=8 ) in 0.062646000 sec for 15962.71 packets/sec ( 0.062646 ms per packet) with standard deviation of 0.053817 ms qSpeedTest(send=0 , recv=16 ) in 0.057945000 sec for 17257.74 packets/sec ( 0.057945 ms per packet) with standard deviation of 0.056490 ms qSpeedTest(send=0 , recv=32 ) in 0.065491000 sec for 15269.27 packets/sec ( 0.065491 ms per packet) with standard deviation of 0.052040 ms qSpeedTest(send=0 , recv=64 ) in 0.069541000 sec for 14380.01 packets/sec ( 0.069541 ms per packet) with standard deviation of 0.057329 ms qSpeedTest(send=0 , recv=128) in 0.065865000 sec for 15182.57 packets/sec ( 0.065865 ms per packet) with standard deviation of 0.052399 ms qSpeedTest(send=0 , recv=256) in 0.086535000 sec for 11556.02 packets/sec ( 0.086535 ms per packet) with standard deviation of 0.064901 ms qSpeedTest(send=0 , recv=512) in 0.09328 sec for 10720.41 packets/sec ( 0.093280 ms per packet) with standard deviation of 0.062687 ms qSpeedTest(send=0 , recv=1024 ) in 0.120688000 sec for 8285.83 packets/sec ( 0.120688 ms per packet) with standard deviation of 0.077364 ms qSpeedTest(send=4 , recv=0 ) in 0.071374000 sec for 14010.70 packets/sec ( 0.071374 ms per packet) with standard deviation of 0.058664 ms qSpeedTest(send=4 , recv=4 ) in 0.056071000 sec for 17834.53 packets/sec ( 0.056071 ms per packet) with standard deviation of 0.049469 ms qSpeedTest(send=4 , recv=8 ) in 0.063151000 sec for 15835.06 packets/sec ( 0.063151 ms per packet) with standard deviation of 0.043858 ms qSpeedTest(send=4 , recv=16 ) in 0.05960 sec for 16778.52 packets/sec ( 0.059600 ms per packet) with standard deviation of 0.041999 ms qSpeedTest(send=4 , recv=32 ) in 0.067713000 sec for 14768.21 packets/sec ( 0.067713 ms per packet) with standard deviation of 0.044975 ms qSpeedTest(send=4 , recv=64 ) in 0.062116000 sec for 16098.91 packets/sec ( 0.062116 ms per packet) with standard deviation of 0.051030 ms qSpeedTest(send=4 , recv=128) in 0.076669000 sec for 13043.08 packets/sec ( 0.076669 ms per packet) with standard deviation of 0.049543 ms qSpeedTest(send=4 , recv=256) in 0.089484000 sec for 11175.18 packets/sec ( 0.089484 ms per packet) with standard deviation of 0.060211 ms qSpeedTest(send=4 , recv=512) in 0.092912000 sec for 10762.87 packets/sec ( 0.092912 ms per packet) with standard deviation of 0.054948 ms qSpeedTest(send=4 , recv=1024 ) in 0.127601000 sec for 7836.93 packets/sec ( 0.127601 ms per packet) with standard deviation of 0.058131 ms qSpeedTest(send=8 , recv=0 ) in 0.071355000 sec for 14014.43 packets/sec ( 0.071355 ms per packet) with standard deviation of 0.057814 ms qSpeedTest(send=8 , recv=4 ) in 0.060355000 sec for 16568.64 packets/sec ( 0.060355 ms per packet) with standard deviation of 0.043343 ms qSpeedTest(send=8 , recv=8 ) in 0.067887000 sec for 14730.36 packets/sec ( 0.067887 ms per packet) with standard deviation of 0.054229 ms qSpeedTest(send=8 , recv=16 ) in 0.068483000 sec for 14602.16 packets/sec ( 0.068483 ms per packet) with standard deviation of 0.063420 ms qSpeedTest(send=8 , recv=32 ) in 0.062375000 sec for 16032.06 packets/sec ( 0.062375 ms per packet) with standard deviation of 0.062549 ms qSpeedTest(send=8 , recv=64 ) in 0.063213000 sec for 15819.53 packets/sec ( 0.063213 ms per packet) with standard deviation of 0.048372 ms qSpeedTest(send=8 , recv=128) in 0.080731000 sec for 12386.82 packets/sec ( 0.080731 ms per packet) with standard deviation of 0.074979 ms qSpeedTest(send=8 , recv=256) in 0.089141000 sec for 11218.18 packets/sec ( 0.089141 ms per packet) with standard deviation of 0.056186 ms qSpeedTest(send=8 , recv=512) in 0.097054000 sec for 10303.54 packets/sec ( 0.097054 ms per packet) with standard deviation of 0.080488 ms qSpeedTest(send=8 , recv=1024 ) in 0.114285000 sec for 8750.05 packets/sec ( 0.114285 ms per packet) with standard deviation of 0.062551 ms qSpeedTest(send=16
Re: [Lldb-commits] [PATCH] D22914: [WIP] Add concurrent packets support to gdb-remote client
labath updated this revision to Diff 67507.
labath added a comment.
The patch I used to run the tests. Still very much WIP.
https://reviews.llvm.org/D22914
Files:
source/Plugins/Process/gdb-remote/GDBRemoteClientBase.cpp
source/Plugins/Process/gdb-remote/GDBRemoteClientBase.h
source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
source/Plugins/Process/gdb-remote/GDBRemoteCommunication.h
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
unittests/Process/gdb-remote/GDBRemoteClientBaseTest.cpp
Index: unittests/Process/gdb-remote/GDBRemoteClientBaseTest.cpp
===
--- unittests/Process/gdb-remote/GDBRemoteClientBaseTest.cpp
+++ unittests/Process/gdb-remote/GDBRemoteClientBaseTest.cpp
@@ -235,6 +235,7 @@
{
StringExtractorGDBRemote continue_response, async_response, response;
const bool send_async = true;
+const GDBRemoteClientBase::Lock::Kind send_kind = GDBRemoteClientBase::Lock::Exclusive;
ContinueFixture fix;
if (HasFailure())
return;
@@ -247,10 +248,11 @@
fix.WaitForRunEvent();
// Sending without async enabled should fail.
-ASSERT_EQ(PacketResult::ErrorSendFailed, fix.client.SendPacketAndWaitForResponse("qTest1", response, !send_async));
+ASSERT_EQ(PacketResult::ErrorSendFailed,
+ fix.client.SendPacketAndWaitForResponse("qTest1", response, send_kind, !send_async));
std::future async_result = std::async(std::launch::async, [&] {
-return fix.client.SendPacketAndWaitForResponse("qTest2", async_response, send_async);
+return fix.client.SendPacketAndWaitForResponse("qTest2", async_response, send_kind, send_async);
});
// First we'll get interrupted.
@@ -341,6 +343,7 @@
{
StringExtractorGDBRemote continue_response, async_response, response;
const bool send_async = true;
+const GDBRemoteClientBase::Lock::Kind send_kind = GDBRemoteClientBase::Lock::Exclusive;
ContinueFixture fix;
if (HasFailure())
return;
@@ -370,7 +373,7 @@
// Packet stream should remain synchronized.
std::future send_result = std::async(std::launch::async, [&] {
-return fix.client.SendPacketAndWaitForResponse("qTest", async_response, !send_async);
+return fix.client.SendPacketAndWaitForResponse("qTest", async_response, send_kind, !send_async);
});
ASSERT_EQ(PacketResult::Success, fix.server.GetPacket(response));
ASSERT_EQ("qTest", response.GetStringRef());
@@ -426,3 +429,81 @@
ASSERT_TRUE(async_result.get());
ASSERT_EQ(eStateInvalid, continue_state.get());
}
+
+TEST(GDBRemoteClientBaseTest, SendTwoPacketsInterleaved)
+{
+StringExtractorGDBRemote async_response1, async_response2, response1, response2;
+const GDBRemoteClientBase::Lock::Kind send_kind = GDBRemoteClientBase::Lock::Shared;
+ContinueFixture fix;
+if (HasFailure())
+return;
+
+std::future async_result1 = std::async(std::launch::async, [&] {
+return fix.client.SendPacketAndWaitForResponse("qTest1", async_response1, send_kind);
+});
+
+std::future async_result2 = std::async(std::launch::async, [&] {
+return fix.client.SendPacketAndWaitForResponse("qTest2", async_response2, send_kind);
+});
+
+// Make sure we can get both requests before we send out the response. The order in which
+// they come is non-deterministic.
+ASSERT_EQ(PacketResult::Success, fix.server.GetPacket(response1));
+ASSERT_TRUE(response1.GetStringRef() == "qTest1" || response1.GetStringRef() == "qTest2");
+ASSERT_EQ(PacketResult::Success, fix.server.GetPacket(response2));
+ASSERT_TRUE(response2.GetStringRef() == "qTest1" || response2.GetStringRef() == "qTest2");
+ASSERT_NE(response1.GetStringRef(), response2.GetStringRef());
+
+// Send both responses (in the correct order).
+ASSERT_EQ(PacketResult::Success, fix.server.SendPacket(response1.GetStringRef() + "X"));
+ASSERT_EQ(PacketResult::Success, fix.server.SendPacket(response2.GetStringRef() + "X"));
+
+// And make sure they get received.
+ASSERT_EQ(PacketResult::Success, async_result1.get());
+ASSERT_EQ("qTest1X", async_response1.GetStringRef());
+ASSERT_EQ(PacketResult::Success, async_result2.get());
+ASSERT_EQ("qTest2X", async_response2.GetStringRef());
+}
+
+TEST(GDBRemoteClientBaseTest, SendManyPacketsStress)
+{
+StringExtractorGDBRemote async_response1, async_response2, response1, response2;
+const GDBRemoteClientBase::Lock::Kind send_kind = GDBRemoteClientBase::Lock::Shared;
+ContinueFixture fix;
+if (HasFailure())
+return;
+
+// Fire up the senders.
+std::vector packet_threads;
+for (unsigned i = 0; i < 4; ++i)
+{
+packet_threads.emplace_back([i, &fix] {
+std::ostringstream packet;
+
[Lldb-commits] [lldb] r278222 - Make sure files include what they use (part 1/N)
Author: labath
Date: Wed Aug 10 08:30:20 2016
New Revision: 278222
URL: http://llvm.org/viewvc/llvm-project?rev=278222&view=rev
Log:
Make sure files include what they use (part 1/N)
preparation for the big clang-format.
Modified:
lldb/trunk/include/lldb/Core/Flags.h
lldb/trunk/include/lldb/Host/MonitoringProcessLauncher.h
lldb/trunk/include/lldb/Utility/Iterable.h
lldb/trunk/source/Plugins/Process/Utility/ARMDefines.h
lldb/trunk/source/Plugins/Process/Utility/RegisterContext_mips.h
lldb/trunk/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm.cpp
lldb/trunk/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm.h
lldb/trunk/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp
lldb/trunk/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.h
lldb/trunk/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_mips64.cpp
lldb/trunk/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_mips64.h
Modified: lldb/trunk/include/lldb/Core/Flags.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/Flags.h?rev=278222&r1=278221&r2=278222&view=diff
==
--- lldb/trunk/include/lldb/Core/Flags.h (original)
+++ lldb/trunk/include/lldb/Core/Flags.h Wed Aug 10 08:30:20 2016
@@ -9,10 +9,9 @@
#ifndef liblldb_Flags_h_
#define liblldb_Flags_h_
-#if defined(__cplusplus)
-
-#include
+#include
+#include
namespace lldb_private {
@@ -248,5 +247,4 @@ protected:
} // namespace lldb_private
-#endif // #if defined(__cplusplus)
#endif // liblldb_Flags_h_
Modified: lldb/trunk/include/lldb/Host/MonitoringProcessLauncher.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Host/MonitoringProcessLauncher.h?rev=278222&r1=278221&r2=278222&view=diff
==
--- lldb/trunk/include/lldb/Host/MonitoringProcessLauncher.h (original)
+++ lldb/trunk/include/lldb/Host/MonitoringProcessLauncher.h Wed Aug 10
08:30:20 2016
@@ -12,6 +12,7 @@
// C Includes
// C++ Includes
+#include
// Other libraries and framework includes
// Project includes
#include "lldb/Host/ProcessLauncher.h"
Modified: lldb/trunk/include/lldb/Utility/Iterable.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Utility/Iterable.h?rev=278222&r1=278221&r2=278222&view=diff
==
--- lldb/trunk/include/lldb/Utility/Iterable.h (original)
+++ lldb/trunk/include/lldb/Utility/Iterable.h Wed Aug 10 08:30:20 2016
@@ -230,7 +230,9 @@ public:
private:
MutexType *m_mutex = nullptr;
-DISALLOW_COPY_AND_ASSIGN(LockingAdaptedIterable);
+LockingAdaptedIterable(const LockingAdaptedIterable &) = delete;
+LockingAdaptedIterable &
+operator=(const LockingAdaptedIterable &) = delete;
};
} // namespace lldb_private
Modified: lldb/trunk/source/Plugins/Process/Utility/ARMDefines.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/Utility/ARMDefines.h?rev=278222&r1=278221&r2=278222&view=diff
==
--- lldb/trunk/source/Plugins/Process/Utility/ARMDefines.h (original)
+++ lldb/trunk/source/Plugins/Process/Utility/ARMDefines.h Wed Aug 10 08:30:20
2016
@@ -10,6 +10,9 @@
#ifndef lldb_ARMDefines_h_
#define lldb_ARMDefines_h_
+#include
+#include
+
// Common definitions for the ARM/Thumb Instruction Set Architecture.
namespace lldb_private {
Modified: lldb/trunk/source/Plugins/Process/Utility/RegisterContext_mips.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/Utility/RegisterContext_mips.h?rev=278222&r1=278221&r2=278222&view=diff
==
--- lldb/trunk/source/Plugins/Process/Utility/RegisterContext_mips.h (original)
+++ lldb/trunk/source/Plugins/Process/Utility/RegisterContext_mips.h Wed Aug 10
08:30:20 2016
@@ -10,6 +10,9 @@
#ifndef liblldb_RegisterContext_mips64_H_
#define liblldb_RegisterContext_mips64_H_
+#include
+#include
+
// eh_frame and DWARF Register numbers (eRegisterKindEHFrame &
eRegisterKindDWARF)
enum
Modified:
lldb/trunk/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm.cpp?rev=278222&r1=278221&r2=278222&view=diff
==
--- lldb/trunk/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm.cpp
(original)
+++ lldb/trunk/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm.cpp
Wed Aug 10 08:30:20 2016
@@ -7,10 +7,10 @@
//
//===--===//
-#include "lldb/Core/DataExtractor.h"
+#include "Re
Re: [Lldb-commits] [PATCH] D23290: Added enforce-interactivity setting
clayborg added a comment. Can you explain the scenarios where you are going to use LLDB with pipes? https://reviews.llvm.org/D23290 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D22914: [WIP] Add concurrent packets support to gdb-remote client
clayborg accepted this revision. clayborg added a comment. This revision is now accepted and ready to land. OK. I can't complain if it doesn't affect performance and could allow multiple packets to be in flight with threading, though I think solving this issue with threading is a bit of a hack, but it should work. Thanks for running the perf tests. https://reviews.llvm.org/D22914 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D23290: Added enforce-interactivity setting
clayborg added a comment. In https://reviews.llvm.org/D23290#511433, @joshimbriani wrote: > In https://reviews.llvm.org/D23290#511275, @clayborg wrote: > > > Can you explain the scenarios where you are going to use LLDB with pipes? > > > Sure! Essentially we are duplicating some of the functionality of the command > line, specifically when commands need confirmation (like process handle or > breakpoint delete). We are interacting with LLDB to confirm these commands > via pipes. And since pipes aren't inherently interactive, we need a way to > override the interactivity check so that LLDB will give us the output we > want, regardless of whether we are using pipes or not. I think we all got that part. The question is why are you interacting via text input/output and not using the C++ API? https://reviews.llvm.org/D23290 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r278253 - Remove a circular include dependency.
Author: zturner Date: Wed Aug 10 12:59:03 2016 New Revision: 278253 URL: http://llvm.org/viewvc/llvm-project?rev=278253&view=rev Log: Remove a circular include dependency. lldb-private-interfaces.h included lldb-private.h, and lldb-private.h included lldb-private-interfaces.h. Modified: lldb/trunk/include/lldb/lldb-private-interfaces.h Modified: lldb/trunk/include/lldb/lldb-private-interfaces.h URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/lldb-private-interfaces.h?rev=278253&r1=278252&r2=278253&view=diff == --- lldb/trunk/include/lldb/lldb-private-interfaces.h (original) +++ lldb/trunk/include/lldb/lldb-private-interfaces.h Wed Aug 10 12:59:03 2016 @@ -12,7 +12,9 @@ #if defined(__cplusplus) -#include "lldb/lldb-private.h" +#include "lldb/lldb-enumerations.h" +#include "lldb/lldb-forward.h" +#include "lldb/lldb-types.h" #include ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r277585 - Fix the BUILD_SHARED_LIBS=ON build, was getting the following error while linking liblldb.so:
Author: ismail Date: Wed Aug 3 05:46:42 2016 New Revision: 277585 URL: http://llvm.org/viewvc/llvm-project?rev=277585&view=rev Log: Fix the BUILD_SHARED_LIBS=ON build, was getting the following error while linking liblldb.so: ../include/llvm/Target/TargetOptions.h:104: error: undefined reference to 'llvm::TargetRecip::TargetRecip()' Modified: lldb/trunk/cmake/LLDBDependencies.cmake Modified: lldb/trunk/cmake/LLDBDependencies.cmake URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/cmake/LLDBDependencies.cmake?rev=277585&r1=277584&r2=277585&view=diff == --- lldb/trunk/cmake/LLDBDependencies.cmake (original) +++ lldb/trunk/cmake/LLDBDependencies.cmake Wed Aug 3 05:46:42 2016 @@ -202,6 +202,7 @@ set(LLVM_LINK_COMPONENTS option support coverage + target ) if ( NOT LLDB_DISABLE_PYTHON ) ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D23290: Added enforce-interactivity setting
joshimbriani added a comment. In https://reviews.llvm.org/D23290#511446, @clayborg wrote: > I think we all got that part. The question is why are you interacting via > text input/output and not using the C++ API? Well we are using the C++ API to initiate the command but the command waits for input from stdin until it is confirmed and since we can't use stdin we're using pipes as the input handler to pass in the input we need to confirm the command and get back the result from the C++ API. https://reviews.llvm.org/D23290 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D23290: Added enforce-interactivity setting
joshimbriani added a comment. In https://reviews.llvm.org/D23290#511275, @clayborg wrote: > Can you explain the scenarios where you are going to use LLDB with pipes? Sure! Essentially we are duplicating some of the functionality of the command line, specifically when commands need confirmation (like process handle or breakpoint delete). We are interacting with LLDB to confirm these commands via pipes. And since pipes aren't inherently interactive, we need a way to override the interactivity check so that LLDB will give us the output we want, regardless of whether we are using pipes or not. https://reviews.llvm.org/D23290 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D23290: Added enforce-interactivity setting
clayborg added a comment.
Is this something the user is typing in your IDE that you are forwarding to
LLDB via pipes? Again, why are you using the command and not the API. There are
API for everything you can do and no IDE should be doing code like:
void MyDebugger::ClearAllBreakpoints()
{
m_debugger.HandleCommand("breakpoint delete");
}
Can you explain your use case here? If this is something the user is typing,
then user PTY instead of pipes and all will be well. I know many functions in
the lldb-mi are incorrectly implemented and they actually create and send LLDB
commands using text and we need to fix this, so hopefully you aren't copying
that code as a basis???
https://reviews.llvm.org/D23290
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r278286 - Fix the lookup of dictionary values by name to not do a linear search.
Author: gclayton
Date: Wed Aug 10 15:37:45 2016
New Revision: 278286
URL: http://llvm.org/viewvc/llvm-project?rev=278286&view=rev
Log:
Fix the lookup of dictionary values by name to not do a linear search.
Modified:
lldb/trunk/include/lldb/Core/StructuredData.h
Modified: lldb/trunk/include/lldb/Core/StructuredData.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/StructuredData.h?rev=278286&r1=278285&r2=278286&view=diff
==
--- lldb/trunk/include/lldb/Core/StructuredData.h (original)
+++ lldb/trunk/include/lldb/Core/StructuredData.h Wed Aug 10 15:37:45 2016
@@ -542,14 +542,9 @@ public:
if (!key.empty())
{
ConstString key_cs(key);
-for (collection::const_iterator iter = m_dict.begin(); iter !=
m_dict.end(); ++iter)
-{
-if (key_cs == iter->first)
-{
-value_sp = iter->second;
-break;
-}
-}
+collection::const_iterator iter = m_dict.find(key_cs);
+if (iter != m_dict.end())
+value_sp = iter->second;
}
return value_sp;
}
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r278289 - xfailed TestObjCNewSyntax.py on macOS for gmodules
Author: tfiala
Date: Wed Aug 10 16:07:48 2016
New Revision: 278289
URL: http://llvm.org/viewvc/llvm-project?rev=278289&view=rev
Log:
xfailed TestObjCNewSyntax.py on macOS for gmodules
Tracked by:
rdar://27792848
Modified:
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/objc-new-syntax/TestObjCNewSyntax.py
Modified:
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/objc-new-syntax/TestObjCNewSyntax.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/objc/objc-new-syntax/TestObjCNewSyntax.py?rev=278289&r1=278288&r2=278289&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/objc-new-syntax/TestObjCNewSyntax.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/objc-new-syntax/TestObjCNewSyntax.py
Wed Aug 10 16:07:48 2016
@@ -27,6 +27,7 @@ class ObjCNewSyntaxTestCase(TestBase):
@skipUnlessDarwin
@expectedFailureAll(oslist=['macosx'], compiler='clang',
compiler_version=['<', '7.0.0'])
+@expectedFailureAll(oslist=['macosx'], debug_info=['gmodules'],
bugnumber='rdar://27792848')
@unittest2.skipIf(platform.system() != "Darwin" or StrictVersion('12.0.0')
> platform.release(), "Only supported on Darwin 12.0.0+")
def test_expr(self):
self.build()
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r278299 - Centralize all select() calls into one place so that we can take advantage of system specific optimizations to deal with more file descriptors than FD_SETSIZE on some s
Author: gclayton
Date: Wed Aug 10 17:43:48 2016
New Revision: 278299
URL: http://llvm.org/viewvc/llvm-project?rev=278299&view=rev
Log:
Centralize all select() calls into one place so that we can take advantage of
system specific optimizations to deal with more file descriptors than
FD_SETSIZE on some systems.
https://reviews.llvm.org/D22950
Added:
lldb/trunk/include/lldb/Utility/SelectHelper.h
lldb/trunk/source/Utility/SelectHelper.cpp
Modified:
lldb/trunk/lldb.xcodeproj/project.pbxproj
lldb/trunk/source/Host/common/Editline.cpp
lldb/trunk/source/Host/posix/ConnectionFileDescriptorPosix.cpp
lldb/trunk/source/Host/posix/PipePosix.cpp
lldb/trunk/source/Target/Process.cpp
lldb/trunk/source/Utility/CMakeLists.txt
Added: lldb/trunk/include/lldb/Utility/SelectHelper.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Utility/SelectHelper.h?rev=278299&view=auto
==
--- lldb/trunk/include/lldb/Utility/SelectHelper.h (added)
+++ lldb/trunk/include/lldb/Utility/SelectHelper.h Wed Aug 10 17:43:48 2016
@@ -0,0 +1,90 @@
+//===-- SelectHelper.h --*- C++
-*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef liblldb_SelectHelper_h_
+#define liblldb_SelectHelper_h_
+
+// C Includes
+// C++ Includes
+#include
+
+// Other libraries and framework includes
+#include "llvm/ADT/DenseMap.h"
+#include "llvm/ADT/Optional.h"
+
+// Project includes
+#include "lldb/lldb-forward.h"
+
+class SelectHelper
+{
+public:
+
+// Defaults to infinite wait for select unless you call SetTimeout()
+SelectHelper();
+
+// Call SetTimeout() before calling SelectHelper::Select() to set the
+// timeout based on the current time + the timeout. This allows multiple
+// calls to SelectHelper::Select() without having to worry about the
+// absolute timeout as this class manages to set the relative timeout
+// correctly.
+void SetTimeout(const std::chrono::microseconds &timeout);
+
+// Call the FDSet*() functions before calling SelectHelper::Select() to
+// set the file descriptors that we will watch for when calling
+// select. This will cause FD_SET() to be called prior to calling select
+// using the "fd" provided.
+void FDSetRead(int fd);
+void FDSetWrite(int fd);
+void FDSetError(int fd);
+
+// Call the FDIsSet*() functions after calling SelectHelper::Select()
+// to check which file descriptors are ready for read/write/error. This
+// will contain the result of FD_ISSET after calling select for a given
+// file descriptor.
+bool FDIsSetRead(int fd) const;
+bool FDIsSetWrite(int fd) const;
+bool FDIsSetError(int fd) const;
+
+// Call the system's select() to wait for descriptors using
+// timeout provided in a call the SelectHelper::SetTimeout(),
+// or infinite wait if no timeout was set.
+lldb_private::Error Select();
+protected:
+struct FDInfo
+{
+FDInfo() :
+read_set(false),
+write_set(false),
+error_set(false),
+read_is_set(false),
+write_is_set(false),
+error_is_set(false)
+{
+}
+
+void
+PrepareForSelect()
+{
+read_is_set = false;
+write_is_set = false;
+error_is_set = false;
+}
+
+bool read_set : 1,
+ write_set: 1,
+ error_set: 1,
+ read_is_set : 1,
+ write_is_set : 1,
+ error_is_set : 1;
+};
+llvm::DenseMap m_fd_map;
+llvm::Optional m_end_time;
+};
+
+#endif // liblldb_SelectHelper_h_
Modified: lldb/trunk/lldb.xcodeproj/project.pbxproj
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/lldb.xcodeproj/project.pbxproj?rev=278299&r1=278298&r2=278299&view=diff
==
--- lldb/trunk/lldb.xcodeproj/project.pbxproj (original)
+++ lldb/trunk/lldb.xcodeproj/project.pbxproj Wed Aug 10 17:43:48 2016
@@ -579,6 +579,7 @@
2697A54D133A6305004E4240 /* PlatformDarwin.cpp in Sources */ =
{isa = PBXBuildFile; fileRef = 2697A54B133A6305004E4240 /* PlatformDarwin.cpp
*/; };
2698699B15E6CBD0002415FF /* OperatingSystemPython.cpp in
Sources */ = {isa = PBXBuildFile; fileRef = 2698699815E6CBD0002415FF /*
OperatingSystemPython.cpp */; };
269DDD4A1B8FD1C300D0DBD8 /* DWARFASTParserClang.cpp in Sources
*/ = {isa = PBXBuildFile; fileRef = 269DDD481B8FD1C300D0DBD8 /*
DWARFASTParserClang.cpp */; };
+ 26A375811D59462700D6CBDB /* SelectHelper.cpp in Sources */ =
{isa = PBXBui
Re: [Lldb-commits] [PATCH] D22950: Centralize all calls to select() into a single class so we always call select properly
clayborg accepted this revision. clayborg added a reviewer: clayborg. clayborg added a comment. This revision is now accepted and ready to land. This was committed with 278299. We can iterate on this as needed. https://reviews.llvm.org/D22950 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r278302 - Make pascal debugging work again.
Author: gclayton
Date: Wed Aug 10 17:55:26 2016
New Revision: 278302
URL: http://llvm.org/viewvc/llvm-project?rev=278302&view=rev
Log:
Make pascal debugging work again.
Modified:
lldb/trunk/source/Symbol/ClangASTContext.cpp
Modified: lldb/trunk/source/Symbol/ClangASTContext.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Symbol/ClangASTContext.cpp?rev=278302&r1=278301&r2=278302&view=diff
==
--- lldb/trunk/source/Symbol/ClangASTContext.cpp (original)
+++ lldb/trunk/source/Symbol/ClangASTContext.cpp Wed Aug 10 17:55:26 2016
@@ -108,9 +108,10 @@ namespace
static inline bool ClangASTContextSupportsLanguage (lldb::LanguageType
language)
{
return language == eLanguageTypeUnknown || // Clang is the default
type system
- Language::LanguageIsC (language) ||
- Language::LanguageIsCPlusPlus (language) ||
- Language::LanguageIsObjC (language) ||
+ Language::LanguageIsC(language) ||
+ Language::LanguageIsCPlusPlus(language) ||
+ Language::LanguageIsObjC(language) ||
+ Language::LanguageIsPascal(language) ||
// Use Clang for Rust until there is a proper language plugin
for it
language == eLanguageTypeRust ||
language == eLanguageTypeExtRenderScript;
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r278304 - Fix a problem where if a uint64_t value is placed into a python dictionary and sent up to LLDB and converted to StructuredData, it would not be able to parse the full 6
Author: gclayton
Date: Wed Aug 10 18:25:57 2016
New Revision: 278304
URL: http://llvm.org/viewvc/llvm-project?rev=278304&view=rev
Log:
Fix a problem where if a uint64_t value is placed into a python dictionary and
sent up to LLDB and converted to StructuredData, it would not be able to parse
the full 64 bit value. A number like 0xf000L could be placed into a
dictionary, and sent to LLDB and it would end up being 0x since
it would overflow a int64_t. We leave the old code there, but if it overflows,
we treat the number like a uint64_t and get it to decode correctly. Added a
gtest to cover this so we don't regress. I verified the gtest failed prior to
the fix, and it succeeds after it.
Modified:
lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp
lldb/trunk/unittests/ScriptInterpreter/Python/PythonDataObjectsTests.cpp
Modified:
lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp?rev=278304&r1=278303&r2=278304&view=diff
==
--- lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp
(original)
+++ lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp
Wed Aug 10 18:25:57 2016
@@ -624,7 +624,18 @@ PythonInteger::GetInteger() const
{
assert(PyLong_Check(m_py_obj) && "PythonInteger::GetInteger has a
PyObject that isn't a PyLong");
-return PyLong_AsLongLong(m_py_obj);
+int overflow = 0;
+int64_t result = PyLong_AsLongLongAndOverflow(m_py_obj, &overflow);
+if (overflow != 0)
+{
+// We got an integer that overflows, like 18446744072853913392L
+// we can't use PyLong_AsLongLong() as it will return
+// 0x. If we use the unsigned long long
+// it will work as expected.
+const uint64_t uval = PyLong_AsUnsignedLongLong(m_py_obj);
+result = *((int64_t *)&uval);
+}
+return result;
}
return UINT64_MAX;
}
Modified:
lldb/trunk/unittests/ScriptInterpreter/Python/PythonDataObjectsTests.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/unittests/ScriptInterpreter/Python/PythonDataObjectsTests.cpp?rev=278304&r1=278303&r2=278304&view=diff
==
--- lldb/trunk/unittests/ScriptInterpreter/Python/PythonDataObjectsTests.cpp
(original)
+++ lldb/trunk/unittests/ScriptInterpreter/Python/PythonDataObjectsTests.cpp
Wed Aug 10 18:25:57 2016
@@ -595,3 +595,27 @@ TEST_F(PythonDataObjectsTest, TestObject
EXPECT_TRUE(numerator_attr.IsAllocated());
EXPECT_EQ(42, numerator_attr.GetInteger());
}
+
+TEST_F(PythonDataObjectsTest, TestExtractingUInt64ThroughStructuredData)
+{
+// Make up a custom dictionary with "sys" pointing to the `sys` module.
+const char *key_name = "addr";
+const uint64_t value = 0xf000ull;
+PythonDictionary python_dict(PyInitialValue::Empty);
+PythonInteger python_ull_value(PyRefType::Owned,
PyLong_FromUnsignedLongLong(value));
+python_dict.SetItemForKey(PythonString(key_name), python_ull_value);
+StructuredData::ObjectSP structured_data_sp =
python_dict.CreateStructuredObject();
+EXPECT_TRUE((bool)structured_data_sp);
+if (structured_data_sp)
+{
+StructuredData::Dictionary *structured_dict_ptr =
structured_data_sp->GetAsDictionary();
+EXPECT_TRUE(structured_dict_ptr != nullptr);
+if (structured_dict_ptr)
+{
+StructuredData::ObjectSP structured_addr_value_sp =
structured_dict_ptr->GetValueForKey(key_name);
+EXPECT_TRUE((bool)structured_addr_value_sp);
+const uint64_t extracted_value =
structured_addr_value_sp->GetIntegerValue(123);
+EXPECT_TRUE(extracted_value == value);
+}
+}
+}
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [lldb] r278304 - Fix a problem where if a uint64_t value is placed into a python dictionary and sent up to LLDB and converted to StructuredData, it would not be able to parse the fu
Couple of random style comments below. You don't have to fix these, just
something to think about in the future.
On Wed, Aug 10, 2016 at 4:33 PM Greg Clayton via lldb-commits <
lldb-commits@lists.llvm.org> wrote:
> +
> +TEST_F(PythonDataObjectsTest, TestExtractingUInt64ThroughStructuredData)
> +{
> +// Make up a custom dictionary with "sys" pointing to the `sys`
> module.
> +const char *key_name = "addr";
> +const uint64_t value = 0xf000ull;
> +PythonDictionary python_dict(PyInitialValue::Empty);
> +PythonInteger python_ull_value(PyRefType::Owned,
> PyLong_FromUnsignedLongLong(value));
> +python_dict.SetItemForKey(PythonString(key_name), python_ull_value);
> +StructuredData::ObjectSP structured_data_sp =
> python_dict.CreateStructuredObject();
> +EXPECT_TRUE((bool)structured_data_sp);
>
EXPECT_NE(nullptr, structured_data_sp);
would be preferable here. If EXPECT_TRUE fails, you will just an error
message saying it was false when it should have been true. If EXPECT_NE
fails, you will get an error message telling you the expected value and the
actual value. This is most useful when the actual and expected values are
integers or strings, but the same concept applies anywhere. Using the
proper EXPECT macro gives you a better error message. Same goes in a few
other places below.
> +if (structured_data_sp)
> +{
> +StructuredData::Dictionary *structured_dict_ptr =
> structured_data_sp->GetAsDictionary();
> +EXPECT_TRUE(structured_dict_ptr != nullptr);
> +if (structured_dict_ptr)
> +{
> +StructuredData::ObjectSP structured_addr_value_sp =
> structured_dict_ptr->GetValueForKey(key_name);
> +EXPECT_TRUE((bool)structured_addr_value_sp);
> +const uint64_t extracted_value =
> structured_addr_value_sp->GetIntegerValue(123);
> +EXPECT_TRUE(extracted_value == value);
>
Here's an example of where EXPECT_EQ(value, extracted_value) would be
really helpful. Without it, you'd need to debug the test to to see what
the actual value is. With it, it will print both values so you can often
easily determine the cause of the failure without any additional effort.
> +}
> +}
> +}
>
As a general rule of thumb, we should probably avoid conditionals in unit
tests unless they're really necessary. It's easy to end up in cases where
your test ends up not testing something because it's behind a conditional.
EXPECT_NE(nullptr, foo_sp) is probably fine, then just assume it's non null.
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r278305 - dlopen & dlclose can't throw C++ or ObjC exceptions, so don't do the extra work of
Author: jingham Date: Wed Aug 10 19:15:28 2016 New Revision: 278305 URL: http://llvm.org/viewvc/llvm-project?rev=278305&view=rev Log: dlopen & dlclose can't throw C++ or ObjC exceptions, so don't do the extra work of setting & deleting the breakpoints to watch for this. Modified: lldb/trunk/source/Plugins/Platform/POSIX/PlatformPOSIX.cpp Modified: lldb/trunk/source/Plugins/Platform/POSIX/PlatformPOSIX.cpp URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Platform/POSIX/PlatformPOSIX.cpp?rev=278305&r1=278304&r2=278305&view=diff == --- lldb/trunk/source/Plugins/Platform/POSIX/PlatformPOSIX.cpp (original) +++ lldb/trunk/source/Plugins/Platform/POSIX/PlatformPOSIX.cpp Wed Aug 10 19:15:28 2016 @@ -882,6 +882,7 @@ PlatformPOSIX::EvaluateLibdlExpression(l expr_options.SetIgnoreBreakpoints(true); expr_options.SetExecutionPolicy(eExecutionPolicyAlways); expr_options.SetLanguage(eLanguageTypeC_plus_plus); +expr_options.SetTrapExceptions(false); // dlopen can't throw exceptions, so don't do the work to trap them. expr_options.SetTimeoutUsec(200); // 2 seconds Error expr_error; ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
