[Lldb-commits] [PATCH] D32585: Implementation of remote packets for Trace data.

2017-05-23 Thread Ravitheja Addepally via Phabricator via lldb-commits
ravitheja added inline comments.



Comment at: 
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp:3293
+  if (custom_params_sp) {
+if (custom_params_sp->GetType() != 
StructuredData::Type::eTypeDictionary) {
+  error.SetErrorString("Invalid Configuration obtained");

clayborg wrote:
> Might be simpler to just do:
> 
> ```
> if (!custom_params_sp->GetAsDictionary())
> ```
> 
Yes that could be dangerous to do, coz it returns a pointer to the Dictionary , 
while setTraceParams needs a shared_pointer and I would have a to create a 
shared_pointer which is not really being shared.



Comment at: 
unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp:400
+
+  HandlePacket(server, "jTraceStart:{\"buffersize\" : 8192,\"jparams\" : 
{\"psb\" : 1,\"tracetech\" : \"intel-pt\"},\"metabuffersize\" : 
8192,\"threadid\" : 35,\"type\" : 1}", "1");
+  ASSERT_EQ(result.get(),1);

clayborg wrote:
> Use the R"( so you don't have to desensitize the double quotes and so you can 
> format nicely:
> 
> ```
> const char *json = R"(
> jTraceStart: {
>   "buffersize" : 8192,
>   "metabuffersize" : 8192,
>   "threadid" : 35,
>   "type" : 1,
>   "jparams" : {
> "psb" : 1,
> "tracetech" : "intel-pt"
>   }
> })";
> HandlePacket(server, json, "1");
> ```
That won't match coz the new lines and extra spaces cause mismatch in the 
packet string produced. Also unfortunately the Dump Function in the 
StrucuturedData::Dictionary adds spaces around the colons between "Key" : Value 
, so removing all whitespaces won't work. Now I can still add some functions to 
format the expexted string according to the one printed by Dump function, but 
that would be more code.


https://reviews.llvm.org/D32585



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D32585: Implementation of remote packets for Trace data.

2017-05-23 Thread Ravitheja Addepally via Phabricator via lldb-commits
ravitheja updated this revision to Diff 99870.
ravitheja added a comment.

Updates from last review.


https://reviews.llvm.org/D32585

Files:
  docs/lldb-gdb-remote.txt
  include/lldb/API/SBTrace.h
  include/lldb/Core/TraceOptions.h
  include/lldb/Host/common/NativeProcessProtocol.h
  include/lldb/Target/Process.h
  include/lldb/Utility/StringExtractor.h
  source/API/SBProcess.cpp
  source/API/SBTrace.cpp
  source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
  source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h
  source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
  source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h
  source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
  source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
  source/Utility/StringExtractor.cpp
  source/Utility/StringExtractorGDBRemote.cpp
  source/Utility/StringExtractorGDBRemote.h
  unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp

Index: unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp
===
--- unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp
+++ unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp
@@ -14,6 +14,7 @@
 #include "lldb/Core/ModuleSpec.h"
 #include "lldb/Core/StructuredData.h"
 #include "lldb/Target/MemoryRegionInfo.h"
+#include "lldb/Core/TraceOptions.h"
 #include "lldb/Utility/DataBuffer.h"
 
 #include "llvm/ADT/ArrayRef.h"
@@ -370,3 +371,202 @@
   HandlePacket(server, "qMemoryRegionInfo:4000", "start:4000;size:;");
   EXPECT_FALSE(result.get().Success());
 }
+
+TEST_F(GDBRemoteCommunicationClientTest, SendStartTracePacket) {
+  TestClient client;
+  MockServer server;
+  Connect(client, server);
+  if (HasFailure())
+return;
+
+  TraceOptions options;
+  Status error;
+
+  options.setType(lldb::TraceType::eTraceTypeProcessorTrace);
+  options.setMetaDataBufferSize(8192);
+  options.setTraceBufferSize(8192);
+  options.setThreadID(0x23);
+
+  StructuredData::DictionarySP custom_params = std::make_shared ();
+  custom_params->AddStringItem("tracetech","intel-pt");
+  custom_params->AddIntegerItem("psb",0x01);
+
+  options.setTraceParams(custom_params);
+
+  std::future result = std::async(std::launch::async, [&] {
+return client.SendStartTracePacket(options, error);
+  });
+
+  HandlePacket(server, "jTraceStart:{\"buffersize\" : 8192,\"metabuffersize\" : 8192,\"params\" : {\"psb\" : 1,\"tracetech\" : \"intel-pt\"},\"threadid\" : 35,\"type\" : 1}", "1");
+  ASSERT_TRUE(error.Success());
+  ASSERT_EQ(result.get(),1);
+
+  error.Clear();
+  result = std::async(std::launch::async, [&] {
+return client.SendStartTracePacket(options, error);
+  });
+
+  HandlePacket(server, "jTraceStart:{\"buffersize\" : 8192,\"metabuffersize\" : 8192,\"params\" : {\"psb\" : 1,\"tracetech\" : \"intel-pt\"},\"threadid\" : 35,\"type\" : 1}", "E23");
+  ASSERT_EQ(result.get(), LLDB_INVALID_UID);
+  ASSERT_FALSE(error.Success());
+}
+
+TEST_F(GDBRemoteCommunicationClientTest, SendStopTracePacket) {
+  TestClient client;
+  MockServer server;
+  Connect(client, server);
+  if (HasFailure())
+return;
+
+  lldb::tid_t thread_id = 0x23;
+  lldb::user_id_t trace_id = 3;
+
+  std::future result = std::async(std::launch::async, [&] {
+return client.SendStopTracePacket(trace_id, thread_id);
+  });
+
+  HandlePacket(server, "jTraceStop:{\"threadid\" : 35,\"traceid\" : 3}", "OK");
+  ASSERT_TRUE(result.get().Success());
+
+  result = std::async(std::launch::async, [&] {
+return client.SendStopTracePacket(trace_id, thread_id);
+  });
+
+  HandlePacket(server, "jTraceStop:{\"threadid\" : 35,\"traceid\" : 3}", "E23");
+  ASSERT_FALSE(result.get().Success());
+}
+
+TEST_F(GDBRemoteCommunicationClientTest, SendGetDataPacket) {
+  TestClient client;
+  MockServer server;
+  Connect(client, server);
+  if (HasFailure())
+return;
+
+  lldb::tid_t thread_id = 0x23;
+  lldb::user_id_t trace_id = 3;
+
+  uint8_t buf[32] = {};
+  llvm::MutableArrayRef buffer (buf, 32);
+  size_t offset = 0;
+
+  std::future result = std::async(std::launch::async, [&] {
+return client.SendGetDataPacket(trace_id, thread_id, buffer, offset);
+  });
+
+  StringRef expected("jTraceBufferRead:{\"buffersize\" : 32,\"offset\" : 0,\"threadid\" : 35,\"traceid\" : 3}");
+  HandlePacket(server, expected, "123456");
+  ASSERT_TRUE(result.get().Success());
+  ASSERT_EQ(buffer.size(), 3);
+  ASSERT_EQ(buf[0], 0x12);
+  ASSERT_EQ(buf[1], 0x34);
+  ASSERT_EQ(buf[2], 0x56);
+
+  llvm::MutableArrayRef buffer2 (buf, 32);
+  result = std::async(std::launch::async, [&] {
+return client.SendGetDataPacket(trace_id, thread_id, buffer2, offset);
+  });
+
+  HandlePacket(server, expected, "E23");
+  ASSERT_FALSE(result.get().Success());
+  ASSERT_EQ(buffer2.size(), 0);
+}
+
+TEST_F(GDBRemoteCommunicationClientTest, SendGetMetaDataPacket) {
+  TestClient client;
+  MockServer server;
+  

[Lldb-commits] [PATCH] D33426: Introduce new command: thread backtrace unique

2017-05-23 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

Sounds like an awesome feature.

Could you please add a test for it as well?


https://reviews.llvm.org/D33426



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D32585: Implementation of remote packets for Trace data.

2017-05-23 Thread Pavel Labath via Phabricator via lldb-commits
labath added inline comments.



Comment at: 
unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp:400
+
+  HandlePacket(server, "jTraceStart:{\"buffersize\" : 8192,\"jparams\" : 
{\"psb\" : 1,\"tracetech\" : \"intel-pt\"},\"metabuffersize\" : 
8192,\"threadid\" : 35,\"type\" : 1}", "1");
+  ASSERT_EQ(result.get(),1);

ravitheja wrote:
> clayborg wrote:
> > Use the R"( so you don't have to desensitize the double quotes and so you 
> > can format nicely:
> > 
> > ```
> > const char *json = R"(
> > jTraceStart: {
> >   "buffersize" : 8192,
> >   "metabuffersize" : 8192,
> >   "threadid" : 35,
> >   "type" : 1,
> >   "jparams" : {
> > "psb" : 1,
> > "tracetech" : "intel-pt"
> >   }
> > })";
> > HandlePacket(server, json, "1");
> > ```
> That won't match coz the new lines and extra spaces cause mismatch in the 
> packet string produced. Also unfortunately the Dump Function in the 
> StrucuturedData::Dictionary adds spaces around the colons between "Key" : 
> Value , so removing all whitespaces won't work. Now I can still add some 
> functions to format the expexted string according to the one printed by Dump 
> function, but that would be more code.
I've been wanting to add make these tests smarter now that they are getting 
more use. I'll take a todo item here to add a smarter way to compare json 
fields here. For now you can at least do the R" thing Greg suggests.


https://reviews.llvm.org/D32585



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D32585: Implementation of remote packets for Trace data.

2017-05-23 Thread Ravitheja Addepally via Phabricator via lldb-commits
ravitheja added inline comments.



Comment at: 
unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp:400
+
+  HandlePacket(server, "jTraceStart:{\"buffersize\" : 8192,\"jparams\" : 
{\"psb\" : 1,\"tracetech\" : \"intel-pt\"},\"metabuffersize\" : 
8192,\"threadid\" : 35,\"type\" : 1}", "1");
+  ASSERT_EQ(result.get(),1);

labath wrote:
> ravitheja wrote:
> > clayborg wrote:
> > > Use the R"( so you don't have to desensitize the double quotes and so you 
> > > can format nicely:
> > > 
> > > ```
> > > const char *json = R"(
> > > jTraceStart: {
> > >   "buffersize" : 8192,
> > >   "metabuffersize" : 8192,
> > >   "threadid" : 35,
> > >   "type" : 1,
> > >   "jparams" : {
> > > "psb" : 1,
> > > "tracetech" : "intel-pt"
> > >   }
> > > })";
> > > HandlePacket(server, json, "1");
> > > ```
> > That won't match coz the new lines and extra spaces cause mismatch in the 
> > packet string produced. Also unfortunately the Dump Function in the 
> > StrucuturedData::Dictionary adds spaces around the colons between "Key" : 
> > Value , so removing all whitespaces won't work. Now I can still add some 
> > functions to format the expexted string according to the one printed by 
> > Dump function, but that would be more code.
> I've been wanting to add make these tests smarter now that they are getting 
> more use. I'll take a todo item here to add a smarter way to compare json 
> fields here. For now you can at least do the R" thing Greg suggests.
Yes I can do the R thing but then i can't format it nicely, as Greg suggested.


https://reviews.llvm.org/D32585



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D32585: Implementation of remote packets for Trace data.

2017-05-23 Thread Pavel Labath via Phabricator via lldb-commits
labath added inline comments.



Comment at: 
unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp:400
+
+  HandlePacket(server, "jTraceStart:{\"buffersize\" : 8192,\"jparams\" : 
{\"psb\" : 1,\"tracetech\" : \"intel-pt\"},\"metabuffersize\" : 
8192,\"threadid\" : 35,\"type\" : 1}", "1");
+  ASSERT_EQ(result.get(),1);

ravitheja wrote:
> labath wrote:
> > ravitheja wrote:
> > > clayborg wrote:
> > > > Use the R"( so you don't have to desensitize the double quotes and so 
> > > > you can format nicely:
> > > > 
> > > > ```
> > > > const char *json = R"(
> > > > jTraceStart: {
> > > >   "buffersize" : 8192,
> > > >   "metabuffersize" : 8192,
> > > >   "threadid" : 35,
> > > >   "type" : 1,
> > > >   "jparams" : {
> > > > "psb" : 1,
> > > > "tracetech" : "intel-pt"
> > > >   }
> > > > })";
> > > > HandlePacket(server, json, "1");
> > > > ```
> > > That won't match coz the new lines and extra spaces cause mismatch in the 
> > > packet string produced. Also unfortunately the Dump Function in the 
> > > StrucuturedData::Dictionary adds spaces around the colons between "Key" : 
> > > Value , so removing all whitespaces won't work. Now I can still add some 
> > > functions to format the expexted string according to the one printed by 
> > > Dump function, but that would be more code.
> > I've been wanting to add make these tests smarter now that they are getting 
> > more use. I'll take a todo item here to add a smarter way to compare json 
> > fields here. For now you can at least do the R" thing Greg suggests.
> Yes I can do the R thing but then i can't format it nicely, as Greg suggested.
Yes, but it will still avoid the need for escaping quotes, which is an 
improvement in itself.


https://reviews.llvm.org/D32585



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] r303627 - Add support for new (3.0.11+) swigs

2017-05-23 Thread Pavel Labath via lldb-commits
Author: labath
Date: Tue May 23 05:55:17 2017
New Revision: 303627

URL: http://llvm.org/viewvc/llvm-project?rev=303627&view=rev
Log:
Add support for new (3.0.11+) swigs

Summary:
A change in swig 3.0.9 has caused it to generate modules incompatible
with us using them as __init__.py (bug #769). Swig 3.0.11 adds a setting to help
fix this problem, so use that. Support for older versions of swig remains
unaffected.

Reviewers: zturner

Subscribers: lldb-commits

Differential Revision: https://reviews.llvm.org/D33409

Modified:
lldb/trunk/scripts/lldb.swig

Modified: lldb/trunk/scripts/lldb.swig
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/lldb.swig?rev=303627&r1=303626&r2=303627&view=diff
==
--- lldb/trunk/scripts/lldb.swig (original)
+++ lldb/trunk/scripts/lldb.swig Tue May 23 05:55:17 2017
@@ -31,8 +31,24 @@ o SBLineEntry: Specifies an association
   and a source file location. SBCompileUnit contains SBLineEntry(s)."
 %enddef
 
+/*
+Since version 3.0.9, swig's logic for importing the native module has changed 
in
+a way that is incompatible with our usage of the python module as __init__.py
+(See swig bug #769).  Fortunately, since version 3.0.11, swig provides a way 
for
+us to override the module import logic to suit our needs. This does that.
+
+Older swig versions will simply ignore this setting.
+*/
+%define MODULEIMPORT
+"from . import $module"
+%enddef
+// These versions will not generate working python modules, so error out early.
+#if SWIG_VERSION >= 0x030009 && SWIG_VERSION < 0x030011
+#error Swig versions 3.0.9 and 3.0.10 are incompatible with lldb.
+#endif
+
 // The name of the module to be created.
-%module(docstring=DOCSTRING) lldb
+%module(docstring=DOCSTRING, moduleimport=MODULEIMPORT) lldb
 
 // Parameter types will be used in the autodoc string.
 %feature("autodoc", "1");


___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D33409: Add support for new (3.0.11+) swigs

2017-05-23 Thread Pavel Labath via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL303627: Add support for new (3.0.11+) swigs (authored by 
labath).

Changed prior to commit:
  https://reviews.llvm.org/D33409?vs=99755&id=99878#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D33409

Files:
  lldb/trunk/scripts/lldb.swig


Index: lldb/trunk/scripts/lldb.swig
===
--- lldb/trunk/scripts/lldb.swig
+++ lldb/trunk/scripts/lldb.swig
@@ -31,8 +31,24 @@
   and a source file location. SBCompileUnit contains SBLineEntry(s)."
 %enddef
 
+/*
+Since version 3.0.9, swig's logic for importing the native module has changed 
in
+a way that is incompatible with our usage of the python module as __init__.py
+(See swig bug #769).  Fortunately, since version 3.0.11, swig provides a way 
for
+us to override the module import logic to suit our needs. This does that.
+
+Older swig versions will simply ignore this setting.
+*/
+%define MODULEIMPORT
+"from . import $module"
+%enddef
+// These versions will not generate working python modules, so error out early.
+#if SWIG_VERSION >= 0x030009 && SWIG_VERSION < 0x030011
+#error Swig versions 3.0.9 and 3.0.10 are incompatible with lldb.
+#endif
+
 // The name of the module to be created.
-%module(docstring=DOCSTRING) lldb
+%module(docstring=DOCSTRING, moduleimport=MODULEIMPORT) lldb
 
 // Parameter types will be used in the autodoc string.
 %feature("autodoc", "1");


Index: lldb/trunk/scripts/lldb.swig
===
--- lldb/trunk/scripts/lldb.swig
+++ lldb/trunk/scripts/lldb.swig
@@ -31,8 +31,24 @@
   and a source file location. SBCompileUnit contains SBLineEntry(s)."
 %enddef
 
+/*
+Since version 3.0.9, swig's logic for importing the native module has changed in
+a way that is incompatible with our usage of the python module as __init__.py
+(See swig bug #769).  Fortunately, since version 3.0.11, swig provides a way for
+us to override the module import logic to suit our needs. This does that.
+
+Older swig versions will simply ignore this setting.
+*/
+%define MODULEIMPORT
+"from . import $module"
+%enddef
+// These versions will not generate working python modules, so error out early.
+#if SWIG_VERSION >= 0x030009 && SWIG_VERSION < 0x030011
+#error Swig versions 3.0.9 and 3.0.10 are incompatible with lldb.
+#endif
+
 // The name of the module to be created.
-%module(docstring=DOCSTRING) lldb
+%module(docstring=DOCSTRING, moduleimport=MODULEIMPORT) lldb
 
 // Parameter types will be used in the autodoc string.
 %feature("autodoc", "1");
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


Re: [Lldb-commits] Patch for fixing FDE indexing when scan debug_info section

2017-05-23 Thread Abid, Hafiz via lldb-commits
It looks ok to me. Please put the differences of .eh_frame and
.debug_frame that you described below in code comments too.?

Thanks,
Abid



From: lldb-commits  on behalf of Tatyana 
Krasnukha via lldb-commits 
Sent: Thursday, May 18, 2017 9:37 PM
To: lldb-commits@lists.llvm.org
Subject: [Lldb-commits] Patch for fixing FDE indexing when scan debug_info 
section

Fix FDE indexing while scan debug_info section.

There are some differences between eh_frame and debug_frame formats that are 
not considered by DWARFCallFrameInfo::GetFDEIndex.
An FDE entry contains CIE_pointer in debug_frame in same place as cie_id in 
eh_frame. As described in dwarf 
standard (section 6.4.1),
CIE_pointer is an "offset into the .debug_frame section". So, variable 
cie_offset should be equal cie_id for debug_frame.
FDE entries with zeroth CIE pointer (which is actually placed in cie_id 
variable) shouldn't be ignored also.

I had same issue as described here 
http://lists.llvm.org/pipermail/lldb-dev/2014-October/005520.html , and these 
changes have fixed it for me (with "m_is_eh_frame" set to false, of course).

Tatyana Krasnukha
Software Engineer, Sr. I, Solutions Group, Synopsys Inc.
w +7.812.408.7463 | m +7 981 757-4491 | 
taty...@synopsys.com

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D32585: Implementation of remote packets for Trace data.

2017-05-23 Thread Ravitheja Addepally via Phabricator via lldb-commits
ravitheja updated this revision to Diff 99891.
ravitheja added a comment.

Modifying string literals in Unit tests.


https://reviews.llvm.org/D32585

Files:
  docs/lldb-gdb-remote.txt
  include/lldb/API/SBTrace.h
  include/lldb/Core/TraceOptions.h
  include/lldb/Host/common/NativeProcessProtocol.h
  include/lldb/Target/Process.h
  include/lldb/Utility/StringExtractor.h
  source/API/SBProcess.cpp
  source/API/SBTrace.cpp
  source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
  source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h
  source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
  source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h
  source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
  source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
  source/Utility/StringExtractor.cpp
  source/Utility/StringExtractorGDBRemote.cpp
  source/Utility/StringExtractorGDBRemote.h
  unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp

Index: unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp
===
--- unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp
+++ unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp
@@ -14,6 +14,7 @@
 #include "lldb/Core/ModuleSpec.h"
 #include "lldb/Core/StructuredData.h"
 #include "lldb/Target/MemoryRegionInfo.h"
+#include "lldb/Core/TraceOptions.h"
 #include "lldb/Utility/DataBuffer.h"
 
 #include "llvm/ADT/ArrayRef.h"
@@ -370,3 +371,205 @@
   HandlePacket(server, "qMemoryRegionInfo:4000", "start:4000;size:;");
   EXPECT_FALSE(result.get().Success());
 }
+
+TEST_F(GDBRemoteCommunicationClientTest, SendStartTracePacket) {
+  TestClient client;
+  MockServer server;
+  Connect(client, server);
+  if (HasFailure())
+return;
+
+  TraceOptions options;
+  Status error;
+
+  options.setType(lldb::TraceType::eTraceTypeProcessorTrace);
+  options.setMetaDataBufferSize(8192);
+  options.setTraceBufferSize(8192);
+  options.setThreadID(0x23);
+
+  StructuredData::DictionarySP custom_params = std::make_shared ();
+  custom_params->AddStringItem("tracetech","intel-pt");
+  custom_params->AddIntegerItem("psb",0x01);
+
+  options.setTraceParams(custom_params);
+
+  std::future result = std::async(std::launch::async, [&] {
+return client.SendStartTracePacket(options, error);
+  });
+
+  const char *expected_packet = R"(jTraceStart:{"buffersize" : 8192,"metabuffersize" : 8192,"params" : {"psb" : 1,"tracetech" : "intel-pt"},"threadid" : 35,"type" : 1})";
+  HandlePacket(server, expected_packet, "1");
+  ASSERT_TRUE(error.Success());
+  ASSERT_EQ(result.get(),1);
+
+  error.Clear();
+  result = std::async(std::launch::async, [&] {
+return client.SendStartTracePacket(options, error);
+  });
+
+  HandlePacket(server, expected_packet, "E23");
+  ASSERT_EQ(result.get(), LLDB_INVALID_UID);
+  ASSERT_FALSE(error.Success());
+}
+
+TEST_F(GDBRemoteCommunicationClientTest, SendStopTracePacket) {
+  TestClient client;
+  MockServer server;
+  Connect(client, server);
+  if (HasFailure())
+return;
+
+  lldb::tid_t thread_id = 0x23;
+  lldb::user_id_t trace_id = 3;
+
+  std::future result = std::async(std::launch::async, [&] {
+return client.SendStopTracePacket(trace_id, thread_id);
+  });
+
+  const char *expected_packet = R"(jTraceStop:{"threadid" : 35,"traceid" : 3})";
+  HandlePacket(server, expected_packet, "OK");
+  ASSERT_TRUE(result.get().Success());
+
+  result = std::async(std::launch::async, [&] {
+return client.SendStopTracePacket(trace_id, thread_id);
+  });
+
+  HandlePacket(server, expected_packet, "E23");
+  ASSERT_FALSE(result.get().Success());
+}
+
+TEST_F(GDBRemoteCommunicationClientTest, SendGetDataPacket) {
+  TestClient client;
+  MockServer server;
+  Connect(client, server);
+  if (HasFailure())
+return;
+
+  lldb::tid_t thread_id = 0x23;
+  lldb::user_id_t trace_id = 3;
+
+  uint8_t buf[32] = {};
+  llvm::MutableArrayRef buffer (buf, 32);
+  size_t offset = 0;
+
+  std::future result = std::async(std::launch::async, [&] {
+return client.SendGetDataPacket(trace_id, thread_id, buffer, offset);
+  });
+
+  const char *expected_packet = R"(jTraceBufferRead:{"buffersize" : 32,"offset" : 0,"threadid" : 35,"traceid" : 3})";
+  HandlePacket(server, expected_packet, "123456");
+  ASSERT_TRUE(result.get().Success());
+  ASSERT_EQ(buffer.size(), 3);
+  ASSERT_EQ(buf[0], 0x12);
+  ASSERT_EQ(buf[1], 0x34);
+  ASSERT_EQ(buf[2], 0x56);
+
+  llvm::MutableArrayRef buffer2 (buf, 32);
+  result = std::async(std::launch::async, [&] {
+return client.SendGetDataPacket(trace_id, thread_id, buffer2, offset);
+  });
+
+  HandlePacket(server, expected_packet, "E23");
+  ASSERT_FALSE(result.get().Success());
+  ASSERT_EQ(buffer2.size(), 0);
+}
+
+TEST_F(GDBRemoteCommunicationClientTest, SendGetMetaDataPacket) {
+  TestClient client;
+  MockServer server;
+  Connect(client, server);
+  if (HasFailure())
+ 

[Lldb-commits] [lldb] r303643 - We shouldn't put actual tests in directories that contain

2017-05-23 Thread Jim Ingham via lldb-commits
Author: jingham
Date: Tue May 23 11:11:21 2017
New Revision: 303643

URL: http://llvm.org/viewvc/llvm-project?rev=303643&view=rev
Log:
We shouldn't put actual tests in directories that contain
other test directories.

Added:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/num_threads/

lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/num_threads/Makefile
  - copied, changed from r303642, 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/Makefile

lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/num_threads/TestNumThreads.py
  - copied unchanged from r303642, 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/TestNumThreads.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/num_threads/main.cpp
  - copied unchanged from r303642, 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/main.cpp
Removed:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/Makefile

lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/TestNumThreads.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/main.cpp

Removed: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/Makefile
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/Makefile?rev=303642&view=auto
==
--- lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/Makefile 
(original)
+++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/Makefile 
(removed)
@@ -1,5 +0,0 @@
-LEVEL = ../../make
-
-CXX_SOURCES := main.cpp
-ENABLE_THREADS := YES
-include $(LEVEL)/Makefile.rules

Removed: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/TestNumThreads.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/TestNumThreads.py?rev=303642&view=auto
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/TestNumThreads.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/TestNumThreads.py
 (removed)
@@ -1,61 +0,0 @@
-"""
-Test number of threads.
-"""
-
-from __future__ import print_function
-
-
-import os
-import time
-import lldb
-from lldbsuite.test.lldbtest import *
-import lldbsuite.test.lldbutil as lldbutil
-
-
-class NumberOfThreadsTestCase(TestBase):
-
-mydir = TestBase.compute_mydir(__file__)
-
-def setUp(self):
-# Call super's setUp().
-TestBase.setUp(self)
-# Find the line number to break inside main().
-self.line = line_number('main.cpp', '// Set break point at this line.')
-
-def test(self):
-"""Test number of threads."""
-self.build()
-exe = os.path.join(os.getcwd(), "a.out")
-self.runCmd("file " + exe, CURRENT_EXECUTABLE_SET)
-
-# This should create a breakpoint with 1 location.
-lldbutil.run_break_set_by_file_and_line(
-self, "main.cpp", self.line, num_expected_locations=1)
-
-# The breakpoint list should show 3 locations.
-self.expect(
-"breakpoint list -f",
-"Breakpoint location shown correctly",
-substrs=[
-"1: file = 'main.cpp', line = %d, exact_match = 0, locations = 
1" %
-self.line])
-
-# Run the program.
-self.runCmd("run", RUN_SUCCEEDED)
-
-# Stopped once.
-self.expect("thread list", STOPPED_DUE_TO_BREAKPOINT,
-substrs=["stop reason = breakpoint 1."])
-
-# Get the target process
-target = self.dbg.GetSelectedTarget()
-process = target.GetProcess()
-
-# Get the number of threads
-num_threads = process.GetNumThreads()
-
-# Using std::thread may involve extra threads, so we assert that there 
are
-# at least 4 rather than exactly 4.
-self.assertTrue(
-num_threads >= 4,
-'Number of expected threads and actual threads do not match.')

Removed: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/main.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/main.cpp?rev=303642&view=auto
==
--- lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/main.cpp 
(original)
+++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/main.cpp 
(removed)
@@ -1,50 +0,0 @@
-#include 
-#include 
-#include 
-
-std::mutex mutex;
-std::condition_variable cond;
-
-void *
-thread3(void *input)
-{
-std::unique_lock lock(mutex);
-cond.notify_all(); // Set break point at this line.
-return NULL;
-}
-
-void *
-thread2(void *input)
-{
-std::un

[Lldb-commits] [PATCH] D33426: Introduce new command: thread backtrace unique

2017-05-23 Thread Jim Ingham via Phabricator via lldb-commits
jingham requested changes to this revision.
jingham added a comment.
This revision now requires changes to proceed.

Pavel's right, it would be good to add a test case.  You could modify the test 
case in packages/Python/lldbsuite/test/functionalities/thread/num_threads/ to 
this end.  Note this Test Case used to be sitting mixed with the directories in 
the thread directory, but I just moved it into its own directory - so update 
before doing this.  You could just make a few more thread 3's and break at the 
lock.unlock line.  Then you should have a bunch of threads with the same stack, 
and your 'unique' listing would coalesce them.  If you do this, please add it 
as a separate test (so make a new method 'test_unique' and redo the setup.  
That way the tests will remain independent.

There's a "functionalities/thread/backtrace_all" test that looks tempting to 
modify, but it doesn't actually look that amenable to modification for your 
purposes.  The TestBacktraceAll.py there does show an example of running a 
command-line command, and looking for patterns in the result, which is what 
you'll need to add.




Comment at: source/Commands/CommandObjectThread.cpp:328
+"Use the thread-index \"all\" to see all threads.\n"
+"Use the thread-index \"unique\" to see threads with unique call 
stacks.",
 nullptr,

Maybe "to see threads grouped by unique call stacks"?  As written it sounds 
like you're going to show me the really cool call stacks.


https://reviews.llvm.org/D33426



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D33426: Introduce new command: thread backtrace unique

2017-05-23 Thread Greg Clayton via Phabricator via lldb-commits
clayborg added a comment.

Add a test and fix the minor things as suggested and this will be good to go.


https://reviews.llvm.org/D33426



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


Re: [Lldb-commits] Patch for fixing FDE indexing when scan debug_info section

2017-05-23 Thread Tatyana Krasnukha via lldb-commits
Done. I have also added a little change which allow to use debug_info section 
when eh_frame is absent. This case really can take place on some platforms.

Thanks,
Tatyana

From: Abid, Hafiz [mailto:hafiz_a...@mentor.com]
Sent: Tuesday, 23 May, 2017 3:31 PM
To: Tatyana Krasnukha ; 
lldb-commits@lists.llvm.org
Subject: Re: [Lldb-commits] Patch for fixing FDE indexing when scan debug_info 
section

It looks ok to me. Please put the differences of .eh_frame and
.debug_frame that you described below in code comments too.​

Thanks,
Abid




From: lldb-commits 
mailto:lldb-commits-boun...@lists.llvm.org>>
 on behalf of Tatyana Krasnukha via lldb-commits 
mailto:lldb-commits@lists.llvm.org>>
Sent: Thursday, May 18, 2017 9:37 PM
To: lldb-commits@lists.llvm.org
Subject: [Lldb-commits] Patch for fixing FDE indexing when scan debug_info 
section

Fix FDE indexing while scan debug_info section.

There are some differences between eh_frame and debug_frame formats that are 
not considered by DWARFCallFrameInfo::GetFDEIndex.
An FDE entry contains CIE_pointer in debug_frame in same place as cie_id in 
eh_frame. As described in dwarf 
standard
 (section 6.4.1),
CIE_pointer is an “offset into the .debug_frame section”. So, variable 
cie_offset should be equal cie_id for debug_frame.
FDE entries with zeroth CIE pointer (which is actually placed in cie_id 
variable) shouldn’t be ignored also.

I had same issue as described here 
http://lists.llvm.org/pipermail/lldb-dev/2014-October/005520.html
 , and these changes have fixed it for me (with "m_is_eh_frame" set to false, 
of course).

Tatyana Krasnukha
Software Engineer, Sr. I, Solutions Group, Synopsys Inc.
w +7.812.408.7463 | m +7 981 757-4491 | 
taty...@synopsys.com



Symbol.patch
Description: Symbol.patch
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D33434: Added new API to SBStructuredData class

2017-05-23 Thread Greg Clayton via Phabricator via lldb-commits
clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.

Very close and overall very nice, just a few implementation details to take 
care of.




Comment at: include/lldb/API/SBStructuredData.h:20-28
+  enum Type {
+eTypeInvalid = -1,
+eTypeArray = 0,
+eTypeInteger,
+eTypeFloat,
+eTypeBoolean,
+eTypeString,

This should go into lldb-enumerations.h and the lldb_private::StructuredData 
should switch over to using that enum as well. Then we won't duplicated the 
enum here and in StructuredData.h. The enum type name will need to become 
longer and the enums will need to include the prefix be longer:

```
enum StructureDataType {
  eStructureDataTypeInvalid,
  eStructureDataTypeArray,
  ...
```




Comment at: include/lldb/API/SBStructuredData.h:53
+  //--
+  lldb::SBStructuredData::Type GetType() const;
+

lldb::StructureDataType to match the new enum in lldb-enumerations.h



Comment at: include/lldb/API/SBStructuredData.h:60
+  //--
+  size_t GetSize() const;
+

What is the user going to really do when getting the size from a dictionary? I 
would vote to just make this for arrays and provide a IsEmpty() method if you 
want to check if the dictionary or array is empty? I am open for reasons why we 
should be able to get the size of the dictionary if there is a need, I am just 
thinking out loud here.



Comment at: include/lldb/API/SBStructuredData.h:93
+  //--
+  size_t GetStringValue(char *dst, size_t dst_len) const;
+

We should make this be able to take NULL for dst and/or zero for dst_len and 
have it return the size that would be needed to store the value. Basically 
document:
- the return value is always the byte size needed for the string value
- if the buffer supplied is insufficient, then dst_len -1 bytes will be filled 
in and the string will be NULL terminated prematurely
- the if the buffer supplied is invalid (dst == NULL, or dst_len == 0), then no 
data will be filled in



Comment at: include/lldb/API/SBStructuredData.h:98-99
 
+  SBStructuredData(const lldb::StructuredDataImplUP &impl_up);
+
   StructuredDataImplUP m_impl_up;

Remove this.



Comment at: include/lldb/Core/StructuredDataImpl.h:99-103
+if (m_data_sp->GetType() == StructuredData::Type::eTypeDictionary) {
+  StructuredData::Dictionary *dict =
+  static_cast(
+  m_data_sp.get());
+  return (dict->GetSize());

Do we need to get the size for a dictionary? See above inlined comment.



Comment at: include/lldb/Core/StructuredDataImpl.h:113-120
+if (!m_data_sp ||
+(m_data_sp->GetType() != StructuredData::Type::eTypeDictionary))
+  return StructuredData::ObjectSP();
+
+StructuredData::Dictionary *dict =
+static_cast(
+m_data_sp.get());

Might be easier to use the StructuredData::GetAsDictionary():
```
if (m_data_sp) {
  auto dict = m_data_sp->GetAsDictionary();
  if (dict)
return dict->GetValueForKey(llvm::StringRef(key))
}
return StructuredData::ObjectSP();
```



Comment at: include/lldb/Core/StructuredDataImpl.h:124-129
+if (!m_data_sp ||
+(m_data_sp->GetType() != StructuredData::Type::eTypeArray))
+  return StructuredData::ObjectSP();
+
+StructuredData::Array *array =
+static_cast(m_data_sp.get());

Use GetAsArray() like above dictionary requested changes.



Comment at: scripts/interface/SBStructuredData.i:22-30
+enum Type {
+  eTypeInvalid = -1,
+  eTypeArray = 0,
+  eTypeInteger,
+  eTypeFloat,
+  eTypeBoolean,
+  eTypeString,

Remove and use from lldb-enumerations.h



Comment at: source/API/SBStructuredData.cpp:34-35
 
+SBStructuredData::SBStructuredData(const lldb::StructuredDataImplUP &impl_up)
+: m_impl_up(new StructuredDataImpl(*(impl_up.get( {}
+

Remove this.



Comment at: source/API/SBStructuredData.cpp:114
+
+  StructuredDataImplUP impl_up(new StructuredDataImpl());
+  impl_up->SetObjectSP(m_impl_up->GetValueForKey(key));

Just default construct one:

```
SBStructuredData result;
result.m_impl_up->SetObjectSP(m_impl_up->GetValueForKey(key));
return result;
```



Comment at: source/API/SBStructuredData.cpp:123-125
+  StructuredDataImplUP impl_up(new StructuredDataImpl());
+  impl_up->SetObjectSP(m_impl_up->GetItemAtIndex(idx));
+  return lldb::SBStructuredData(impl_up);

Default construct and use the o

[Lldb-commits] [PATCH] D32585: Implementation of remote packets for Trace data.

2017-05-23 Thread Greg Clayton via Phabricator via lldb-commits
clayborg added a comment.

Looks like we are down to just running clang format on the code so the R"( 
strings don't go over 80 chars and this is good to go from me.


https://reviews.llvm.org/D32585



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] Fixing of Bug 32920 - Potentially premature destroying of the locker in Python interpreter

2017-05-23 Thread Tatyana Krasnukha via lldb-commits
CreateStructuredDictionary() needs the GIL to be held because it calls 
PyList_GET_SIZE from a nested function.



ScriptInterpreterPython.cpp.patch
Description: ScriptInterpreterPython.cpp.patch
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] r303674 - hange RenderScriptx86ABIFixups.cpp to use llvm::AttributeList iterator

2017-05-23 Thread Stephane Sezer via lldb-commits
Author: sas
Date: Tue May 23 13:54:03 2017
New Revision: 303674

URL: http://llvm.org/viewvc/llvm-project?rev=303674&view=rev
Log:
hange RenderScriptx86ABIFixups.cpp to use llvm::AttributeList iterator

LLVM::AttributeList recently had getNumSlots() removed, which broke the
build. This fixes the build using functions introduced in the
update to LLVM::AttributeList.

Change by Alex Langford 

Modified:

lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptx86ABIFixups.cpp

Modified: 
lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptx86ABIFixups.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptx86ABIFixups.cpp?rev=303674&r1=303673&r2=303674&view=diff
==
--- 
lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptx86ABIFixups.cpp
 (original)
+++ 
lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptx86ABIFixups.cpp
 Tue May 23 13:54:03 2017
@@ -254,7 +254,8 @@ bool fixupRSAllocationStructByValCalls(l
 llvm::AttributeList call_attribs = call_inst->getAttributes();
 
 // iterate over the argument attributes
-for (size_t i = 1; i <= call_attribs.getNumSlots(); ++i) {
+for (unsigned I = call_attribs.index_begin(); I != 
call_attribs.index_end();
+ I++) {
   // if this argument is passed by val
   if (call_attribs.hasAttribute(i, llvm::Attribute::ByVal)) {
 // strip away the byval attribute


___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] r303677 - Fix bad change in RenderScriptx86ABIFixups.cpp, forgot to change everything necessary

2017-05-23 Thread Stephane Sezer via lldb-commits
Author: sas
Date: Tue May 23 14:22:31 2017
New Revision: 303677

URL: http://llvm.org/viewvc/llvm-project?rev=303677&view=rev
Log:
Fix bad change in RenderScriptx86ABIFixups.cpp, forgot to change everything 
necessary

Summary: I didn't change all instances of i to I in this loop. I am a bad 
person and should feel bad. :(

Reviewers: sas

Differential Revision: https://reviews.llvm.org/D33456

Change by Alex Langford 

Modified:

lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptx86ABIFixups.cpp

Modified: 
lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptx86ABIFixups.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptx86ABIFixups.cpp?rev=303677&r1=303676&r2=303677&view=diff
==
--- 
lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptx86ABIFixups.cpp
 (original)
+++ 
lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptx86ABIFixups.cpp
 Tue May 23 14:22:31 2017
@@ -257,9 +257,9 @@ bool fixupRSAllocationStructByValCalls(l
 for (unsigned I = call_attribs.index_begin(); I != 
call_attribs.index_end();
  I++) {
   // if this argument is passed by val
-  if (call_attribs.hasAttribute(i, llvm::Attribute::ByVal)) {
+  if (call_attribs.hasAttribute(I, llvm::Attribute::ByVal)) {
 // strip away the byval attribute
-call_inst->removeAttribute(i, llvm::Attribute::ByVal);
+call_inst->removeAttribute(I, llvm::Attribute::ByVal);
 changed = true;
   }
 }


___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D32366: Set "success" status correctly

2017-05-23 Thread Tatyana Krasnukha via Phabricator via lldb-commits
tatyana-krasnukha added a comment.

It can make sense to add

  static_assert(eReturnStatusStarted != result);

after cmd_obj->Execute() invocation at CommandInterpreter::HandleCommand, do 
you think?


Repository:
  rL LLVM

https://reviews.llvm.org/D32366



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D33283: RunThreadPlan: Fix halting logic in IgnoreBreakpoints = false

2017-05-23 Thread Jim Ingham via Phabricator via lldb-commits
jingham added a comment.

That looks right to me, and is much nicer to read.

I think "plan failure" once you've actually kicked off the execution of a 
function calling thread plan is theoretical, there are plenty of ways the plan 
can fail, though at present all the ways I can think of would happen either 
before or after you got here.  But just because we haven't found a way to make 
that stage fail yet...


https://reviews.llvm.org/D33283



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D33283: RunThreadPlan: Fix halting logic in IgnoreBreakpoints = false

2017-05-23 Thread Jim Ingham via Phabricator via lldb-commits
jingham accepted this revision.
jingham added a comment.
This revision is now accepted and ready to land.

Oh, yeah, check the checkbox, Jim...


https://reviews.llvm.org/D33283



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D32149: Correct handling NetBSD core(5) files with threads

2017-05-23 Thread Kamil Rytarowski via Phabricator via lldb-commits
krytarowski updated this revision to Diff 100035.
krytarowski added a comment.

Rebase to HEAD.
Apply "Error" -> "Status" rename.


Repository:
  rL LLVM

https://reviews.llvm.org/D32149

Files:
  source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
  source/Plugins/Process/elf-core/ProcessElfCore.cpp
  source/Plugins/Process/elf-core/ProcessElfCore.h

Index: source/Plugins/Process/elf-core/ProcessElfCore.h
===
--- source/Plugins/Process/elf-core/ProcessElfCore.h
+++ source/Plugins/Process/elf-core/ProcessElfCore.h
@@ -125,6 +125,18 @@
 lldb_private::ConstString path;
   };
 
+  // Parse thread(s) data structuresNetBSD(prstatus, prpsinfo) from given NOTE
+  // segment
+  lldb_private::Status ParseThreadContextsFromNoteSegmentNetBSD(
+  const elf::ELFProgramHeader *segment_header,
+  lldb_private::DataExtractor segment_data);
+
+  // Parse thread(s) data structuresGeneric(prstatus, prpsinfo) from given NOTE
+  // segment
+  lldb_private::Status ParseThreadContextsFromNoteSegmentGeneric(
+  const elf::ELFProgramHeader *segment_header,
+  lldb_private::DataExtractor segment_data);
+
   //--
   // For ProcessElfCore only
   //--
Index: source/Plugins/Process/elf-core/ProcessElfCore.cpp
===
--- source/Plugins/Process/elf-core/ProcessElfCore.cpp
+++ source/Plugins/Process/elf-core/ProcessElfCore.cpp
@@ -27,6 +27,7 @@
 #include "lldb/Utility/DataBufferLLVM.h"
 #include "lldb/Utility/Log.h"
 
+#include "llvm/ADT/StringRef.h"
 #include "llvm/Support/ELF.h"
 #include "llvm/Support/Threading.h"
 
@@ -458,9 +459,42 @@
 
 namespace NETBSD {
 
-enum { NT_PROCINFO = 1, NT_AUXV, NT_AMD64_REGS = 33, NT_AMD64_FPREGS = 35 };
+enum { NT_PROCINFO = 1, NT_AUXV = 2 };
+
+/* Size in bytes */
+enum { NT_PROCINFO_SIZE = 160 };
+
+/* Size in bytes */
+enum {
+  NT_PROCINFO_CPI_VERSION_SIZE = 4,
+  NT_PROCINFO_CPI_CPISIZE_SIZE = 4,
+  NT_PROCINFO_CPI_SIGNO_SIZE = 4,
+  NT_PROCINFO_CPI_SIGCODE_SIZE = 4,
+  NT_PROCINFO_CPI_SIGPEND_SIZE = 16,
+  NT_PROCINFO_CPI_SIGMASK_SIZE = 16,
+  NT_PROCINFO_CPI_SIGIGNORE_SIZE = 16,
+  NT_PROCINFO_CPI_SIGCATCH_SIZE = 16,
+  NT_PROCINFO_CPI_PID_SIZE = 4,
+  NT_PROCINFO_CPI_PPID_SIZE = 4,
+  NT_PROCINFO_CPI_PGRP_SIZE = 4,
+  NT_PROCINFO_CPI_SID_SIZE = 4,
+  NT_PROCINFO_CPI_RUID_SIZE = 4,
+  NT_PROCINFO_CPI_EUID_SIZE = 4,
+  NT_PROCINFO_CPI_SVUID_SIZE = 4,
+  NT_PROCINFO_CPI_RGID_SIZE = 4,
+  NT_PROCINFO_CPI_EGID_SIZE = 4,
+  NT_PROCINFO_CPI_SVGID_SIZE = 4,
+  NT_PROCINFO_CPI_NLWPS_SIZE = 4,
+  NT_PROCINFO_CPI_NAME_SIZE = 32,
+  NT_PROCINFO_CPI_SIGLWP_SIZE = 4,
+};
+
+namespace AMD64 {
+enum { NT_REGS = 33, NT_FPREGS = 35 };
 }
 
+} // namespace NETBSD
+
 // Parse a FreeBSD NT_PRSTATUS note - see FreeBSD sys/procfs.h for details.
 static void ParseFreeBSDPrStatus(ThreadData &thread_data, DataExtractor &data,
  ArchSpec &arch) {
@@ -497,15 +531,43 @@
   thread_data.name = data.GetCStr(&offset, 20);
 }
 
-static void ParseNetBSDProcInfo(ThreadData &thread_data, DataExtractor &data) {
+static Status ParseNetBSDProcInfo(DataExtractor &data, uint32_t &cpi_nlwps,
+ uint32_t &cpi_signo, uint32_t &cpi_siglwp) {
   lldb::offset_t offset = 0;
 
-  int version = data.GetU32(&offset);
+  uint32_t version = data.GetU32(&offset);
   if (version != 1)
-return;
+return Status(
+"Error parsing NetBSD core(5) notes: Unsupported procinfo version");
+
+  uint32_t cpisize = data.GetU32(&offset);
+  if (cpisize != NETBSD::NT_PROCINFO_SIZE)
+return Status(
+"Error parsing NetBSD core(5) notes: Unsupported procinfo size");
+
+  cpi_signo = data.GetU32(&offset); /* killing signal */
+
+  offset += NETBSD::NT_PROCINFO_CPI_SIGCODE_SIZE;
+  offset += NETBSD::NT_PROCINFO_CPI_SIGPEND_SIZE;
+  offset += NETBSD::NT_PROCINFO_CPI_SIGMASK_SIZE;
+  offset += NETBSD::NT_PROCINFO_CPI_SIGIGNORE_SIZE;
+  offset += NETBSD::NT_PROCINFO_CPI_SIGCATCH_SIZE;
+  offset += NETBSD::NT_PROCINFO_CPI_PID_SIZE;
+  offset += NETBSD::NT_PROCINFO_CPI_PPID_SIZE;
+  offset += NETBSD::NT_PROCINFO_CPI_PGRP_SIZE;
+  offset += NETBSD::NT_PROCINFO_CPI_SID_SIZE;
+  offset += NETBSD::NT_PROCINFO_CPI_RUID_SIZE;
+  offset += NETBSD::NT_PROCINFO_CPI_EUID_SIZE;
+  offset += NETBSD::NT_PROCINFO_CPI_SVUID_SIZE;
+  offset += NETBSD::NT_PROCINFO_CPI_RGID_SIZE;
+  offset += NETBSD::NT_PROCINFO_CPI_EGID_SIZE;
+  offset += NETBSD::NT_PROCINFO_CPI_SVGID_SIZE;
+  cpi_nlwps = data.GetU32(&offset); /* number of LWPs */
+
+  offset += NETBSD::NT_PROCINFO_CPI_NAME_SIZE;
+  cpi_siglwp = data.GetU32(&offset); /* LWP target of killing signal */
 
-  offset += 4;
-  thread_data.signo = data.GetU32(&offset);
+  return Status();
 }
 
 static void ParseOpenBSDProcInfo(ThreadData &thread_data, DataExtractor &data) {
@@ -524,12 +586,28 

[Lldb-commits] [PATCH] D32149: Correct handling NetBSD core(5) files with threads

2017-05-23 Thread Kamil Rytarowski via Phabricator via lldb-commits
krytarowski added a comment.

Can we go with this change?


Repository:
  rL LLVM

https://reviews.llvm.org/D32149



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits