[Lldb-commits] [PATCH] D82863: [LLDB] Add support to resize SVE registers at run-time

[Muhammad Omair Javaid via Phabricator via lldb-commits]

omjavaid added a comment.

HI @labath Do you have any comments or suggestions for this patch?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D82863/new/

https://reviews.llvm.org/D82863

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

[Lldb-commits] [PATCH] D89019: Change the default handling of SIGCONT to nostop/noprint

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

I believe we should at least print/notify about the fact that the process has 
received a SIGCONT (like we do with SIGCHLD, which happens a lot more often). 
As for stopping, I don't really have a strong opinion.

One reason for keeping the existing behavior would be compatibility with gdb, 
but that's about all I can think of. The obvious use case for wanting to stop 
on SIGCONT is when you want to debug the job control behavior of some process  
-- e.g., vi (and even lldb) refreshes some state whenever it comes back from 
suspension. But this is not not something that comes up very often, I would 
expect.

Another possibility would be to try to detect these "useless" SIGCONTs and 
ignore them specifically (or just ignore SIGCONTs for the processes that are 
likely to receive them). I believe we had a patch for SIGSEGV and android like 
that at some point (i can't find a trace of it in the source, so I guess it did 
not land). OTOH, SIGSEGVs are not nearly as important as SIGCONT, so maybe a 
blanket ignore on the signal would be ok


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D89019/new/

https://reviews.llvm.org/D89019

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

[Lldb-commits] [PATCH] D88975: [LLDB] On Windows, fix tests

[Pavel Labath via Phabricator via lldb-commits]

labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.

This looks fine. Thanks.




Comment at: lldb/unittests/Utility/StatusTest.cpp:76
+  ULONG langs = 0;
+  ULONG nameLen = sizeof(name) / sizeof(WCHAR);
+  GetUserPreferredUILanguages(MUI_LANGUAGE_NAME, &langs, (PZZWSTR)&name,

llvm::array_lengthof(name);



Comment at: lldb/unittests/Utility/StatusTest.cpp:77
+  ULONG nameLen = sizeof(name) / sizeof(WCHAR);
+  GetUserPreferredUILanguages(MUI_LANGUAGE_NAME, &langs, (PZZWSTR)&name,
+  &nameLen);

reinterpret_cast?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88975/new/

https://reviews.llvm.org/D88975

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

[Lldb-commits] [PATCH] D88387: Create "skinny corefiles" for Mach-O with process save-core / reading

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

/me parachutes into the discussion.

On the topic of interfaces, I'd like to say that eventually I'd like to have 
the ability to choose the format for the core file that lldb generates (so that 
one can generate minidump files on mac or linux). There's no direct 
implications of that for this patch, as the two choices are likely to be 
orthogonal (full or "skinny" minidumps make sense too), it would just be good 
to leave room for this extension in the future (e.g. in the SB API).

As for the flag discussion, it might be interesting to note that the linux 
coredump_filter is a set of flags

  bit 0  Dump anonymous private mappings.
  bit 1  Dump anonymous shared mappings.
  bit 2  Dump file-backed private mappings.
  bit 3  Dump file-backed shared mappings.
  bit 4 (since Linux 2.6.24)
 Dump ELF headers.
  bit 5 (since Linux 2.6.28)
 Dump private huge pages.
  bit 6 (since Linux 2.6.28)
 Dump shared huge pages.
  bit 7 (since Linux 4.4)
 Dump private DAX pages.
  bit 8 (since Linux 4.4)
 Dump shared DAX pages.

I have no plans on doing anything with that, though someone theoretically 
might. However, I think that even if we do have the ability to fine-tune the 
core contents via individual flags, we should probably still have some way to 
select some reasonable set of predefined flags.

Lastly, I think it would be good to extend the `memory region` command to show 
the new MemoryRegionInfo contents. If for nothing else, then to enable the 
testing of this (pretty large) patch in a more granular way. Having this in the 
output of `memory region` would enable splitting the gdb-remote part of this 
into a separate patch.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88387/new/

https://reviews.llvm.org/D88387

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

[Lldb-commits] [PATCH] D88796: [lldb] Initial version of FreeBSD remote process plugin

[Michał Górny via Phabricator via lldb-commits]

mgorny added inline comments.



Comment at: lldb/source/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp:82
 void ProcessFreeBSD::Initialize() {
-  static llvm::once_flag g_once_flag;
+  if (!getenv("FREEBSD_REMOTE_PLUGIN")) {
+static llvm::once_flag g_once_flag;

labath wrote:
> mgorny wrote:
> > labath wrote:
> > > I would expect that the check above is sufficient, is it not?
> > Could you be more specific? I'm pretty sure I had to do this or otherwise 
> > the old plugin ended up being used. This is also how windows does it. 
> Hmm... interesting. But windows does not have the check in PlatformWindows. 
> Does that mean that check is redundant? I find it strange that we need to 
> check this at two places..
That Platform check really means to preserve the old behavior. I don't really 
know whether it is really needed or not, I've presumed this is safer to do.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88796/new/

https://reviews.llvm.org/D88796

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

[Lldb-commits] [lldb] 1a60026 - [lldb] Initial version of FreeBSD remote process plugin

[Michał Górny via lldb-commits]

Author: Michał Górny
Date: 2020-10-08T16:03:00+02:00
New Revision: 1a600266c3ad1193d41ebb08a5a87c00cf726b1b

URL: 
https://github.com/llvm/llvm-project/commit/1a600266c3ad1193d41ebb08a5a87c00cf726b1b
DIFF: 
https://github.com/llvm/llvm-project/commit/1a600266c3ad1193d41ebb08a5a87c00cf726b1b.diff

LOG: [lldb] Initial version of FreeBSD remote process plugin

Add a new FreeBSD Process plugin using client/server model.  This plugin
is based on the one used by NetBSD.  It currently supports a subset
of functionality for amd64.  It is automatically used when spawning
lldb-server.  It can also be used by lldb client by setting
FREEBSD_REMOTE_PLUGIN environment variable (to any value).

The code is capable of debugging simple single-threaded programs.  It
supports general purpose, debug and FPU registers (up to XMM) of amd64,
basic signalling, software breakpoints.

Adding the support for the plugin involves removing some dead code
from FreeBSDPlatform plugin (that was not ever used because
CanDebugProcess() returned false), and replacing it with appropriate
code from NetBSD platform support.

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

Added: 
lldb/source/Plugins/Process/FreeBSDRemote/CMakeLists.txt
lldb/source/Plugins/Process/FreeBSDRemote/NativeProcessFreeBSD.cpp
lldb/source/Plugins/Process/FreeBSDRemote/NativeProcessFreeBSD.h
lldb/source/Plugins/Process/FreeBSDRemote/NativeRegisterContextFreeBSD.cpp
lldb/source/Plugins/Process/FreeBSDRemote/NativeRegisterContextFreeBSD.h

lldb/source/Plugins/Process/FreeBSDRemote/NativeRegisterContextFreeBSD_x86_64.cpp

lldb/source/Plugins/Process/FreeBSDRemote/NativeRegisterContextFreeBSD_x86_64.h
lldb/source/Plugins/Process/FreeBSDRemote/NativeThreadFreeBSD.cpp
lldb/source/Plugins/Process/FreeBSDRemote/NativeThreadFreeBSD.h

Modified: 
lldb/source/Plugins/Platform/FreeBSD/PlatformFreeBSD.cpp
lldb/source/Plugins/Platform/FreeBSD/PlatformFreeBSD.h
lldb/source/Plugins/Process/CMakeLists.txt
lldb/source/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp

lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp
lldb/test/Shell/lit.cfg.py
lldb/tools/lldb-server/CMakeLists.txt
lldb/tools/lldb-server/lldb-gdbserver.cpp

Removed: 




diff  --git a/lldb/source/Plugins/Platform/FreeBSD/PlatformFreeBSD.cpp 
b/lldb/source/Plugins/Platform/FreeBSD/PlatformFreeBSD.cpp
index 97c2f22b505f..7318264c554b 100644
--- a/lldb/source/Plugins/Platform/FreeBSD/PlatformFreeBSD.cpp
+++ b/lldb/source/Plugins/Platform/FreeBSD/PlatformFreeBSD.cpp
@@ -246,58 +246,15 @@ PlatformFreeBSD::GetSoftwareBreakpointTrapOpcode(Target 
&target,
   }
 }
 
-Status PlatformFreeBSD::LaunchProcess(ProcessLaunchInfo &launch_info) {
-  Status error;
-  if (IsHost()) {
-error = Platform::LaunchProcess(launch_info);
-  } else {
-if (m_remote_platform_sp)
-  error = m_remote_platform_sp->LaunchProcess(launch_info);
-else
-  error.SetErrorString("the platform is not currently connected");
-  }
-  return error;
-}
-
-lldb::ProcessSP PlatformFreeBSD::Attach(ProcessAttachInfo &attach_info,
-Debugger &debugger, Target *target,
-Status &error) {
-  lldb::ProcessSP process_sp;
-  if (IsHost()) {
-if (target == nullptr) {
-  TargetSP new_target_sp;
-  ArchSpec emptyArchSpec;
-
-  error = debugger.GetTargetList().CreateTarget(
-  debugger, "", emptyArchSpec, eLoadDependentsNo, m_remote_platform_sp,
-  new_target_sp);
-  target = new_target_sp.get();
-} else
-  error.Clear();
-
-if (target && error.Success()) {
-  debugger.GetTargetList().SetSelectedTarget(target);
-  // The freebsd always currently uses the GDB remote debugger plug-in so
-  // even when debugging locally we are debugging remotely! Just like the
-  // darwin plugin.
-  process_sp = target->CreateProcess(
-  attach_info.GetListenerForProcess(debugger), "gdb-remote", nullptr);
-
-  if (process_sp)
-error = process_sp->Attach(attach_info);
+bool PlatformFreeBSD::CanDebugProcess() {
+  if (getenv("FREEBSD_REMOTE_PLUGIN")) {
+if (IsHost()) {
+  return true;
+} else {
+  // If we're connected, we can debug.
+  return IsConnected();
 }
-  } else {
-if (m_remote_platform_sp)
-  process_sp =
-  m_remote_platform_sp->Attach(attach_info, debugger, target, error);
-else
-  error.SetErrorString("the platform is not currently connected");
   }
-  return process_sp;
-}
-
-// FreeBSD processes cannot yet be launched by spawning and attaching.
-bool PlatformFreeBSD::CanDebugProcess() {
   return false;
 }
 

diff  --git a/lldb/source/Plugins/Platform/FreeBSD/PlatformFreeBSD.h 
b/lldb/source/Plugins/Platform/FreeBSD/PlatformFreeBSD.h
index 56f2f2771d12..4f3b119c568f 100644
--- a/

[Lldb-commits] [PATCH] D88796: [lldb] Initial version of FreeBSD remote process plugin

[Michał Górny via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG1a600266c3ad: [lldb] Initial version of FreeBSD remote 
process plugin (authored by mgorny).
Herald added a project: LLDB.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88796/new/

https://reviews.llvm.org/D88796

Files:
  lldb/source/Plugins/Platform/FreeBSD/PlatformFreeBSD.cpp
  lldb/source/Plugins/Platform/FreeBSD/PlatformFreeBSD.h
  lldb/source/Plugins/Process/CMakeLists.txt
  lldb/source/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp
  lldb/source/Plugins/Process/FreeBSDRemote/CMakeLists.txt
  lldb/source/Plugins/Process/FreeBSDRemote/NativeProcessFreeBSD.cpp
  lldb/source/Plugins/Process/FreeBSDRemote/NativeProcessFreeBSD.h
  lldb/source/Plugins/Process/FreeBSDRemote/NativeRegisterContextFreeBSD.cpp
  lldb/source/Plugins/Process/FreeBSDRemote/NativeRegisterContextFreeBSD.h
  
lldb/source/Plugins/Process/FreeBSDRemote/NativeRegisterContextFreeBSD_x86_64.cpp
  
lldb/source/Plugins/Process/FreeBSDRemote/NativeRegisterContextFreeBSD_x86_64.h
  lldb/source/Plugins/Process/FreeBSDRemote/NativeThreadFreeBSD.cpp
  lldb/source/Plugins/Process/FreeBSDRemote/NativeThreadFreeBSD.h
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp
  lldb/test/Shell/lit.cfg.py
  lldb/tools/lldb-server/CMakeLists.txt
  lldb/tools/lldb-server/lldb-gdbserver.cpp

Index: lldb/tools/lldb-server/lldb-gdbserver.cpp
===
--- lldb/tools/lldb-server/lldb-gdbserver.cpp
+++ lldb/tools/lldb-server/lldb-gdbserver.cpp
@@ -38,6 +38,8 @@
 
 #if defined(__linux__)
 #include "Plugins/Process/Linux/NativeProcessLinux.h"
+#elif defined(__FreeBSD__)
+#include "Plugins/Process/FreeBSDRemote/NativeProcessFreeBSD.h"
 #elif defined(__NetBSD__)
 #include "Plugins/Process/NetBSD/NativeProcessNetBSD.h"
 #elif defined(_WIN32)
@@ -61,6 +63,8 @@
 namespace {
 #if defined(__linux__)
 typedef process_linux::NativeProcessLinux::Factory NativeProcessFactory;
+#elif defined(__FreeBSD__)
+typedef process_freebsd::NativeProcessFreeBSD::Factory NativeProcessFactory;
 #elif defined(__NetBSD__)
 typedef process_netbsd::NativeProcessNetBSD::Factory NativeProcessFactory;
 #elif defined(_WIN32)
Index: lldb/tools/lldb-server/CMakeLists.txt
===
--- lldb/tools/lldb-server/CMakeLists.txt
+++ lldb/tools/lldb-server/CMakeLists.txt
@@ -4,6 +4,12 @@
   list(APPEND LLDB_PLUGINS lldbPluginProcessLinux)
 endif()
 
+if(CMAKE_SYSTEM_NAME MATCHES "FreeBSD")
+  list(APPEND LLDB_PLUGINS
+lldbPluginProcessFreeBSDRemote
+lldbPluginProcessFreeBSD)
+endif()
+
 if(CMAKE_SYSTEM_NAME MATCHES "NetBSD")
   list(APPEND LLDB_PLUGINS lldbPluginProcessNetBSD)
 endif()
Index: lldb/test/Shell/lit.cfg.py
===
--- lldb/test/Shell/lit.cfg.py
+++ lldb/test/Shell/lit.cfg.py
@@ -133,3 +133,6 @@
 can_set_dbregs = False
 if can_set_dbregs:
 config.available_features.add('dbregs-set')
+
+# pass control variable through
+llvm_config.with_system_environment('FREEBSD_REMOTE_PLUGIN')
Index: lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp
===
--- lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp
+++ lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp
@@ -843,7 +843,7 @@
   response.PutCString(";QListThreadsInStopReply+");
   response.PutCString(";qEcho+");
   response.PutCString(";qXfer:features:read+");
-#if defined(__linux__) || defined(__NetBSD__)
+#if defined(__linux__) || defined(__NetBSD__) || defined(__FreeBSD__)
   response.PutCString(";QPassSignals+");
   response.PutCString(";qXfer:auxv:read+");
   response.PutCString(";qXfer:libraries-svr4:read+");
Index: lldb/source/Plugins/Process/FreeBSDRemote/NativeThreadFreeBSD.h
===
--- /dev/null
+++ lldb/source/Plugins/Process/FreeBSDRemote/NativeThreadFreeBSD.h
@@ -0,0 +1,83 @@
+//===-- NativeThreadFreeBSD.h - -*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef liblldb_NativeThreadFreeBSD_H_
+#define liblldb_NativeThreadFreeBSD_H_
+
+#include "lldb/Host/common/NativeThreadProtocol.h"
+
+#include "Plugins/Process/FreeBSDRemote/NativeRegisterContextFreeBSD.h"
+
+#include 
+#include 
+#include 
+
+namespace lldb_private {
+namespace process_freebsd {
+
+class NativeProcessFreeBSD;
+
+class NativeThreadFreeBSD : public NativeThreadProtocol {
+  friend class NativeProcessFreeBSD;
+
+public:
+  Nati

[Lldb-commits] [PATCH] D88841: [intel pt] Refactor parsing

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

I like this. A lot of comments, but they're all cosmetic.




Comment at: lldb/include/lldb/Target/Trace.h:96-98
 protected:
   Trace() {}
 

delete completely. As this is an abstract class, making the constructor 
protected does not do anything.



Comment at: lldb/include/lldb/Target/TraceSessionFileParser.h:9
+
+#ifndef LLDB_TARGET_TRACE_SESSION_PARSER_H
+#define LLDB_TARGET_TRACE_SESSION_PARSER_H

I think it wants this to be `LLDB_TARGET_TRACESESSIONPARSER_H`



Comment at: lldb/include/lldb/Target/TraceSessionFileParser.h:107
+
+using namespace lldb_private;
+

delete. "using namespace" in a header file is a big no-no.



Comment at: lldb/include/lldb/Target/TraceSessionFileParser.h:109
+
+inline bool fromJSON(const Value &value,
+ TraceSessionFileParser::JSONAddress &address, Path path);

delete inline



Comment at: lldb/source/Commands/CommandObjectTrace.cpp:263
+else
+  error.SetErrorString(llvm::toString(schemaOrErr.takeError()));
 

`error = schemaOrErr.takeError()`



Comment at: lldb/source/Core/PluginManager.cpp:1043
 
+const char *PluginManager::GetTraceSchema(ConstString name) {
+  for (const TraceInstance &instance : GetTraceInstances().GetInstances())

Return StringRef



Comment at: lldb/source/Plugins/Trace/intel-pt/ThreadIntelPT.cpp:23-25
+  if (!m_reg_context_sp) {
+m_reg_context_sp = CreateRegisterContextForFrame(nullptr);
+  }

[[ 
http://llvm.org/docs/CodingStandards.html#don-t-use-braces-on-simple-single-statement-bodies-of-if-else-loop-statements|
 no braces on simple if bodies ]]



Comment at: lldb/source/Plugins/Trace/intel-pt/ThreadIntelPT.h:14
+
+class ThreadIntelPT : public lldb_private::Thread {
+public:

btw, (most of) new plugins tend to place themselves in a sub-namespace of 
lldb_private. That avoids prefixing everything with `lldb_private::`



Comment at: lldb/source/Plugins/Trace/intel-pt/TraceIntelPT.cpp:23
+  GetPluginNameStatic(), "Intel Processor Trace", CreateInstance,
+  TraceIntelPTSessionFileParser::GetSchema().data());
 }

drop `data()` and have this function take a StringRef ?



Comment at: lldb/source/Plugins/Trace/intel-pt/TraceIntelPT.cpp:46
+lldb::TraceSP
+TraceIntelPT::CreateInstance(const llvm::json::Value &trace_session_file,
+ llvm::StringRef session_file_dir,

This could probably also return an `Expected`



Comment at: lldb/source/Plugins/Trace/intel-pt/TraceIntelPT.h:64
+  : Trace(), m_pt_cpu(pt_cpu) {
+for (auto target_sp : targets)
+  m_targets.push_back(target_sp);

[[ 
http://llvm.org/docs/CodingStandards.html#beware-unnecessary-copies-with-auto | 
const auto & ]], or potentially even `const TargetSP &` due to [[ 
http://llvm.org/docs/CodingStandards.html#beware-unnecessary-copies-with-auto | 
this ]].



Comment at: 
lldb/source/Plugins/Trace/intel-pt/TraceIntelPTSessionFileParser.cpp:18
+using namespace lldb_private;
+using namespace llvm;
+

You're `using namespace llvm`, but then still prefixing a lot of the stuff with 
`llvm::`. Is that because `llvm::json::` is a mouthful? `namespace json = 
llvm::json`, maybe?



Comment at: 
lldb/source/Plugins/Trace/intel-pt/TraceIntelPTSessionFileParser.h:80
+bool fromJSON(const Value &value,
+  TraceIntelPTSessionFileParser::JSONPTCPU &pt_cpu, Path path);
+

This demonstrates why the previous "using namespace" is so bad. Now the 
entirety of lldb is accessible from within the llvm::json namespace. :D



Comment at: lldb/source/Target/TraceSessionFileParser.cpp:98
+// Notes:
+// All paths are either absolute or relative to the session file.)";
+  return schema_builder.str();

End this with a newline ?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88841/new/

https://reviews.llvm.org/D88841

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

[Lldb-commits] [PATCH] D88975: [LLDB] On Windows, fix tests

[Alexandre Ganea via Phabricator via lldb-commits]

aganea marked 2 inline comments as done.
aganea added a comment.

Thank you all for your time!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88975/new/

https://reviews.llvm.org/D88975

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

[Lldb-commits] [lldb] 79809f5 - [LLDB] On Windows, fix tests

[Alexandre Ganea via lldb-commits]

Author: Alexandre Ganea
Date: 2020-10-08T11:46:59-04:00
New Revision: 79809f58b02419a5d1bfb6c9a59dbd13cd038c77

URL: 
https://github.com/llvm/llvm-project/commit/79809f58b02419a5d1bfb6c9a59dbd13cd038c77
DIFF: 
https://github.com/llvm/llvm-project/commit/79809f58b02419a5d1bfb6c9a59dbd13cd038c77.diff

LOG: [LLDB] On Windows, fix tests

This patch fixes a few issues seen when running `ninja check-lldb` in a Release 
build with VS2017:

- Some binaries couldn't be found (such as lldb-vscode.exe), because .exe 
wasn't appended to the file name.
- Many tests used to fail since our installed locale is in French - the OS 
error messages are not emitted in English.
- Our codepage being Windows-1252, python failed to decode some error messages 
with accentuations.

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

Added: 


Modified: 
lldb/packages/Python/lldbsuite/test/decorators.py
lldb/packages/Python/lldbsuite/test/dotest.py
lldb/packages/Python/lldbsuite/test_event/build_exception.py
lldb/test/API/commands/target/basic/TestTargetCommand.py
lldb/unittests/Utility/StatusTest.cpp

Removed: 




diff  --git a/lldb/packages/Python/lldbsuite/test/decorators.py 
b/lldb/packages/Python/lldbsuite/test/decorators.py
index 4e47165cdb1f..bb4a459abe68 100644
--- a/lldb/packages/Python/lldbsuite/test/decorators.py
+++ b/lldb/packages/Python/lldbsuite/test/decorators.py
@@ -3,6 +3,8 @@
 # System modules
 from distutils.version import LooseVersion
 from functools import wraps
+import ctypes
+import locale
 import os
 import platform
 import re
@@ -592,6 +594,17 @@ def skipIfWindows(func):
 """Decorate the item to skip tests that should be skipped on Windows."""
 return skipIfPlatform(["windows"])(func)
 
+def skipIfWindowsAndNonEnglish(func):
+"""Decorate the item to skip tests that should be skipped on non-English 
locales on Windows."""
+def is_Windows_NonEnglish(self):
+if lldbplatformutil.getPlatform() != "windows":
+return None
+kernel = ctypes.windll.kernel32
+if locale.windows_locale[ kernel.GetUserDefaultUILanguage() ] == 
"en_US":
+return None
+return "skipping non-English Windows locale"
+return skipTestIfFn(is_Windows_NonEnglish)(func)
+
 def skipUnlessWindows(func):
 """Decorate the item to skip tests that should be skipped on any 
non-Windows platform."""
 return skipUnlessPlatform(["windows"])(func)

diff  --git a/lldb/packages/Python/lldbsuite/test/dotest.py 
b/lldb/packages/Python/lldbsuite/test/dotest.py
index 922d7c9377ee..0da60f11a609 100644
--- a/lldb/packages/Python/lldbsuite/test/dotest.py
+++ b/lldb/packages/Python/lldbsuite/test/dotest.py
@@ -52,6 +52,9 @@ def is_exe(fpath):
 """Returns true if fpath is an executable."""
 if fpath == None:
 return False
+if sys.platform == 'win32':
+if not fpath.endswith(".exe"):
+fpath += ".exe"
 return os.path.isfile(fpath) and os.access(fpath, os.X_OK)
 
 

diff  --git a/lldb/packages/Python/lldbsuite/test_event/build_exception.py 
b/lldb/packages/Python/lldbsuite/test_event/build_exception.py
index 993214edd871..e08b632eb9a9 100644
--- a/lldb/packages/Python/lldbsuite/test_event/build_exception.py
+++ b/lldb/packages/Python/lldbsuite/test_event/build_exception.py
@@ -12,4 +12,4 @@ def __str__(self):
 @staticmethod
 def format_build_error(command, command_output):
 return "Error when building test subject.\n\nBuild 
Command:\n{}\n\nBuild Command Output:\n{}".format(
-command, command_output.decode("utf-8"))
+command, command_output.decode("utf-8", errors='ignore'))

diff  --git a/lldb/test/API/commands/target/basic/TestTargetCommand.py 
b/lldb/test/API/commands/target/basic/TestTargetCommand.py
index be6eeb938ab8..74b6c1fdcaed 100644
--- a/lldb/test/API/commands/target/basic/TestTargetCommand.py
+++ b/lldb/test/API/commands/target/basic/TestTargetCommand.py
@@ -350,6 +350,7 @@ def test_target_create_multiple_args(self):
 self.expect("target create a b", error=True,
 substrs=["'target create' takes exactly one executable 
path"])
 
+@skipIfWindowsAndNonEnglish
 @no_debug_info_test
 def test_target_create_nonexistent_core_file(self):
 self.expect("target create -c doesntexist", error=True,
@@ -365,6 +366,7 @@ def test_target_create_unreadable_core_file(self):
 self.expect("target create -c '" + tf.name + "'", error=True,
 substrs=["Cannot open '", "': Permission denied"])
 
+@skipIfWindowsAndNonEnglish
 @no_debug_info_test
 def test_target_create_nonexistent_sym_file(self):
 self.expect("target create -s doesntexist doesntexisteither", 
error=True,

diff  --git a/lldb/unittests/Utility/StatusTest.cpp 
b/lldb/unittests/Utility/StatusTest.cpp
index 862c063b2e06..9b9d870cd12a 100644
--- a/lldb/unitte

[Lldb-commits] [PATCH] D88975: [LLDB] On Windows, fix tests

[Alexandre Ganea via Phabricator via lldb-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG79809f58b024: [LLDB] On Windows, fix tests (authored by 
aganea).

Changed prior to commit:
  https://reviews.llvm.org/D88975?vs=296809&id=296982#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88975/new/

https://reviews.llvm.org/D88975

Files:
  lldb/packages/Python/lldbsuite/test/decorators.py
  lldb/packages/Python/lldbsuite/test/dotest.py
  lldb/packages/Python/lldbsuite/test_event/build_exception.py
  lldb/test/API/commands/target/basic/TestTargetCommand.py
  lldb/unittests/Utility/StatusTest.cpp

Index: lldb/unittests/Utility/StatusTest.cpp
===
--- lldb/unittests/Utility/StatusTest.cpp
+++ lldb/unittests/Utility/StatusTest.cpp
@@ -10,7 +10,7 @@
 #include "gtest/gtest.h"
 
 #ifdef _WIN32
-#include 
+#include 
 #endif
 
 using namespace lldb_private;
@@ -71,14 +71,26 @@
   EXPECT_FALSE(success.ToError());
   EXPECT_TRUE(success.Success());
 
+  WCHAR name[128]{};
+  ULONG nameLen = llvm::array_lengthof(name);
+  ULONG langs = 0;
+  GetUserPreferredUILanguages(MUI_LANGUAGE_NAME, &langs,
+  reinterpret_cast(&name), &nameLen);
+  // Skip the following tests on non-English, non-US, locales because the
+  // formatted messages will be different.
+  bool skip = wcscmp(L"en-US", name) != 0;
+
   auto s = Status(ERROR_ACCESS_DENIED, ErrorType::eErrorTypeWin32);
   EXPECT_TRUE(s.Fail());
-  EXPECT_STREQ("Access is denied. ", s.AsCString());
+  if (!skip)
+EXPECT_STREQ("Access is denied. ", s.AsCString());
 
   s.SetError(ERROR_IPSEC_IKE_TIMED_OUT, ErrorType::eErrorTypeWin32);
-  EXPECT_STREQ("Negotiation timed out ", s.AsCString());
+  if (!skip)
+EXPECT_STREQ("Negotiation timed out ", s.AsCString());
 
   s.SetError(16000, ErrorType::eErrorTypeWin32);
-  EXPECT_STREQ("unknown error", s.AsCString());
+  if (!skip)
+EXPECT_STREQ("unknown error", s.AsCString());
 }
 #endif
Index: lldb/test/API/commands/target/basic/TestTargetCommand.py
===
--- lldb/test/API/commands/target/basic/TestTargetCommand.py
+++ lldb/test/API/commands/target/basic/TestTargetCommand.py
@@ -350,6 +350,7 @@
 self.expect("target create a b", error=True,
 substrs=["'target create' takes exactly one executable path"])
 
+@skipIfWindowsAndNonEnglish
 @no_debug_info_test
 def test_target_create_nonexistent_core_file(self):
 self.expect("target create -c doesntexist", error=True,
@@ -365,6 +366,7 @@
 self.expect("target create -c '" + tf.name + "'", error=True,
 substrs=["Cannot open '", "': Permission denied"])
 
+@skipIfWindowsAndNonEnglish
 @no_debug_info_test
 def test_target_create_nonexistent_sym_file(self):
 self.expect("target create -s doesntexist doesntexisteither", error=True,
Index: lldb/packages/Python/lldbsuite/test_event/build_exception.py
===
--- lldb/packages/Python/lldbsuite/test_event/build_exception.py
+++ lldb/packages/Python/lldbsuite/test_event/build_exception.py
@@ -12,4 +12,4 @@
 @staticmethod
 def format_build_error(command, command_output):
 return "Error when building test subject.\n\nBuild Command:\n{}\n\nBuild Command Output:\n{}".format(
-command, command_output.decode("utf-8"))
+command, command_output.decode("utf-8", errors='ignore'))
Index: lldb/packages/Python/lldbsuite/test/dotest.py
===
--- lldb/packages/Python/lldbsuite/test/dotest.py
+++ lldb/packages/Python/lldbsuite/test/dotest.py
@@ -52,6 +52,9 @@
 """Returns true if fpath is an executable."""
 if fpath == None:
 return False
+if sys.platform == 'win32':
+if not fpath.endswith(".exe"):
+fpath += ".exe"
 return os.path.isfile(fpath) and os.access(fpath, os.X_OK)
 
 
Index: lldb/packages/Python/lldbsuite/test/decorators.py
===
--- lldb/packages/Python/lldbsuite/test/decorators.py
+++ lldb/packages/Python/lldbsuite/test/decorators.py
@@ -3,6 +3,8 @@
 # System modules
 from distutils.version import LooseVersion
 from functools import wraps
+import ctypes
+import locale
 import os
 import platform
 import re
@@ -592,6 +594,17 @@
 """Decorate the item to skip tests that should be skipped on Windows."""
 return skipIfPlatform(["windows"])(func)
 
+def skipIfWindowsAndNonEnglish(func):
+"""Decorate the item to skip tests that should be skipped on non-English locales on Windows."""
+def is_Windows_NonEnglish(self):
+if lldbplatformutil.getPlatform() != "windows":
+return None
+kernel = ctypes.win

[Lldb-commits] [PATCH] D82863: [LLDB] Add support to resize SVE registers at run-time

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

I haven't looked at the new version of the patch yet, partly because I'm busy 
(sorry), and partly because I'm not sure we have reached a consensus yet (or at 
least, I don't know what that consensus is).

Here's some questions/comments to what was earlier said, as I try to figure out 
what's going on.

In D82863#2311196 , @omjavaid wrote:

> Furthermore, GDB keeps a list of target descriptions for every combination of 
> (vq, pauth) where pauth is flag telling if pointer authentication feature is 
> supported while vq is vector length quad (multiples of 128bits). 
> https://sourceware.org/git?p=binutils-gdb.git;a=blob;f=gdb/aarch64-tdep.c;h=cbc7038dbba9472a12a3ae927bbb0937b10b2bdd;hb=HEAD#l3284
>
> On gdbserver side similar to what is proposed for LLDB, GDB also exchanges 
> vector length information using expedited registers list and updates target 
> descriptions based on vg (vector granule register) value.
> https://sourceware.org/git?p=binutils-gdb.git;a=blob;f=gdbserver/linux-aarch64-tdesc.cc;h=897fbb43bd28ddf44c69d4162dda43c2589b060f;hb=HEAD#l35

So you're saying that gdb will obtain the vg value from gdbserver and then 
lookup the proper target.xml description in the set of hardcoded xmls, is that 
right?

Does that mean that gdb will never send the qXfer:target.xml packet on aarch64? 
Or, it will send it, but then ignore/override the received data with the 
hardcoded xml ?

In D82863#2313676 , @jasonmolenda 
wrote:

> (about g packets...) they cause so many problems if there is a 
> mis-coordination between the remote stub and lldb, I never want to stop the 
> remote stub from providing those offsets.

I am not sure how to interpret this in the context of SVE registers. The stub 
cannot send the offsets of those, as their size/offset might change depending 
on their configuration.

Are we saying that we want the stub to send the offsets all registers _except_ 
SVE (and we hand-compute their offsets on the client)? That might also be 
tricky because we'd also need to change the offsets of registers that come 
_after_ the SVE regs.

Unless of course, we make sure SVE regs come last, but that imposes some 
constraints on future registers sets. I suppose we might be able to say that 
all variable-length or otherwise-funny registers must come last.

Another option would be to reserve enough space in the g packet to never have 
to move other registers due to the another register changing size. That would 
be nice, though it might pose a problem for stubs that want to be compatible 
with both gdb and lldb. Unless gdb is doing the same thing that is (is gdb 
doing the same thing?).


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D82863/new/

https://reviews.llvm.org/D82863

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

[Lldb-commits] [PATCH] D88967: [lldb] Add a cmake warning about the python/swig incompatibility

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

In D88967#2317851 , @amccarth wrote:

> In D88967#2317545 , @labath wrote:
>
>> In D88967#2317522 , @amccarth wrote:
>>
>>> If I recall correctly, the non-debug builds still had the problem, they 
>>> just didn't have the assertion that made it obvious.
>>
>> Is that problem only theoretical (like, "you shouldn't be doing that") or 
>> does it have some practical consequences (crashes, incorrect operation, 
>> etc.)?
>
> My memory isn't that detailed.  I think it was an argument being passed in as 
> a single value but being referenced as though it was an array or list.  Or 
> vice versa.

If we're talking about the same thing then it's about passing `None` instead of 
an empty list/dictionary. And it seems this is benign because the way python 
checks for emptyness also returns zero for `None` values.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88967/new/

https://reviews.llvm.org/D88967

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

Re: [Lldb-commits] [lldb] 81b11c9 - Fix a macOS build break caused by 3dfb94986170.

[Pavel Labath via lldb-commits]

On 08/10/2020 00:01, Jim Ingham via lldb-commits wrote:


Author: Jim Ingham
Date: 2020-10-07T15:01:27-07:00
New Revision: 81b11c91070f3a969b64b2c2e6011b02450fa75f

URL: 
https://github.com/llvm/llvm-project/commit/81b11c91070f3a969b64b2c2e6011b02450fa75f
DIFF: 
https://github.com/llvm/llvm-project/commit/81b11c91070f3a969b64b2c2e6011b02450fa75f.diff

LOG: Fix a macOS build break caused by 3dfb94986170.

Added:
 


Modified:
 
lldb/source/Plugins/Platform/MacOSX/objcxx/PlatformiOSSimulatorCoreSimulatorSupport.mm

Removed:
 




diff  --git 
a/lldb/source/Plugins/Platform/MacOSX/objcxx/PlatformiOSSimulatorCoreSimulatorSupport.mm
 
b/lldb/source/Plugins/Platform/MacOSX/objcxx/PlatformiOSSimulatorCoreSimulatorSupport.mm
index cfd44f9ae5ce..92bf716599b0 100644
--- 
a/lldb/source/Plugins/Platform/MacOSX/objcxx/PlatformiOSSimulatorCoreSimulatorSupport.mm
+++ 
b/lldb/source/Plugins/Platform/MacOSX/objcxx/PlatformiOSSimulatorCoreSimulatorSupport.mm
@@ -415,8 +415,9 @@ static Status HandleFileAction(ProcessLaunchInfo 
&launch_info,
secondary_fd =
launch_info.GetPTY().OpenSecondary(O_RDWR, nullptr, 0);
  if (secondary_fd == PseudoTerminal::invalid_fd) {
+  std::string secondary_path = secondary_spec.GetPath();
error.SetErrorStringWithFormat(
-  "unable to open secondary pty '%s'", secondary_path);
+  "unable to open secondary pty '%s'", secondary_path.c_str());
return error; // Failure
  }
  [options setValue:[NSNumber numberWithInteger:secondary_fd]


 
___

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



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

[Lldb-commits] [PATCH] D88992: [lldb] Fix "frame var" for large bitfields

[Pavel Labath via Phabricator via lldb-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG19d64138e6a7: [lldb] Fix "frame var" for large 
bitfields (authored by labath).

Changed prior to commit:
  https://reviews.llvm.org/D88992?vs=296749&id=296998#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88992/new/

https://reviews.llvm.org/D88992

Files:
  lldb/source/Core/ValueObjectChild.cpp
  lldb/test/API/lang/c/bitfields/TestBitfields.py


Index: lldb/test/API/lang/c/bitfields/TestBitfields.py
===
--- lldb/test/API/lang/c/bitfields/TestBitfields.py
+++ lldb/test/API/lang/c/bitfields/TestBitfields.py
@@ -147,6 +147,27 @@
 self.expect("v/x large_packed", VARIABLES_DISPLAYED_CORRECTLY,
 substrs=["a = 0x000c", "b = 
0x000deee"])
 
+# BitFields exhibit crashes in record layout on Windows
+# (http://llvm.org/pr21800)
+@skipIfWindows
+def test_expression_bug(self):
+# Ensure evaluating (emulating) an expression does not break bitfield
+# values for already parsed variables. The expression is run twice
+# because the very first expression can resume a target (to allocate
+# memory, etc.) even if it is not being jitted.
+self.build()
+lldbutil.run_to_line_breakpoint(self, lldb.SBFileSpec("main.c"),
+self.line)
+self.expect("v/x large_packed", VARIABLES_DISPLAYED_CORRECTLY,
+substrs=["a = 0x000c", "b = 
0x000deee"])
+self.expect("expr --allow-jit false  -- more_bits.a", 
VARIABLES_DISPLAYED_CORRECTLY,
+substrs=['uint32_t', '3'])
+self.expect("v/x large_packed", VARIABLES_DISPLAYED_CORRECTLY,
+substrs=["a = 0x000c", "b = 
0x000deee"])
+self.expect("expr --allow-jit false  -- more_bits.a", 
VARIABLES_DISPLAYED_CORRECTLY,
+substrs=['uint32_t', '3'])
+self.expect("v/x large_packed", VARIABLES_DISPLAYED_CORRECTLY,
+substrs=["a = 0x000c", "b = 
0x000deee"])
 
 @add_test_categories(['pyapi'])
 # BitFields exhibit crashes in record layout on Windows
Index: lldb/source/Core/ValueObjectChild.cpp
===
--- lldb/source/Core/ValueObjectChild.cpp
+++ lldb/source/Core/ValueObjectChild.cpp
@@ -165,10 +165,6 @@
   } else if (addr == 0) {
 m_error.SetErrorString("parent is NULL");
   } else {
-// Set this object's scalar value to the address of its value by
-// adding its byte offset to the parent address
-m_value.GetScalar() += GetByteOffset();
-
 // If a bitfield doesn't fit into the child_byte_size'd
 // window at child_byte_offset, move the window forward
 // until it fits.  The problem here is that Value has no
@@ -187,11 +183,15 @@
 if (bitfield_end > *type_bit_size) {
   uint64_t overhang_bytes =
   (bitfield_end - *type_bit_size + 7) / 8;
-  m_value.GetScalar() += overhang_bytes;
+  m_byte_offset += overhang_bytes;
   m_bitfield_bit_offset -= overhang_bytes * 8;
 }
   }
 }
+
+// Set this object's scalar value to the address of its value by
+// adding its byte offset to the parent address
+m_value.GetScalar() += m_byte_offset;
   }
 } break;
 


Index: lldb/test/API/lang/c/bitfields/TestBitfields.py
===
--- lldb/test/API/lang/c/bitfields/TestBitfields.py
+++ lldb/test/API/lang/c/bitfields/TestBitfields.py
@@ -147,6 +147,27 @@
 self.expect("v/x large_packed", VARIABLES_DISPLAYED_CORRECTLY,
 substrs=["a = 0x000c", "b = 0x000deee"])
 
+# BitFields exhibit crashes in record layout on Windows
+# (http://llvm.org/pr21800)
+@skipIfWindows
+def test_expression_bug(self):
+# Ensure evaluating (emulating) an expression does not break bitfield
+# values for already parsed variables. The expression is run twice
+# because the very first expression can resume a target (to allocate
+# memory, etc.) even if it is not being jitted.
+self.build()
+lldbutil.run_to_line_breakpoint(self, lldb.SBFileSpec("main.c"),
+self.line)
+self.expect("v/x large_packed", VARIABLES_DISPLAYED_CORRECTLY,
+substrs=["a = 0x000c", "b = 0x000deee"])
+self.expect("expr --allow-jit false  -- more_bits.a", VARIABLES_DISPLAYED_CORRECTLY,
+substrs=['uint32_t', '3'

[Lldb-commits] [lldb] d4a7c70 - [lldb] Add a cmake warning about the python/swig incompatibility

[Pavel Labath via lldb-commits]

Author: Pavel Labath
Date: 2020-10-08T18:42:50+02:00
New Revision: d4a7c70751cf5c0b0ce344555e3966ddc80290d2

URL: 
https://github.com/llvm/llvm-project/commit/d4a7c70751cf5c0b0ce344555e3966ddc80290d2
DIFF: 
https://github.com/llvm/llvm-project/commit/d4a7c70751cf5c0b0ce344555e3966ddc80290d2.diff

LOG: [lldb] Add a cmake warning about the python/swig incompatibility

Raise awareness of the fact that some versions of swig and python (and
build types) just don't mix.

One day this will be a reason to require swig>=4.0, but this version is
too hot off the press right now..

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

Added: 


Modified: 
lldb/cmake/modules/FindPythonAndSwig.cmake

Removed: 




diff  --git a/lldb/cmake/modules/FindPythonAndSwig.cmake 
b/lldb/cmake/modules/FindPythonAndSwig.cmake
index c8edaaaca3e0..de274ede5dbf 100644
--- a/lldb/cmake/modules/FindPythonAndSwig.cmake
+++ b/lldb/cmake/modules/FindPythonAndSwig.cmake
@@ -45,6 +45,17 @@ else()
 message(STATUS "SWIG 2 or later is required for Python support in LLDB but 
could not be found")
   endif()
 
+  get_property(MULTI_CONFIG GLOBAL PROPERTY GENERATOR_IS_MULTI_CONFIG)
+  if ("${Python3_VERSION}" VERSION_GREATER_EQUAL "3.7" AND
+  "${SWIG_VERSION}" VERSION_LESS "4.0" AND WIN32 AND (
+  ${MULTI_CONFIG} OR (${uppercase_CMAKE_BUILD_TYPE} STREQUAL "DEBUG")))
+# Technically this can happen with non-Windows builds too, but we are not
+# able to detect whether Python was built with assertions, and only Windows
+# has the requirement that Debug LLDB must use Debug Python.
+message(WARNING "Debug builds of LLDB are likely to be unusable due to "
+  ". Please use SWIG >= 4.0.")
+  endif()
+
   include(FindPackageHandleStandardArgs)
   find_package_handle_standard_args(PythonAndSwig
 FOUND_VAR



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

[Lldb-commits] [PATCH] D88967: [lldb] Add a cmake warning about the python/swig incompatibility

[Pavel Labath via Phabricator via lldb-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGd4a7c70751cf: [lldb] Add a cmake warning about the 
python/swig incompatibility (authored by labath).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88967/new/

https://reviews.llvm.org/D88967

Files:
  lldb/cmake/modules/FindPythonAndSwig.cmake


Index: lldb/cmake/modules/FindPythonAndSwig.cmake
===
--- lldb/cmake/modules/FindPythonAndSwig.cmake
+++ lldb/cmake/modules/FindPythonAndSwig.cmake
@@ -45,6 +45,17 @@
 message(STATUS "SWIG 2 or later is required for Python support in LLDB but 
could not be found")
   endif()
 
+  get_property(MULTI_CONFIG GLOBAL PROPERTY GENERATOR_IS_MULTI_CONFIG)
+  if ("${Python3_VERSION}" VERSION_GREATER_EQUAL "3.7" AND
+  "${SWIG_VERSION}" VERSION_LESS "4.0" AND WIN32 AND (
+  ${MULTI_CONFIG} OR (${uppercase_CMAKE_BUILD_TYPE} STREQUAL "DEBUG")))
+# Technically this can happen with non-Windows builds too, but we are not
+# able to detect whether Python was built with assertions, and only Windows
+# has the requirement that Debug LLDB must use Debug Python.
+message(WARNING "Debug builds of LLDB are likely to be unusable due to "
+  ". Please use SWIG >= 4.0.")
+  endif()
+
   include(FindPackageHandleStandardArgs)
   find_package_handle_standard_args(PythonAndSwig
 FOUND_VAR


Index: lldb/cmake/modules/FindPythonAndSwig.cmake
===
--- lldb/cmake/modules/FindPythonAndSwig.cmake
+++ lldb/cmake/modules/FindPythonAndSwig.cmake
@@ -45,6 +45,17 @@
 message(STATUS "SWIG 2 or later is required for Python support in LLDB but could not be found")
   endif()
 
+  get_property(MULTI_CONFIG GLOBAL PROPERTY GENERATOR_IS_MULTI_CONFIG)
+  if ("${Python3_VERSION}" VERSION_GREATER_EQUAL "3.7" AND
+  "${SWIG_VERSION}" VERSION_LESS "4.0" AND WIN32 AND (
+  ${MULTI_CONFIG} OR (${uppercase_CMAKE_BUILD_TYPE} STREQUAL "DEBUG")))
+# Technically this can happen with non-Windows builds too, but we are not
+# able to detect whether Python was built with assertions, and only Windows
+# has the requirement that Debug LLDB must use Debug Python.
+message(WARNING "Debug builds of LLDB are likely to be unusable due to "
+  ". Please use SWIG >= 4.0.")
+  endif()
+
   include(FindPackageHandleStandardArgs)
   find_package_handle_standard_args(PythonAndSwig
 FOUND_VAR
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] 19d6413 - [lldb] Fix "frame var" for large bitfields

[Pavel Labath via lldb-commits]

Author: Pavel Labath
Date: 2020-10-08T18:42:50+02:00
New Revision: 19d64138e6a708d1d0571da3ac51e1b4777c2b47

URL: 
https://github.com/llvm/llvm-project/commit/19d64138e6a708d1d0571da3ac51e1b4777c2b47
DIFF: 
https://github.com/llvm/llvm-project/commit/19d64138e6a708d1d0571da3ac51e1b4777c2b47.diff

LOG: [lldb] Fix "frame var" for large bitfields

The problem here is in the "sliding" code in
ValueObjectChild::UpdateValue. It modifies m_bitfield_bit_offset and
m_value to ensure the bitfield value fits the window given by the
underlying type.

However, this is broken next time UpdateValue is called, because it
updates the m_value value from the parent. However, the value cannot be
slid again because the m_bitfield_bit_offset is already modified.

It seems this can happen only under specific circumstances. One way to
trigger is is to run an expression which can be interpreted (jitting it
causes a new StackFrame and ValueObject variables to be created).

I fix this bug by modifying m_byte_offset instead of m_scalar, and
ensuring the changes are folded into m_scalar regardless of how many
times UpdateValue is called.

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

Added: 


Modified: 
lldb/source/Core/ValueObjectChild.cpp
lldb/test/API/lang/c/bitfields/TestBitfields.py

Removed: 




diff  --git a/lldb/source/Core/ValueObjectChild.cpp 
b/lldb/source/Core/ValueObjectChild.cpp
index 1059c8f34b3b..63661a482313 100644
--- a/lldb/source/Core/ValueObjectChild.cpp
+++ b/lldb/source/Core/ValueObjectChild.cpp
@@ -165,10 +165,6 @@ bool ValueObjectChild::UpdateValue() {
   } else if (addr == 0) {
 m_error.SetErrorString("parent is NULL");
   } else {
-// Set this object's scalar value to the address of its value by
-// adding its byte offset to the parent address
-m_value.GetScalar() += GetByteOffset();
-
 // If a bitfield doesn't fit into the child_byte_size'd
 // window at child_byte_offset, move the window forward
 // until it fits.  The problem here is that Value has no
@@ -187,11 +183,15 @@ bool ValueObjectChild::UpdateValue() {
 if (bitfield_end > *type_bit_size) {
   uint64_t overhang_bytes =
   (bitfield_end - *type_bit_size + 7) / 8;
-  m_value.GetScalar() += overhang_bytes;
+  m_byte_offset += overhang_bytes;
   m_bitfield_bit_offset -= overhang_bytes * 8;
 }
   }
 }
+
+// Set this object's scalar value to the address of its value by
+// adding its byte offset to the parent address
+m_value.GetScalar() += m_byte_offset;
   }
 } break;
 

diff  --git a/lldb/test/API/lang/c/bitfields/TestBitfields.py 
b/lldb/test/API/lang/c/bitfields/TestBitfields.py
index 7b28a321ff61..d838a886bf2d 100644
--- a/lldb/test/API/lang/c/bitfields/TestBitfields.py
+++ b/lldb/test/API/lang/c/bitfields/TestBitfields.py
@@ -147,6 +147,27 @@ def test_and_run_command(self):
 self.expect("v/x large_packed", VARIABLES_DISPLAYED_CORRECTLY,
 substrs=["a = 0x000c", "b = 
0x000deee"])
 
+# BitFields exhibit crashes in record layout on Windows
+# (http://llvm.org/pr21800)
+@skipIfWindows
+def test_expression_bug(self):
+# Ensure evaluating (emulating) an expression does not break bitfield
+# values for already parsed variables. The expression is run twice
+# because the very first expression can resume a target (to allocate
+# memory, etc.) even if it is not being jitted.
+self.build()
+lldbutil.run_to_line_breakpoint(self, lldb.SBFileSpec("main.c"),
+self.line)
+self.expect("v/x large_packed", VARIABLES_DISPLAYED_CORRECTLY,
+substrs=["a = 0x000c", "b = 
0x000deee"])
+self.expect("expr --allow-jit false  -- more_bits.a", 
VARIABLES_DISPLAYED_CORRECTLY,
+substrs=['uint32_t', '3'])
+self.expect("v/x large_packed", VARIABLES_DISPLAYED_CORRECTLY,
+substrs=["a = 0x000c", "b = 
0x000deee"])
+self.expect("expr --allow-jit false  -- more_bits.a", 
VARIABLES_DISPLAYED_CORRECTLY,
+substrs=['uint32_t', '3'])
+self.expect("v/x large_packed", VARIABLES_DISPLAYED_CORRECTLY,
+substrs=["a = 0x000c", "b = 
0x000deee"])
 
 @add_test_categories(['pyapi'])
 # BitFields exhibit crashes in record layout on Windows



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

[Lldb-commits] [PATCH] D89019: Change the default handling of SIGCONT to nostop/noprint

[Jim Ingham via Phabricator via lldb-commits]

jingham updated this revision to Diff 297029.
jingham added a comment.

Adopt Pavel's suggestion to do "nosuppress/nostop/notify" for SIGCONT instead 
of "nosuppress/nostop/nonotify".


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D89019/new/

https://reviews.llvm.org/D89019

Files:
  lldb/source/Plugins/Process/Utility/LinuxSignals.cpp
  lldb/source/Plugins/Process/Utility/MipsLinuxSignals.cpp
  lldb/source/Target/UnixSignals.cpp


Index: lldb/source/Target/UnixSignals.cpp
===
--- lldb/source/Target/UnixSignals.cpp
+++ lldb/source/Target/UnixSignals.cpp
@@ -94,7 +94,7 @@
   AddSignal(16, "SIGURG", false,false,  false,  "urgent condition 
on IO channel");
   AddSignal(17, "SIGSTOP",true, true,   true,   "sendable stop 
signal not from tty");
   AddSignal(18, "SIGTSTP",false,true,   true,   "stop signal from 
tty");
-  AddSignal(19, "SIGCONT",false,true,   true,   "continue a 
stopped process");
+  AddSignal(19, "SIGCONT",false,false,  true,   "continue a 
stopped process");
   AddSignal(20, "SIGCHLD",false,false,  false,  "to parent on 
child stop or exit");
   AddSignal(21, "SIGTTIN",false,true,   true,   "to readers 
process group upon background tty read");
   AddSignal(22, "SIGTTOU",false,true,   true,   "to readers 
process group upon background tty write");
Index: lldb/source/Plugins/Process/Utility/MipsLinuxSignals.cpp
===
--- lldb/source/Plugins/Process/Utility/MipsLinuxSignals.cpp
+++ lldb/source/Plugins/Process/Utility/MipsLinuxSignals.cpp
@@ -45,7 +45,7 @@
 "SIGPOLL");
   AddSignal(23, "SIGSTOP", true, true, true, "process stop");
   AddSignal(24, "SIGTSTP", false, true, true, "tty stop");
-  AddSignal(25, "SIGCONT", false, true, true, "process continue");
+  AddSignal(25, "SIGCONT", false, false, true, "process continue");
   AddSignal(26, "SIGTTIN", false, true, true, "background tty read");
   AddSignal(27, "SIGTTOU", false, true, true, "background tty write");
   AddSignal(28, "SIGVTALRM", false, true, true, "virtual time alarm");
Index: lldb/source/Plugins/Process/Utility/LinuxSignals.cpp
===
--- lldb/source/Plugins/Process/Utility/LinuxSignals.cpp
+++ lldb/source/Plugins/Process/Utility/LinuxSignals.cpp
@@ -37,7 +37,7 @@
   AddSignal(16, "SIGSTKFLT", false, true, true, "stack fault");
   AddSignal(17, "SIGCHLD", false, false, true, "child status has changed",
 "SIGCLD");
-  AddSignal(18, "SIGCONT", false, true, true, "process continue");
+  AddSignal(18, "SIGCONT", false, false, true, "process continue");
   AddSignal(19, "SIGSTOP", true, true, true, "process stop");
   AddSignal(20, "SIGTSTP", false, true, true, "tty stop");
   AddSignal(21, "SIGTTIN", false, true, true, "background tty read");


Index: lldb/source/Target/UnixSignals.cpp
===
--- lldb/source/Target/UnixSignals.cpp
+++ lldb/source/Target/UnixSignals.cpp
@@ -94,7 +94,7 @@
   AddSignal(16, "SIGURG", false,false,  false,  "urgent condition on IO channel");
   AddSignal(17, "SIGSTOP",true, true,   true,   "sendable stop signal not from tty");
   AddSignal(18, "SIGTSTP",false,true,   true,   "stop signal from tty");
-  AddSignal(19, "SIGCONT",false,true,   true,   "continue a stopped process");
+  AddSignal(19, "SIGCONT",false,false,  true,   "continue a stopped process");
   AddSignal(20, "SIGCHLD",false,false,  false,  "to parent on child stop or exit");
   AddSignal(21, "SIGTTIN",false,true,   true,   "to readers process group upon background tty read");
   AddSignal(22, "SIGTTOU",false,true,   true,   "to readers process group upon background tty write");
Index: lldb/source/Plugins/Process/Utility/MipsLinuxSignals.cpp
===
--- lldb/source/Plugins/Process/Utility/MipsLinuxSignals.cpp
+++ lldb/source/Plugins/Process/Utility/MipsLinuxSignals.cpp
@@ -45,7 +45,7 @@
 "SIGPOLL");
   AddSignal(23, "SIGSTOP", true, true, true, "process stop");
   AddSignal(24, "SIGTSTP", false, true, true, "tty stop");
-  AddSignal(25, "SIGCONT", false, true, true, "process continue");
+  AddSignal(25, "SIGCONT", false, false, true, "process continue");
   AddSignal(26, "SIGTTIN", false, true, true, "background tty read");
   AddSignal(27, "SIGTTOU", false, true, true, "background tty write");
   AddSignal(28, "SIGVTALRM", false, true, true, "virtual time alarm");
Index: lldb/source/Plugins/Process/Utility/LinuxSignals.cpp
===
--- lldb/source/Plugins/Process/Utility/LinuxSignals.cpp
+++ lldb/source/Plugin

Re: [Lldb-commits] [cfe-dev] Upcoming upgrade of LLVM buildbot

[Galina Kistanova via lldb-commits]

Hello bot owners,

I see a lot of builders went down and not connecting back to the production
buildbot.

Could you check your bots to make sure they are up and running, please?
And report connectivity issues if any with quotes from the logs directly to
me.

Thanks

Galina


On Thu, Oct 8, 2020 at 2:43 AM Andrzej Warzynski 
wrote:

> Our Flang-aarch64 buildbots just won't connect to the main Buildbot
> master anymore. I switched them to the staging buildbot master instead
> and it seems fine for now. Is there anything that we can/should tweak at
> our end?
>
> http://lab.llvm.org:8014/#/waterfall?tags=flang
>
> -Andrzej
>
> On 08/10/2020 00:31, Galina Kistanova via cfe-dev wrote:
> > They are online now -
> http://lab.llvm.org:8011/#/waterfall?tags=sanitizer
> >
> > AnnotatedCommand has severe design conflict with the new buildbot.
> > We have changed it to be safe and still do something useful, but it will
> > need more love and care.
> >
> > Please let me know if you have some spare time to work on porting
> > AnnotatedCommand.
> >
> > Thanks
> >
> > Galina
> >
> > On Wed, Oct 7, 2020 at 2:57 PM Vitaly Buka  > > wrote:
> >
> > It looks like all sanitizer builder are still offline
> > http://lab.llvm.org:8011/#/builders
> >
> > On Tue, 6 Oct 2020 at 00:34, Galina Kistanova via cfe-commits
> > mailto:cfe-comm...@lists.llvm.org>>
> wrote:
> >
> > Hello everyone,
> >
> > The staging buildbot was up and running for 6 days now, and
> > looks good.
> >
> > Tomorrow at 12:00 PM PDT we will switch the production buildbot
> > to the new version.
> >
> > If you are a bot owner, you do not need to do anything at this
> > point, unless I'll ask you to help.
> > The buildbot will go down for a short period of time, and then a
> > new version will come up and will accept connections from your
> bots.
> >
> > Please note that the new version has a bit different URL
> > structure. You will need to update the bookmarks or scripts if
> > you have stored direct URLs to inside the buldbot.
> >
> > We will be watching the production and staging bots and will be
> > improving zorg for the next week or so.
> >
> > I will need your feedback about blame e-mails delivery, IRC
> > reporting issues, and anything you could spot wrong with the new
> > bot. I  hope the transition will go smoothly and we will handle
> > issues quickly if any would come up.
> >
> > After production is good and we have about a week of running
> > history, I'll ask the bot owners to upgrade buildbots on their
> > side. Please do not upgrade your buildbots unless I'll ask you
> > to. We are trying to limit a number of moving parts at this
> > stage. We will start accepting change to zorg at this point.
> > Please feel free to talk to me if you will have a special
> > situation and if you would absolutely have to make changes.
> >
> > Thanks for your support and help. And please feel free to ask if
> > you have questions.
> >
> > Galina
> >
> >
> > On Thu, Sep 10, 2020 at 9:35 PM Galina Kistanova
> > mailto:gkistan...@gmail.com>> wrote:
> >
> > Hello everyone,
> >
> > The buildbot upgrade is entering the phase when the results
> > to become visible.
> >
> > No change is required at this time on any of the builders.
> > The bot owners could upgrade the buildbot on build computers
> > later, at their convenience, as this is not on the critical
> > path.
> >
> > We are going to upgrade the staging bot first. Then, once
> > that is stable and all detected issues are resolved, we will
> > upgrade the production bot.
> >
> > I will need some help with testing, and will be asking to
> > move some of the builders temporarily to the staging. LLVM
> > buildbot is a piece of critical infrastructure, so more eyes
> > and hands in making sure it works properly the better.
> >
> > I'll be posting updates and ETA of particular changes in
> > this thread.
> >
> > Please feel free to ask if you have any questions or
> concerns.
> >
> > Thanks
> >
> > Galina
> >
> > ___
> > cfe-commits mailing list
> > cfe-comm...@lists.llvm.org 
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
> >
> >
> > ___
> > cfe-dev mailing list
> > cfe-...@lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >
>
___
lldb-commits mailing list
lldb-commits@lists.llvm

[Lldb-commits] [PATCH] D88387: Create "skinny corefiles" for Mach-O with process save-core / reading

[Jason Molenda via Phabricator via lldb-commits]

jasonmolenda added a comment.

Thanks for the feedback Pavel.  Good point on piping the dirty pages list 
through the memory region command and adding tests for that.  And good thoughts 
on different memory types that could be included in the corefile.  I think we 
may revisit how the 'process save-core' command arguments work as we add more 
formats.  We could do some pretty cool stuff here.

I'm not going to bite this off right now, but I was thinking about the fact 
that a "dirty memory only" corefile depends on having all the binaries on the 
system that the corefile was taken.  Why can't you run lldb on a dirty memory 
corefile and create a full corefile from it, if it's on the same system with 
the same libraries?

Also, with a full corefile, if we know the dirty-memory-page list, if a memory 
region corresponds to a binary (libc.so text for instance), why should we read 
the memory from the inferior at all?  We can copy the pages of the binary into 
the memory buffer. On a Darwin system, the vast majority of a full corefile are 
system binaries that are unmodified; it would make a full coredump a lot faster 
to create.  I don't think perf is the most important thing with a corefile, but 
just some thoughts I had while looking at this.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88387/new/

https://reviews.llvm.org/D88387

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

[Lldb-commits] [PATCH] D88769: [trace] Scaffold "thread trace dump instructions"

[Greg Clayton via Phabricator via lldb-commits]

clayborg accepted this revision.
clayborg added a comment.
This revision is now accepted and ready to land.

LGTM. Pavel please chime in if you have any issues.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88769/new/

https://reviews.llvm.org/D88769

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

[Lldb-commits] [PATCH] D88841: [intel pt] Refactor parsing

[Greg Clayton via Phabricator via lldb-commits]

clayborg requested changes to this revision.
clayborg added inline comments.
This revision now requires changes to proceed.



Comment at: lldb/include/lldb/Core/PluginManager.h:342
 
+  static const char *GetTraceSchema(ConstString name);
+

This is fine if we have a case where we want the scheme for a given plug-in. We 
should probably also add a call that takes a "size_t index" as an argument that 
is the index of the plug-ins. When the index is too big, returns NULL. This 
will allow us to iterate over all of the installed plug-ins and print out the 
schemas for each one?



Comment at: lldb/include/lldb/Target/Trace.h:94
+  static llvm::Expected
+  FindPluginSchema(llvm::StringRef plugin_name);
 

Do we also want a non static version of this to be able to get the schema for 
the current Trace plugin? 



Comment at: lldb/include/lldb/Target/TraceSessionFileParser.h:107
+
+using namespace lldb_private;
+

labath wrote:
> delete. "using namespace" in a header file is a big no-no.
indeed! I will trickly through to any .cpp file that includes it



Comment at: lldb/source/Commands/CommandObjectTrace.cpp:242
 "Show the schema of the given trace plugin.",
 "trace schema "),
 m_options() {}

Make  optional so we can list all trace plug-in schemas?



Comment at: lldb/source/Plugins/Trace/intel-pt/ThreadIntelPT.h:14
+
+class ThreadIntelPT : public lldb_private::Thread {
+public:

labath wrote:
> btw, (most of) new plugins tend to place themselves in a sub-namespace of 
> lldb_private. That avoids prefixing everything with `lldb_private::`
I second this, add a plug-in namespace!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88841/new/

https://reviews.llvm.org/D88841

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

[Lldb-commits] [lldb] 97e7fbb - [LLDB] More Windows non-English locales fixes

[Alexandre Ganea via lldb-commits]

Author: Alexandre Ganea
Date: 2020-10-08T17:22:42-04:00
New Revision: 97e7fbb343e2a4ea913686254105b9965c5468f8

URL: 
https://github.com/llvm/llvm-project/commit/97e7fbb343e2a4ea913686254105b9965c5468f8
DIFF: 
https://github.com/llvm/llvm-project/commit/97e7fbb343e2a4ea913686254105b9965c5468f8.diff

LOG: [LLDB] More Windows non-English locales fixes

This is a follow-up for https://reviews.llvm.org/D88975

Added: 


Modified: 
lldb/packages/Python/lldbsuite/test/lldbtest.py

Removed: 




diff  --git a/lldb/packages/Python/lldbsuite/test/lldbtest.py 
b/lldb/packages/Python/lldbsuite/test/lldbtest.py
index 2309b403cb99..69da3914f1f2 100644
--- a/lldb/packages/Python/lldbsuite/test/lldbtest.py
+++ b/lldb/packages/Python/lldbsuite/test/lldbtest.py
@@ -516,7 +516,7 @@ def system(commands, **kwargs):
 "command": shellCommand
 }
 raise cpe
-output = output + this_output.decode("utf-8")
+output = output + this_output.decode("utf-8", errors='ignore')
 return output
 
 



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

[Lldb-commits] [PATCH] D88975: [LLDB] On Windows, fix tests

[Alexandre Ganea via Phabricator via lldb-commits]

aganea added a comment.

I've commited one more fix here: https://reviews.llvm.org/rG97e7fbb343e2 - This 
didn't occur locally on my machine, but only on another machine. But in 
essence, the issue was the same, an accentuated Windows-1252 codepage character 
that was being decoded as UTF-8 by the Python runtime.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88975/new/

https://reviews.llvm.org/D88975

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

[Lldb-commits] [PATCH] D82863: [LLDB] Add support to resize SVE registers at run-time

[Jason Molenda via Phabricator via lldb-commits]

jasonmolenda added a comment.

In D82863#2319568 , @labath wrote:

> In D82863#2313676 , @jasonmolenda 
> wrote:
>
>> (about g packets...) they cause so many problems if there is a 
>> mis-coordination between the remote stub and lldb, I never want to stop the 
>> remote stub from providing those offsets.
>
> I am not sure how to interpret this in the context of SVE registers. The stub 
> cannot send the offsets of those, as their size/offset might change depending 
> on their configuration.

Yeah, of course you're right, in the case of a dynamic register context like 
this, the g/G packets shouldn't be used (we should have 
GDBRemoteCommunicationClient::AvoidGPackets return true).

The jThreadsInfo may give us the full register context (in base10 because json 
lol) although debugserver only sends the GPRs in the jThreadsInfo response.  If 
lldb needs to read the full register context, it would need to read them 
individually (and write them individually if saving the full register context). 
 We could add qReadAllRegisters and QWriteAllRegisters which have a series of 
regnum:base16-regval-target-endian, or JSON versions of the same packets if the 
perf was important.

The original g/G packets were designed for little embedded systems where the 
stub had to be very small and dumb, and could just memcpy the payload in the 
packet into the register context & back out again.  Any sensible design today 
would, at least, have some form of an array of regnum:regval to eliminate many 
of the problems.

> Unless of course, we make sure SVE regs come last, but that imposes some 
> constraints on future registers sets. I suppose we might be able to say that 
> all variable-length or otherwise-funny registers must come last.

Yeah, Omair's patch currently assumes that the SVE regs come last already when 
they copy & truncate the registers context to heap.  I fear that we'll get to 
armv12 and we'll be adding registers after the SVE and wonder why they're being 
truncated somewhere in lldb. :)

@omjavaid , what do you think about disabling g/G when we're working with SVE 
registers (GDBRemoteCommunicationClient::AvoidGPackets)?  There are some 
gdb-remote stubs that can *only* read/write registers with g/G, but I think 
it's reasonable to say "you must implement p/P for a target with SVE", that's a 
generic packet shared by both lldb and gdb.  We could add a more-modern g/G 
replacement packet, but no one would have that implemented, and if they were 
going to add anything, I'd have them implement p/P unless it's perf problems 
and they need a read-all-registers / write-all-registers packet that works with 
SVE.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D82863/new/

https://reviews.llvm.org/D82863

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

[Lldb-commits] [lldb] a68ffb1 - Change the default handling of SIGCONT to nosuppress/nostop/notify

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2020-10-08T15:24:19-07:00
New Revision: a68ffb19d392c6d52f6e42925217a77b4cd71cee

URL: 
https://github.com/llvm/llvm-project/commit/a68ffb19d392c6d52f6e42925217a77b4cd71cee
DIFF: 
https://github.com/llvm/llvm-project/commit/a68ffb19d392c6d52f6e42925217a77b4cd71cee.diff

LOG: Change the default handling of SIGCONT to nosuppress/nostop/notify

Except for the few people actually debugging shells, stopping on a
SIGCONT doesn't add any value.  And for people trying to run tests
under the debugger, stopping here is actively inconvenient.  So this
patch switches the default behavior to not stop.

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

Added: 


Modified: 
lldb/source/Plugins/Process/Utility/LinuxSignals.cpp
lldb/source/Plugins/Process/Utility/MipsLinuxSignals.cpp
lldb/source/Target/UnixSignals.cpp

Removed: 




diff  --git a/lldb/source/Plugins/Process/Utility/LinuxSignals.cpp 
b/lldb/source/Plugins/Process/Utility/LinuxSignals.cpp
index 4dd619e3bade..568939029aee 100644
--- a/lldb/source/Plugins/Process/Utility/LinuxSignals.cpp
+++ b/lldb/source/Plugins/Process/Utility/LinuxSignals.cpp
@@ -37,7 +37,7 @@ void LinuxSignals::Reset() {
   AddSignal(16, "SIGSTKFLT", false, true, true, "stack fault");
   AddSignal(17, "SIGCHLD", false, false, true, "child status has changed",
 "SIGCLD");
-  AddSignal(18, "SIGCONT", false, true, true, "process continue");
+  AddSignal(18, "SIGCONT", false, false, true, "process continue");
   AddSignal(19, "SIGSTOP", true, true, true, "process stop");
   AddSignal(20, "SIGTSTP", false, true, true, "tty stop");
   AddSignal(21, "SIGTTIN", false, true, true, "background tty read");

diff  --git a/lldb/source/Plugins/Process/Utility/MipsLinuxSignals.cpp 
b/lldb/source/Plugins/Process/Utility/MipsLinuxSignals.cpp
index 8f75844277c0..17c238c04453 100644
--- a/lldb/source/Plugins/Process/Utility/MipsLinuxSignals.cpp
+++ b/lldb/source/Plugins/Process/Utility/MipsLinuxSignals.cpp
@@ -45,7 +45,7 @@ void MipsLinuxSignals::Reset() {
 "SIGPOLL");
   AddSignal(23, "SIGSTOP", true, true, true, "process stop");
   AddSignal(24, "SIGTSTP", false, true, true, "tty stop");
-  AddSignal(25, "SIGCONT", false, true, true, "process continue");
+  AddSignal(25, "SIGCONT", false, false, true, "process continue");
   AddSignal(26, "SIGTTIN", false, true, true, "background tty read");
   AddSignal(27, "SIGTTOU", false, true, true, "background tty write");
   AddSignal(28, "SIGVTALRM", false, true, true, "virtual time alarm");

diff  --git a/lldb/source/Target/UnixSignals.cpp 
b/lldb/source/Target/UnixSignals.cpp
index f6b4e82a88ed..84a2ef67ac29 100644
--- a/lldb/source/Target/UnixSignals.cpp
+++ b/lldb/source/Target/UnixSignals.cpp
@@ -94,7 +94,7 @@ void UnixSignals::Reset() {
   AddSignal(16, "SIGURG", false,false,  false,  "urgent condition 
on IO channel");
   AddSignal(17, "SIGSTOP",true, true,   true,   "sendable stop 
signal not from tty");
   AddSignal(18, "SIGTSTP",false,true,   true,   "stop signal from 
tty");
-  AddSignal(19, "SIGCONT",false,true,   true,   "continue a 
stopped process");
+  AddSignal(19, "SIGCONT",false,false,  true,   "continue a 
stopped process");
   AddSignal(20, "SIGCHLD",false,false,  false,  "to parent on 
child stop or exit");
   AddSignal(21, "SIGTTIN",false,true,   true,   "to readers 
process group upon background tty read");
   AddSignal(22, "SIGTTOU",false,true,   true,   "to readers 
process group upon background tty write");



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

[Lldb-commits] [PATCH] D89019: Change the default handling of SIGCONT to nostop/noprint

[Jim Ingham via Phabricator via lldb-commits]

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGa68ffb19d392: Change the default handling of SIGCONT to 
nosuppress/nostop/notify (authored by jingham).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D89019/new/

https://reviews.llvm.org/D89019

Files:
  lldb/source/Plugins/Process/Utility/LinuxSignals.cpp
  lldb/source/Plugins/Process/Utility/MipsLinuxSignals.cpp
  lldb/source/Target/UnixSignals.cpp


Index: lldb/source/Target/UnixSignals.cpp
===
--- lldb/source/Target/UnixSignals.cpp
+++ lldb/source/Target/UnixSignals.cpp
@@ -94,7 +94,7 @@
   AddSignal(16, "SIGURG", false,false,  false,  "urgent condition 
on IO channel");
   AddSignal(17, "SIGSTOP",true, true,   true,   "sendable stop 
signal not from tty");
   AddSignal(18, "SIGTSTP",false,true,   true,   "stop signal from 
tty");
-  AddSignal(19, "SIGCONT",false,true,   true,   "continue a 
stopped process");
+  AddSignal(19, "SIGCONT",false,false,  true,   "continue a 
stopped process");
   AddSignal(20, "SIGCHLD",false,false,  false,  "to parent on 
child stop or exit");
   AddSignal(21, "SIGTTIN",false,true,   true,   "to readers 
process group upon background tty read");
   AddSignal(22, "SIGTTOU",false,true,   true,   "to readers 
process group upon background tty write");
Index: lldb/source/Plugins/Process/Utility/MipsLinuxSignals.cpp
===
--- lldb/source/Plugins/Process/Utility/MipsLinuxSignals.cpp
+++ lldb/source/Plugins/Process/Utility/MipsLinuxSignals.cpp
@@ -45,7 +45,7 @@
 "SIGPOLL");
   AddSignal(23, "SIGSTOP", true, true, true, "process stop");
   AddSignal(24, "SIGTSTP", false, true, true, "tty stop");
-  AddSignal(25, "SIGCONT", false, true, true, "process continue");
+  AddSignal(25, "SIGCONT", false, false, true, "process continue");
   AddSignal(26, "SIGTTIN", false, true, true, "background tty read");
   AddSignal(27, "SIGTTOU", false, true, true, "background tty write");
   AddSignal(28, "SIGVTALRM", false, true, true, "virtual time alarm");
Index: lldb/source/Plugins/Process/Utility/LinuxSignals.cpp
===
--- lldb/source/Plugins/Process/Utility/LinuxSignals.cpp
+++ lldb/source/Plugins/Process/Utility/LinuxSignals.cpp
@@ -37,7 +37,7 @@
   AddSignal(16, "SIGSTKFLT", false, true, true, "stack fault");
   AddSignal(17, "SIGCHLD", false, false, true, "child status has changed",
 "SIGCLD");
-  AddSignal(18, "SIGCONT", false, true, true, "process continue");
+  AddSignal(18, "SIGCONT", false, false, true, "process continue");
   AddSignal(19, "SIGSTOP", true, true, true, "process stop");
   AddSignal(20, "SIGTSTP", false, true, true, "tty stop");
   AddSignal(21, "SIGTTIN", false, true, true, "background tty read");


Index: lldb/source/Target/UnixSignals.cpp
===
--- lldb/source/Target/UnixSignals.cpp
+++ lldb/source/Target/UnixSignals.cpp
@@ -94,7 +94,7 @@
   AddSignal(16, "SIGURG", false,false,  false,  "urgent condition on IO channel");
   AddSignal(17, "SIGSTOP",true, true,   true,   "sendable stop signal not from tty");
   AddSignal(18, "SIGTSTP",false,true,   true,   "stop signal from tty");
-  AddSignal(19, "SIGCONT",false,true,   true,   "continue a stopped process");
+  AddSignal(19, "SIGCONT",false,false,  true,   "continue a stopped process");
   AddSignal(20, "SIGCHLD",false,false,  false,  "to parent on child stop or exit");
   AddSignal(21, "SIGTTIN",false,true,   true,   "to readers process group upon background tty read");
   AddSignal(22, "SIGTTOU",false,true,   true,   "to readers process group upon background tty write");
Index: lldb/source/Plugins/Process/Utility/MipsLinuxSignals.cpp
===
--- lldb/source/Plugins/Process/Utility/MipsLinuxSignals.cpp
+++ lldb/source/Plugins/Process/Utility/MipsLinuxSignals.cpp
@@ -45,7 +45,7 @@
 "SIGPOLL");
   AddSignal(23, "SIGSTOP", true, true, true, "process stop");
   AddSignal(24, "SIGTSTP", false, true, true, "tty stop");
-  AddSignal(25, "SIGCONT", false, true, true, "process continue");
+  AddSignal(25, "SIGCONT", false, false, true, "process continue");
   AddSignal(26, "SIGTTIN", false, true, true, "background tty read");
   AddSignal(27, "SIGTTOU", false, true, true, "background tty write");
   AddSignal(28, "SIGVTALRM", false, true, true, "virtual time alarm");
Index: lldb/source/Plugins/Process/Utility/LinuxSignals

[Lldb-commits] [PATCH] D88841: [intel pt] Refactor parsing

[walter erquinigo via Phabricator via lldb-commits]

wallace updated this revision to Diff 297075.
wallace added a comment.

- Added “trace schema all”, following the pattern from "trace  all", 
and added a test for this.
- Created a non-static version of GetSchema in Trace.h
- Cannot delete Trace() {}, as there’s a compilation error. Could be because 
some constructors have been marked as deleted, so the compiler wants explicit 
declarations.
- Created the lldb_private::trace_intel_pt namespace
- Deleted all unnecessary namespace and “using namespace” usages.
- Using StringRef more ubiquitously now and other small fixes requested by Pavel


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88841/new/

https://reviews.llvm.org/D88841

Files:
  lldb/include/lldb/Core/PluginManager.h
  lldb/include/lldb/Target/Trace.h
  lldb/include/lldb/Target/TraceSessionFileParser.h
  lldb/include/lldb/Target/TraceSettingsParser.h
  lldb/include/lldb/lldb-forward.h
  lldb/include/lldb/lldb-private-interfaces.h
  lldb/source/Commands/CommandObjectTrace.cpp
  lldb/source/Core/PluginManager.cpp
  lldb/source/Plugins/Trace/intel-pt/CMakeLists.txt
  lldb/source/Plugins/Trace/intel-pt/ThreadIntelPT.cpp
  lldb/source/Plugins/Trace/intel-pt/ThreadIntelPT.h
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPT.cpp
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPT.h
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPTSessionFileParser.cpp
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPTSessionFileParser.h
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPTSettingsParser.cpp
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPTSettingsParser.h
  lldb/source/Target/CMakeLists.txt
  lldb/source/Target/Trace.cpp
  lldb/source/Target/TraceSessionFileParser.cpp
  lldb/source/Target/TraceSettingsParser.cpp
  lldb/test/API/commands/trace/TestTraceLoad.py
  lldb/test/API/commands/trace/TestTraceSchema.py

Index: lldb/test/API/commands/trace/TestTraceSchema.py
===
--- lldb/test/API/commands/trace/TestTraceSchema.py
+++ lldb/test/API/commands/trace/TestTraceSchema.py
@@ -20,3 +20,15 @@
 def testInvalidPluginSchema(self):
 self.expect("trace schema invalid-plugin", error=True,
 substrs=['error: no trace plug-in matches the specified type: "invalid-plugin"'])
+
+def testAllSchemas(self):
+self.expect("trace schema all", substrs=['''{
+  "trace": {
+"type": "intel-pt",
+"pt_cpu": {
+  "vendor": "intel" | "unknown",
+  "family": integer,
+  "model": integer,
+  "stepping": integer
+}
+  },'''])
Index: lldb/test/API/commands/trace/TestTraceLoad.py
===
--- lldb/test/API/commands/trace/TestTraceLoad.py
+++ lldb/test/API/commands/trace/TestTraceLoad.py
@@ -40,7 +40,7 @@
 src_dir = self.getSourceDir()
 # We test first an invalid type
 self.expect("trace load -v " + os.path.join(src_dir, "intelpt-trace", "trace_bad.json"), error=True,
-  substrs=['''error: expected object at settings.processes[0]
+  substrs=['''error: expected object at traceSession.processes[0]
 
 Context:
 {
@@ -53,7 +53,7 @@
 
 Schema:
 {
- "trace": {
+  "trace": {
 "type": "intel-pt",
 "pt_cpu": {
   "vendor": "intel" | "unknown",
@@ -63,32 +63,35 @@
 }
   },'''])
 
-# Now we test a missing field in the global settings
+# Now we test a missing field in the global session file
 self.expect("trace load -v " + os.path.join(src_dir, "intelpt-trace", "trace_bad2.json"), error=True,
-substrs=['error: missing value at settings.processes[1].triple', "Context", "Schema"])
+substrs=['error: missing value at traceSession.processes[1].triple', "Context", "Schema"])
 
 # Now we test a missing field in the intel-pt settings
 self.expect("trace load -v " + os.path.join(src_dir, "intelpt-trace", "trace_bad4.json"), error=True,
-substrs=['''error: missing value at settings.trace.pt_cpu.family
+substrs=['''error: missing value at traceSession.trace.pt_cpu.family
 
 Context:
 {
-  "pt_cpu": /* error: missing value */ {
-"model": 79,
-"stepping": 1,
-"vendor": "intel"
-  },
-  "type": "intel-pt"
+  "processes": [],
+  "trace": {
+"pt_cpu": /* error: missing value */ {
+  "model": 79,
+  "stepping": 1,
+  "vendor": "intel"
+},
+"type": "intel-pt"
+  }
 }''', "Schema"])
 
 # Now we test an incorrect load address in the intel-pt settings
 self.expect("trace load -v " + os.path.join(src_dir, "intelpt-trace", "trace_bad5.json"), error=True,
-substrs=['error: expected numeric string at settings.processes[0].modules[0].loadAddress',
+substrs=['error: expected numeric string at traceSession.processes[0].modules[0].loadAddress',
  '"loadAddress": /* error: expected numeric string */ 40,', "Schema"])
 
  

Re: [Lldb-commits] [llvm-dev] [cfe-dev] Upcoming upgrade of LLVM buildbot

[Galina Kistanova via lldb-commits]

Hi Paula,

This error is fine. The buildbot has tested the worker version. 0.8.x
apparently does not have that method.
The error gets handled gracefully on the server side. At least it seems so
so far.

That should not prevent your bot from connecting.

Thanks

Galina

On Thu, Oct 8, 2020 at 2:11 PM Paula Askar  wrote:

> Hey Andrzej,
>
> What are you seeing in your buildbot logs? Is it this error?
> `twisted.spread.flavors.NoSuchMethod: No such method:
> remote_getWorkerInfo`
>
> If so, you might want to try updating your buildbot worker.
> I updated llvmlibc's to 2.8.4 and that seemed to solve the connection
> problem:
> https://github.com/llvm/llvm-project/commit/f60686f35cc89504f3411f49cf16a651a74be6eb
>
> Best,
> Paula Askar
>
>
> On Thu, Oct 8, 2020 at 5:43 AM Andrzej Warzynski via llvm-dev
>  wrote:
> >
> > Our Flang-aarch64 buildbots just won't connect to the main Buildbot
> > master anymore. I switched them to the staging buildbot master instead
> > and it seems fine for now. Is there anything that we can/should tweak at
> > our end?
> >
> > http://lab.llvm.org:8014/#/waterfall?tags=flang
> >
> > -Andrzej
> >
> > On 08/10/2020 00:31, Galina Kistanova via cfe-dev wrote:
> > > They are online now -
> http://lab.llvm.org:8011/#/waterfall?tags=sanitizer
> > >
> > > AnnotatedCommand has severe design conflict with the new buildbot.
> > > We have changed it to be safe and still do something useful, but it
> will
> > > need more love and care.
> > >
> > > Please let me know if you have some spare time to work on porting
> > > AnnotatedCommand.
> > >
> > > Thanks
> > >
> > > Galina
> > >
> > > On Wed, Oct 7, 2020 at 2:57 PM Vitaly Buka  > > > wrote:
> > >
> > > It looks like all sanitizer builder are still offline
> > > http://lab.llvm.org:8011/#/builders
> > >
> > > On Tue, 6 Oct 2020 at 00:34, Galina Kistanova via cfe-commits
> > > mailto:cfe-comm...@lists.llvm.org>>
> wrote:
> > >
> > > Hello everyone,
> > >
> > > The staging buildbot was up and running for 6 days now, and
> > > looks good.
> > >
> > > Tomorrow at 12:00 PM PDT we will switch the production buildbot
> > > to the new version.
> > >
> > > If you are a bot owner, you do not need to do anything at this
> > > point, unless I'll ask you to help.
> > > The buildbot will go down for a short period of time, and then
> a
> > > new version will come up and will accept connections from your
> bots.
> > >
> > > Please note that the new version has a bit different URL
> > > structure. You will need to update the bookmarks or scripts if
> > > you have stored direct URLs to inside the buldbot.
> > >
> > > We will be watching the production and staging bots and will be
> > > improving zorg for the next week or so.
> > >
> > > I will need your feedback about blame e-mails delivery, IRC
> > > reporting issues, and anything you could spot wrong with the
> new
> > > bot. I  hope the transition will go smoothly and we will handle
> > > issues quickly if any would come up.
> > >
> > > After production is good and we have about a week of running
> > > history, I'll ask the bot owners to upgrade buildbots on their
> > > side. Please do not upgrade your buildbots unless I'll ask you
> > > to. We are trying to limit a number of moving parts at this
> > > stage. We will start accepting change to zorg at this point.
> > > Please feel free to talk to me if you will have a special
> > > situation and if you would absolutely have to make changes.
> > >
> > > Thanks for your support and help. And please feel free to ask
> if
> > > you have questions.
> > >
> > > Galina
> > >
> > >
> > > On Thu, Sep 10, 2020 at 9:35 PM Galina Kistanova
> > > mailto:gkistan...@gmail.com>> wrote:
> > >
> > > Hello everyone,
> > >
> > > The buildbot upgrade is entering the phase when the results
> > > to become visible.
> > >
> > > No change is required at this time on any of the builders.
> > > The bot owners could upgrade the buildbot on build
> computers
> > > later, at their convenience, as this is not on the critical
> > > path.
> > >
> > > We are going to upgrade the staging bot first. Then, once
> > > that is stable and all detected issues are resolved, we
> will
> > > upgrade the production bot.
> > >
> > > I will need some help with testing, and will be asking to
> > > move some of the builders temporarily to the staging. LLVM
> > > buildbot is a piece of critical infrastructure, so more
> eyes
> > > and hands in making sure it works properly the better.
> > >
> > > I'll be posting updates and ETA of particular changes in
>

[Lldb-commits] [lldb] 9d7b08b - [lldb] Format remaining signal table (NFC)

[Jonas Devlieghere via lldb-commits]

Author: Jonas Devlieghere
Date: 2020-10-08T21:51:41-07:00
New Revision: 9d7b08bd0657688c186b5b3d39512c484e8c37f5

URL: 
https://github.com/llvm/llvm-project/commit/9d7b08bd0657688c186b5b3d39512c484e8c37f5
DIFF: 
https://github.com/llvm/llvm-project/commit/9d7b08bd0657688c186b5b3d39512c484e8c37f5.diff

LOG: [lldb] Format remaining signal table (NFC)

Restore the signal tables to its original glory and mark it as not to be
clang-formatted.

Added: 


Modified: 
lldb/source/Plugins/Process/Utility/LinuxSignals.cpp
lldb/source/Plugins/Process/Utility/MipsLinuxSignals.cpp
lldb/source/Target/UnixSignals.cpp

Removed: 




diff  --git a/lldb/source/Plugins/Process/Utility/LinuxSignals.cpp 
b/lldb/source/Plugins/Process/Utility/LinuxSignals.cpp
index 568939029aee..d4b0f4039da9 100644
--- a/lldb/source/Plugins/Process/Utility/LinuxSignals.cpp
+++ b/lldb/source/Plugins/Process/Utility/LinuxSignals.cpp
@@ -14,79 +14,72 @@ LinuxSignals::LinuxSignals() : UnixSignals() { Reset(); }
 
 void LinuxSignals::Reset() {
   m_signals.clear();
-  //SIGNO  NAME SUPPRESS STOP   NOTIFY DESCRIPTION ALIAS
-  //=  ===   =  ==
-  //==   ==
-  AddSignal(1, "SIGHUP", false, true, true, "hangup");
-  AddSignal(2, "SIGINT", true, true, true, "interrupt");
-  AddSignal(3, "SIGQUIT", false, true, true, "quit");
-  AddSignal(4, "SIGILL", false, true, true, "illegal instruction");
-  AddSignal(5, "SIGTRAP", true, true, true,
-"trace trap (not reset when caught)");
-  AddSignal(6, "SIGABRT", false, true, true, "abort()/IOT trap", "SIGIOT");
-  AddSignal(7, "SIGBUS", false, true, true, "bus error");
-  AddSignal(8, "SIGFPE", false, true, true, "floating point exception");
-  AddSignal(9, "SIGKILL", false, true, true, "kill");
-  AddSignal(10, "SIGUSR1", false, true, true, "user defined signal 1");
-  AddSignal(11, "SIGSEGV", false, true, true, "segmentation violation");
-  AddSignal(12, "SIGUSR2", false, true, true, "user defined signal 2");
-  AddSignal(13, "SIGPIPE", false, true, true,
-"write to pipe with reading end closed");
-  AddSignal(14, "SIGALRM", false, false, false, "alarm");
-  AddSignal(15, "SIGTERM", false, true, true, "termination requested");
-  AddSignal(16, "SIGSTKFLT", false, true, true, "stack fault");
-  AddSignal(17, "SIGCHLD", false, false, true, "child status has changed",
-"SIGCLD");
-  AddSignal(18, "SIGCONT", false, false, true, "process continue");
-  AddSignal(19, "SIGSTOP", true, true, true, "process stop");
-  AddSignal(20, "SIGTSTP", false, true, true, "tty stop");
-  AddSignal(21, "SIGTTIN", false, true, true, "background tty read");
-  AddSignal(22, "SIGTTOU", false, true, true, "background tty write");
-  AddSignal(23, "SIGURG", false, true, true, "urgent data on socket");
-  AddSignal(24, "SIGXCPU", false, true, true, "CPU resource exceeded");
-  AddSignal(25, "SIGXFSZ", false, true, true, "file size limit exceeded");
-  AddSignal(26, "SIGVTALRM", false, true, true, "virtual time alarm");
-  AddSignal(27, "SIGPROF", false, false, false, "profiling time alarm");
-  AddSignal(28, "SIGWINCH", false, true, true, "window size changes");
-  AddSignal(29, "SIGIO", false, true, true, "input/output ready/Pollable 
event",
-"SIGPOLL");
-  AddSignal(30, "SIGPWR", false, true, true, "power failure");
-  AddSignal(31, "SIGSYS", false, true, true, "invalid system call");
-  AddSignal(32, "SIG32", false, false, false,
-"threading library internal signal 1");
-  AddSignal(33, "SIG33", false, false, false,
-"threading library internal signal 2");
-  AddSignal(34, "SIGRTMIN", false, false, false, "real time signal 0");
-  AddSignal(35, "SIGRTMIN+1", false, false, false, "real time signal 1");
-  AddSignal(36, "SIGRTMIN+2", false, false, false, "real time signal 2");
-  AddSignal(37, "SIGRTMIN+3", false, false, false, "real time signal 3");
-  AddSignal(38, "SIGRTMIN+4", false, false, false, "real time signal 4");
-  AddSignal(39, "SIGRTMIN+5", false, false, false, "real time signal 5");
-  AddSignal(40, "SIGRTMIN+6", false, false, false, "real time signal 6");
-  AddSignal(41, "SIGRTMIN+7", false, false, false, "real time signal 7");
-  AddSignal(42, "SIGRTMIN+8", false, false, false, "real time signal 8");
-  AddSignal(43, "SIGRTMIN+9", false, false, false, "real time signal 9");
-  AddSignal(44, "SIGRTMIN+10", false, false, false, "real time signal 10");
-  AddSignal(45, "SIGRTMIN+11", false, false, false, "real time signal 11");
-  AddSignal(46, "SIGRTMIN+12", false, false, false, "real time signal 12");
-  AddSignal(47, "SIGRTMIN+13", false, false, false, "real time signal 13");
-  AddSignal(48, "SIGRTMIN+14", false, false, false, "real time signal 14");
-  AddSignal(49, "SIGRTMIN+15", false, false, false, "real time signal 15");
-  AddSignal(50, 

[Lldb-commits] [PATCH] D88769: [trace] Scaffold "thread trace dump instructions"

[walter erquinigo via Phabricator via lldb-commits]

wallace updated this revision to Diff 297127.
wallace added a comment.

Rebase and made some cosmetic fixes.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88769/new/

https://reviews.llvm.org/D88769

Files:
  lldb/include/lldb/Target/Target.h
  lldb/include/lldb/Target/Thread.h
  lldb/include/lldb/Target/Trace.h
  lldb/source/Commands/CommandObjectThread.cpp
  lldb/source/Commands/Options.td
  lldb/source/Plugins/Process/CMakeLists.txt
  lldb/source/Plugins/Process/Trace/CMakeLists.txt
  lldb/source/Plugins/Process/Trace/ProcessTrace.cpp
  lldb/source/Plugins/Process/Trace/ProcessTrace.h
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPT.cpp
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPT.h
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPTSessionFileParser.cpp
  lldb/source/Target/Target.cpp
  lldb/source/Target/Thread.cpp
  lldb/test/API/commands/trace/TestTraceDumpInstructions.py
  lldb/test/API/commands/trace/TestTraceLoad.py
  lldb/test/API/commands/trace/intelpt-trace/trace_2threads.json

Index: lldb/test/API/commands/trace/intelpt-trace/trace_2threads.json
===
--- /dev/null
+++ lldb/test/API/commands/trace/intelpt-trace/trace_2threads.json
@@ -0,0 +1,35 @@
+{
+  "trace": {
+"type": "intel-pt",
+"pt_cpu": {
+  "vendor": "intel",
+  "family": 6,
+  "model": 79,
+  "stepping": 1
+}
+  },
+  "processes": [
+{
+  "pid": 1234,
+  "triple": "x86_64-*-linux",
+  "threads": [
+{
+  "tid": 3842849,
+  "traceFile": "3842849.trace"
+},
+{
+  "tid": 3842850,
+  "traceFile": "3842849.trace"
+}
+  ],
+  "modules": [
+{
+  "file": "a.out",
+  "systemPath": "a.out",
+  "loadAddress": "0x0040",
+  "uuid": "6AA9A4E2-6F28-2F33-377D-59FECE874C71-5B41261A"
+}
+  ]
+}
+  ]
+}
Index: lldb/test/API/commands/trace/TestTraceLoad.py
===
--- lldb/test/API/commands/trace/TestTraceLoad.py
+++ lldb/test/API/commands/trace/TestTraceLoad.py
@@ -35,6 +35,10 @@
 
 self.assertEqual("6AA9A4E2-6F28-2F33-377D-59FECE874C71-5B41261A", module.GetUUIDString())
 
+# check that the Process and Thread objects were created correctly
+self.expect("thread info", substrs=["tid = 3842849"])
+self.expect("thread list", substrs=["Process 1234 stopped", "tid = 3842849"])
+
 
 def testLoadInvalidTraces(self):
 src_dir = self.getSourceDir()
Index: lldb/test/API/commands/trace/TestTraceDumpInstructions.py
===
--- /dev/null
+++ lldb/test/API/commands/trace/TestTraceDumpInstructions.py
@@ -0,0 +1,91 @@
+import lldb
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+from lldbsuite.test.decorators import *
+
+class TestTraceDumpInstructions(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+NO_DEBUG_INFO_TESTCASE = True
+
+def setUp(self):
+TestBase.setUp(self)
+if 'intel-pt' not in configuration.enabled_plugins:
+self.skipTest("The intel-pt test plugin is not enabled")
+
+def testErrorMessages(self):
+# We first check the output when there are no targets
+self.expect("thread trace dump instructions",
+substrs=["error: invalid target, create a target using the 'target create' command"],
+error=True)
+
+# We now check the output when there's a non-running target
+self.expect("target create " + os.path.join(self.getSourceDir(), "intelpt-trace", "a.out"))
+
+self.expect("thread trace dump instructions",
+substrs=["error: invalid process"],
+error=True)
+
+# Now we check the output when there's a running target without a trace
+self.expect("b main")
+self.expect("run")
+
+self.expect("thread trace dump instructions",
+substrs=["error: no trace in this target"])
+
+def testDumpInstructions(self):
+self.expect("trace load -v " + os.path.join(self.getSourceDir(), "intelpt-trace", "trace.json"),
+substrs=["intel-pt"])
+
+self.expect("thread trace dump instructions",
+substrs=['thread #1: tid = 3842849, total instructions = 1000',
+ 'would print 20 instructions from position 0'])
+
+# We check if we can pass count and offset
+self.expect("thread trace dump instructions --count 5 --start-position 10",
+substrs=['thread #1: tid = 3842849, total instructions = 1000',
+ 'would print 5 instructions from position 10'])
+
+# We check if we can access the thread by index id
+self.expect("thread trace dump instructions 1",
+substrs=['thread #1: tid = 3842849, total instructions