[Lldb-commits] [PATCH] D30454: [LLDB][MIPS] Fix typo in MatchesModuleSpec()

2017-03-02 Thread Nitesh Jain via Phabricator via lldb-commits 
nitesh.jain added a comment.

The issue was observed while parsing "vdso module" for the core file. When the 
DynamicLoader::LoadModuleAtAddress is called to load "vdso" module. Since 
"vdso" doesn't match with any of the module in the target.GetImages(), the 
check_alternative_file_name becomes true. This cause MatchesModuleSpec to 
return true and application binary to reload again at vdso base 
address(AT_SYSINFO_EHDR) thus all load addresses of application elf's sections 
becomes incorrect. Please find attach log file.
DynamicLoader::LoadModuleAtAddress(...)
{

  ...
  ...
  ...
  if (check_alternative_file_name) {
  ...
  ...
  ...
  **FileSpec(memory_info.GetName().AsCString(), false),**  ** // 
memory_info.GetName().AsCString() is empty here**
  target.GetArchitecture());
  
  if ((module_sp = modules.FindFirstModule(new_module_spec))) {  // 
FindFirstModule returns application elf's module
UpdateLoadedSections(module_sp, link_map_addr, base_addr, false); // 
load addresses of application elf's sections gets updated to vdso's address 
(which is incorrect)
return module_sp;
  }

...
 ...
 ...
}


https://reviews.llvm.org/D30454



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

[Lldb-commits] [PATCH] D30454: [LLDB][MIPS] Fix typo in MatchesModuleSpec()

2017-03-02 Thread Nitesh Jain via Phabricator via lldb-commits 
nitesh.jain added a comment.

Attach log file F3122646: module.log 


https://reviews.llvm.org/D30454



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

[Lldb-commits] [lldb] r296738 - Fix MSVC build

2017-03-02 Thread Pavel Labath via lldb-commits 
Author: labath
Date: Thu Mar  2 04:35:53 2017
New Revision: 296738

URL: http://llvm.org/viewvc/llvm-project?rev=296738&view=rev
Log:
Fix MSVC build

MSVC (at least the version I am using) does not want to implicitly
capture a const bool variable. Move it into the lambda, as it is not
used outside anyway.

Modified:
lldb/trunk/source/Commands/CommandObjectFrame.cpp

Modified: lldb/trunk/source/Commands/CommandObjectFrame.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Commands/CommandObjectFrame.cpp?rev=296738&r1=296737&r2=296738&view=diff
==
--- lldb/trunk/source/Commands/CommandObjectFrame.cpp (original)
+++ lldb/trunk/source/Commands/CommandObjectFrame.cpp Thu Mar  2 04:35:53 2017
@@ -192,13 +192,13 @@ protected:
   return false;
 }
 
-const bool qualify_cxx_base_classes = false;
 
 DumpValueObjectOptions::DeclPrintingHelper helper = [&valobj_sp](
 ConstString type, ConstString var, const DumpValueObjectOptions &opts,
 Stream &stream) -> bool {
   const ValueObject::GetExpressionPathFormat format = ValueObject::
   GetExpressionPathFormat::eGetExpressionPathFormatHonorPointers;
+  const bool qualify_cxx_base_classes = false;
   valobj_sp->GetExpressionPath(stream, qualify_cxx_base_classes, format);
   stream.PutCString(" =");
   return true;


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

Re: [Lldb-commits] [lldb] r296717 - Fix various warnings. NFC

2017-03-02 Thread Pavel Labath via lldb-commits 
On 2 March 2017 at 00:05, Zachary Turner via lldb-commits <
lldb-commits@lists.llvm.org> wrote:

> -DumpValueObjectOptions::DeclPrintingHelper helper =
> -[&valobj_sp, qualify_cxx_base_classes](
> -ConstString type, ConstString var,
> -const DumpValueObjectOptions &opts, Stream &stream) -> bool {
> +DumpValueObjectOptions::DeclPrintingHelper helper = [&valobj_sp](
> +ConstString type, ConstString var, const DumpValueObjectOptions
> &opts,
> +Stream &stream) -> bool {
>const ValueObject::GetExpressionPathFormat format = ValueObject::
>

Hi Zach,

what's the compiler that was giving you this warning. The version of MSVC I
am using is complaining about a missing capture when you removed this.

I've updated the code in a way which should make both compilers satisfied,
but I'd like to know if we are using an unsupported version of MSVC or
something.

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

[Lldb-commits] [PATCH] D30520: Make LLDB skip server-client roundtrip for signals that don't require any actions

2017-03-02 Thread Pavel Labath via Phabricator via lldb-commits 
labath added a comment.

Jim's comment about putting the function in the parent class makes sense -- 
apart from remote stubs I guess you could also envision other ways a process 
class could speed up signal processing in case it know we don't care about 
them).

Jim: do you have a idea about how to write a test for this? These 
performance-improvement kind of changes don't fit really well into the SB API 
test framework, as this change should not have any observable behavior, and we 
already have tests that make sure that "process handle" does the right thing 
(i.e., we don't stop for ignored signals). The best thing I can come up with 
(without going on a major refactoring effort) is enabling logging and then 
grepping it for some string.

Actually, I can think of a potential improvement. Move the code currently in 
`ProcessGDBRemote::SendSignalsToIgnoreIfNeeded` to 
`GDBRemoteCommunicationClient`. The latter is unit-testable so it would give as 
more coverage, and I think an API like `Error 
GDBRemoteCommunicationClient::IgnoreSignalsIfSupported(const UnixSignals 
&signals)` would still make sense. It won't solve the problem of testing the 
whole thing end-to-end, but it would certainly increase the test coverage of 
this change.

Let me know what you think.




Comment at: source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp:1067
 "using %s %s",
-__FUNCTION__, process_arch.GetArchitectureName()
-  ? process_arch.GetArchitectureName()

It looks like you reformatted the whole file instead of just your changes. 
Random diff makes review harder. If you set it up correctly `git clang-format` 
should only format the code around your changes, so I recommend using that.



Comment at: source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp:3795
+LLDB_LOG(log, "Error: {0}", error);
+  }
+  return error;

No braces.



Comment at: 
unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp:332
+
+  HandlePacket(server, "QPassSignals:2;3;5;7;B;D;11", "OK");
+  EXPECT_TRUE(result.get().Success());

The documentation for QPassSignals 
 states 
that "Signals are numbered identically to continue packets and stop replies". 
While it does not say that directly, I would interpret that as "you should 
always use two digits for the signal number" because that's how stop-reply 
packets work. It's fine to keep the receiving code lax, but let's be stricter  
in what we generate.


https://reviews.llvm.org/D30520



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

[Lldb-commits] [lldb] r296741 - Fix flakyness in TestGdbRemoteHostInfo

2017-03-02 Thread Pavel Labath via lldb-commits 
Author: labath
Date: Thu Mar  2 05:36:14 2017
New Revision: 296741

URL: http://llvm.org/viewvc/llvm-project?rev=296741&view=rev
Log:
Fix flakyness in TestGdbRemoteHostInfo

this test was using the VPATH hack to avoid having a copy of the
inferior source code. This makes the test fail if in happens to run
concurrently with a test in the parent folder. Fix that by moving it up
to the parent.

Added:

lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteHostInfo.py
  - copied, changed from r296738, 
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/host-info/TestGdbRemoteHostInfo.py
Removed:

lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/host-info/Makefile

lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/host-info/TestGdbRemoteHostInfo.py

Copied: 
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteHostInfo.py
 (from r296738, 
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/host-info/TestGdbRemoteHostInfo.py)
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteHostInfo.py?p2=lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteHostInfo.py&p1=lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/host-info/TestGdbRemoteHostInfo.py&r1=296738&r2=296741&rev=296741&view=diff
==
(empty)

Removed: 
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/host-info/Makefile
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/host-info/Makefile?rev=296740&view=auto
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/host-info/Makefile 
(original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/host-info/Makefile 
(removed)
@@ -1,10 +0,0 @@
-LEVEL = ../../../make
-
-VPATH = ..
-
-override CFLAGS_EXTRAS += -D__STDC_LIMIT_MACROS -D__STDC_FORMAT_MACROS
-ENABLE_THREADS := YES
-CXX_SOURCES := main.cpp
-MAKE_DSYM :=NO
-
-include $(LEVEL)/Makefile.rules

Removed: 
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/host-info/TestGdbRemoteHostInfo.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/host-info/TestGdbRemoteHostInfo.py?rev=296740&view=auto
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/host-info/TestGdbRemoteHostInfo.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/host-info/TestGdbRemoteHostInfo.py
 (removed)
@@ -1,126 +0,0 @@
-from __future__ import print_function
-
-# lldb test suite imports
-from lldbsuite.test.decorators import *
-from lldbsuite.test.lldbtest import TestBase
-
-# gdb-remote-specific imports
-import lldbgdbserverutils
-from gdbremote_testcase import GdbRemoteTestCaseBase
-
-
-class TestGdbRemoteHostInfo(GdbRemoteTestCaseBase):
-
-mydir = TestBase.compute_mydir(__file__)
-
-KNOWN_HOST_INFO_KEYS = set([
-"cputype",
-"cpusubtype",
-"distribution_id",
-"endian",
-"hostname",
-"ostype",
-"os_build",
-"os_kernel",
-"os_version",
-"ptrsize",
-"triple",
-"vendor",
-"watchpoint_exceptions_received",
-"default_packet_timeout",
-])
-
-DARWIN_REQUIRED_HOST_INFO_KEYS = set([
-"cputype",
-"cpusubtype",
-"endian",
-"ostype",
-"ptrsize",
-"vendor",
-"watchpoint_exceptions_received"
-])
-
-def add_host_info_collection_packets(self):
-self.test_sequence.add_log_lines(
-["read packet: $qHostInfo#9b",
- {"direction": "send", "regex": r"^\$(.+)#[0-9a-fA-F]{2}$",
-  "capture": {1: "host_info_raw"}}],
-True)
-
-def parse_host_info_response(self, context):
-# Ensure we have a host info response.
-self.assertIsNotNone(context)
-host_info_raw = context.get("host_info_raw")
-self.assertIsNotNone(host_info_raw)
-
-# Pull out key:value; pairs.
-host_info_dict = {match.group(1): match.group(2)
-  for match in re.finditer(r"([^:]+):([^;]+);",
-   host_info_raw)}
-
-import pprint
-print("\nqHostInfo response:")
-pprint.pprint(host_info_dict)
-
-# Validate keys are known.
-for (key, val) in list(host_info_dict.items()):
-self.assertTrue(key in self.KNOWN_HOST_INFO_KEYS,
-"unknown qHostInfo key: " + key)
-self.assertIsNotNone(val)
-
-# Return the key:val pairs.
-return host_info_dict
-
-def get_qHostInfo_response(self):
-# Launch

[Lldb-commits] [PATCH] D30457: [LLDB][MIPS] Core Dump Support

2017-03-02 Thread Nitesh Jain via Phabricator via lldb-commits 
nitesh.jain updated this revision to Diff 90328.
nitesh.jain added a comment.

Update diff as per suggestion.


https://reviews.llvm.org/D30457

Files:
  source/Plugins/Process/FreeBSD/RegisterContextPOSIXProcessMonitor_mips64.h
  source/Plugins/Process/Linux/NativeRegisterContextLinux_mips64.cpp
  source/Plugins/Process/Utility/RegisterContextFreeBSD_mips64.cpp
  source/Plugins/Process/Utility/RegisterContextFreeBSD_mips64.h
  source/Plugins/Process/Utility/RegisterContextLinux_mips.cpp
  source/Plugins/Process/Utility/RegisterContextLinux_mips.h
  source/Plugins/Process/Utility/RegisterContextLinux_mips64.cpp
  source/Plugins/Process/Utility/RegisterContextLinux_mips64.h
  source/Plugins/Process/Utility/RegisterContextPOSIX_mips64.cpp
  source/Plugins/Process/Utility/RegisterContextPOSIX_mips64.h
  source/Plugins/Process/elf-core/RegisterContextPOSIXCore_mips64.cpp
  source/Plugins/Process/elf-core/RegisterContextPOSIXCore_mips64.h
  source/Plugins/Process/elf-core/ThreadElfCore.cpp
  source/Plugins/Process/elf-core/ThreadElfCore.h

Index: source/Plugins/Process/elf-core/ThreadElfCore.h
===
--- source/Plugins/Process/elf-core/ThreadElfCore.h
+++ source/Plugins/Process/elf-core/ThreadElfCore.h
@@ -19,6 +19,10 @@
 #include "lldb/Core/DataExtractor.h"
 #include "lldb/Target/Thread.h"
 
+#define MIPS_LINUX_PR_STATUS_SIZE_O32 96
+#define MIPS_LINUX_PR_STATUS_SIZE_N32 72
+#define MIPS_LINUX_PR_PSINFO_SIZE_O32_N32 128
+
 struct compat_timeval {
   alignas(8) uint64_t tv_sec;
   alignas(8) uint64_t tv_usec;
@@ -66,6 +70,17 @@
   // members are smaller -
   // so the layout is not the same
   static size_t GetSize(lldb_private::ArchSpec &arch) {
+if (arch.IsMIPS()) {
+  std::string abi = arch.GetTargetABI();
+  assert(!abi.empty() && "ABI is not set");
+  if (!abi.compare("n64"))
+return sizeof(ELFLinuxPrStatus);
+  else if (!abi.compare("o32"))
+return MIPS_LINUX_PR_STATUS_SIZE_O32;
+  // N32 ABI
+  return MIPS_LINUX_PR_STATUS_SIZE_N32;
+}
+
 switch (arch.GetCore()) {
 case lldb_private::ArchSpec::eCore_s390x_generic:
 case lldb_private::ArchSpec::eCore_x86_64_x86_64:
@@ -98,6 +113,8 @@
   // members are smaller -
   // so the layout is not the same
   static size_t GetSize(const lldb_private::ArchSpec &arch) {
+if (arch.IsMIPS())
+return sizeof(ELFLinuxSigInfo);
 switch (arch.GetCore()) {
 case lldb_private::ArchSpec::eCore_x86_64_x86_64:
   return sizeof(ELFLinuxSigInfo);
@@ -144,6 +161,13 @@
   // members are smaller -
   // so the layout is not the same
   static size_t GetSize(lldb_private::ArchSpec &arch) {
+if (arch.IsMIPS()) {
+  uint8_t address_byte_size = arch.GetAddressByteSize();
+  if (address_byte_size == 8)
+return sizeof(ELFLinuxPrPsInfo);
+  return MIPS_LINUX_PR_PSINFO_SIZE_O32_N32;
+}
+
 switch (arch.GetCore()) {
 case lldb_private::ArchSpec::eCore_s390x_generic:
 case lldb_private::ArchSpec::eCore_x86_64_x86_64:
Index: source/Plugins/Process/elf-core/ThreadElfCore.cpp
===
--- source/Plugins/Process/elf-core/ThreadElfCore.cpp
+++ source/Plugins/Process/elf-core/ThreadElfCore.cpp
@@ -18,6 +18,8 @@
 #include "Plugins/Process/Utility/RegisterContextFreeBSD_mips64.h"
 #include "Plugins/Process/Utility/RegisterContextFreeBSD_powerpc.h"
 #include "Plugins/Process/Utility/RegisterContextFreeBSD_x86_64.h"
+#include "Plugins/Process/Utility/RegisterContextLinux_mips64.h"
+#include "Plugins/Process/Utility/RegisterContextLinux_mips.h"
 #include "Plugins/Process/Utility/RegisterContextLinux_i386.h"
 #include "Plugins/Process/Utility/RegisterContextLinux_s390x.h"
 #include "Plugins/Process/Utility/RegisterContextLinux_x86_64.h"
@@ -118,6 +120,14 @@
   case llvm::Triple::aarch64:
 reg_interface = new RegisterInfoPOSIX_arm64(arch);
 break;
+  case llvm::Triple::mipsel:
+  case llvm::Triple::mips:
+reg_interface = new RegisterContextLinux_mips(arch);
+break;
+  case llvm::Triple::mips64el:
+  case llvm::Triple::mips64:
+reg_interface = new RegisterContextLinux_mips64(arch);
+break;
   case llvm::Triple::systemz:
 reg_interface = new RegisterContextLinux_s390x(arch);
 break;
@@ -153,7 +163,13 @@
   m_thread_reg_ctx_sp.reset(new RegisterContextCorePOSIX_arm(
   *this, reg_interface, m_gpregset_data, m_fpregset_data));
   break;
+case llvm::Triple::mipsel:
+case llvm::Triple::mips:
+  m_thread_reg_ctx_sp.reset(new RegisterContextCorePOSIX_mips64(
+ *this, reg_interface, m_gpregset_data, m_fpregset_data));
+  break;
 case llvm::Triple::mips64:
+case llvm::Triple::mips64el:
   m_thread_reg_ctx_sp.reset(new RegisterContextCorePOSIX_mips64(
   *this, reg_interface, m_gpregset_data, m_fpregset_data));
   break;
Index: so

[Lldb-commits] [PATCH] D30457: [LLDB][MIPS] Core Dump Support

2017-03-02 Thread Nitesh Jain via Phabricator via lldb-commits 
nitesh.jain marked an inline comment as done.
nitesh.jain added inline comments.



Comment at: source/Plugins/Process/Utility/RegisterInfoInterface.h:32
 
+  virtual const lldb_private::RegisterSet *
+  GetRegisterSet(size_t set) const {return nullptr;}

labath wrote:
> While I don't see anything obviously wrong about adding this interface, I am 
> wondering why the other subclasses have not needed this.
> 
> I'd defer to @clayborg judgement on the appropriateness of the interface. 
> What I don't like however, is that the default implementation will blatantly 
> lie about the number of register sets for the non-mips case.
> 
> What I can suggest is to avoid putting these functions in the generic class 
> -- you seem to be calling them from mips code only, so I don't see any 
> immediate need to have them here. (e.g. have GetRegisterInfoInterface() cast 
> to the appropriate type).
In case of MIPS, the register set is different for FreeBSD and Linux. In other 
platform, the register set may be same.  


https://reviews.llvm.org/D30457



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

[Lldb-commits] [PATCH] D30457: [LLDB][MIPS] Core Dump Support

2017-03-02 Thread Nitesh Jain via Phabricator via lldb-commits 
nitesh.jain marked an inline comment as done.
nitesh.jain added a comment.

The  .note.ABI-tag is missing in the  ELF file, generated by 
test/testcases/functionalities/postmortem/elf-core/make-core.sh. Need to look 
into it.

-Thanks


https://reviews.llvm.org/D30457



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

Re: [Lldb-commits] [lldb] r296717 - Fix various warnings. NFC

2017-03-02 Thread Zachary Turner via lldb-commits 
Clang-cl
On Thu, Mar 2, 2017 at 2:51 AM Pavel Labath  wrote:

>
> On 2 March 2017 at 00:05, Zachary Turner via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
>
> -DumpValueObjectOptions::DeclPrintingHelper helper =
> -[&valobj_sp, qualify_cxx_base_classes](
> -ConstString type, ConstString var,
> -const DumpValueObjectOptions &opts, Stream &stream) -> bool {
> +DumpValueObjectOptions::DeclPrintingHelper helper = [&valobj_sp](
> +ConstString type, ConstString var, const DumpValueObjectOptions
> &opts,
> +Stream &stream) -> bool {
>const ValueObject::GetExpressionPathFormat format = ValueObject::
>
>
> Hi Zach,
>
> what's the compiler that was giving you this warning. The version of MSVC
> I am using is complaining about a missing capture when you removed this.
>
> I've updated the code in a way which should make both compilers satisfied,
> but I'd like to know if we are using an unsupported version of MSVC or
> something.
>
> cheers,
> pl
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb] r296717 - Fix various warnings. NFC

2017-03-02 Thread Zachary Turner via lldb-commits 
What capture does it say is missing? Also what version of msvc?
On Thu, Mar 2, 2017 at 7:17 AM Zachary Turner  wrote:

> Clang-cl
> On Thu, Mar 2, 2017 at 2:51 AM Pavel Labath  wrote:
>
>
> On 2 March 2017 at 00:05, Zachary Turner via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
>
> -DumpValueObjectOptions::DeclPrintingHelper helper =
> -[&valobj_sp, qualify_cxx_base_classes](
> -ConstString type, ConstString var,
> -const DumpValueObjectOptions &opts, Stream &stream) -> bool {
> +DumpValueObjectOptions::DeclPrintingHelper helper = [&valobj_sp](
> +ConstString type, ConstString var, const DumpValueObjectOptions
> &opts,
> +Stream &stream) -> bool {
>const ValueObject::GetExpressionPathFormat format = ValueObject::
>
>
> Hi Zach,
>
> what's the compiler that was giving you this warning. The version of MSVC
> I am using is complaining about a missing capture when you removed this.
>
> I've updated the code in a way which should make both compilers satisfied,
> but I'd like to know if we are using an unsupported version of MSVC or
> something.
>
> cheers,
> pl
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb] r296717 - Fix various warnings. NFC

2017-03-02 Thread Pavel Labath via lldb-commits 
FAILED: C:\PROGRA~2\MICROS~3.0\VC\bin\cl.exe   /nologo /TP
-DGTEST_HAS_RTTI=0 -DLLDB_DISABLE_CURSES -DLLDB_DISABLE_LIBEDIT
-DLLDB_PYTHON_HOME=\"C:/Users/lldb_build/ll/prebuilts/python-2015/x86\"
-DLLDB_USE_BUILTIN_DEMANGLER -DLLVM_BUILD_GLOBAL_ISEL -DUNICODE
-D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NONSTDC_NO_WARNINGS
-D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS
-D_FILE_OFFSET_BITS=64 -D_HAS_EXCEPTIONS=0 -D_LARGEFILE_SOURCE
-D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -D_UNICODE
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-Itools\lldb\source\Commands
-IC:\lldbSlave\lldb-win7-android\llvm\tools\lldb\source\Commands
-IC:\lldbSlave\lldb-win7-android\llvm\tools\lldb\include
-Itools\lldb\include -Iinclude
-IC:\lldbSlave\lldb-win7-android\llvm\include
-IC:\Users\lldb_build\ll\prebuilts\python-2015\x86\Include
-IC:\lldbSlave\lldb-win7-android\llvm\tools\clang\include
-Itools\lldb\..\clang\include
-IC:\lldbSlave\lldb-win7-android\llvm\tools\lldb\source\. /DWIN32
/D_WINDOWS   /W4 -wd4141 -wd4146 -wd4180 -wd4244 -wd4258 -wd4267
-wd4291 -wd4345 -wd4351 -wd4355 -wd4456 -wd4457 -wd4458 -wd4459
-wd4503 -wd4624 -wd4722 -wd4800 -wd4100 -wd4127 -wd4512 -wd4505
-wd4610 -wd4510 -wd4702 -wd4245 -wd4706 -wd4310 -wd4701 -wd4703
-wd4389 -wd4611 -wd4805 -wd4204 -wd4577 -wd4091 -wd4592 -wd4319
-wd4324 -w14062 -we4238 /Zc:inline /Zc:strictStrings /Oi
/Zc:rvalueCast /MD /O2 /Ob2 /D NDEBUG   -wd4018 -wd4068 -wd4150
-wd4251 -wd4521 -wd4530  /EHs-c- /GR- /showIncludes
/Fotools\lldb\source\Commands\CMakeFiles\lldbCommands.dir\CommandObjectFrame.cpp.obj
/Fdtools\lldb\source\Commands\CMakeFiles\lldbCommands.dir\ /FS -c
C:\lldbSlave\lldb-win7-android\llvm\tools\lldb\source\Commands\CommandObjectFrame.cpp
C:\lldbSlave\lldb-win7-android\llvm\tools\lldb\source\Commands\CommandObjectFrame.cpp(202):
error C3493: 'qualify_cxx_base_classes' cannot be implicitly captured
because no default capture mode has been specified
ninja: build stopped: subcommand failed.


Basically, clang and gcc are perfectly happy with you referencing a
const variable (maybe it has to be of integral type) from a lambda
without an explicit capture (a behavior which actually quite surprises
me), but MSVC chokes on that.

The compiler is MSCV 2015, but I don't know which update. This is its
ident string, if that means anything to you:
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.23506 for x86



On 2 March 2017 at 15:18, Zachary Turner  wrote:
> What capture does it say is missing? Also what version of msvc?
>
> On Thu, Mar 2, 2017 at 7:17 AM Zachary Turner  wrote:
>>
>> Clang-cl
>> On Thu, Mar 2, 2017 at 2:51 AM Pavel Labath  wrote:
>>>
>>>
>>> On 2 March 2017 at 00:05, Zachary Turner via lldb-commits
>>>  wrote:

 -DumpValueObjectOptions::DeclPrintingHelper helper =
 -[&valobj_sp, qualify_cxx_base_classes](
 -ConstString type, ConstString var,
 -const DumpValueObjectOptions &opts, Stream &stream) -> bool
 {
 +DumpValueObjectOptions::DeclPrintingHelper helper = [&valobj_sp](
 +ConstString type, ConstString var, const DumpValueObjectOptions
 &opts,
 +Stream &stream) -> bool {
const ValueObject::GetExpressionPathFormat format = ValueObject::
>>>
>>>
>>> Hi Zach,
>>>
>>> what's the compiler that was giving you this warning. The version of MSVC
>>> I am using is complaining about a missing capture when you removed this.
>>>
>>> I've updated the code in a way which should make both compilers
>>> satisfied, but I'd like to know if we are using an unsupported version of
>>> MSVC or something.
>>>
>>> cheers,
>>> pl
>>>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb] r296717 - Fix various warnings. NFC

2017-03-02 Thread Zachary Turner via lldb-commits 
Interesting. Another workaround is probably to make it constexpr
On Thu, Mar 2, 2017 at 7:50 AM Pavel Labath  wrote:

> FAILED: C:\PROGRA~2\MICROS~3.0\VC\bin\cl.exe   /nologo /TP
> -DGTEST_HAS_RTTI=0 -DLLDB_DISABLE_CURSES -DLLDB_DISABLE_LIBEDIT
> -DLLDB_PYTHON_HOME=\"C:/Users/lldb_build/ll/prebuilts/python-2015/x86\"
> -DLLDB_USE_BUILTIN_DEMANGLER -DLLVM_BUILD_GLOBAL_ISEL -DUNICODE
> -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NONSTDC_NO_WARNINGS
> -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS
> -D_FILE_OFFSET_BITS=64 -D_HAS_EXCEPTIONS=0 -D_LARGEFILE_SOURCE
> -D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -D_UNICODE
> -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
> -Itools\lldb\source\Commands
> -IC:\lldbSlave\lldb-win7-android\llvm\tools\lldb\source\Commands
> -IC:\lldbSlave\lldb-win7-android\llvm\tools\lldb\include
> -Itools\lldb\include -Iinclude
> -IC:\lldbSlave\lldb-win7-android\llvm\include
> -IC:\Users\lldb_build\ll\prebuilts\python-2015\x86\Include
> -IC:\lldbSlave\lldb-win7-android\llvm\tools\clang\include
> -Itools\lldb\..\clang\include
> -IC:\lldbSlave\lldb-win7-android\llvm\tools\lldb\source\. /DWIN32
> /D_WINDOWS   /W4 -wd4141 -wd4146 -wd4180 -wd4244 -wd4258 -wd4267
> -wd4291 -wd4345 -wd4351 -wd4355 -wd4456 -wd4457 -wd4458 -wd4459
> -wd4503 -wd4624 -wd4722 -wd4800 -wd4100 -wd4127 -wd4512 -wd4505
> -wd4610 -wd4510 -wd4702 -wd4245 -wd4706 -wd4310 -wd4701 -wd4703
> -wd4389 -wd4611 -wd4805 -wd4204 -wd4577 -wd4091 -wd4592 -wd4319
> -wd4324 -w14062 -we4238 /Zc:inline /Zc:strictStrings /Oi
> /Zc:rvalueCast /MD /O2 /Ob2 /D NDEBUG   -wd4018 -wd4068 -wd4150
> -wd4251 -wd4521 -wd4530  /EHs-c- /GR- /showIncludes
>
> /Fotools\lldb\source\Commands\CMakeFiles\lldbCommands.dir\CommandObjectFrame.cpp.obj
> /Fdtools\lldb\source\Commands\CMakeFiles\lldbCommands.dir\ /FS -c
>
> C:\lldbSlave\lldb-win7-android\llvm\tools\lldb\source\Commands\CommandObjectFrame.cpp
>
> C:\lldbSlave\lldb-win7-android\llvm\tools\lldb\source\Commands\CommandObjectFrame.cpp(202):
> error C3493: 'qualify_cxx_base_classes' cannot be implicitly captured
> because no default capture mode has been specified
> ninja: build stopped: subcommand failed.
>
>
> Basically, clang and gcc are perfectly happy with you referencing a
> const variable (maybe it has to be of integral type) from a lambda
> without an explicit capture (a behavior which actually quite surprises
> me), but MSVC chokes on that.
>
> The compiler is MSCV 2015, but I don't know which update. This is its
> ident string, if that means anything to you:
> Microsoft (R) C/C++ Optimizing Compiler Version 19.00.23506 for x86
>
>
>
> On 2 March 2017 at 15:18, Zachary Turner  wrote:
> > What capture does it say is missing? Also what version of msvc?
> >
> > On Thu, Mar 2, 2017 at 7:17 AM Zachary Turner 
> wrote:
> >>
> >> Clang-cl
> >> On Thu, Mar 2, 2017 at 2:51 AM Pavel Labath  wrote:
> >>>
> >>>
> >>> On 2 March 2017 at 00:05, Zachary Turner via lldb-commits
> >>>  wrote:
> 
>  -DumpValueObjectOptions::DeclPrintingHelper helper =
>  -[&valobj_sp, qualify_cxx_base_classes](
>  -ConstString type, ConstString var,
>  -const DumpValueObjectOptions &opts, Stream &stream) ->
> bool
>  {
>  +DumpValueObjectOptions::DeclPrintingHelper helper = [&valobj_sp](
>  +ConstString type, ConstString var, const
> DumpValueObjectOptions
>  &opts,
>  +Stream &stream) -> bool {
> const ValueObject::GetExpressionPathFormat format =
> ValueObject::
> >>>
> >>>
> >>> Hi Zach,
> >>>
> >>> what's the compiler that was giving you this warning. The version of
> MSVC
> >>> I am using is complaining about a missing capture when you removed
> this.
> >>>
> >>> I've updated the code in a way which should make both compilers
> >>> satisfied, but I'd like to know if we are using an unsupported version
> of
> >>> MSVC or something.
> >>>
> >>> cheers,
> >>> pl
> >>>
> >
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D30520: Make LLDB skip server-client roundtrip for signals that don't require any actions

2017-03-02 Thread Jim Ingham via Phabricator via lldb-commits 
jingham added a comment.

Note that ProcessGDBRemote (or maybe the client) keeps a history array of 
packets sent.  Greg added that long ago so that when you enabled the packet log 
you would get the packet history up to the time you enabled it, and not just 
the new packets.  That has often come  in quite handy.  And having a SB API 
like:

bool SBProcess::HasRemoteTrafficLog();
SBStringList SBProcess::DumpRemoteTraffic();

doesn't seem like a bad API.  I could imagine some really horribly geeky 
debugger UI that would want to have a packet traffic window.  Then using the 
checkpoint, you could get the strings from event to event and look for the 
packets you expected.  That seems a lot of work for testing this bit of code, 
however.

Short of that, Pavel's last suggestion seems right for testing that the  
contents of the Process's m_unix_signals_sp is correctly copied into the ignore 
signals packet you are going to send.  The higher level tests already ensure 
that we are correctly filling m_unix_signals_sp from commands or SB API's, but 
this last step is uncovered.  So if you move the API to the communication 
client, and pass in the signals, you can then test that last step in isolation. 
 And it seems perfectly reasonable for the Communication client to be doing the 
actual work of copying the signals over.

Another bit that isn't tested is that if you change the signals in the process, 
you will trigger resending the packet.  You could test more of this path if:

(a) you had the UnixSignals class be the one that returns the array of signals 
to ignore rather than it being freestanding logic in the ProcessGDBRemote 
class; the bit of logic that checks pass, stop & notify seems more appropriate 
in the signals class anyway.

(b) change the m_last_signals_version logic to a "HasChanged" and 
"SetHasChanged(bool changed)" API vended by UnixSignals. SetHasChanged would be 
called passing false in the Process::SendSignalsToIgnoreIfNeeded, that seems 
pretty clearly right.  And you probably have to call SetHasChanged(true) to 
force things for the launch case, but that should be straightforward.

Then you could test all most of the chain by making your own UnixSignals and 
passing that to the GDBRemoteCommunicationClient.  If you change it and pass it 
in again, you could ensure that the right packet is sent.  That leave out that 
Process handles the SetHasChanged properly but it gets pretty close.


https://reviews.llvm.org/D30520



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

[Lldb-commits] [lldb] r296814 - Added a list of outstanding projects that would benefit lldb.

2017-03-02 Thread Jim Ingham via lldb-commits 
Author: jingham
Date: Thu Mar  2 15:39:27 2017
New Revision: 296814

URL: http://llvm.org/viewvc/llvm-project?rev=296814&view=rev
Log:
Added a list of outstanding projects that would benefit lldb.

This was a list that I've had kicking around for a while, and would 
add to whenever some hallway conversation would bring up another good
idea.  It's not doing any good on my desktop, but it might generate
some inspiration here.  Please add to this if you have any other
good ideas.

I apologize for the formatting, but if I wait to get it looking
nice it would probably stay on my desktop.

Added:
lldb/trunk/www/projects.html   (with props)
Modified:
lldb/trunk/www/sidebar.incl

Added: lldb/trunk/www/projects.html
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/www/projects.html?rev=296814&view=auto
==
--- lldb/trunk/www/projects.html (added)
+++ lldb/trunk/www/projects.html Thu Mar  2 15:39:27 2017
@@ -0,0 +1,379 @@
+http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
+http://www.w3.org/1999/xhtml";>
+
+
+
+LLDB Projects
+
+
+
+
+  Project ideas for the LLDB Debugger
+
+
+
+   
+ 
+   
+   
+   Goals
+   
+
+ The following is a mostly 
unordered set of the ideas for improvements
+to the LLDB debugger.  Some are 
fairly deep, some would require less 
+effort.
+
+
+ 
+
+  Speed up type realization in 
lldb.  
+  
+The type of problem I'm 
addressing here is the situation where you are 
+debugging a large program 
(lldb built with debug clang/swift will do) 
+and you go to print a simple 
expression, and lldb goes away for 30 seconds.  
+When you sample it, it is 
always busily churning through all the CU's in the
+world looking for something.  
The problem isn't that looking for something in 
+particular is slow, but rather 
that we somehow turned an bounded search 
+(maybe a subtype of 
"std::string" into an unbounded search (all things with the 
+name of that subtype.)  Or 
didn't stop when we got a reasonable answer 
+proximate to the context of 
the search, but let the search leak out globally. 
+And quite likely there are 
other issues that I haven't guessed yet. 
+But if you end up churning 
though 3 or 4 Gig of debug info, that's going to be slow 
+no matter how well written 
your debug reader is...
+  
+  
+My guess is the work will be 
more in the general symbol lookup than in the DWARF 
+parser in particular, but it 
may be a combination of both.
+  
+  
+As a user debugging a largish 
program, this is the most obvious lameness of lldb.
+  
+
+
+
+  Symbol name completion in the 
expression parser.
+  
+  This is the other obvious 
lameness of lldb.  You can do:
+  
+
+(lldb) frame var foo.b
+
+  
+and we will tell you it is 
"foo.bar".  But you can't do that in the expression parser. 
+This will require 
collaboration with the clang/swift folks to get the right extension 
+points in the compiler. And 
whatever they are, lldb will need use them to tell the 
+compiler about what names are 
available.  It will be important to avoid the pitfalls 
+

[Lldb-commits] [lldb] r296816 - Goals->Projects.

2017-03-02 Thread Jim Ingham via lldb-commits 
Author: jingham
Date: Thu Mar  2 15:42:00 2017
New Revision: 296816

URL: http://llvm.org/viewvc/llvm-project?rev=296816&view=rev
Log:
Goals->Projects.

Modified:
lldb/trunk/www/projects.html

Modified: lldb/trunk/www/projects.html
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/www/projects.html?rev=296816&r1=296815&r2=296816&view=diff
==
--- lldb/trunk/www/projects.html (original)
+++ lldb/trunk/www/projects.html Thu Mar  2 15:42:00 2017
@@ -16,7 +16,7 @@
  


-   Goals
+   Projects

 
  The following is a mostly 
unordered set of the ideas for improvements


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

Re: [Lldb-commits] [lldb] r296814 - Added a list of outstanding projects that would benefit lldb.

2017-03-02 Thread Zachary Turner via lldb-commits 
Nice list, thanks!

On Thu, Mar 2, 2017 at 1:51 PM Jim Ingham via lldb-commits <
lldb-commits@lists.llvm.org> wrote:

> Author: jingham
> Date: Thu Mar  2 15:39:27 2017
> New Revision: 296814
>
> URL: http://llvm.org/viewvc/llvm-project?rev=296814&view=rev
> Log:
> Added a list of outstanding projects that would benefit lldb.
>
> This was a list that I've had kicking around for a while, and would
> add to whenever some hallway conversation would bring up another good
> idea.  It's not doing any good on my desktop, but it might generate
> some inspiration here.  Please add to this if you have any other
> good ideas.
>
> I apologize for the formatting, but if I wait to get it looking
> nice it would probably stay on my desktop.
>
> Added:
> lldb/trunk/www/projects.html   (with props)
> Modified:
> lldb/trunk/www/sidebar.incl
>
> Added: lldb/trunk/www/projects.html
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/www/projects.html?rev=296814&view=auto
>
> ==
> --- lldb/trunk/www/projects.html (added)
> +++ lldb/trunk/www/projects.html Thu Mar  2 15:39:27 2017
> @@ -0,0 +1,379 @@
> + http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
> +http://www.w3.org/1999/xhtml";>
> +
> +
> +
> +LLDB Projects
> +
> +
> +
> +
> +  Project ideas for the LLDB Debugger
> +
> +
> +
> +   
> + 
> +   
> +   
> +   Goals
> +   
> +
> + The following is a mostly
> unordered set of the ideas for improvements
> +to the LLDB debugger.  Some
> are fairly deep, some would require less
> +effort.
> +
> +
> + 
> +
> +  Speed up type realization
> in lldb.
> +  
> +The type of problem I'm
> addressing here is the situation where you are
> +debugging a large program
> (lldb built with debug clang/swift will do)
> +and you go to print a
> simple expression, and lldb goes away for 30 seconds.
> +When you sample it, it is
> always busily churning through all the CU's in the
> +world looking for
> something.  The problem isn't that looking for something in
> +particular is slow, but
> rather that we somehow turned an bounded search
> +(maybe a subtype of
> "std::string" into an unbounded search (all things with the
> +name of that subtype.)
>  Or didn't stop when we got a reasonable answer
> +proximate to the context
> of the search, but let the search leak out globally.
> +And quite likely there
> are other issues that I haven't guessed yet.
> +But if you end up
> churning though 3 or 4 Gig of debug info, that's going to be slow
> +no matter how well
> written your debug reader is...
> +  
> +  
> +My guess is the work will
> be more in the general symbol lookup than in the DWARF
> +parser in particular, but
> it may be a combination of both.
> +  
> +  
> +As a user debugging a
> largish program, this is the most obvious lameness of lldb.
> +  
> +
> +
> +
> +  Symbol name completion in
> the expression parser.
> +  
> +  This is the other obvious
> lameness of lldb.  You can do:
> +  
> +
> +(lldb) frame var foo.b
> +
> +  
> +and we will tell you it
> is "foo.bar".  But you can't do that in the expression parser.
> +This will require
> collaboration with the clang/swift folks t

[Lldb-commits] [lldb] r296819 - Add a reference to the projects in the Get involved section.

2017-03-02 Thread Jim Ingham via lldb-commits 
Author: jingham
Date: Thu Mar  2 15:45:39 2017
New Revision: 296819

URL: http://llvm.org/viewvc/llvm-project?rev=296819&view=rev
Log:
Add a reference to the projects in the Get involved section.

Modified:
lldb/trunk/www/index.html

Modified: lldb/trunk/www/index.html
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/www/index.html?rev=296819&r1=296818&r2=296819&view=diff
==
--- lldb/trunk/www/index.html (original)
+++ lldb/trunk/www/index.html Thu Mar  2 15:45:39 2017
@@ -126,6 +126,8 @@
http://lists.llvm.org/mailman/listinfo/lldb-commits";>lldb-commits
mailing list, and this is also the 
preferred mailing list for patch
submissions.
+See the Projects page if you are looking for some interesting 
areas to contribute 
+  to lldb.





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

[Lldb-commits] [lldb] r296826 - Forgot about local variable lookup.

2017-03-02 Thread Jim Ingham via lldb-commits 
Author: jingham
Date: Thu Mar  2 16:04:05 2017
New Revision: 296826

URL: http://llvm.org/viewvc/llvm-project?rev=296826&view=rev
Log:
Forgot about local variable lookup.  

Yay for coffee lines.

Modified:
lldb/trunk/www/projects.html

Modified: lldb/trunk/www/projects.html
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/www/projects.html?rev=296826&r1=296825&r2=296826&view=diff
==
--- lldb/trunk/www/projects.html (original)
+++ lldb/trunk/www/projects.html Thu Mar  2 16:04:05 2017
@@ -86,6 +86,24 @@
 
 
 
+  Fix local variable lookup in the 
lldb expression parser.
+
+  
+The injection of local 
variables into the clang expression parser is 
+currently done incorrectly - 
it happens too late in the lookup.  This results
+in namespace variables & 
functions, same named types and ivars shadowing 
+locals when it should be the 
other way around.  An attempt was made to fix
+this by manually inserting all 
the visible local variables into wrapper function
+in the expression text.  This 
mostly gets the job done but that method 
+means you have to realize all 
the types
+and locations of all local 
variables for even the simplest of expressions, and
+when run on large programs 
(e.g. lldb) it would cause unacceptable delays.  And
+it was very fragile since an 
error in realizing any of the locals would cause
+all expressions run in that 
context to fail.  We need to fix this by adjusting
+the points where name lookup 
calls out to lldb in clang.
+  
+
+
   Fix the event handling/process 
control machinery to support calling SB & Commands 
   everywhere, and to support 
non-stop debugging
   


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

[Lldb-commits] [lldb] r296833 - Mention fetching thread lists lazily.

2017-03-02 Thread Jim Ingham via lldb-commits 
Author: jingham
Date: Thu Mar  2 16:13:45 2017
New Revision: 296833

URL: http://llvm.org/viewvc/llvm-project?rev=296833&view=rev
Log:
Mention fetching thread lists lazily.

Modified:
lldb/trunk/www/projects.html

Modified: lldb/trunk/www/projects.html
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/www/projects.html?rev=296833&r1=296832&r2=296833&view=diff
==
--- lldb/trunk/www/projects.html (original)
+++ lldb/trunk/www/projects.html Thu Mar  2 16:13:45 2017
@@ -200,6 +200,24 @@
 
 
 
+  Recover thread information lazily
+  
+LLDB stores all the user 
intentions for a thread in the ThreadPlans stored in 
+the Thread class.  That allows 
us to reliably implement a very natural model for
+users moving through a debug 
session.  For example, if step-over stops at a breakpoint
+in an function in a younger 
region of the stack, continue will complete the step-over
+rather than having to manually 
step out.  But that means that it is important that
+the Thread objects live as 
long as the Threads they represent.  For programs with many
+threads, but only one that you 
are debugging, that makes stepping less efficient,
+since now you have to fetch 
the thread list on every step or stepping doesn't work
+correctly.  This is especially 
an issue when the threads are provided by an
+Operating System plugin, where 
it may take non-trivial work to reconstruct the 
+thread list.  It would be 
better to fetch threads lazily but keep "unseen" threads in 
+a holding area, and only 
retire them when we know we've fetched the whole thread list
+and ensured they are no longer 
alive.
+  
+
+
   Add an extension point in the 
breakpoint search machinery.
   
 This would allow highly 
customizable, algorithmic breakpoint types, like "break on every 


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

[Lldb-commits] [lldb] r296834 - Python commands as first class citizens.

2017-03-02 Thread Jim Ingham via lldb-commits 
Author: jingham
Date: Thu Mar  2 16:24:01 2017
New Revision: 296834

URL: http://llvm.org/viewvc/llvm-project?rev=296834&view=rev
Log:
Python commands as first class citizens.

This should be a necessary precursor to adding support 
for any future extension languages.

Modified:
lldb/trunk/www/projects.html

Modified: lldb/trunk/www/projects.html
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/www/projects.html?rev=296834&r1=296833&r2=296834&view=diff
==
--- lldb/trunk/www/projects.html (original)
+++ lldb/trunk/www/projects.html Thu Mar  2 16:24:01 2017
@@ -198,7 +198,7 @@
   SomeVectorLikeType that it gets 
from the synthetic children.
   
 
-
+
 
   Recover thread information lazily
   
@@ -224,6 +224,24 @@
 use of some particular 
instruction, or instruction pattern, etc."
   
 
+
+
+  Make Python-backed commands 
first class citizens
+  
+As it stands, Python commands 
have no way to advertise their options.  They are
+required to parse their 
arguments by hand.  That leads to inconsistency, and more
+importantly means they can't 
take advantage of auto-generated help and command
+completion.  This leaves 
python-backed commands feeling worse than built-in ones.
+  
+  
+As part of this job, it would 
also be great to hook automatically hook the "type" of an option value
+or argument (e.g. 
eArgTypeShlibName) to sensible default completers.  You need to be able to
+over-ride this in more 
complicated scenarios (like in "break set" where the presence of
+a "-s" option limits the 
search for completion of a "-n" option.)  But in common cases it is
+unnecessary busy-work to have 
to supply the completer AND the type.  If this worked, then 
+it would be easier for Python 
commands to also get correct completers.
+  
+
 
 
   Documentation and better examples


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

[Lldb-commits] [PATCH] D30520: Make LLDB skip server-client roundtrip for signals that don't require any actions

2017-03-02 Thread Eugene Zemtsov via Phabricator via lldb-commits 
eugene updated this revision to Diff 90407.
eugene added a comment.

Addressing code review commends, and moving a signal filtering method to the 
base Process class.


https://reviews.llvm.org/D30520

Files:
  include/lldb/Target/Process.h
  include/lldb/Target/UnixSignals.h
  source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
  source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h
  source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
  source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
  source/Target/Process.cpp
  source/Target/UnixSignals.cpp
  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
@@ -314,3 +314,27 @@
   << ss.GetString();
   ASSERT_EQ(10, num_packets);
 }
+
+TEST_F(GDBRemoteCommunicationClientTest, SendSignalsToIgnore) {
+  TestClient client;
+  MockServer server;
+  Connect(client, server);
+  if (HasFailure())
+return;
+
+  const lldb::tid_t tid = 0x47;
+  const uint32_t reg_num = 4;
+  std::future result = std::async(std::launch::async, [&] {
+return client.SendSignalsToIgnore({2, 3, 5, 7, 0xB, 0xD, 0x11});
+  });
+
+  HandlePacket(server, "QPassSignals:02;03;05;07;0b;0d;11", "OK");
+  EXPECT_TRUE(result.get().Success());
+
+  result = std::async(std::launch::async, [&] {
+return client.SendSignalsToIgnore(std::vector());
+  });
+
+  HandlePacket(server, "QPassSignals:", "OK");
+  EXPECT_TRUE(result.get().Success());
+}
Index: source/Target/UnixSignals.cpp
===
--- source/Target/UnixSignals.cpp
+++ source/Target/UnixSignals.cpp
@@ -123,12 +123,14 @@
   Signal new_signal(name, default_suppress, default_stop, default_notify,
 description, alias);
   m_signals.insert(std::make_pair(signo, new_signal));
+  ++m_version;
 }
 
 void UnixSignals::RemoveSignal(int signo) {
   collection::iterator pos = m_signals.find(signo);
   if (pos != m_signals.end())
 m_signals.erase(pos);
+  ++m_version;
 }
 
 const char *UnixSignals::GetSignalAsCString(int signo) const {
@@ -217,6 +219,7 @@
   collection::iterator pos = m_signals.find(signo);
   if (pos != m_signals.end()) {
 pos->second.m_suppress = value;
+++m_version;
 return true;
   }
   return false;
@@ -240,6 +243,7 @@
   collection::iterator pos = m_signals.find(signo);
   if (pos != m_signals.end()) {
 pos->second.m_stop = value;
+++m_version;
 return true;
   }
   return false;
@@ -263,6 +267,7 @@
   collection::iterator pos = m_signals.find(signo);
   if (pos != m_signals.end()) {
 pos->second.m_notify = value;
+++m_version;
 return true;
   }
   return false;
@@ -284,3 +289,5 @@
   std::advance(it, index);
   return it->first;
 }
+
+uint64_t UnixSignals::GetVersion() const { return m_version; }
Index: source/Target/Process.cpp
===
--- source/Target/Process.cpp
+++ source/Target/Process.cpp
@@ -1621,6 +1621,13 @@
   return PrivateResume();
 }
 
+Error Process::WillResume() {
+  UpdateAutomaticSignalFiltering();
+  return Error();
+}
+
+void Process::DidLaunch() { UpdateAutomaticSignalFiltering(); }
+
 Error Process::ResumeSynchronous(Stream *stream) {
   Log *log(lldb_private::GetLogIfAnyCategoriesSet(LIBLLDB_LOG_STATE |
   LIBLLDB_LOG_PROCESS));
@@ -6217,3 +6224,9 @@
   find_it->second->HandleArrivalOfStructuredData(*this, type_name, object_sp);
   return true;
 }
+
+Error Process::UpdateAutomaticSignalFiltering() {
+  // Default implementation does nothign.
+  // No automatic signal filtering to speak of.
+  return Error();
+}
Index: source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
===
--- source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
+++ source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
@@ -397,12 +397,15 @@
  lldb::addr_t base_addr,
  bool value_is_offset);
 
+  Error UpdateAutomaticSignalFiltering() override;
+
 private:
   //--
   // For ProcessGDBRemote only
   //--
   std::string m_partial_profile_data;
   std::map m_thread_id_to_used_usec_map;
+  uint64_t m_last_signals_version = 0;
 
   static bool NewThreadNotifyBreakpointHit(void *baton,
StoppointCallbackContext *context,
Index: source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
===
--- source/Plugins/Process/gdb-remote/ProcessGD

[Lldb-commits] [PATCH] D30520: Make LLDB skip server-client roundtrip for signals that don't require any actions

2017-03-02 Thread Jim Ingham via Phabricator via lldb-commits 
jingham added a comment.

I added a few comments.  It doesn't look like you addressed Pavel's idea for 
testing more of the code path you're introducing.  Do you plan to do that?




Comment at: source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp:3766-3776
+  llvm::SmallVector signals_to_ignore;
+  int32_t signo = m_unix_signals_sp->GetFirstSignalNumber();
+  while (signo != LLDB_INVALID_SIGNAL_NUMBER) {
+bool should_ignore = !m_unix_signals_sp->GetShouldStop(signo) &&
+ !m_unix_signals_sp->GetShouldNotify(signo) &&
+ !m_unix_signals_sp->GetShouldSuppress(signo);
+

This code should go into the UnixSignals class.  Any other Process plugin that 
wanted to implement expedited signal handling would also have to do this 
computation, and we shouldn't duplicate the code.



Comment at: source/Target/Process.cpp:1629-1630
+
+void Process::DidLaunch() { UpdateAutomaticSignalFiltering(); }
+
 Error Process::ResumeSynchronous(Stream *stream) {

For this to work, you are relying on the Constructor of the signals class to 
set up the object by calling AddSignal on all the signals.  Otherwise initially 
m_version in the signals class and m_last_signal_version will start out at 0 
and you won't prime the filtering here.

You should probably add a comment to that effect somewhere in UnixSignals so we 
don't forget this dependency.


https://reviews.llvm.org/D30520



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

[Lldb-commits] [PATCH] D30560: Split DataExtractor into two classes.

2017-03-02 Thread Jim Ingham via Phabricator via lldb-commits 
jingham added a comment.

Is it horrible of me to ask that we choose a name that is more descriptive than 
DataExtractorEx?  That "Ex" extension to a class name is just such a punt, and 
I'd really rather not encourage it.

The subclass you made adds the ability to:

(a) Dump itself
(b) Extract some Dwarf EH Frame specific bits.

And (b) is only used in DwarfCallFrameInfo.cpp,

So it would be clearer to make a class that just does (a) and call it 
DataExtractorDumpable.

Then you could have a local class override (like DataExtractorEH) to 
DwarfCallFrameInfo that adds the GetGNUEHPointer.  That latter seems awfully 
specific, and probably doesn't need to be sitting out in the general world.  It 
certainly doesn't need to be riding along all the dumpable data extractors.


https://reviews.llvm.org/D30560



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

Re: [Lldb-commits] [PATCH] D30560: Split DataExtractor into two classes.

2017-03-02 Thread Zachary Turner via lldb-commits 
Tbh I felt dirty calling it Ex, so thanks for calling me out on it :)

I'll whip up some changes later
On Thu, Mar 2, 2017 at 6:09 PM Jim Ingham via Phabricator <
revi...@reviews.llvm.org> wrote:

> jingham added a comment.
>
> Is it horrible of me to ask that we choose a name that is more descriptive
> than DataExtractorEx?  That "Ex" extension to a class name is just such a
> punt, and I'd really rather not encourage it.
>
> The subclass you made adds the ability to:
>
> (a) Dump itself
> (b) Extract some Dwarf EH Frame specific bits.
>
> And (b) is only used in DwarfCallFrameInfo.cpp,
>
> So it would be clearer to make a class that just does (a) and call it
> DataExtractorDumpable.
>
> Then you could have a local class override (like DataExtractorEH) to
> DwarfCallFrameInfo that adds the GetGNUEHPointer.  That latter seems
> awfully specific, and probably doesn't need to be sitting out in the
> general world.  It certainly doesn't need to be riding along all the
> dumpable data extractors.
>
>
> https://reviews.llvm.org/D30560
>
>
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D30560: Split DataExtractor into two classes.

2017-03-02 Thread Jim Ingham via Phabricator via lldb-commits 
jingham added a comment.

The EH stuff should definitely go in a specific subclass.

It also seems a shame to lose the capability to Dump DataExtractors in general. 
 The only thing the exe_scope is used for in Dump (which is what is causing you 
problems) is to print instructions, and to do a more accurate job of printing 
non-native floats.  It would be best to leave the Dump without these bits in 
the base data extractor, and return an error for the unsupported format kinds, 
and then add a Dump method that takes an exe_scope in the subclass (now 
DataExtractorTargetAware???)


https://reviews.llvm.org/D30560



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

[Lldb-commits] [PATCH] D30520: Make LLDB skip server-client roundtrip for signals that don't require any actions

2017-03-02 Thread Eugene Zemtsov via Phabricator via lldb-commits 
eugene updated this revision to Diff 90424.
eugene marked an inline comment as done.
eugene added a comment.

Added comment to UnixSignals::m_version. 
Still thinking about the best way to test it all.


https://reviews.llvm.org/D30520

Files:
  include/lldb/Target/Process.h
  include/lldb/Target/UnixSignals.h
  source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
  source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h
  source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
  source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
  source/Target/Process.cpp
  source/Target/UnixSignals.cpp
  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
@@ -314,3 +314,27 @@
   << ss.GetString();
   ASSERT_EQ(10, num_packets);
 }
+
+TEST_F(GDBRemoteCommunicationClientTest, SendSignalsToIgnore) {
+  TestClient client;
+  MockServer server;
+  Connect(client, server);
+  if (HasFailure())
+return;
+
+  const lldb::tid_t tid = 0x47;
+  const uint32_t reg_num = 4;
+  std::future result = std::async(std::launch::async, [&] {
+return client.SendSignalsToIgnore({2, 3, 5, 7, 0xB, 0xD, 0x11});
+  });
+
+  HandlePacket(server, "QPassSignals:02;03;05;07;0b;0d;11", "OK");
+  EXPECT_TRUE(result.get().Success());
+
+  result = std::async(std::launch::async, [&] {
+return client.SendSignalsToIgnore(std::vector());
+  });
+
+  HandlePacket(server, "QPassSignals:", "OK");
+  EXPECT_TRUE(result.get().Success());
+}
Index: source/Target/UnixSignals.cpp
===
--- source/Target/UnixSignals.cpp
+++ source/Target/UnixSignals.cpp
@@ -123,12 +123,14 @@
   Signal new_signal(name, default_suppress, default_stop, default_notify,
 description, alias);
   m_signals.insert(std::make_pair(signo, new_signal));
+  ++m_version;
 }
 
 void UnixSignals::RemoveSignal(int signo) {
   collection::iterator pos = m_signals.find(signo);
   if (pos != m_signals.end())
 m_signals.erase(pos);
+  ++m_version;
 }
 
 const char *UnixSignals::GetSignalAsCString(int signo) const {
@@ -217,6 +219,7 @@
   collection::iterator pos = m_signals.find(signo);
   if (pos != m_signals.end()) {
 pos->second.m_suppress = value;
+++m_version;
 return true;
   }
   return false;
@@ -240,6 +243,7 @@
   collection::iterator pos = m_signals.find(signo);
   if (pos != m_signals.end()) {
 pos->second.m_stop = value;
+++m_version;
 return true;
   }
   return false;
@@ -263,6 +267,7 @@
   collection::iterator pos = m_signals.find(signo);
   if (pos != m_signals.end()) {
 pos->second.m_notify = value;
+++m_version;
 return true;
   }
   return false;
@@ -284,3 +289,5 @@
   std::advance(it, index);
   return it->first;
 }
+
+uint64_t UnixSignals::GetVersion() const { return m_version; }
Index: source/Target/Process.cpp
===
--- source/Target/Process.cpp
+++ source/Target/Process.cpp
@@ -1621,6 +1621,15 @@
   return PrivateResume();
 }
 
+Error Process::WillResume() {
+  UpdateAutomaticSignalFiltering();
+  return Error();
+}
+
+void Process::DidLaunch() {
+  UpdateAutomaticSignalFiltering();
+}
+
 Error Process::ResumeSynchronous(Stream *stream) {
   Log *log(lldb_private::GetLogIfAnyCategoriesSet(LIBLLDB_LOG_STATE |
   LIBLLDB_LOG_PROCESS));
@@ -6217,3 +6226,9 @@
   find_it->second->HandleArrivalOfStructuredData(*this, type_name, object_sp);
   return true;
 }
+
+Error Process::UpdateAutomaticSignalFiltering() {
+  // Default implementation does nothign.
+  // No automatic signal filtering to speak of.
+  return Error();
+}
Index: source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
===
--- source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
+++ source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
@@ -397,12 +397,15 @@
  lldb::addr_t base_addr,
  bool value_is_offset);
 
+  Error UpdateAutomaticSignalFiltering() override;
+
 private:
   //--
   // For ProcessGDBRemote only
   //--
   std::string m_partial_profile_data;
   std::map m_thread_id_to_used_usec_map;
+  uint64_t m_last_signals_version = 0;
 
   static bool NewThreadNotifyBreakpointHit(void *baton,
StoppointCallbackContext *context,
Index: source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
===
--- sour

[Lldb-commits] [PATCH] D30520: Make LLDB skip server-client roundtrip for signals that don't require any actions

2017-03-02 Thread Eugene Zemtsov via Phabricator via lldb-commits 
eugene added inline comments.



Comment at: source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp:3766-3776
+  llvm::SmallVector signals_to_ignore;
+  int32_t signo = m_unix_signals_sp->GetFirstSignalNumber();
+  while (signo != LLDB_INVALID_SIGNAL_NUMBER) {
+bool should_ignore = !m_unix_signals_sp->GetShouldStop(signo) &&
+ !m_unix_signals_sp->GetShouldNotify(signo) &&
+ !m_unix_signals_sp->GetShouldSuppress(signo);
+

jingham wrote:
> This code should go into the UnixSignals class.  Any other Process plugin 
> that wanted to implement expedited signal handling would also have to do this 
> computation, and we shouldn't duplicate the code.
I think it would be a mistake to over-engineer it and try to anticipate needs 
of any possible implementation at this point.
Maybe another implementation would require a list of signals that need to be 
stopped instead of ignored. 

Whenever  we have an alternative implementation that needs to do such thins we 
can always go back and generalize this code, as for now I think we need to keep 
things simple. 

I like the concise interface that UnixSignals provides and  I don't want to 
pollute it with things can be easily done in the code that uses it.



Comment at: source/Target/Process.cpp:1629-1630
+
+void Process::DidLaunch() { UpdateAutomaticSignalFiltering(); }
+
 Error Process::ResumeSynchronous(Stream *stream) {

jingham wrote:
> For this to work, you are relying on the Constructor of the signals class to 
> set up the object by calling AddSignal on all the signals.  Otherwise 
> initially m_version in the signals class and m_last_signal_version will start 
> out at 0 and you won't prime the filtering here.
> 
> You should probably add a comment to that effect somewhere in UnixSignals so 
> we don't forget this dependency.
I added a comment to UnixSignals::m_version


https://reviews.llvm.org/D30520



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

Re: [Lldb-commits] [PATCH] D30560: Split DataExtractor into two classes.

2017-03-02 Thread Zachary Turner via lldb-commits 
I was actually thinking of making the dump functions free functions that
take a const DataExtractor&. This way the entire implementation could
remain unchanged with the exception of replacing implicit member variable
reads with reads through an explicit instance of the extractor.

This way we don't lose the ability to dump arbitrary DataExtractors and
don't have to introduce a class for no practical benefit
On Thu, Mar 2, 2017 at 6:45 PM Jim Ingham via Phabricator <
revi...@reviews.llvm.org> wrote:

> jingham added a comment.
>
> The EH stuff should definitely go in a specific subclass.
>
> It also seems a shame to lose the capability to Dump DataExtractors in
> general.  The only thing the exe_scope is used for in Dump (which is what
> is causing you problems) is to print instructions, and to do a more
> accurate job of printing non-native floats.  It would be best to leave the
> Dump without these bits in the base data extractor, and return an error for
> the unsupported format kinds, and then add a Dump method that takes an
> exe_scope in the subclass (now DataExtractorTargetAware???)
>
>
> https://reviews.llvm.org/D30560
>
>
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D30560: Split DataExtractor into two classes.

2017-03-02 Thread Zachary Turner via Phabricator via lldb-commits 
zturner updated this revision to Diff 90432.
zturner added a comment.

I basically turned the two dump methods into free functions and moved the DWARF 
specific function into `DWARFCallFrameInfo.cpp`.  I think this is much better 
than before, as we don't muck with the inheritance hierarchy at all (removes a 
lot of code churn), and the header is very appropriately named.


https://reviews.llvm.org/D30560

Files:
  lldb/include/lldb/Core/DataExtractor.h
  lldb/include/lldb/Core/DumpDataExtractor.h
  lldb/include/lldb/Symbol/CompilerType.h
  lldb/include/lldb/Symbol/DWARFCallFrameInfo.h
  lldb/include/lldb/Symbol/Type.h
  lldb/source/API/SBData.cpp
  lldb/source/Commands/CommandObjectMemory.cpp
  lldb/source/Core/Address.cpp
  lldb/source/Core/CMakeLists.txt
  lldb/source/Core/DataExtractor.cpp
  lldb/source/Core/DumpDataExtractor.cpp
  lldb/source/Core/Event.cpp
  lldb/source/Core/RegisterValue.cpp
  lldb/source/DataFormatters/TypeFormat.cpp
  lldb/source/Expression/Materializer.cpp
  
lldb/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
  lldb/source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp
  lldb/source/Plugins/SymbolFile/DWARF/DWARFDataExtractor.h
  
lldb/source/Plugins/UnwindAssembly/InstEmulation/UnwindAssemblyInstEmulation.cpp
  lldb/source/Symbol/ClangASTContext.cpp
  lldb/source/Symbol/CompilerType.cpp
  lldb/source/Symbol/DWARFCallFrameInfo.cpp
  lldb/source/Symbol/GoASTContext.cpp
  lldb/source/Symbol/JavaASTContext.cpp
  lldb/source/Symbol/OCamlASTContext.cpp

Index: lldb/source/Symbol/OCamlASTContext.cpp
===
--- lldb/source/Symbol/OCamlASTContext.cpp
+++ lldb/source/Symbol/OCamlASTContext.cpp
@@ -9,6 +9,7 @@
 //===--===//
 
 #include "lldb/Symbol/OCamlASTContext.h"
+#include "lldb/Core/DumpDataExtractor.h"
 #include "lldb/Core/Module.h"
 #include "lldb/Core/PluginManager.h"
 #include "lldb/Core/StreamFile.h"
@@ -621,9 +622,9 @@
   }
 
   if (IsScalarType(type)) {
-return data.Dump(s, byte_offset, format, byte_size, 1, SIZE_MAX,
- LLDB_INVALID_ADDRESS, bitfield_bit_size,
- bitfield_bit_offset, exe_scope);
+return dumpDataExtractor(data, s, byte_offset, format, byte_size, 1,
+ SIZE_MAX, LLDB_INVALID_ADDRESS, bitfield_bit_size,
+ bitfield_bit_offset, exe_scope);
   }
 
   return false;
Index: lldb/source/Symbol/JavaASTContext.cpp
===
--- lldb/source/Symbol/JavaASTContext.cpp
+++ lldb/source/Symbol/JavaASTContext.cpp
@@ -10,7 +10,7 @@
 #include 
 
 #include "lldb/Core/ArchSpec.h"
-#include "lldb/Core/DataExtractor.h"
+#include "lldb/Core/DumpDataExtractor.h"
 #include "lldb/Core/Module.h"
 #include "lldb/Core/PluginManager.h"
 #include "lldb/Core/StreamFile.h"
@@ -1004,10 +1004,10 @@
 size_t data_byte_size, uint32_t bitfield_bit_size,
 uint32_t bitfield_bit_offset, ExecutionContextScope *exe_scope) {
   if (IsScalarType(type)) {
-return data.Dump(s, data_offset, format, data_byte_size,
- 1, // count
- UINT32_MAX, LLDB_INVALID_ADDRESS, bitfield_bit_size,
- bitfield_bit_offset, exe_scope);
+return dumpDataExtractor(data, s, data_offset, format, data_byte_size,
+ 1, // count
+ UINT32_MAX, LLDB_INVALID_ADDRESS,
+ bitfield_bit_size, bitfield_bit_offset, exe_scope);
   }
   return false;
 }
Index: lldb/source/Symbol/GoASTContext.cpp
===
--- lldb/source/Symbol/GoASTContext.cpp
+++ lldb/source/Symbol/GoASTContext.cpp
@@ -11,6 +11,7 @@
 #include 
 #include 
 
+#include "lldb/Core/DumpDataExtractor.h"
 #include "lldb/Core/Module.h"
 #include "lldb/Core/PluginManager.h"
 #include "lldb/Core/StreamFile.h"
@@ -1263,9 +1264,9 @@
   byte_size = 4;
   break;
 }
-return data.Dump(s, byte_offset, format, byte_size, item_count, UINT32_MAX,
- LLDB_INVALID_ADDRESS, bitfield_bit_size,
- bitfield_bit_offset, exe_scope);
+return dumpDataExtractor(data, s, byte_offset, format, byte_size,
+ item_count, UINT32_MAX, LLDB_INVALID_ADDRESS,
+ bitfield_bit_size, bitfield_bit_offset, exe_scope);
   }
   return 0;
 }
Index: lldb/source/Symbol/DWARFCallFrameInfo.cpp
===
--- lldb/source/Symbol/DWARFCallFrameInfo.cpp
+++ lldb/source/Symbol/DWARFCallFrameInfo.cpp
@@ -14,8 +14,8 @@
 #include "lldb/Core/ArchSpec.h"
 #include "lldb/Core/Module.h"
 #include "lldb/Core/Section.h"
-#include "lldb/Core/Section.h"
 #include "lldb/Core/Timer.h"
+#include "lldb/Core/dwarf.h"
 #include "lldb/Host/Host.h"
 #inclu

[Lldb-commits] [lldb] r296855 - Remove some dead code in FileSpec.

2017-03-02 Thread Zachary Turner via lldb-commits 
Author: zturner
Date: Fri Mar  3 00:14:38 2017
New Revision: 296855

URL: http://llvm.org/viewvc/llvm-project?rev=296855&view=rev
Log:
Remove some dead code in FileSpec.

This in turn triggered some fallout where other files had
been transitively picking up includes that they needed from
FileSpec.h, so I've fixed those up as well.

Modified:
lldb/trunk/include/lldb/Core/Disassembler.h
lldb/trunk/include/lldb/Core/StringList.h
lldb/trunk/include/lldb/Host/FileCache.h
lldb/trunk/include/lldb/Host/FileSpec.h
lldb/trunk/source/Core/StringList.cpp
lldb/trunk/source/Host/common/FileSpec.cpp
lldb/trunk/source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.h

lldb/trunk/source/Plugins/ObjectContainer/BSD-Archive/ObjectContainerBSDArchive.h
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.h
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugPubnamesSet.h
lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.h
lldb/trunk/source/Plugins/SymbolFile/Symtab/SymbolFileSymtab.h

Modified: lldb/trunk/include/lldb/Core/Disassembler.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/Disassembler.h?rev=296855&r1=296854&r2=296855&view=diff
==
--- lldb/trunk/include/lldb/Core/Disassembler.h (original)
+++ lldb/trunk/include/lldb/Core/Disassembler.h Fri Mar  3 00:14:38 2017
@@ -12,6 +12,8 @@
 
 // C Includes
 // C++ Includes
+#include 
+#include 
 #include 
 #include 
 

Modified: lldb/trunk/include/lldb/Core/StringList.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/StringList.h?rev=296855&r1=296854&r2=296855&view=diff
==
--- lldb/trunk/include/lldb/Core/StringList.h (original)
+++ lldb/trunk/include/lldb/Core/StringList.h Fri Mar  3 00:14:38 2017
@@ -49,8 +49,6 @@ public:
 
   void AppendList(StringList strings);
 
-  bool ReadFileLines(FileSpec &input_file);
-
   size_t GetSize() const;
 
   void SetSize(size_t n) { m_strings.resize(n); }

Modified: lldb/trunk/include/lldb/Host/FileCache.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Host/FileCache.h?rev=296855&r1=296854&r2=296855&view=diff
==
--- lldb/trunk/include/lldb/Host/FileCache.h (original)
+++ lldb/trunk/include/lldb/Host/FileCache.h Fri Mar  3 00:14:38 2017
@@ -9,6 +9,7 @@
 #ifndef liblldb_Host_FileCache_h
 #define liblldb_Host_FileCache_h
 
+#include 
 #include 
 
 #include "lldb/lldb-forward.h"

Modified: lldb/trunk/include/lldb/Host/FileSpec.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Host/FileSpec.h?rev=296855&r1=296854&r2=296855&view=diff
==
--- lldb/trunk/include/lldb/Host/FileSpec.h (original)
+++ lldb/trunk/include/lldb/Host/FileSpec.h Fri Mar  3 00:14:38 2017
@@ -17,7 +17,6 @@
 
 // Other libraries and framework includes
 // Project includes
-#include "lldb/Core/STLUtils.h"
 #include "lldb/Host/PosixApi.h"
 #include "lldb/Utility/ConstString.h"
 #include "lldb/lldb-private.h"
@@ -590,21 +589,6 @@ public:
   void SetIsResolved(bool is_resolved) { m_is_resolved = is_resolved; }
 
   //--
-  /// Read the file into an array of strings, one per line.
-  ///
-  /// Opens and reads the file in this object into an array of strings,
-  /// one string per line of the file. Returns a boolean indicating
-  /// success or failure.
-  ///
-  /// @param[out] lines
-  /// The string array into which to read the file.
-  ///
-  /// @result
-  /// Returns the number of lines that were read from the file.
-  //--
-  size_t ReadFileLines(STLStringArray &lines);
-
-  //--
   /// Resolves user name and links in \a path, and overwrites the input
   /// argument with the resolved path.
   ///

Modified: lldb/trunk/source/Core/StringList.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/StringList.cpp?rev=296855&r1=296854&r2=296855&view=diff
==
--- lldb/trunk/source/Core/StringList.cpp (original)
+++ lldb/trunk/source/Core/StringList.cpp Fri Mar  3 00:14:38 2017
@@ -65,10 +65,6 @@ void StringList::AppendList(StringList s
 m_strings.push_back(strings.GetStringAtIndex(i));
 }
 
-bool StringList::ReadFileLines(FileSpec &input_file) {
-  return input_file.ReadFileLines(m_strings);
-}
-
 size_t StringList::GetSize() const { return m_strings.size(); }
 
 size_t StringList::GetMaxStringLength() const {

Modified: lldb/trunk/source/Host/common/FileSpec.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Host/common/F