[Lldb-commits] [PATCH] D90729: [trace][intel-pt] Scaffold the 'thread trace start | stop' commands

[walter erquinigo 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 rGfb19f11ef47b: [trace][intel-pt] Scaffold the thread 
trace start | stop commands (authored by wallace).

Changed prior to commit:
  https://reviews.llvm.org/D90729?vs=306177=306279#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90729

Files:
  lldb/include/lldb/Core/PluginManager.h
  lldb/include/lldb/Interpreter/CommandObjectMultiword.h
  lldb/include/lldb/Target/PostMortemProcess.h
  lldb/include/lldb/Target/Process.h
  lldb/include/lldb/Target/ProcessTrace.h
  lldb/include/lldb/Target/Trace.h
  lldb/include/lldb/lldb-enumerations.h
  lldb/include/lldb/lldb-private-interfaces.h
  lldb/source/Commands/CMakeLists.txt
  lldb/source/Commands/CommandObjectMultiword.cpp
  lldb/source/Commands/CommandObjectThread.cpp
  lldb/source/Commands/CommandObjectThreadUtil.cpp
  lldb/source/Commands/CommandObjectThreadUtil.h
  lldb/source/Core/PluginManager.cpp
  lldb/source/Interpreter/CommandObject.cpp
  lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp
  lldb/source/Plugins/Process/elf-core/ProcessElfCore.h
  lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
  lldb/source/Plugins/Process/mach-core/ProcessMachCore.h
  lldb/source/Plugins/Process/minidump/ProcessMinidump.cpp
  lldb/source/Plugins/Process/minidump/ProcessMinidump.h
  lldb/source/Plugins/Trace/intel-pt/CMakeLists.txt
  lldb/source/Plugins/Trace/intel-pt/CommandObjectTraceStartIntelPT.cpp
  lldb/source/Plugins/Trace/intel-pt/CommandObjectTraceStartIntelPT.h
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPT.cpp
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPTOptions.td
  lldb/source/Target/Process.cpp
  lldb/source/Target/ProcessTrace.cpp
  lldb/test/API/commands/trace/TestTraceDumpInstructions.py
  lldb/test/API/commands/trace/TestTraceStartStop.py

Index: lldb/test/API/commands/trace/TestTraceStartStop.py
===
--- /dev/null
+++ lldb/test/API/commands/trace/TestTraceStartStop.py
@@ -0,0 +1,73 @@
+import lldb
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+from lldbsuite.test.decorators import *
+
+class TestTraceLoad(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 expectGenericHelpMessageForStartCommand(self):
+self.expect("help thread trace start",
+substrs=["Syntax: thread trace start []"])
+
+def testStartStopSessionFileThreads(self):
+# it should fail for processes from json session files
+self.expect("trace load -v " + os.path.join(self.getSourceDir(), "intelpt-trace", "trace.json"))
+self.expect("thread trace start", error=True,
+substrs=["error: Tracing is not supported. Can't trace a non-live process"])
+
+# the help command should be the generic one, as it's not a live process
+self.expectGenericHelpMessageForStartCommand()
+
+# this should fail because 'trace stop' is not yet implemented
+self.expect("thread trace stop", error=True,
+substrs=["error: Failed stopping thread 3842849"])
+
+@skipIf(oslist=no_match(['linux']), archs=no_match(['i386', 'x86_64']))
+def testStartStopLiveThreads(self):
+# The help command should be the generic one if there's no process running
+self.expectGenericHelpMessageForStartCommand()
+
+self.expect("thread trace start", error=True,
+substrs=["error: Process not available"])
+
+self.expect("file " + os.path.join(self.getSourceDir(), "intelpt-trace", "a.out"))
+self.expect("b main")
+
+self.expect("thread trace start", error=True,
+substrs=["error: Process not available"])
+
+# The help command should be the generic one if there's still no process running
+self.expectGenericHelpMessageForStartCommand()
+
+self.expect("r")
+
+# the help command should be the intel-pt one now
+self.expect("help thread trace start",
+substrs=["Start tracing one or more threads with intel-pt.",
+ "Syntax: thread trace start [  ...] []"])
+
+self.expect("thread trace start",
+patterns=["would trace tid .* with size_in_kb 4 and custom_config 0"])
+
+self.expect("thread trace start --size 20 --custom-config 1",
+patterns=["would trace tid .* with size_in_kb 20 and custom_config 1"])
+
+# This fails because "trace stop" is not yet implemented.
+self.expect("thread trace stop", error=True,
+substrs=["error: Process is not being traced"])
+
+

[Lldb-commits] [lldb] fb19f11 - [trace][intel-pt] Scaffold the 'thread trace start | stop' commands

[Walter Erquinigo via lldb-commits]

Author: Walter Erquinigo
Date: 2020-11-18T18:24:36-08:00
New Revision: fb19f11ef47bc479d42c11450817c5e855a9830b

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

LOG: [trace][intel-pt] Scaffold the 'thread trace start | stop' commands

Depends on D90490.

The stop command is simple and invokes the new method 
Trace::StopTracingThread(thread).

On the other hand, the start command works by delegating its implementation to 
a CommandObject provided by the Trace plugin. This is necessary because each 
trace plugin needs different options for this command. There's even the chance 
that a Trace plugin can't support live tracing, but instead supports offline 
decoding and analysis, which means that "thread trace dump instructions" works 
but "thread trace start" doest. Because of this and a few other reasons, it's 
better to have each plugin provide this implementation.

Besides, I'm using the GetSupportedTraceType method introduced in D90490 to 
quickly infer what's the trace plug-in that works for the current process.

As an implementation note, I moved CommandObjectIterateOverThreads to its 
header so that I can use it from the IntelPT plugin. Besides, the actual start 
and stop logic for intel-pt is not part of this diff.

Reviewed By: clayborg

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

Added: 
lldb/include/lldb/Target/PostMortemProcess.h
lldb/source/Commands/CommandObjectThreadUtil.cpp
lldb/source/Commands/CommandObjectThreadUtil.h
lldb/source/Plugins/Trace/intel-pt/CommandObjectTraceStartIntelPT.cpp
lldb/source/Plugins/Trace/intel-pt/CommandObjectTraceStartIntelPT.h
lldb/source/Plugins/Trace/intel-pt/TraceIntelPTOptions.td
lldb/test/API/commands/trace/TestTraceStartStop.py

Modified: 
lldb/include/lldb/Core/PluginManager.h
lldb/include/lldb/Interpreter/CommandObjectMultiword.h
lldb/include/lldb/Target/Process.h
lldb/include/lldb/Target/ProcessTrace.h
lldb/include/lldb/Target/Trace.h
lldb/include/lldb/lldb-enumerations.h
lldb/include/lldb/lldb-private-interfaces.h
lldb/source/Commands/CMakeLists.txt
lldb/source/Commands/CommandObjectMultiword.cpp
lldb/source/Commands/CommandObjectThread.cpp
lldb/source/Core/PluginManager.cpp
lldb/source/Interpreter/CommandObject.cpp
lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp
lldb/source/Plugins/Process/elf-core/ProcessElfCore.h
lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
lldb/source/Plugins/Process/mach-core/ProcessMachCore.h
lldb/source/Plugins/Process/minidump/ProcessMinidump.cpp
lldb/source/Plugins/Process/minidump/ProcessMinidump.h
lldb/source/Plugins/Trace/intel-pt/CMakeLists.txt
lldb/source/Plugins/Trace/intel-pt/TraceIntelPT.cpp
lldb/source/Target/Process.cpp
lldb/source/Target/ProcessTrace.cpp
lldb/test/API/commands/trace/TestTraceDumpInstructions.py

Removed: 




diff  --git a/lldb/include/lldb/Core/PluginManager.h 
b/lldb/include/lldb/Core/PluginManager.h
index 77ace59a98b8..0ac8308d1758 100644
--- a/lldb/include/lldb/Core/PluginManager.h
+++ b/lldb/include/lldb/Core/PluginManager.h
@@ -333,12 +333,17 @@ class PluginManager {
   // Trace
   static bool RegisterPlugin(ConstString name, const char *description,
  TraceCreateInstance create_callback,
- llvm::StringRef schema);
+ llvm::StringRef schema,
+ TraceGetStartCommand get_start_command);
 
   static bool UnregisterPlugin(TraceCreateInstance create_callback);
 
   static TraceCreateInstance GetTraceCreateCallback(ConstString plugin_name);
 
+  static lldb::CommandObjectSP
+  GetTraceStartCommand(llvm::StringRef plugin_name,
+   CommandInterpreter );
+
   /// Get the JSON schema for a trace session file corresponding to the given
   /// plugin.
   ///

diff  --git a/lldb/include/lldb/Interpreter/CommandObjectMultiword.h 
b/lldb/include/lldb/Interpreter/CommandObjectMultiword.h
index 6b383f8cfb34..f330a745f9bd 100644
--- a/lldb/include/lldb/Interpreter/CommandObjectMultiword.h
+++ b/lldb/include/lldb/Interpreter/CommandObjectMultiword.h
@@ -82,6 +82,10 @@ class CommandObjectProxy : public CommandObject {
   // for this object.
   virtual CommandObject *GetProxyCommandObject() = 0;
 
+  llvm::StringRef GetSyntax() override;
+
+  llvm::StringRef GetHelp() override;
+
   llvm::StringRef GetHelpLong() override;
 
   bool IsRemovable() const override;
@@ -121,6 +125,11 @@ class CommandObjectProxy : public CommandObject {
   const char *GetRepeatCommand(Args _command_args,
uint32_t index) override;
 
+  /// \return
+  /// An error message to be displayed when the command is 

[Lldb-commits] [lldb] f3aa9e3 - [MachO] Update embedded part of ObjectFileMachO for Mangled API change

[Jonas Devlieghere via lldb-commits]

Author: Jonas Devlieghere
Date: 2020-11-18T14:47:31-08:00
New Revision: f3aa9e36d91b7b0f4f24f7a3b13cf80c11356e5e

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

LOG: [MachO] Update embedded part of ObjectFileMachO for Mangled API change

Mangled::GetName and Mangled::GetDemangledName no longer take any
arguments.

Added: 


Modified: 
lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp

Removed: 




diff  --git a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp 
b/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
index f9f27d0ee6c2..2653290ea8c7 100644
--- a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
+++ b/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
@@ -3032,12 +3032,10 @@ size_t ObjectFileMachO::ParseSymtab() {
 // contains just the filename, so here we combine
 // it with the first one if we are minimizing the
 // symbol table
-const char *so_path =
-sym[sym_idx - 1]
-.GetMangled()
-.GetDemangledName(
-lldb::eLanguageTypeUnknown)
-.AsCString();
+const char *so_path = sym[sym_idx - 1]
+  .GetMangled()
+  .GetDemangledName()
+  .AsCString();
 if (so_path && so_path[0]) {
   std::string full_so_path(so_path);
   const size_t double_slash_pos =
@@ -3469,12 +3467,10 @@ size_t ObjectFileMachO::ParseSymtab() {
   sym[sym_idx].GetMangled().SetValue(
   const_symbol_name, symbol_name_is_mangled);
   if (is_gsym && is_debug) {
-const char *gsym_name =
-sym[sym_idx]
-.GetMangled()
-.GetName(lldb::eLanguageTypeUnknown,
- Mangled::ePreferMangled)
-.GetCString();
+const char *gsym_name = sym[sym_idx]
+.GetMangled()
+.GetName()
+.GetCString();
 if (gsym_name)
   N_GSYM_name_to_sym_idx[gsym_name] = sym_idx;
   }
@@ -3554,12 +3550,8 @@ size_t ObjectFileMachO::ParseSymtab() {
 bool found_it = false;
 for (auto pos = range.first; pos != range.second;
  ++pos) {
-  if (sym[sym_idx].GetMangled().GetName(
-  lldb::eLanguageTypeUnknown,
-  Mangled::ePreferMangled) ==
-  sym[pos->second].GetMangled().GetName(
-  lldb::eLanguageTypeUnknown,
-  Mangled::ePreferMangled)) {
+  if (sym[sym_idx].GetMangled().GetName() ==
+  sym[pos->second].GetMangled().GetName()) {
 m_nlist_idx_to_sym_idx[nlist_idx] = 
pos->second;
 // We just need the flags from the linker
 // symbol, so put these flags
@@ -3599,12 +3591,8 @@ size_t ObjectFileMachO::ParseSymtab() {
 bool found_it = false;
 for (auto pos = range.first; pos != range.second;
  ++pos) {
-  if (sym[sym_idx].GetMangled().GetName(
-  lldb::eLanguageTypeUnknown,
-  Mangled::ePreferMangled) ==
-  sym[pos->second].GetMangled().GetName(
-  lldb::eLanguageTypeUnknown,
-  Mangled::ePreferMangled)) {
+  if (sym[sym_idx].GetMangled().GetName() ==
+  sym[pos->second].GetMangled().GetName()) {
 m_nlist_idx_to_sym_idx[nlist_idx] = 
pos->second;
 // We just need the 

[Lldb-commits] [PATCH] D91742: [lldb] Add examples and reword source-map help string

[Dave Lee via Phabricator via lldb-commits]

kastiglione created this revision.
kastiglione added reviewers: aprantl, keith.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.
kastiglione requested review of this revision.
Herald added a subscriber: JDevlieghere.

Update the help string for `target.source-map` to remove the use of the word
"duple" and to add examples. Additionally I rewrote parts with the goal of
making the description more concrete.

rdar://68736012


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D91742

Files:
  lldb/source/Target/TargetProperties.td


Index: lldb/source/Target/TargetProperties.td
===
--- lldb/source/Target/TargetProperties.td
+++ lldb/source/Target/TargetProperties.td
@@ -36,7 +36,7 @@
 Desc<"Skip function prologues when setting breakpoints by name.">;
   def SourceMap: Property<"source-map", "PathMap">,
 DefaultStringValue<"">,
-Desc<"Source path remappings are used to track the change of location 
between a source file when built, and where it exists on the current system.  
It consists of an array of duples, the first element of each duple is some part 
(starting at the root) of the path to the file when it was built, and the 
second is where the remainder of the original build hierarchy is rooted on the 
local system.  Each element of the array is checked in order and the first one 
that results in a match wins.">;
+Desc<"Source path remappings are used to substitute path prefixes of 
source files, typically needed to debug from a different host than the one that 
built the target.  The source-map property consists of an array of pairs, the 
first element is a path prefix, and the second is its replacement.  The syntax 
is `prefix1 replacement1 prefix2 replacement2...`.  The pairs are checked in 
order, the first prefix that matches is used, and that prefix is substituted 
with the replacement.  A common pattern is to use source-map in conjunction 
with the clang -fdebug-prefix-map flag.  In the build, use 
`-fdebug-prefix-map=/path/to/build_dir=.` to rewrite the host specific build 
directory to `.`.  Then for debugging, use `settings set target.source-map . 
/path/to/local_dir` to convert `.` to a valid local path.">;
   def ExecutableSearchPaths: Property<"exec-search-paths", "FileSpecList">,
 DefaultStringValue<"">,
 Desc<"Executable search paths to use when locating executable files whose 
paths don't match the local file system.">;


Index: lldb/source/Target/TargetProperties.td
===
--- lldb/source/Target/TargetProperties.td
+++ lldb/source/Target/TargetProperties.td
@@ -36,7 +36,7 @@
 Desc<"Skip function prologues when setting breakpoints by name.">;
   def SourceMap: Property<"source-map", "PathMap">,
 DefaultStringValue<"">,
-Desc<"Source path remappings are used to track the change of location between a source file when built, and where it exists on the current system.  It consists of an array of duples, the first element of each duple is some part (starting at the root) of the path to the file when it was built, and the second is where the remainder of the original build hierarchy is rooted on the local system.  Each element of the array is checked in order and the first one that results in a match wins.">;
+Desc<"Source path remappings are used to substitute path prefixes of source files, typically needed to debug from a different host than the one that built the target.  The source-map property consists of an array of pairs, the first element is a path prefix, and the second is its replacement.  The syntax is `prefix1 replacement1 prefix2 replacement2...`.  The pairs are checked in order, the first prefix that matches is used, and that prefix is substituted with the replacement.  A common pattern is to use source-map in conjunction with the clang -fdebug-prefix-map flag.  In the build, use `-fdebug-prefix-map=/path/to/build_dir=.` to rewrite the host specific build directory to `.`.  Then for debugging, use `settings set target.source-map . /path/to/local_dir` to convert `.` to a valid local path.">;
   def ExecutableSearchPaths: Property<"exec-search-paths", "FileSpecList">,
 DefaultStringValue<"">,
 Desc<"Executable search paths to use when locating executable files whose paths don't match the local file system.">;
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D90729: [trace][intel-pt] Scaffold the 'thread trace start | stop' commands

[Greg Clayton via Phabricator via lldb-commits]

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

Thanks for chiming in Pavel. LGTM.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90729

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

[Lldb-commits] [PATCH] D91508: [LLDB/Lua] add support for one-liner breakpoint callback

[Pedro Tammela via Phabricator via lldb-commits]

tammela added inline comments.



Comment at: lldb/source/Plugins/ScriptInterpreter/Lua/Lua.cpp:60-78
+static int runCallback(lua_State *L) {
+  LuaCallback *callback = static_cast(lua_touserdata(L, -1));
+  return (*callback)(L);
+}
+
+llvm::Error Lua::Run(LuaCallback ) {
+  lua_pushcfunction(m_lua_state, runCallback);

labath wrote:
> tammela wrote:
> > labath wrote:
> > > I'm confused. Why use lua to call a c callback, when you could just do 
> > > `calllback()`?
> > Some Lua API functions throw errors, if there's any it will `abort()` the 
> > program if no panic handler or protected call is provided.
> > To guarantee that the callback always runs in a protected environment and 
> > it has error handling, we do the above.
> > Delegating this to the callback itself makes it cumbersome to write.
> Aha, I see.
> 
> So, if I remember my lua correctly (I wrote a c++ lua wrapper once, but that 
> was years ago..), whenever there's a lua exception inside this (c++) 
> callback, lua will longjmp(3) back to the lua_pcall call on line 68, skipping 
> any destructors that should normally be invoked. Is that so?
> 
> If that's the case, then I think this is a dangerous api, that should at the 
> very least get a big fat warning, but that ideally shouldn't exist at all.
> 
> What's the part that makes delegating this to the callback "cumersome to 
> write"? And why can't that be overcome by a suitable utility function which 
> wraps `lua_pcall` or whatever else is needed?
> 
> The approach that we've chosen in python is to have very little code 
> interacting with the python C API directly. Instead, code generally works 
> with our C++ wrappers defined in `PythonDataObject.h`. These functions try to 
> hide the python exception magic as much as possible, and present a c++-y 
> version of the interface.
> 
> Now, since lua is stack-based, something like LuaDataObjects.h would probably 
> not work. However, that doesn't meant we should give up on the c++ wrapper  
> idea altogether. During the intitial reviews, my intention was for the `Lua` 
> class to serve this purpose. I still think this can be achieved if we make 
> the callback functions take `Lua&` instead of `lua_State*` as an argument, 
> and then ensure the class contains whatever is needed to make the callbacks 
> not cumerbsome to write.
> So, if I remember my lua correctly (I wrote a c++ lua wrapper once, but that 
> was years ago..), whenever there's a lua exception inside this (c++) 
> callback, lua will longjmp(3) back to the lua_pcall call on line 68, skipping 
> any destructors that should normally be invoked. Is that so?
>
> If that's the case, then I think this is a dangerous api, that should at the 
> very least get a big fat warning, but that ideally shouldn't exist at all.

You are right. This escaped me completely.
Lua can be compiled to use `try/catch` instead of `longjmp`, but that is an 
exception (no pun intended). Since we rely on the host's library, we need to 
assume that it's using `longjmp`.

> What's the part that makes delegating this to the callback "cumersome to 
> write"? And why can't that be overcome by a suitable utility function which 
> wraps lua_pcall or whatever else is needed?
>
> The approach that we've chosen in python is to have very little code 
> interacting with the python C API directly. Instead, code generally works 
> with our C++ wrappers defined in PythonDataObject.h. These functions try to 
> hide the python exception magic as much as possible, and present a c++-y 
> version of the interface.
>
> Now, since lua is stack-based, something like LuaDataObjects.h would probably 
> not work. However, that doesn't meant we should give up on the c++ wrapper 
> idea altogether. During the intitial reviews, my intention was for the Lua 
> class to serve this purpose. I still think this can be achieved if we make 
> the callback functions take Lua& instead of lua_State* as an argument, and 
> then ensure the class contains whatever is needed to make the callbacks not 
> cumerbsome to write.

Any C++ code that runs in a `lua_pcall` seems to face this issue. I checked a 
very complete C++ Lua wrapper called `sol2` and they seem to have the same 
issue. I don't think there's a way out of it except code discipline.

Lua provides `lua_atpanic` as a way to recover from unprotected throws. Perhaps 
we can leverage this to throw an exception, guaranteeing stack unwinding and 
avoiding a call to `abort()`. We would then let the callback run unprotected 
and delegate any calls to `lua_pcall` to the callback.

Changes proposed:
- Register the panic function on `Lua` ctor
- Let the `Callback` run unprotected
- Wrap the `Callback` call in a `try catch` block
- Change the `Callback` signature to receive `Lua&` and return `llvm::Error`

It looks like it ticks all goals.
- Unprotected Lua errors do not cause lldb to abort.
- Stack unwinding is guaranteed for C++ code interacting with the Lua state.
- 

[Lldb-commits] [PATCH] D90729: [trace][intel-pt] Scaffold the 'thread trace start | stop' commands

[walter erquinigo via Phabricator via lldb-commits]

wallace updated this revision to Diff 306177.
wallace marked 5 inline comments as done.
wallace added a comment.

Renamed to SavedProcess


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90729

Files:
  lldb/include/lldb/Core/PluginManager.h
  lldb/include/lldb/Interpreter/CommandObjectMultiword.h
  lldb/include/lldb/Target/Process.h
  lldb/include/lldb/Target/ProcessTrace.h
  lldb/include/lldb/Target/SavedProcess.h
  lldb/include/lldb/Target/Trace.h
  lldb/include/lldb/lldb-enumerations.h
  lldb/include/lldb/lldb-private-interfaces.h
  lldb/source/Commands/CMakeLists.txt
  lldb/source/Commands/CommandObjectMultiword.cpp
  lldb/source/Commands/CommandObjectThread.cpp
  lldb/source/Commands/CommandObjectThreadUtil.cpp
  lldb/source/Commands/CommandObjectThreadUtil.h
  lldb/source/Core/PluginManager.cpp
  lldb/source/Interpreter/CommandObject.cpp
  lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp
  lldb/source/Plugins/Process/elf-core/ProcessElfCore.h
  lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp
  lldb/source/Plugins/Process/mach-core/ProcessMachCore.h
  lldb/source/Plugins/Process/minidump/ProcessMinidump.cpp
  lldb/source/Plugins/Process/minidump/ProcessMinidump.h
  lldb/source/Plugins/Trace/intel-pt/CMakeLists.txt
  lldb/source/Plugins/Trace/intel-pt/CommandObjectTraceStartIntelPT.cpp
  lldb/source/Plugins/Trace/intel-pt/CommandObjectTraceStartIntelPT.h
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPT.cpp
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPTOptions.td
  lldb/source/Target/Process.cpp
  lldb/source/Target/ProcessTrace.cpp
  lldb/test/API/commands/trace/TestTraceDumpInstructions.py
  lldb/test/API/commands/trace/TestTraceStartStop.py

Index: lldb/test/API/commands/trace/TestTraceStartStop.py
===
--- /dev/null
+++ lldb/test/API/commands/trace/TestTraceStartStop.py
@@ -0,0 +1,73 @@
+import lldb
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+from lldbsuite.test.decorators import *
+
+class TestTraceLoad(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 expectGenericHelpMessageForStartCommand(self):
+self.expect("help thread trace start",
+substrs=["Syntax: thread trace start []"])
+
+def testStartStopSessionFileThreads(self):
+# it should fail for processes from json session files
+self.expect("trace load -v " + os.path.join(self.getSourceDir(), "intelpt-trace", "trace.json"))
+self.expect("thread trace start", error=True,
+substrs=["error: Tracing is not supported. Can't trace a non-live process"])
+
+# the help command should be the generic one, as it's not a live process
+self.expectGenericHelpMessageForStartCommand()
+
+# this should fail because 'trace stop' is not yet implemented
+self.expect("thread trace stop", error=True,
+substrs=["error: Failed stopping thread 3842849"])
+
+@skipIf(oslist=no_match(['linux']), archs=no_match(['i386', 'x86_64']))
+def testStartStopLiveThreads(self):
+# The help command should be the generic one if there's no process running
+self.expectGenericHelpMessageForStartCommand()
+
+self.expect("thread trace start", error=True,
+substrs=["error: Process not available"])
+
+self.expect("file " + os.path.join(self.getSourceDir(), "intelpt-trace", "a.out"))
+self.expect("b main")
+
+self.expect("thread trace start", error=True,
+substrs=["error: Process not available"])
+
+# The help command should be the generic one if there's still no process running
+self.expectGenericHelpMessageForStartCommand()
+
+self.expect("r")
+
+# the help command should be the intel-pt one now
+self.expect("help thread trace start",
+substrs=["Start tracing one or more threads with intel-pt.",
+ "Syntax: thread trace start [  ...] []"])
+
+self.expect("thread trace start",
+patterns=["would trace tid .* with size_in_kb 4 and custom_config 0"])
+
+self.expect("thread trace start --size 20 --custom-config 1",
+patterns=["would trace tid .* with size_in_kb 20 and custom_config 1"])
+
+# This fails because "trace stop" is not yet implemented.
+self.expect("thread trace stop", error=True,
+substrs=["error: Process is not being traced"])
+
+self.expect("c")
+# Now the process has finished, so the commands should fail
+self.expect("thread trace start", error=True,
+substrs=["error: Process must be launched"])

[Lldb-commits] [PATCH] D91728: [lldb] [Process/Utility] Declare register overlaps between ST and MM [WIP]

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

mgorny added a comment.

@labath, what do you think about this approach? What really sucks is that we 
have to repeat the whole voodoo for i386 and amd64 separately.




Comment at: lldb/source/Plugins/Process/Utility/RegisterInfos_x86_64.h:93
   {
\
 #reg #i, nullptr, sizeof(uint64_t),
\
   LLVM_EXTENSION FPR_OFFSET(   
\

To be honest, I completely don't get the indentation below.


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

https://reviews.llvm.org/D91728

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

[Lldb-commits] [PATCH] D91728: [lldb] [Process/Utility] Declare register overlaps between ST and MM

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

mgorny created this revision.
mgorny added reviewers: labath, krytarowski, emaste.
mgorny requested review of this revision.

Explicitly declare register overlaps/invalidation between ST(i) and MMi
registers.


https://reviews.llvm.org/D91728

Files:
  lldb/source/Plugins/Process/Utility/RegisterContextPOSIX_x86.cpp
  lldb/source/Plugins/Process/Utility/RegisterContextPOSIX_x86.h
  lldb/source/Plugins/Process/Utility/RegisterInfos_x86_64.h

Index: lldb/source/Plugins/Process/Utility/RegisterInfos_x86_64.h
===
--- lldb/source/Plugins/Process/Utility/RegisterInfos_x86_64.h
+++ lldb/source/Plugins/Process/Utility/RegisterInfos_x86_64.h
@@ -88,7 +88,7 @@
  nullptr, nullptr, nullptr, 0  \
   }
 
-#define DEFINE_FP_MM(reg, i)   \
+#define DEFINE_FP_MM(reg, i, streg)\
   {\
 #reg #i, nullptr, sizeof(uint64_t),\
   LLVM_EXTENSION FPR_OFFSET(   \
@@ -96,7 +96,9 @@
   {dwarf_mm##i##_x86_64, dwarf_mm##i##_x86_64, \
LLDB_INVALID_REGNUM, LLDB_INVALID_REGNUM,   \
lldb_mm##i##_x86_64 },  \
-   nullptr, nullptr, nullptr, 0\
+   RegisterContextPOSIX_x86::g_contained_##streg,  \
+   RegisterContextPOSIX_x86::g_invalidate_##streg, \
+   nullptr, 0  \
   }
 
 #define DEFINE_XMM(reg, i) \
@@ -277,10 +279,12 @@
 // FP registers.
 DEFINE_FP_ST(st, 0), DEFINE_FP_ST(st, 1), DEFINE_FP_ST(st, 2),
 DEFINE_FP_ST(st, 3), DEFINE_FP_ST(st, 4), DEFINE_FP_ST(st, 5),
-DEFINE_FP_ST(st, 6), DEFINE_FP_ST(st, 7), DEFINE_FP_MM(mm, 0),
-DEFINE_FP_MM(mm, 1), DEFINE_FP_MM(mm, 2), DEFINE_FP_MM(mm, 3),
-DEFINE_FP_MM(mm, 4), DEFINE_FP_MM(mm, 5), DEFINE_FP_MM(mm, 6),
-DEFINE_FP_MM(mm, 7),
+DEFINE_FP_ST(st, 6), DEFINE_FP_ST(st, 7),
+
+DEFINE_FP_MM(mm, 0, st0_64), DEFINE_FP_MM(mm, 1, st1_64),
+DEFINE_FP_MM(mm, 2, st2_64), DEFINE_FP_MM(mm, 3, st3_64),
+DEFINE_FP_MM(mm, 4, st4_64), DEFINE_FP_MM(mm, 5, st5_64),
+DEFINE_FP_MM(mm, 6, st6_64), DEFINE_FP_MM(mm, 7, st7_64),
 
 // XMM registers
 DEFINE_XMM(xmm, 0), DEFINE_XMM(xmm, 1), DEFINE_XMM(xmm, 2),
Index: lldb/source/Plugins/Process/Utility/RegisterContextPOSIX_x86.h
===
--- lldb/source/Plugins/Process/Utility/RegisterContextPOSIX_x86.h
+++ lldb/source/Plugins/Process/Utility/RegisterContextPOSIX_x86.h
@@ -112,6 +112,24 @@
   static uint32_t g_invalidate_fip[];
   static uint32_t g_invalidate_fdp[];
 
+  static uint32_t g_contained_st0_64[];
+  static uint32_t g_contained_st1_64[];
+  static uint32_t g_contained_st2_64[];
+  static uint32_t g_contained_st3_64[];
+  static uint32_t g_contained_st4_64[];
+  static uint32_t g_contained_st5_64[];
+  static uint32_t g_contained_st6_64[];
+  static uint32_t g_contained_st7_64[];
+
+  static uint32_t g_invalidate_st0_64[];
+  static uint32_t g_invalidate_st1_64[];
+  static uint32_t g_invalidate_st2_64[];
+  static uint32_t g_invalidate_st3_64[];
+  static uint32_t g_invalidate_st4_64[];
+  static uint32_t g_invalidate_st5_64[];
+  static uint32_t g_invalidate_st6_64[];
+  static uint32_t g_invalidate_st7_64[];
+
 protected:
   struct RegInfo {
 uint32_t num_registers;
Index: lldb/source/Plugins/Process/Utility/RegisterContextPOSIX_x86.cpp
===
--- lldb/source/Plugins/Process/Utility/RegisterContextPOSIX_x86.cpp
+++ lldb/source/Plugins/Process/Utility/RegisterContextPOSIX_x86.cpp
@@ -286,6 +286,40 @@
 uint32_t RegisterContextPOSIX_x86::g_invalidate_fdp[] = {
 lldb_fdp_x86_64, lldb_fooff_x86_64, lldb_foseg_x86_64, LLDB_INVALID_REGNUM};
 
+uint32_t RegisterContextPOSIX_x86::g_contained_st0_64[] = {lldb_st0_x86_64,
+   LLDB_INVALID_REGNUM};
+uint32_t RegisterContextPOSIX_x86::g_contained_st1_64[] = {lldb_st1_x86_64,
+   LLDB_INVALID_REGNUM};
+uint32_t RegisterContextPOSIX_x86::g_contained_st2_64[] = {lldb_st2_x86_64,
+   LLDB_INVALID_REGNUM};
+uint32_t RegisterContextPOSIX_x86::g_contained_st3_64[] = {lldb_st3_x86_64,
+   LLDB_INVALID_REGNUM};
+uint32_t RegisterContextPOSIX_x86::g_contained_st4_64[] = {lldb_st4_x86_64,
+  

[Lldb-commits] [PATCH] D91497: [lldb] Add explicit 64-bit fip/fdp registers on x86_64

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

mgorny updated this revision to Diff 306160.
mgorny added a comment.

Added contained/invalidate entries for FIP/FDP.


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

https://reviews.llvm.org/D91497

Files:
  
lldb/source/Plugins/Process/FreeBSDRemote/NativeRegisterContextFreeBSD_x86_64.cpp
  lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.cpp
  lldb/source/Plugins/Process/NetBSD/NativeRegisterContextNetBSD_x86_64.cpp
  lldb/source/Plugins/Process/Utility/RegisterContextPOSIX_x86.cpp
  lldb/source/Plugins/Process/Utility/RegisterContextPOSIX_x86.h
  lldb/source/Plugins/Process/Utility/RegisterInfos_x86_64.h
  lldb/source/Plugins/Process/Utility/lldb-x86-register-enums.h
  lldb/test/Shell/Register/x86-64-fp-read.test
  lldb/test/Shell/Register/x86-64-fp-write.test
  lldb/test/Shell/Register/x86-fp-read.test
  lldb/test/Shell/Register/x86-fp-write.test
  lldb/unittests/Process/Utility/RegisterContextFreeBSDTest.cpp

Index: lldb/unittests/Process/Utility/RegisterContextFreeBSDTest.cpp
===
--- lldb/unittests/Process/Utility/RegisterContextFreeBSDTest.cpp
+++ lldb/unittests/Process/Utility/RegisterContextFreeBSDTest.cpp
@@ -82,11 +82,15 @@
   EXPECT_OFF(ftag_x86_64, 0x04, 2);
   EXPECT_OFF(fop_x86_64, 0x06, 2);
   // NB: Technically fiseg/foseg are 16-bit long and the higher 16 bits
-  // are reserved.  However, we use them to access/recombine 64-bit FIP/FDP.
+  // are reserved.  However, LLDB defines them to be 32-bit long for backwards
+  // compatibility, as they were used to reconstruct FIP/FDP before explicit
+  // register entries for them were added.  Also, this is still how GDB does it.
   EXPECT_OFF(fioff_x86_64, 0x08, 4);
   EXPECT_OFF(fiseg_x86_64, 0x0C, 4);
+  EXPECT_OFF(fip_x86_64, 0x08, 8);
   EXPECT_OFF(fooff_x86_64, 0x10, 4);
   EXPECT_OFF(foseg_x86_64, 0x14, 4);
+  EXPECT_OFF(fdp_x86_64, 0x10, 8);
   EXPECT_OFF(mxcsr_x86_64, 0x18, 4);
   EXPECT_OFF(mxcsrmask_x86_64, 0x1C, 4);
   EXPECT_OFF(st0_x86_64, 0x20, 10);
Index: lldb/test/Shell/Register/x86-fp-write.test
===
--- lldb/test/Shell/Register/x86-fp-write.test
+++ lldb/test/Shell/Register/x86-fp-write.test
@@ -1,5 +1,5 @@
 # XFAIL: system-windows
-# REQUIRES: native && target-x86
+# REQUIRES: native && (target-x86 || target-x86_64)
 # RUN: %clangxx_host %p/Inputs/x86-fp-write.cpp -o %t
 # RUN: %lldb -b -s %s %t | FileCheck %s
 process launch
@@ -31,8 +31,11 @@
 # CHECK-DAG: fstat = 0x8884
 # CHECK-DAG: ftag = 0xa961
 # CHECK-DAG: fop = 0x0033
-# CHECK-DAG: fip = 0x89abcdef
-# CHECK-DAG: fdp = 0x76543210
+
+# This test is run both on 32-bit and 64-bit systems, in order to test
+# that fioff/fooff setting works as well as fip/fdp.
+# CHECK-DAG: fip = 0x{{()?}}89abcdef
+# CHECK-DAG: fdp = 0x{{()?}}76543210
 
 # CHECK-DAG: st0 = { 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x80 0x00 0x40 }
 # CHECK-DAG: st1 = { 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x3f 0x00 0x00 }
Index: lldb/test/Shell/Register/x86-fp-read.test
===
--- lldb/test/Shell/Register/x86-fp-read.test
+++ lldb/test/Shell/Register/x86-fp-read.test
@@ -1,10 +1,16 @@
 # XFAIL: system-windows
-# REQUIRES: native && (target-x86 || target-x86_64)
+# REQUIRES: native && target-x86
 # RUN: %clangxx_host -g %p/Inputs/x86-fp-read.cpp -o %t
 # RUN: %lldb -b -s %s %t | FileCheck %s
 process launch
 # CHECK: Process {{.*}} stopped
 
+# fdiv (%rbx) gets encoded into 2 bytes, int3 into 1 byte
+print (void*)($pc-3)
+# CHECK: (void *) $0 = [[FDIV:0x[0-9a-f]*]]
+print 
+# CHECK: (uint32_t *) $1 = [[ZERO:0x[0-9a-f]*]]
+
 register read --all
 # CHECK-DAG: fctrl = 0x037b
 # CHECK-DAG: fstat = 0x8084
@@ -12,6 +18,8 @@
 # FXSAVE/XSAVE is interpreted
 # CHECK-DAG: ftag = 0x007f
 # CHECK-DAG: fop = 0x0033
+# CHECK-DAG: fioff = [[FDIV]]
+# CHECK-DAG: fooff = [[ZERO]]
 
 # CHECK-DAG: st{{(mm)?}}0 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x80 0x00 0x40}
 # CHECK-DAG: st{{(mm)?}}1 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x3f 0x00 0x00}
@@ -22,16 +30,5 @@
 # CHECK-DAG: st{{(mm)?}}6 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xc0 0xff 0xff}
 # CHECK-DAG: st{{(mm)?}}7 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00}
 
-# fdiv (%rbx) gets encoded into 2 bytes, int3 into 1 byte
-print (void*)($pc-3)
-# CHECK: (void *) $0 = [[FDIV:0x[0-9a-f]*]]
-# TODO: we probably should not split it like this
-print (void*)($fiseg*0x1 + $fioff)
-# CHECK: (void *) $1 = [[FDIV]]
-print 
-# CHECK: (uint32_t *) $2 = [[ZERO:0x[0-9a-f]*]]
-print (uint32_t*)($foseg * 0x1 + $fooff)
-# CHECK: (uint32_t *) $3 = [[ZERO]]
-
 process continue
 # CHECK: Process {{[0-9]+}} exited with status = 0
Index: lldb/test/Shell/Register/x86-64-fp-write.test
===
--- lldb/test/Shell/Register/x86-64-fp-write.test
+++ 

[Lldb-commits] [PATCH] D91504: [lldb] Use translated full ftag values

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

mgorny updated this revision to Diff 306159.
mgorny retitled this revision from "[lldb] Use translated full ftag values 
[WIP]" to "[lldb] Use translated full ftag values".
mgorny added a comment.

Updated Linux to use pointer comparison and FreeBSD. It's ready for review now, 
though I'd use a better suggestion for FreeBSD.


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

https://reviews.llvm.org/D91504

Files:
  
lldb/source/Plugins/Process/FreeBSDRemote/NativeRegisterContextFreeBSD_x86_64.cpp
  lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.cpp
  lldb/source/Plugins/Process/NetBSD/NativeRegisterContextNetBSD_x86_64.cpp
  lldb/source/Plugins/Process/Utility/CMakeLists.txt
  lldb/source/Plugins/Process/Utility/RegisterContext_x86.cpp
  lldb/source/Plugins/Process/Utility/RegisterContext_x86.h
  lldb/test/Shell/Register/x86-64-fp-read.test
  lldb/test/Shell/Register/x86-64-fp-write.test
  lldb/test/Shell/Register/x86-fp-read.test
  lldb/test/Shell/Register/x86-fp-write.test
  lldb/unittests/Process/Utility/CMakeLists.txt
  lldb/unittests/Process/Utility/RegisterContextTest.cpp

Index: lldb/unittests/Process/Utility/RegisterContextTest.cpp
===
--- /dev/null
+++ lldb/unittests/Process/Utility/RegisterContextTest.cpp
@@ -0,0 +1,65 @@
+//===-- RegisterContextTest.cpp ---===//
+//
+// 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
+//
+//===--===//
+
+#include "gtest/gtest.h"
+
+#include "Plugins/Process/Utility/RegisterContext_x86.h"
+
+#include 
+
+using namespace lldb_private;
+
+struct TagWordTestVector {
+  uint16_t sw;
+  uint16_t tw;
+  uint8_t tw_abridged;
+  int st_reg_num;
+};
+
+constexpr MMSReg st_from_comp(uint64_t mantissa, uint16_t sign_exp) {
+  MMSReg ret = {};
+  ret.comp.mantissa = mantissa;
+  ret.comp.sign_exp = sign_exp;
+  return ret;
+}
+
+const std::array st_regs = {
+st_from_comp(0x8000, 0x4000), // +2.0
+st_from_comp(0x3f00, 0x), // 1.654785e-4932
+st_from_comp(0x, 0x), // +0
+st_from_comp(0x, 0x8000), // -0
+st_from_comp(0x8000, 0x7fff), // +inf
+st_from_comp(0x8000, 0x), // -inf
+st_from_comp(0xc000, 0x), // nan
+st_from_comp(0x8000, 0xc000), // -2.0
+};
+
+const std::array tag_word_test_vectors{
+TagWordTestVector{0x3800, 0x3fff, 0x80, 1},
+TagWordTestVector{0x3000, 0x2fff, 0xc0, 2},
+TagWordTestVector{0x2800, 0x27ff, 0xe0, 3},
+TagWordTestVector{0x2000, 0x25ff, 0xf0, 4},
+TagWordTestVector{0x1800, 0x25bf, 0xf8, 5},
+TagWordTestVector{0x1000, 0x25af, 0xfc, 6},
+TagWordTestVector{0x0800, 0x25ab, 0xfe, 7},
+TagWordTestVector{0x, 0x25a8, 0xff, 8},
+};
+
+TEST(RegisterContext_x86Test, AbridgedToFullTagWord) {
+  for (const TagWordTestVector  : tag_word_test_vectors) {
+std::array test_regs;
+for (int i = 0; i < x.st_reg_num; ++i)
+  test_regs[i] = st_regs[x.st_reg_num - i - 1];
+EXPECT_EQ(AbridgedToFullTagWord(x.tw_abridged, x.sw, test_regs), x.tw);
+  }
+}
+
+TEST(RegisterContext_x86Test, FullToAbridgedTagWord) {
+  for (const TagWordTestVector  : tag_word_test_vectors)
+EXPECT_EQ(FullToAbridgedTagWord(x.tw), x.tw_abridged);
+}
Index: lldb/unittests/Process/Utility/CMakeLists.txt
===
--- lldb/unittests/Process/Utility/CMakeLists.txt
+++ lldb/unittests/Process/Utility/CMakeLists.txt
@@ -1,4 +1,5 @@
 add_lldb_unittest(ProcessUtilityTests
+  RegisterContextTest.cpp
   RegisterContextFreeBSDTest.cpp
 
   LINK_LIBS
Index: lldb/test/Shell/Register/x86-fp-write.test
===
--- lldb/test/Shell/Register/x86-fp-write.test
+++ lldb/test/Shell/Register/x86-fp-write.test
@@ -7,8 +7,7 @@
 register write fctrl 0x037b
 register write fstat 0x8884
 # note: this needs to enable all registers for writes to be effective
-# TODO: fix it to use proper ftag values instead of 'abridged'
-register write ftag 0x00ff
+register write ftag 0x2a58
 register write fop 0x0033
 # the exact addresses do not matter, we want just to verify FXSAVE
 # note: segment registers are not supported on all CPUs
Index: lldb/test/Shell/Register/x86-fp-read.test
===
--- lldb/test/Shell/Register/x86-fp-read.test
+++ lldb/test/Shell/Register/x86-fp-read.test
@@ -14,9 +14,7 @@
 register read --all
 # CHECK-DAG: fctrl = 0x037b
 # CHECK-DAG: fstat = 0x8084
-# TODO: the following value is incorrect, it's a bug in the way
-# FXSAVE/XSAVE is interpreted
-# CHECK-DAG: ftag = 0x007f
+# 

[Lldb-commits] [PATCH] D91645: [lldb] [test] Un-XFAIL tests on freebsd/i386

[Ed Maste via Phabricator via lldb-commits]

emaste added inline comments.



Comment at: lldb/test/API/functionalities/exec/TestExec.py:19
 
-@expectedFailureAll(archs=['i386'], bugnumber="rdar://28656532")
+@expectedFailureAll(archs=['i386'],
+oslist=no_match(["freebsd"]),

labath wrote:
> labath wrote:
> > mgorny wrote:
> > > emaste wrote:
> > > > Interesting, so FreeBSD is now the only OS where this test passes on 
> > > > i386?
> > > > 
> > > > Of course rdar://28656532 is opaque, would be nice if Apple folks can 
> > > > provide some insight on this.
> > > I suspect others might pass too and this is a Darwin-specific issue but I 
> > > don't have 32-bit NetBSD install handy at the moment, and LLDB doesn't 
> > > seem to work at all on Arch Linux 32 for some obscure reason.
> > I was actually running the test on a 64-bit multilib system. It's possible 
> > that a pure 32-bit system behaves differently.
> (or just a 32-bit build of lldb)
Ah, fair point. I'm not all that interested in FreeBSD/i386 tbh, it just seemed 
surprising.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91645

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

[Lldb-commits] [PATCH] D87442: [lldb] Show flags for memory regions

[David Spickett via Phabricator via lldb-commits]

DavidSpickett updated this revision to Diff 306091.
DavidSpickett added a comment.

Updated the way the test works.

- If you build without MTE in the toolchain the binary just returns the magic 
failure number.
- If you do have an MTE toolchain but your target doesn't have MTE then it will 
also fail with the magic return code.

If it does either of those we skip, otherwise we then run
again to do the actual checks.

The vmflags check will be needed for future tests so I've
not moved it into the test itself.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87442

Files:
  lldb/docs/lldb-gdb-remote.txt
  lldb/docs/use/qemu-testing.rst
  lldb/include/lldb/Target/MemoryRegionInfo.h
  lldb/packages/Python/lldbsuite/test/lldbtest.py
  lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
  lldb/scripts/lldb-test-qemu/run-qemu.sh
  lldb/source/Commands/CommandObjectMemory.cpp
  lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp
  lldb/source/Plugins/Process/Utility/LinuxProcMaps.cpp
  lldb/source/Plugins/Process/Utility/LinuxProcMaps.h
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
  lldb/source/Plugins/Process/minidump/MinidumpParser.cpp
  lldb/source/Target/MemoryRegionInfo.cpp
  lldb/test/API/linux/aarch64/mte_memory_region/Makefile
  
lldb/test/API/linux/aarch64/mte_memory_region/TestAArch64LinuxMTEMemoryRegion.py
  lldb/test/API/linux/aarch64/mte_memory_region/main.c
  lldb/unittests/Process/Utility/CMakeLists.txt
  lldb/unittests/Process/Utility/LinuxProcMapsTest.cpp
  lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp
  lldb/unittests/Process/minidump/MinidumpParserTest.cpp

Index: lldb/unittests/Process/minidump/MinidumpParserTest.cpp
===
--- lldb/unittests/Process/minidump/MinidumpParserTest.cpp
+++ lldb/unittests/Process/minidump/MinidumpParserTest.cpp
@@ -378,15 +378,15 @@
   parser->BuildMemoryRegions(),
   testing::Pair(testing::ElementsAre(
 MemoryRegionInfo({0x0, 0x1}, no, no, no, no,
- ConstString(), unknown, 0),
+ ConstString(), unknown, 0, unknown),
 MemoryRegionInfo({0x1, 0x21000}, yes, yes, no, yes,
- ConstString(), unknown, 0),
+ ConstString(), unknown, 0, unknown),
 MemoryRegionInfo({0x4, 0x1000}, yes, no, no, yes,
- ConstString(), unknown, 0),
+ ConstString(), unknown, 0, unknown),
 MemoryRegionInfo({0x7ffe, 0x1000}, yes, no, no, yes,
- ConstString(), unknown, 0),
+ ConstString(), unknown, 0, unknown),
 MemoryRegionInfo({0x7ffe1000, 0xf000}, no, no, no, yes,
- ConstString(), unknown, 0)),
+ ConstString(), unknown, 0, unknown)),
 true));
 }
 
@@ -409,12 +409,13 @@
 
   EXPECT_THAT(
   parser->BuildMemoryRegions(),
-  testing::Pair(testing::ElementsAre(
-MemoryRegionInfo({0x1000, 0x10}, yes, unknown, unknown,
- yes, ConstString(), unknown, 0),
-MemoryRegionInfo({0x2000, 0x20}, yes, unknown, unknown,
- yes, ConstString(), unknown, 0)),
-false));
+  testing::Pair(
+  testing::ElementsAre(
+  MemoryRegionInfo({0x1000, 0x10}, yes, unknown, unknown, yes,
+   ConstString(), unknown, 0, unknown),
+  MemoryRegionInfo({0x2000, 0x20}, yes, unknown, unknown, yes,
+   ConstString(), unknown, 0, unknown)),
+  false));
 }
 
 TEST_F(MinidumpParserTest, GetMemoryRegionInfoFromMemory64List) {
@@ -424,12 +425,13 @@
   // we don't have a MemoryInfoListStream.
   EXPECT_THAT(
   parser->BuildMemoryRegions(),
-  testing::Pair(testing::ElementsAre(
-MemoryRegionInfo({0x1000, 0x10}, yes, unknown, unknown,
- yes, ConstString(), unknown, 0),
-MemoryRegionInfo({0x2000, 0x20}, yes, unknown, unknown,
- yes, ConstString(), unknown, 0)),
-false));
+  testing::Pair(
+  testing::ElementsAre(
+  MemoryRegionInfo({0x1000, 0x10}, yes, unknown, unknown, yes,
+   ConstString(), unknown, 0, unknown),
+  

[Lldb-commits] [PATCH] D90729: [trace][intel-pt] Scaffold the 'thread trace start | stop' commands

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

I am can't keep up with all the reviews, so don't wait on my account. I 
checking these out from time to time though, and I will speak up if I see 
something very out of place.

I like the idea of a common base class for different kinds of "core" processes. 
The name RecordedProcess also made me think twice, but I am not sure what would 
be a better name for it. Maybe SavedProcess is slightly better as the name does 
not carry the notion of "time" (which real core files do not have). Or some 
variation of PostMortemProcess?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90729

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

[Lldb-commits] [PATCH] D91699: [lldb][NFC] Don't let Process inherit from UserID

[Raphael Isemann via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGccd9091d4a2f: [lldb][NFC] Dont let Process inherit 
from UserID (authored by teemperor).
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

Changed prior to commit:
  https://reviews.llvm.org/D91699?vs=306052=306071#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91699

Files:
  lldb/include/lldb/Target/Process.h
  lldb/source/Target/Process.cpp


Index: lldb/source/Target/Process.cpp
===
--- lldb/source/Target/Process.cpp
+++ lldb/source/Target/Process.cpp
@@ -529,7 +529,7 @@
 
 Process::Process(lldb::TargetSP target_sp, ListenerSP listener_sp,
  const UnixSignalsSP _signals_sp)
-: ProcessProperties(this), UserID(LLDB_INVALID_PROCESS_ID),
+: ProcessProperties(this),
   Broadcaster((target_sp->GetDebugger().GetBroadcasterManager()),
   Process::GetStaticBroadcasterClass().AsCString()),
   m_target_wp(target_sp), m_public_state(eStateUnloaded),
Index: lldb/include/lldb/Target/Process.h
===
--- lldb/include/lldb/Target/Process.h
+++ lldb/include/lldb/Target/Process.h
@@ -364,7 +364,6 @@
 /// A plug-in interface definition class for debugging a process.
 class Process : public std::enable_shared_from_this,
 public ProcessProperties,
-public UserID,
 public Broadcaster,
 public ExecutionContextScope,
 public PluginInterface {
@@ -560,6 +559,15 @@
 
   uint32_t GetAddressByteSize() const;
 
+  /// Sets the stored pid.
+  ///
+  /// This does not change the pid of underlying process.
+  lldb::pid_t GetID() const { return m_pid; }
+
+  /// Returns the pid of the process or LLDB_INVALID_PROCESS_ID if there is
+  /// no known pid.
+  void SetID(lldb::pid_t new_pid) { m_pid = new_pid; }
+
   uint32_t GetUniqueID() const { return m_process_unique_id; }
 
   /// Check if a plug-in instance can debug the file in \a module.
@@ -2730,6 +2738,7 @@
 
   // Member variables
   std::weak_ptr m_target_wp; ///< The target that owns this process.
+  lldb::pid_t m_pid = LLDB_INVALID_PROCESS_ID;
   ThreadSafeValue m_public_state;
   ThreadSafeValue
   m_private_state; // The actual state of our process


Index: lldb/source/Target/Process.cpp
===
--- lldb/source/Target/Process.cpp
+++ lldb/source/Target/Process.cpp
@@ -529,7 +529,7 @@
 
 Process::Process(lldb::TargetSP target_sp, ListenerSP listener_sp,
  const UnixSignalsSP _signals_sp)
-: ProcessProperties(this), UserID(LLDB_INVALID_PROCESS_ID),
+: ProcessProperties(this),
   Broadcaster((target_sp->GetDebugger().GetBroadcasterManager()),
   Process::GetStaticBroadcasterClass().AsCString()),
   m_target_wp(target_sp), m_public_state(eStateUnloaded),
Index: lldb/include/lldb/Target/Process.h
===
--- lldb/include/lldb/Target/Process.h
+++ lldb/include/lldb/Target/Process.h
@@ -364,7 +364,6 @@
 /// A plug-in interface definition class for debugging a process.
 class Process : public std::enable_shared_from_this,
 public ProcessProperties,
-public UserID,
 public Broadcaster,
 public ExecutionContextScope,
 public PluginInterface {
@@ -560,6 +559,15 @@
 
   uint32_t GetAddressByteSize() const;
 
+  /// Sets the stored pid.
+  ///
+  /// This does not change the pid of underlying process.
+  lldb::pid_t GetID() const { return m_pid; }
+
+  /// Returns the pid of the process or LLDB_INVALID_PROCESS_ID if there is
+  /// no known pid.
+  void SetID(lldb::pid_t new_pid) { m_pid = new_pid; }
+
   uint32_t GetUniqueID() const { return m_process_unique_id; }
 
   /// Check if a plug-in instance can debug the file in \a module.
@@ -2730,6 +2738,7 @@
 
   // Member variables
   std::weak_ptr m_target_wp; ///< The target that owns this process.
+  lldb::pid_t m_pid = LLDB_INVALID_PROCESS_ID;
   ThreadSafeValue m_public_state;
   ThreadSafeValue
   m_private_state; // The actual state of our process
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] ccd9091 - [lldb][NFC] Don't let Process inherit from UserID

[Raphael Isemann via lldb-commits]

Author: Raphael Isemann
Date: 2020-11-18T14:33:48+01:00
New Revision: ccd9091d4a2fd55cb455e61fa77530e1a5de6e69

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

LOG: [lldb][NFC] Don't let Process inherit from UserID

I noticed that Process is inheriting from UserID to store its PID value. This 
patch
replaces this with a dedicated field in the Process class. This is NFC, but has 
some
small effects on the code using Process:
* `GetID()` now returns a `lldb::pid_t` like all other process code instead of 
`lldb::user_id_t`. Both are typedefs for `uint64_t`, so no change in behaviour.
* The equality operators defined for UserID no longer accept Process instances.
* Removes the inherited method `Process::Clear()` which didn't actually clear 
anything beside the PID value.

We maybe should also remove the getters/setters to `S/GetPID` or something like 
that. I can update all the code for that
in a follow-up NFC commit.

Reviewed By: labath

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

Added: 


Modified: 
lldb/include/lldb/Target/Process.h
lldb/source/Target/Process.cpp

Removed: 




diff  --git a/lldb/include/lldb/Target/Process.h 
b/lldb/include/lldb/Target/Process.h
index a1a9760c0006..2c21b80d7309 100644
--- a/lldb/include/lldb/Target/Process.h
+++ b/lldb/include/lldb/Target/Process.h
@@ -364,7 +364,6 @@ inline bool operator!=(const ProcessModID , const 
ProcessModID ) {
 /// A plug-in interface definition class for debugging a process.
 class Process : public std::enable_shared_from_this,
 public ProcessProperties,
-public UserID,
 public Broadcaster,
 public ExecutionContextScope,
 public PluginInterface {
@@ -560,6 +559,15 @@ class Process : public 
std::enable_shared_from_this,
 
   uint32_t GetAddressByteSize() const;
 
+  /// Sets the stored pid.
+  ///
+  /// This does not change the pid of underlying process.
+  lldb::pid_t GetID() const { return m_pid; }
+
+  /// Returns the pid of the process or LLDB_INVALID_PROCESS_ID if there is
+  /// no known pid.
+  void SetID(lldb::pid_t new_pid) { m_pid = new_pid; }
+
   uint32_t GetUniqueID() const { return m_process_unique_id; }
 
   /// Check if a plug-in instance can debug the file in \a module.
@@ -2730,6 +2738,7 @@ void PruneThreadPlans();
 
   // Member variables
   std::weak_ptr m_target_wp; ///< The target that owns this process.
+  lldb::pid_t m_pid = LLDB_INVALID_PROCESS_ID;
   ThreadSafeValue m_public_state;
   ThreadSafeValue
   m_private_state; // The actual state of our process

diff  --git a/lldb/source/Target/Process.cpp b/lldb/source/Target/Process.cpp
index 490ca45bfee2..d32d3df5c8e6 100644
--- a/lldb/source/Target/Process.cpp
+++ b/lldb/source/Target/Process.cpp
@@ -529,7 +529,7 @@ Process::Process(lldb::TargetSP target_sp, ListenerSP 
listener_sp)
 
 Process::Process(lldb::TargetSP target_sp, ListenerSP listener_sp,
  const UnixSignalsSP _signals_sp)
-: ProcessProperties(this), UserID(LLDB_INVALID_PROCESS_ID),
+: ProcessProperties(this),
   Broadcaster((target_sp->GetDebugger().GetBroadcasterManager()),
   Process::GetStaticBroadcasterClass().AsCString()),
   m_target_wp(target_sp), m_public_state(eStateUnloaded),



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

[Lldb-commits] [PATCH] D91634: [lldb] Error when there are no ports to launch a gdbserver on

[David Spickett via Phabricator via lldb-commits]

DavidSpickett added a comment.

I hadn't considered using a unit test instead, I'll give that a go.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91634

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

[Lldb-commits] [PATCH] D91241: [LLDB] Make offset field optional in RegisterInfo packet for Arm64

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

Yes, this is pretty much what I hoped for. Thanks.

Besides relaxing existing tests, it would be nice to have a positive test that 
checks for the behavior that we want. Maybe a gdb-client test which checks that 
the register values are extracted from the appropriate place from within a g 
packet (send custom target.xml, and a `g` response, and ensure the register 
values come out what we expect)?

In D91241#2398995 , @omjavaid wrote:

> I have made some updates which are sufficient for current AArch64 scenario 
> where offset field is not present. For ordering registers based on register 
> numbers I think we may skip doing that for now though i intend to come back 
> to it after getting SVE through.

That seems fair.




Comment at: lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp:480
 0, // byte size
 reg_offset,// offset
 eEncodingUint, // encoding

How about we initialize to UINT32_MAX here, and then just don't update the 
field if the offset is not set.



Comment at: lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp:573
+  else
+reg_info.byte_offset = LLDB_INVALID_INDEX32;
+} else {

The use of LLDB_INVALID_INDEX32 is not really correct (this is not an index) 
and the rest of the code (e.g. line 507) already uses UINT32_MAX.


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

https://reviews.llvm.org/D91241

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

[Lldb-commits] [PATCH] D91645: [lldb] [test] Un-XFAIL tests on freebsd/i386

[Pavel Labath via Phabricator via lldb-commits]

labath added inline comments.



Comment at: lldb/test/API/functionalities/exec/TestExec.py:19
 
-@expectedFailureAll(archs=['i386'], bugnumber="rdar://28656532")
+@expectedFailureAll(archs=['i386'],
+oslist=no_match(["freebsd"]),

labath wrote:
> mgorny wrote:
> > emaste wrote:
> > > Interesting, so FreeBSD is now the only OS where this test passes on i386?
> > > 
> > > Of course rdar://28656532 is opaque, would be nice if Apple folks can 
> > > provide some insight on this.
> > I suspect others might pass too and this is a Darwin-specific issue but I 
> > don't have 32-bit NetBSD install handy at the moment, and LLDB doesn't seem 
> > to work at all on Arch Linux 32 for some obscure reason.
> I was actually running the test on a 64-bit multilib system. It's possible 
> that a pure 32-bit system behaves differently.
(or just a 32-bit build of lldb)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91645

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

[Lldb-commits] [PATCH] D91645: [lldb] [test] Un-XFAIL tests on freebsd/i386

[Pavel Labath via Phabricator via lldb-commits]

labath added inline comments.
Herald added a subscriber: JDevlieghere.



Comment at: lldb/test/API/functionalities/exec/TestExec.py:19
 
-@expectedFailureAll(archs=['i386'], bugnumber="rdar://28656532")
+@expectedFailureAll(archs=['i386'],
+oslist=no_match(["freebsd"]),

mgorny wrote:
> emaste wrote:
> > Interesting, so FreeBSD is now the only OS where this test passes on i386?
> > 
> > Of course rdar://28656532 is opaque, would be nice if Apple folks can 
> > provide some insight on this.
> I suspect others might pass too and this is a Darwin-specific issue but I 
> don't have 32-bit NetBSD install handy at the moment, and LLDB doesn't seem 
> to work at all on Arch Linux 32 for some obscure reason.
I was actually running the test on a 64-bit multilib system. It's possible that 
a pure 32-bit system behaves differently.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91645

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

[Lldb-commits] [PATCH] D91634: [lldb] Error when there are no ports to launch a gdbserver on

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

Yeah, I don't think it's possible to write a reliable end-to-end test for this 
feature. A unit test might be an option -- I don't know how hard it would be to 
mock the parts needed (starting a debug server). One could also consider 
refactoring this code to avoid the usage of a valid port number to represent 
the "no port" state (and while doing so, making the code easier to unit test).

While I would encourage you to try some of these things out, I wouldn't say 
that that's really required for this bugfix.

BTW, the --min/max-gdbserver-port is a constant source of bug reports (last one 
was last weel --  I'll have to reply to that one) and ideally I'd just do away 
with it. It just leaves a bad FTP taste in the mouth..


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91634

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

[Lldb-commits] [PATCH] D91612: [lldb] Fix a couple of remote llgs tests

[David Spickett via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG50f12ade2de1: [lldb] Fix a couple of remote llgs tests 
(authored by DavidSpickett).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91612

Files:
  
lldb/test/API/commands/target/auto-install-main-executable/TestAutoInstallMainExecutable.py
  
lldb/test/API/tools/lldb-server/platform-process-connect/TestPlatformProcessConnect.py


Index: 
lldb/test/API/tools/lldb-server/platform-process-connect/TestPlatformProcessConnect.py
===
--- 
lldb/test/API/tools/lldb-server/platform-process-connect/TestPlatformProcessConnect.py
+++ 
lldb/test/API/tools/lldb-server/platform-process-connect/TestPlatformProcessConnect.py
@@ -16,7 +16,7 @@
 @expectedFailureAll(hostoslist=["windows"], triple='.*-android')
 def test_platform_process_connect(self):
 self.build()
-self.init_llgs_test(False)
+self.init_llgs_test()
 
 working_dir = lldb.remote_platform.GetWorkingDirectory()
 src = lldb.SBFileSpec(self.getBuildArtifact("a.out"))
Index: 
lldb/test/API/commands/target/auto-install-main-executable/TestAutoInstallMainExecutable.py
===
--- 
lldb/test/API/commands/target/auto-install-main-executable/TestAutoInstallMainExecutable.py
+++ 
lldb/test/API/commands/target/auto-install-main-executable/TestAutoInstallMainExecutable.py
@@ -19,7 +19,7 @@
 @expectedFailureAll(hostoslist=["windows"], triple='.*-android')
 def test_target_auto_install_main_executable(self):
 self.build()
-self.init_llgs_test(False)
+self.init_llgs_test()
 
 # Manually install the modified binary.
 working_dir = lldb.remote_platform.GetWorkingDirectory()
@@ -77,10 +77,10 @@
 
(os.path.join(working_dir,dest.GetFilename()),
 self.getBuildArtifact("a.out")))
 
-target = new_debugger.GetSelectedTarget()
+target = self.dbg.GetSelectedTarget()
 breakpoint = target.BreakpointCreateByName("main")
 
-launch_info = taget.GetLaunchInfo()
+launch_info = target.GetLaunchInfo()
 error = lldb.SBError()
 process = target.Launch(launch_info, error)
 self.assertTrue(process, PROCESS_IS_VALID)


Index: lldb/test/API/tools/lldb-server/platform-process-connect/TestPlatformProcessConnect.py
===
--- lldb/test/API/tools/lldb-server/platform-process-connect/TestPlatformProcessConnect.py
+++ lldb/test/API/tools/lldb-server/platform-process-connect/TestPlatformProcessConnect.py
@@ -16,7 +16,7 @@
 @expectedFailureAll(hostoslist=["windows"], triple='.*-android')
 def test_platform_process_connect(self):
 self.build()
-self.init_llgs_test(False)
+self.init_llgs_test()
 
 working_dir = lldb.remote_platform.GetWorkingDirectory()
 src = lldb.SBFileSpec(self.getBuildArtifact("a.out"))
Index: lldb/test/API/commands/target/auto-install-main-executable/TestAutoInstallMainExecutable.py
===
--- lldb/test/API/commands/target/auto-install-main-executable/TestAutoInstallMainExecutable.py
+++ lldb/test/API/commands/target/auto-install-main-executable/TestAutoInstallMainExecutable.py
@@ -19,7 +19,7 @@
 @expectedFailureAll(hostoslist=["windows"], triple='.*-android')
 def test_target_auto_install_main_executable(self):
 self.build()
-self.init_llgs_test(False)
+self.init_llgs_test()
 
 # Manually install the modified binary.
 working_dir = lldb.remote_platform.GetWorkingDirectory()
@@ -77,10 +77,10 @@
 (os.path.join(working_dir,dest.GetFilename()),
 self.getBuildArtifact("a.out")))
 
-target = new_debugger.GetSelectedTarget()
+target = self.dbg.GetSelectedTarget()
 breakpoint = target.BreakpointCreateByName("main")
 
-launch_info = taget.GetLaunchInfo()
+launch_info = target.GetLaunchInfo()
 error = lldb.SBError()
 process = target.Launch(launch_info, error)
 self.assertTrue(process, PROCESS_IS_VALID)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] 50f12ad - [lldb] Fix a couple of remote llgs tests

[David Spickett via lldb-commits]

Author: David Spickett
Date: 2020-11-18T11:36:45Z
New Revision: 50f12ade2de1b30e989c13f410461cb27c126f13

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

LOG: [lldb] Fix a couple of remote llgs tests

init_llgs_test no longer takes an argument
but these two were not updated.

Also fix some mistakes in TestAutoInstallMainExecutable
to get it passing again.

Reviewed By: JDevlieghere, labath

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

Added: 


Modified: 

lldb/test/API/commands/target/auto-install-main-executable/TestAutoInstallMainExecutable.py

lldb/test/API/tools/lldb-server/platform-process-connect/TestPlatformProcessConnect.py

Removed: 




diff  --git 
a/lldb/test/API/commands/target/auto-install-main-executable/TestAutoInstallMainExecutable.py
 
b/lldb/test/API/commands/target/auto-install-main-executable/TestAutoInstallMainExecutable.py
index 47c016e14c2d..fe4e124cd605 100644
--- 
a/lldb/test/API/commands/target/auto-install-main-executable/TestAutoInstallMainExecutable.py
+++ 
b/lldb/test/API/commands/target/auto-install-main-executable/TestAutoInstallMainExecutable.py
@@ -19,7 +19,7 @@ class 
TestAutoInstallMainExecutable(gdbremote_testcase.GdbRemoteTestCaseBase):
 @expectedFailureAll(hostoslist=["windows"], triple='.*-android')
 def test_target_auto_install_main_executable(self):
 self.build()
-self.init_llgs_test(False)
+self.init_llgs_test()
 
 # Manually install the modified binary.
 working_dir = lldb.remote_platform.GetWorkingDirectory()
@@ -77,10 +77,10 @@ def test_target_auto_install_main_executable(self):
 
(os.path.join(working_dir,dest.GetFilename()),
 self.getBuildArtifact("a.out")))
 
-target = new_debugger.GetSelectedTarget()
+target = self.dbg.GetSelectedTarget()
 breakpoint = target.BreakpointCreateByName("main")
 
-launch_info = taget.GetLaunchInfo()
+launch_info = target.GetLaunchInfo()
 error = lldb.SBError()
 process = target.Launch(launch_info, error)
 self.assertTrue(process, PROCESS_IS_VALID)

diff  --git 
a/lldb/test/API/tools/lldb-server/platform-process-connect/TestPlatformProcessConnect.py
 
b/lldb/test/API/tools/lldb-server/platform-process-connect/TestPlatformProcessConnect.py
index c9331e7d09a5..fcfb0a829e03 100644
--- 
a/lldb/test/API/tools/lldb-server/platform-process-connect/TestPlatformProcessConnect.py
+++ 
b/lldb/test/API/tools/lldb-server/platform-process-connect/TestPlatformProcessConnect.py
@@ -16,7 +16,7 @@ class 
TestPlatformProcessConnect(gdbremote_testcase.GdbRemoteTestCaseBase):
 @expectedFailureAll(hostoslist=["windows"], triple='.*-android')
 def test_platform_process_connect(self):
 self.build()
-self.init_llgs_test(False)
+self.init_llgs_test()
 
 working_dir = lldb.remote_platform.GetWorkingDirectory()
 src = lldb.SBFileSpec(self.getBuildArtifact("a.out"))



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

[Lldb-commits] [PATCH] D91497: [lldb] Add explicit 64-bit fip/fdp registers on x86_64

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

mgorny updated this revision to Diff 306031.
mgorny marked an inline comment as done.
mgorny added a comment.

Updated the test comment.


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

https://reviews.llvm.org/D91497

Files:
  
lldb/source/Plugins/Process/FreeBSDRemote/NativeRegisterContextFreeBSD_x86_64.cpp
  lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.cpp
  lldb/source/Plugins/Process/NetBSD/NativeRegisterContextNetBSD_x86_64.cpp
  lldb/source/Plugins/Process/Utility/RegisterContextPOSIX_x86.cpp
  lldb/source/Plugins/Process/Utility/RegisterInfos_x86_64.h
  lldb/source/Plugins/Process/Utility/lldb-x86-register-enums.h
  lldb/test/Shell/Register/x86-64-fp-read.test
  lldb/test/Shell/Register/x86-64-fp-write.test
  lldb/test/Shell/Register/x86-fp-read.test
  lldb/test/Shell/Register/x86-fp-write.test
  lldb/unittests/Process/Utility/RegisterContextFreeBSDTest.cpp

Index: lldb/unittests/Process/Utility/RegisterContextFreeBSDTest.cpp
===
--- lldb/unittests/Process/Utility/RegisterContextFreeBSDTest.cpp
+++ lldb/unittests/Process/Utility/RegisterContextFreeBSDTest.cpp
@@ -82,11 +82,15 @@
   EXPECT_OFF(ftag_x86_64, 0x04, 2);
   EXPECT_OFF(fop_x86_64, 0x06, 2);
   // NB: Technically fiseg/foseg are 16-bit long and the higher 16 bits
-  // are reserved.  However, we use them to access/recombine 64-bit FIP/FDP.
+  // are reserved.  However, LLDB defines them to be 32-bit long for backwards
+  // compatibility, as they were used to reconstruct FIP/FDP before explicit
+  // register entries for them were added.  Also, this is still how GDB does it.
   EXPECT_OFF(fioff_x86_64, 0x08, 4);
   EXPECT_OFF(fiseg_x86_64, 0x0C, 4);
+  EXPECT_OFF(fip_x86_64, 0x08, 8);
   EXPECT_OFF(fooff_x86_64, 0x10, 4);
   EXPECT_OFF(foseg_x86_64, 0x14, 4);
+  EXPECT_OFF(fdp_x86_64, 0x10, 8);
   EXPECT_OFF(mxcsr_x86_64, 0x18, 4);
   EXPECT_OFF(mxcsrmask_x86_64, 0x1C, 4);
   EXPECT_OFF(st0_x86_64, 0x20, 10);
Index: lldb/test/Shell/Register/x86-fp-write.test
===
--- lldb/test/Shell/Register/x86-fp-write.test
+++ lldb/test/Shell/Register/x86-fp-write.test
@@ -1,5 +1,5 @@
 # XFAIL: system-windows
-# REQUIRES: native && target-x86
+# REQUIRES: native && (target-x86 || target-x86_64)
 # RUN: %clangxx_host %p/Inputs/x86-fp-write.cpp -o %t
 # RUN: %lldb -b -s %s %t | FileCheck %s
 process launch
@@ -31,8 +31,11 @@
 # CHECK-DAG: fstat = 0x8884
 # CHECK-DAG: ftag = 0xa961
 # CHECK-DAG: fop = 0x0033
-# CHECK-DAG: fip = 0x89abcdef
-# CHECK-DAG: fdp = 0x76543210
+
+# This test is run both on 32-bit and 64-bit systems, in order to test
+# that fioff/fooff setting works as well as fip/fdp.
+# CHECK-DAG: fip = 0x{{()?}}89abcdef
+# CHECK-DAG: fdp = 0x{{()?}}76543210
 
 # CHECK-DAG: st0 = { 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x80 0x00 0x40 }
 # CHECK-DAG: st1 = { 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x3f 0x00 0x00 }
Index: lldb/test/Shell/Register/x86-fp-read.test
===
--- lldb/test/Shell/Register/x86-fp-read.test
+++ lldb/test/Shell/Register/x86-fp-read.test
@@ -1,10 +1,16 @@
 # XFAIL: system-windows
-# REQUIRES: native && (target-x86 || target-x86_64)
+# REQUIRES: native && target-x86
 # RUN: %clangxx_host -g %p/Inputs/x86-fp-read.cpp -o %t
 # RUN: %lldb -b -s %s %t | FileCheck %s
 process launch
 # CHECK: Process {{.*}} stopped
 
+# fdiv (%rbx) gets encoded into 2 bytes, int3 into 1 byte
+print (void*)($pc-3)
+# CHECK: (void *) $0 = [[FDIV:0x[0-9a-f]*]]
+print 
+# CHECK: (uint32_t *) $1 = [[ZERO:0x[0-9a-f]*]]
+
 register read --all
 # CHECK-DAG: fctrl = 0x037b
 # CHECK-DAG: fstat = 0x8084
@@ -12,6 +18,8 @@
 # FXSAVE/XSAVE is interpreted
 # CHECK-DAG: ftag = 0x007f
 # CHECK-DAG: fop = 0x0033
+# CHECK-DAG: fioff = [[FDIV]]
+# CHECK-DAG: fooff = [[ZERO]]
 
 # CHECK-DAG: st{{(mm)?}}0 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x80 0x00 0x40}
 # CHECK-DAG: st{{(mm)?}}1 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x3f 0x00 0x00}
@@ -22,16 +30,5 @@
 # CHECK-DAG: st{{(mm)?}}6 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xc0 0xff 0xff}
 # CHECK-DAG: st{{(mm)?}}7 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00}
 
-# fdiv (%rbx) gets encoded into 2 bytes, int3 into 1 byte
-print (void*)($pc-3)
-# CHECK: (void *) $0 = [[FDIV:0x[0-9a-f]*]]
-# TODO: we probably should not split it like this
-print (void*)($fiseg*0x1 + $fioff)
-# CHECK: (void *) $1 = [[FDIV]]
-print 
-# CHECK: (uint32_t *) $2 = [[ZERO:0x[0-9a-f]*]]
-print (uint32_t*)($foseg * 0x1 + $fooff)
-# CHECK: (uint32_t *) $3 = [[ZERO]]
-
 process continue
 # CHECK: Process {{[0-9]+}} exited with status = 0
Index: lldb/test/Shell/Register/x86-64-fp-write.test
===
--- lldb/test/Shell/Register/x86-64-fp-write.test
+++ lldb/test/Shell/Register/x86-64-fp-write.test
@@ -14,10 +14,8 @@
 # the exact 

[Lldb-commits] [PATCH] D91645: [lldb] [test] Un-XFAIL tests on freebsd/i386

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

This revision was automatically updated to reflect the committed changes.
Closed by commit rG97a2eac3a924: [lldb] [test] Un-XFAIL tests on freebsd/i386 
(authored by mgorny).
Herald added a project: LLDB.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91645

Files:
  lldb/test/API/functionalities/exec/TestExec.py
  lldb/test/API/functionalities/step-avoids-no-debug/TestStepNoDebug.py


Index: lldb/test/API/functionalities/step-avoids-no-debug/TestStepNoDebug.py
===
--- lldb/test/API/functionalities/step-avoids-no-debug/TestStepNoDebug.py
+++ lldb/test/API/functionalities/step-avoids-no-debug/TestStepNoDebug.py
@@ -31,6 +31,7 @@
 ">=",
 "3.9"],
 archs=["i386"],
+oslist=no_match(["freebsd"]),
 bugnumber="llvm.org/pr28549")
 def test_step_over_with_python(self):
 """Test stepping over using avoid-no-debug with dwarf."""
@@ -47,6 +48,7 @@
 ">=",
 "3.9"],
 archs=["i386"],
+oslist=no_match(["freebsd"]),
 bugnumber="llvm.org/pr28549")
 @expectedFailureAll(archs=["arm64"], 
bugnumber="")  # lldb doesn't step past last source 
line in function on arm64
 @expectedFailureAll(archs=["aarch64"], oslist=["linux"],
Index: lldb/test/API/functionalities/exec/TestExec.py
===
--- lldb/test/API/functionalities/exec/TestExec.py
+++ lldb/test/API/functionalities/exec/TestExec.py
@@ -16,7 +16,9 @@
 
 mydir = TestBase.compute_mydir(__file__)
 
-@expectedFailureAll(archs=['i386'], bugnumber="rdar://28656532")
+@expectedFailureAll(archs=['i386'],
+oslist=no_match(["freebsd"]),
+bugnumber="rdar://28656532")
 @expectedFailureAll(oslist=["ios", "tvos", "watchos", "bridgeos"], 
bugnumber="rdar://problem/34559552") # this exec test has problems on ios 
systems
 @expectedFailureNetBSD
 @skipIfAsan # rdar://problem/43756823
@@ -24,7 +26,9 @@
 def test_hitting_exec (self):
 self.do_test(False)
 
-@expectedFailureAll(archs=['i386'], bugnumber="rdar://28656532")
+@expectedFailureAll(archs=['i386'],
+oslist=no_match(["freebsd"]),
+bugnumber="rdar://28656532")
 @expectedFailureAll(oslist=["ios", "tvos", "watchos", "bridgeos"], 
bugnumber="rdar://problem/34559552") # this exec test has problems on ios 
systems
 @expectedFailureNetBSD
 @skipIfAsan # rdar://problem/43756823


Index: lldb/test/API/functionalities/step-avoids-no-debug/TestStepNoDebug.py
===
--- lldb/test/API/functionalities/step-avoids-no-debug/TestStepNoDebug.py
+++ lldb/test/API/functionalities/step-avoids-no-debug/TestStepNoDebug.py
@@ -31,6 +31,7 @@
 ">=",
 "3.9"],
 archs=["i386"],
+oslist=no_match(["freebsd"]),
 bugnumber="llvm.org/pr28549")
 def test_step_over_with_python(self):
 """Test stepping over using avoid-no-debug with dwarf."""
@@ -47,6 +48,7 @@
 ">=",
 "3.9"],
 archs=["i386"],
+oslist=no_match(["freebsd"]),
 bugnumber="llvm.org/pr28549")
 @expectedFailureAll(archs=["arm64"], bugnumber="")  # lldb doesn't step past last source line in function on arm64
 @expectedFailureAll(archs=["aarch64"], oslist=["linux"],
Index: lldb/test/API/functionalities/exec/TestExec.py
===
--- lldb/test/API/functionalities/exec/TestExec.py
+++ lldb/test/API/functionalities/exec/TestExec.py
@@ -16,7 +16,9 @@
 
 mydir = TestBase.compute_mydir(__file__)
 
-@expectedFailureAll(archs=['i386'], bugnumber="rdar://28656532")
+@expectedFailureAll(archs=['i386'],
+oslist=no_match(["freebsd"]),
+bugnumber="rdar://28656532")
 @expectedFailureAll(oslist=["ios", "tvos", "watchos", "bridgeos"], bugnumber="rdar://problem/34559552") # this exec test has problems on ios systems
 @expectedFailureNetBSD
 @skipIfAsan # rdar://problem/43756823
@@ -24,7 +26,9 @@
 def test_hitting_exec (self):
 self.do_test(False)
 
-@expectedFailureAll(archs=['i386'], bugnumber="rdar://28656532")
+@expectedFailureAll(archs=['i386'],
+oslist=no_match(["freebsd"]),
+bugnumber="rdar://28656532")
 @expectedFailureAll(oslist=["ios", "tvos", "watchos", "bridgeos"], bugnumber="rdar://problem/34559552") # this exec test has problems on ios systems
 @expectedFailureNetBSD
 @skipIfAsan # rdar://problem/43756823
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D91578: [lldb] [test] Pass -mmmx to x86-gp-write test explicitly

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

This revision was automatically updated to reflect the committed changes.
Closed by commit rG3e1f1b406e92: [lldb] [test] Pass -mmmx to x86-gp-write test 
explicitly (authored by mgorny).
Herald added a project: LLDB.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91578

Files:
  lldb/test/Shell/Register/x86-gp-write.test


Index: lldb/test/Shell/Register/x86-gp-write.test
===
--- lldb/test/Shell/Register/x86-gp-write.test
+++ lldb/test/Shell/Register/x86-gp-write.test
@@ -1,6 +1,6 @@
 # XFAIL: system-windows
 # REQUIRES: native && target-x86
-# RUN: %clangxx_host -fomit-frame-pointer %p/Inputs/x86-gp-write.cpp -o %t
+# RUN: %clangxx_host -mmmx -fomit-frame-pointer %p/Inputs/x86-gp-write.cpp -o 
%t
 # RUN: %lldb -b -s %s %t | FileCheck %s
 process launch
 


Index: lldb/test/Shell/Register/x86-gp-write.test
===
--- lldb/test/Shell/Register/x86-gp-write.test
+++ lldb/test/Shell/Register/x86-gp-write.test
@@ -1,6 +1,6 @@
 # XFAIL: system-windows
 # REQUIRES: native && target-x86
-# RUN: %clangxx_host -fomit-frame-pointer %p/Inputs/x86-gp-write.cpp -o %t
+# RUN: %clangxx_host -mmmx -fomit-frame-pointer %p/Inputs/x86-gp-write.cpp -o %t
 # RUN: %lldb -b -s %s %t | FileCheck %s
 process launch
 
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] 97a2eac - [lldb] [test] Un-XFAIL tests on freebsd/i386

[Michał Górny via lldb-commits]

Author: Michał Górny
Date: 2020-11-18T12:09:11+01:00
New Revision: 97a2eac3a924f3081bf80ee69ce59bc89257b857

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

LOG: [lldb] [test] Un-XFAIL tests on freebsd/i386

Restrict i386-specific XFAIL on a few tests to non-FreeBSD systems,
as they pass on FreeBSD.

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

Added: 


Modified: 
lldb/test/API/functionalities/exec/TestExec.py
lldb/test/API/functionalities/step-avoids-no-debug/TestStepNoDebug.py

Removed: 




diff  --git a/lldb/test/API/functionalities/exec/TestExec.py 
b/lldb/test/API/functionalities/exec/TestExec.py
index 019df2177137..fab118cfcf2a 100644
--- a/lldb/test/API/functionalities/exec/TestExec.py
+++ b/lldb/test/API/functionalities/exec/TestExec.py
@@ -16,7 +16,9 @@ class ExecTestCase(TestBase):
 
 mydir = TestBase.compute_mydir(__file__)
 
-@expectedFailureAll(archs=['i386'], bugnumber="rdar://28656532")
+@expectedFailureAll(archs=['i386'],
+oslist=no_match(["freebsd"]),
+bugnumber="rdar://28656532")
 @expectedFailureAll(oslist=["ios", "tvos", "watchos", "bridgeos"], 
bugnumber="rdar://problem/34559552") # this exec test has problems on ios 
systems
 @expectedFailureNetBSD
 @skipIfAsan # rdar://problem/43756823
@@ -24,7 +26,9 @@ class ExecTestCase(TestBase):
 def test_hitting_exec (self):
 self.do_test(False)
 
-@expectedFailureAll(archs=['i386'], bugnumber="rdar://28656532")
+@expectedFailureAll(archs=['i386'],
+oslist=no_match(["freebsd"]),
+bugnumber="rdar://28656532")
 @expectedFailureAll(oslist=["ios", "tvos", "watchos", "bridgeos"], 
bugnumber="rdar://problem/34559552") # this exec test has problems on ios 
systems
 @expectedFailureNetBSD
 @skipIfAsan # rdar://problem/43756823

diff  --git 
a/lldb/test/API/functionalities/step-avoids-no-debug/TestStepNoDebug.py 
b/lldb/test/API/functionalities/step-avoids-no-debug/TestStepNoDebug.py
index 92036b2f215a..500c314313fe 100644
--- a/lldb/test/API/functionalities/step-avoids-no-debug/TestStepNoDebug.py
+++ b/lldb/test/API/functionalities/step-avoids-no-debug/TestStepNoDebug.py
@@ -31,6 +31,7 @@ def test_step_out_with_python(self):
 ">=",
 "3.9"],
 archs=["i386"],
+oslist=no_match(["freebsd"]),
 bugnumber="llvm.org/pr28549")
 def test_step_over_with_python(self):
 """Test stepping over using avoid-no-debug with dwarf."""
@@ -47,6 +48,7 @@ def test_step_over_with_python(self):
 ">=",
 "3.9"],
 archs=["i386"],
+oslist=no_match(["freebsd"]),
 bugnumber="llvm.org/pr28549")
 @expectedFailureAll(archs=["arm64"], 
bugnumber="")  # lldb doesn't step past last source 
line in function on arm64
 @expectedFailureAll(archs=["aarch64"], oslist=["linux"],



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

[Lldb-commits] [lldb] b48ace0 - [lldb] [test] Un-XFAIL TestMultipleDebuggers.py

[Michał Górny via lldb-commits]

Author: Michał Górny
Date: 2020-11-18T12:09:04+01:00
New Revision: b48ace051c4bd0a51152ace717bb3f7104f70433

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

LOG: [lldb] [test] Un-XFAIL TestMultipleDebuggers.py

This test is flaky, and for the time being we do not mark them as XFAIL.

Added: 


Modified: 
lldb/test/API/api/multiple-debuggers/TestMultipleDebuggers.py

Removed: 




diff  --git a/lldb/test/API/api/multiple-debuggers/TestMultipleDebuggers.py 
b/lldb/test/API/api/multiple-debuggers/TestMultipleDebuggers.py
index 60a61fd1afff..d3a69a10baa5 100644
--- a/lldb/test/API/api/multiple-debuggers/TestMultipleDebuggers.py
+++ b/lldb/test/API/api/multiple-debuggers/TestMultipleDebuggers.py
@@ -19,7 +19,6 @@ class TestMultipleSimultaneousDebuggers(TestBase):
 
 @skipIfNoSBHeaders
 @skipIfWindows
-@expectedFailureAll(oslist=["freebsd"])
 def test_multiple_debuggers(self):
 env = {self.dylibPath: self.getLLDBLibraryEnvVal()}
 



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

[Lldb-commits] [lldb] 5a75512 - [lldb] [test] Mark command-process-connect.test XFAIL

[Michał Górny via lldb-commits]

Author: Michał Górny
Date: 2020-11-18T12:08:59+01:00
New Revision: 5a75512eba7ef351dab6f699b45c8bef37cb60b7

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

LOG: [lldb] [test] Mark command-process-connect.test XFAIL

We are still investigating why 'process connect' does not work while
'gdb-remote' does.

Signed-off-by: Michał Górny 

Added: 


Modified: 
lldb/test/Shell/Commands/command-process-connect.test

Removed: 




diff  --git a/lldb/test/Shell/Commands/command-process-connect.test 
b/lldb/test/Shell/Commands/command-process-connect.test
index 30782243d4ed..415cda123b35 100644
--- a/lldb/test/Shell/Commands/command-process-connect.test
+++ b/lldb/test/Shell/Commands/command-process-connect.test
@@ -1,4 +1,5 @@
 # UNSUPPORTED: system-windows
+# XFAIL: system-freebsd
 
 # Synchronous
 # RUN: %lldb -o 'platform select remote-gdb-server' -o 'process connect 
connect://localhost:4321' 2>&1 | FileCheck %s



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

[Lldb-commits] [lldb] 3e1f1b4 - [lldb] [test] Pass -mmmx to x86-gp-write test explicitly

[Michał Górny via lldb-commits]

Author: Michał Górny
Date: 2020-11-18T12:08:24+01:00
New Revision: 3e1f1b406e92115f2a36294c2084a8b3a5d6a651

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

LOG: [lldb] [test] Pass -mmmx to x86-gp-write test explicitly

Pass -mmmx explicitly to fix build failure with FreeBSD's clang on i386.

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

Added: 


Modified: 
lldb/test/Shell/Register/x86-gp-write.test

Removed: 




diff  --git a/lldb/test/Shell/Register/x86-gp-write.test 
b/lldb/test/Shell/Register/x86-gp-write.test
index c422ffd95bea..7ec0d858f7b8 100644
--- a/lldb/test/Shell/Register/x86-gp-write.test
+++ b/lldb/test/Shell/Register/x86-gp-write.test
@@ -1,6 +1,6 @@
 # XFAIL: system-windows
 # REQUIRES: native && target-x86
-# RUN: %clangxx_host -fomit-frame-pointer %p/Inputs/x86-gp-write.cpp -o %t
+# RUN: %clangxx_host -mmmx -fomit-frame-pointer %p/Inputs/x86-gp-write.cpp -o 
%t
 # RUN: %lldb -b -s %s %t | FileCheck %s
 process launch
 



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

[Lldb-commits] [PATCH] D91497: [lldb] Add explicit 64-bit fip/fdp registers on x86_64

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

mgorny marked an inline comment as done.
mgorny added inline comments.



Comment at: lldb/unittests/Process/Utility/RegisterContextFreeBSDTest.cpp:82-83
   EXPECT_OFF(fop_x86_64, 0x06, 2);
   // NB: Technically fiseg/foseg are 16-bit long and the higher 16 bits
   // are reserved.  However, we use them to access/recombine 64-bit FIP/FDP.
   EXPECT_OFF(fioff_x86_64, 0x08, 4);

labath wrote:
> I guess this isn't really true anymore?
I'll update the comment to make it clear it's backwards compat thing.


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

https://reviews.llvm.org/D91497

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

[Lldb-commits] [PATCH] D91645: [lldb] [test] Un-XFAIL tests on freebsd/i386

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

mgorny added inline comments.



Comment at: lldb/test/API/functionalities/exec/TestExec.py:19
 
-@expectedFailureAll(archs=['i386'], bugnumber="rdar://28656532")
+@expectedFailureAll(archs=['i386'],
+oslist=no_match(["freebsd"]),

emaste wrote:
> Interesting, so FreeBSD is now the only OS where this test passes on i386?
> 
> Of course rdar://28656532 is opaque, would be nice if Apple folks can provide 
> some insight on this.
I suspect others might pass too and this is a Darwin-specific issue but I don't 
have 32-bit NetBSD install handy at the moment, and LLDB doesn't seem to work 
at all on Arch Linux 32 for some obscure reason.


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

https://reviews.llvm.org/D91645

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

[Lldb-commits] [PATCH] D89315: [debugserver] Add option to propagate SIGSEGV to target process

[Alessandro Arzilli via Phabricator via lldb-commits]

aarzilli added a comment.

In D89315#2400244 , @JDevlieghere 
wrote:

> In D89315#2399805 , @aarzilli wrote:
>
>> I don't want to be overbearing but should I be doing something else? Is this 
>> going to be merged and, if it is, what timeline should I expect?
>
> I think nobody realized you didn't have commit access, feel free to ask 
> someone to merge something for you in the future.  I'll take care of this 
> patch for you.

Thank you.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89315

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

[Lldb-commits] [PATCH] D91504: [lldb] Use translated full ftag values [WIP]

[Pavel Labath via Phabricator via lldb-commits]

labath added inline comments.



Comment at: 
lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.cpp:534
+  // TODO
+  if (reg_info->kinds[lldb::eRegisterKindLLDB] == lldb_ftag_x86_64) {
+uint8_t abridged_tw = *(uint8_t *)src;

mgorny wrote:
> labath wrote:
> > mgorny wrote:
> > > @labath, any suggestion what kind of test to use here? Maybe against 
> > > `_xstate->fxsave.ftag` address?
> > You mean, like, how to detect that we're dealing with the ftag register?
> > 
> > This approach seems reasonable to me..
> This = checking register number like in the code (in which I suppose we'd 
> have to move distinguishing amd64/i386 to ctor like `first_fpr`? Or checking 
> for actual pointer as I suggested in the comment?
I originally meant the register number approach, but I see what you mean now.

I think that going off of the address is perfectly fine...


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

https://reviews.llvm.org/D91504

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

[Lldb-commits] [PATCH] D91508: [LLDB/Lua] add support for one-liner breakpoint callback

[Pavel Labath via Phabricator via lldb-commits]

labath added inline comments.



Comment at: lldb/bindings/lua/lua-wrapper.swig:26-27
+
+   SBTypeToSWIGWrapper(L, _frame);
+   SBTypeToSWIGWrapper(L, _bp_loc);
+

This name made sense for python, as the functions actually returned the 
wrappers. But here, the name makes it pretty unobvious that these functions 
actually push the object on the lua stack. It'd be better if this was called 
something like `PushSBType` or something



Comment at: lldb/source/Plugins/ScriptInterpreter/Lua/Lua.cpp:60-78
+static int runCallback(lua_State *L) {
+  LuaCallback *callback = static_cast(lua_touserdata(L, -1));
+  return (*callback)(L);
+}
+
+llvm::Error Lua::Run(LuaCallback ) {
+  lua_pushcfunction(m_lua_state, runCallback);

tammela wrote:
> labath wrote:
> > I'm confused. Why use lua to call a c callback, when you could just do 
> > `calllback()`?
> Some Lua API functions throw errors, if there's any it will `abort()` the 
> program if no panic handler or protected call is provided.
> To guarantee that the callback always runs in a protected environment and it 
> has error handling, we do the above.
> Delegating this to the callback itself makes it cumbersome to write.
Aha, I see.

So, if I remember my lua correctly (I wrote a c++ lua wrapper once, but that 
was years ago..), whenever there's a lua exception inside this (c++) callback, 
lua will longjmp(3) back to the lua_pcall call on line 68, skipping any 
destructors that should normally be invoked. Is that so?

If that's the case, then I think this is a dangerous api, that should at the 
very least get a big fat warning, but that ideally shouldn't exist at all.

What's the part that makes delegating this to the callback "cumersome to 
write"? And why can't that be overcome by a suitable utility function which 
wraps `lua_pcall` or whatever else is needed?

The approach that we've chosen in python is to have very little code 
interacting with the python C API directly. Instead, code generally works with 
our C++ wrappers defined in `PythonDataObject.h`. These functions try to hide 
the python exception magic as much as possible, and present a c++-y version of 
the interface.

Now, since lua is stack-based, something like LuaDataObjects.h would probably 
not work. However, that doesn't meant we should give up on the c++ wrapper  
idea altogether. During the intitial reviews, my intention was for the `Lua` 
class to serve this purpose. I still think this can be achieved if we make the 
callback functions take `Lua&` instead of `lua_State*` as an argument, and then 
ensure the class contains whatever is needed to make the callbacks not 
cumerbsome to write.



Comment at: 
lldb/source/Plugins/ScriptInterpreter/Lua/ScriptInterpreterLua.cpp:200
+  Debugger  = target->GetDebugger();
+  ScriptInterpreterLua *lua_interpreter =
+  static_cast(debugger.GetScriptInterpreter());

tammela wrote:
> labath wrote:
> > How is `lua_interpreter` different from `this`?
> Are you asking why I didn't go for `m_script_interpreter`?
> 
> This function is static (on the class declaration), perhaps it's clearer a 
> `static` keyword here as well?
I just missed the fact that this is a static function (I hate these static 
baton functions in lldb). Putting `static` on an out-of-line member function 
definition is not valid c++.

However, this does raise a different issue. Debugger::GetScriptInterpreter will 
return the default script interpreter, and that may not be the lua one. I think 
you should pass eScriptLanguageLua here explicitly.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91508

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

[Lldb-commits] [PATCH] D91645: [lldb] [test] Un-XFAIL tests on freebsd/i386

[Pavel Labath via Phabricator via lldb-commits]

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

These seems to pass on linux as well (and possibly others too), but I guess 
nobody runs i386 tests these days...


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

https://reviews.llvm.org/D91645

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

[Lldb-commits] [lldb] 2fa38fa - [lldb] Python3 byte<->string issue in patch-crashlog.py

[Raphael Isemann via lldb-commits]

Author: Raphael Isemann
Date: 2020-11-18T09:58:02+01:00
New Revision: 2fa38fa9a651553080620f4c9883d075df2a706e

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

LOG: [lldb] Python3 byte<->string issue in patch-crashlog.py

Added: 


Modified: 
lldb/test/Shell/ScriptInterpreter/Python/Crashlog/patch-crashlog.py

Removed: 




diff  --git 
a/lldb/test/Shell/ScriptInterpreter/Python/Crashlog/patch-crashlog.py 
b/lldb/test/Shell/ScriptInterpreter/Python/Crashlog/patch-crashlog.py
index a8aeb357c846..9616591c1f74 100644
--- a/lldb/test/Shell/ScriptInterpreter/Python/Crashlog/patch-crashlog.py
+++ b/lldb/test/Shell/ScriptInterpreter/Python/Crashlog/patch-crashlog.py
@@ -24,7 +24,7 @@ def patch_executable(self):
 self.data = self.data.replace("@NAME@", os.path.basename(self.binary))
 
 def patch_uuid(self):
-output = subprocess.check_output(['dwarfdump', '--uuid', self.binary])
+output = subprocess.check_output(['dwarfdump', '--uuid', 
self.binary]).decode("utf-8")
 m = self.UUID_REGEX.match(output)
 if m:
 self.data = self.data.replace("@UUID@", m.group(1))



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