[Lldb-commits] [lldb] 3805455 - Fix buildbots after https://reviews.llvm.org/D119797

[Greg Clayton via lldb-commits]

Author: Greg Clayton
Date: 2022-02-17T23:59:15-08:00
New Revision: 38054556a08884aa15d3ebc720e2f43d0cb5a944

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

LOG: Fix buildbots after https://reviews.llvm.org/D119797

This value error is no longer needed with the new version of the patch

Added: 


Modified: 
lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/vscode.py

Removed: 




diff  --git a/lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/vscode.py 
b/lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/vscode.py
index ae919fc2ed0c6..faa0b93b3f9a7 100644
--- a/lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/vscode.py
+++ b/lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/vscode.py
@@ -228,9 +228,9 @@ def handle_recv_packet(self, packet):
 # 'stopped' event. We need to remember the thread stop
 # reasons since the 'threads' command doesn't return
 # that information.
-if not self.configuration_done_sent:
-raise ValueError("'stopped' event received before "
- "configuationDone packet was sent")
+# if not self.configuration_done_sent:
+# raise ValueError("'stopped' event received before "
+#  "configuationDone packet was sent")
 self._process_stopped()
 tid = body['threadId']
 self.thread_stop_reasons[tid] = body



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

[Lldb-commits] [PATCH] D119797: Fix race condition when launching and attaching.

[Greg Clayton via Phabricator via lldb-commits]

clayborg added a comment.

Fixed buildbots with:

  commit 38054556a08884aa15d3ebc720e2f43d0cb5a944 (HEAD -> main, origin/main, 
origin/HEAD)
  Author: Greg Clayton 
  Date:   Thu Feb 17 23:59:15 2022 -0800
  
  Fix buildbots after https://reviews.llvm.org/D119797
  
  This value error is no longer needed with the new version of the patch


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119797

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

[Lldb-commits] [PATCH] D119797: Fix race condition when launching and attaching.

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

TestVSCode_attach.py  
is still failing. Are you able to fix that quickly or shall we revert?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119797

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

[Lldb-commits] [PATCH] D119797: Fix race condition when launching and attaching.

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

There's also a timeout in TestVSCode_coreFile.py


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119797

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

[Lldb-commits] [PATCH] D120101: [lldb] Fix (unintentional) recursion in CommandObjectRegexCommand

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

Wouldn't want to miss a good bikeshed. Logarithms are cool, but I think 
something like this (untested) snippet would be simpler

  Input.split(Parts, '%');
  Result << Parts[0];
  for (llvm::StringRef Part : drop_begin(Parts)) {
if (!Part.consumeInteger(10, Idx) && Idx < Replacements.size())
  Result << Replacements[Idx];
else
  Result << '%';
Result << Part;
  }


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

https://reviews.llvm.org/D120101

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

[Lldb-commits] [PATCH] D119548: [lldb] Fix race condition between lldb-vscode and stop hooks executor

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

In D119548#3330773 , @ilya-nozhkin 
wrote:

> In D119548#3330226 , @clayborg 
> wrote:
>
>> Try out the https://reviews.llvm.org/D119797 patch and see if this fixes 
>> this issue? I have just updated it after responding to comments.
>
> Yes, it fixes this particular race. But I think, that the issue is not only 
> with stop hooks and lldb-vscode. Some other tools can do something similar to 
> lldb-vscode and get the same issue. So, I think, it's still worth fixing the 
> event dispatching.

Definitely worth fixing this too.

In D119548#3329785 , @ilya-nozhkin 
wrote:

> Made requested changes.
>
> I agree with @jingham that if the listener is passed via launch info then we 
> don't need to activate it in `CreateProcess`.

Sounds good. I'm happy with this if Jim is.


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

https://reviews.llvm.org/D119548

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

[Lldb-commits] [PATCH] D111634: [lldb] Print embedded nuls in char arrays (PR44649)

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

Yeah, I suppose that makes sense. Like, I don't think we can ever have a single 
solution that does exactly what people would expect in every possible 
situation. The only counterargument I can think of is "but gdb does it that 
way", but I don't think that's a particularly strong one in this case.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111634

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

[Lldb-commits] [PATCH] D119963: [LLDB] Dump valid ranges of variables

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

In D119963#3329973 , @jingham wrote:

> There was a question on the dev list a while ago about to print out all the 
> valid ranges of a variable.  That's a useful bit of info if you're trying to 
> figure out where you could break to actually see or change a variable's value 
> in an optimized function.  I think that's the motivation for the change, so 
> just showing the range that encompasses the address wouldn't satisfy that 
> initial impetus for the change.

I'm pretty sure the immediate motivation is testing of D119508 
, but yes, if there was another feature 
request for something like this, then it makes sense to implement it more fully.




Comment at: lldb/test/Shell/SymbolFile/DWARF/x86/debug_loc.s:28-29
 # CHECK: Variable{{.*}}, name = "x0", {{.*}}, scope = parameter, location =
 # CHECK-NEXT:  [0x, 0x0001): DW_OP_reg5 RDI
 # CHECK-NEXT:  [0x0001, 0x0006): DW_OP_reg0 RAX
 # CHECK: Variable{{.*}}, name = "x1", {{.*}}, scope = parameter

zequanwu wrote:
> labath wrote:
> > zequanwu wrote:
> > > `image dump symfile` already prints valid ranges for variables along with 
> > > where the value is at each range.
> > Are you sure it does?
> > 
> > I was under the impression that there are two distinct range concepts being 
> > combined here. One is the range list member of the Variable object (as 
> > given by `GetScopeRange` -- that's the one you're printing now), and the 
> > other is the list of ranges hidden in the DWARFExpression object, which 
> > come from the debug_loc(lists) section (that's the one we've been printing 
> > so far). And that the root cause of the confusion is the very existence of 
> > these two concepts.
> > 
> > If I got it wrong, then do let me know, cause it would make things a lot 
> > simpler if there is only one validity concept to think about.
> Dwarf plugin is supposed to construct the `m_scope_range` member of an 
> Variable, but it doesn't. `scope_ranges` is empty at 
> https://github.com/llvm/llvm-project/blob/main/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp#L3468.
>  
> `image dump symfile` dumps the dwarf location list in `m_location` in 
> `Variable`. 
> The dwarf location list has more information than `m_scope_range` as it 
> contains info about where the value is during each range. (e.g. which 
> register the variable lives in). 
> 
> So, I think we need to use similar logic to construct `m_scope_range` when 
> creating `Variable` in dwarf plugin like this 
> https://github.com/llvm/llvm-project/blob/main/lldb/source/Expression/DWARFExpression.cpp#L145.
Ok, I see where you're coming from. You're essentially saying that the fact 
that the dwarf plugin does not fill this out is a bug.

I don't think that's the case. My interpretation was (and [[ 
https://github.com/llvm/llvm-project/blob/main/lldb/source/Symbol/Variable.cpp#L313
 | this comment]] confirms it) that an empty range here means the entire 
enclosing block. (Also, DWARF was for a long time the only symbol file plugin, 
so what it does is kinda "correct by definition").

I don't think we want to change that interpretation, as forcing a copy of the 
range in the location list would be wasteful (it would be different if this was 
an interface that one could query, and that the dwarf plugin could implement by 
consulting the location list). However, since the dwarf class does not actually 
make use of this functionality (it was [[ https://reviews.llvm.org/D17449 | 
added ]] to support DW_AT_start_scope, then broken at some point, and 
eventually [[ https://reviews.llvm.org/D62302 | removed ]]), we do have some 
freedom in defining the interactions of the two fields (if you still want to 
pursue this, that is).

So how about this: if the user passes the extra flag, then we print both the 
range field (if it exists), and the *full* location list (in that order, 
ideally). That way the output will be either `range = [a, b), [c, d), location 
= DW_OP_reg47` or `location = [a,b) -> DW_OP_reg4, [c,d) -> DW_OP_reg7`. If the 
dwarf plugin starts using the range field again then the output will contain 
both fields, which will be slightly confusing, but at least not misleading (and 
we can also change the format then).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119963

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

[Lldb-commits] [PATCH] D120100: [lldb] Expose eBroadcastBitProgress to the SWIG SBAPI

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

I'm not sure how we ended up with the .i files in the first place, but maybe a 
good solution to this problem would be to ditch those and generate bindings 
from .h files directly.

It may mean that we need to put `#ifndef SWIG` around some code, but I'd say 
that beats maintaining two separate copies of the interface. (Also, the ifdefs 
are a pretty good way to document the bits of the "public" API that we do not 
wish to make available to scripts.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120100

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

[Lldb-commits] [lldb] a59014b - Revert "Fix race condition when launching and attaching."

[Pavel Labath via lldb-commits]

Author: Pavel Labath
Date: 2022-02-18T12:11:37+01:00
New Revision: a59014b759050af93e0ab214dcbf0cc2dd75bb75

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

LOG: Revert "Fix race condition when launching and attaching."

It breaks TestVSCode_attach.py.

This reverts commit 9febd1e573fb8b3d1de5844b7bfd33eb998f0106 and
38054556a08884aa15d3ebc720e2f43d0cb5a944.

Added: 


Modified: 
lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/vscode.py
lldb/test/API/tools/lldb-vscode/launch/TestVSCode_launch.py
lldb/tools/lldb-vscode/VSCode.cpp
lldb/tools/lldb-vscode/VSCode.h
lldb/tools/lldb-vscode/lldb-vscode.cpp
lldb/tools/lldb-vscode/package.json

Removed: 




diff  --git a/lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/vscode.py 
b/lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/vscode.py
index faa0b93b3f9a7..603b1545cd714 100644
--- a/lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/vscode.py
+++ b/lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/vscode.py
@@ -228,9 +228,6 @@ def handle_recv_packet(self, packet):
 # 'stopped' event. We need to remember the thread stop
 # reasons since the 'threads' command doesn't return
 # that information.
-# if not self.configuration_done_sent:
-# raise ValueError("'stopped' event received before "
-#  "configuationDone packet was sent")
 self._process_stopped()
 tid = body['threadId']
 self.thread_stop_reasons[tid] = body

diff  --git a/lldb/test/API/tools/lldb-vscode/launch/TestVSCode_launch.py 
b/lldb/test/API/tools/lldb-vscode/launch/TestVSCode_launch.py
index 8cbdb1546..ff798364c9573 100644
--- a/lldb/test/API/tools/lldb-vscode/launch/TestVSCode_launch.py
+++ b/lldb/test/API/tools/lldb-vscode/launch/TestVSCode_launch.py
@@ -374,7 +374,7 @@ def test_commands(self):
 @skipIfRemote
 def test_extra_launch_commands(self):
 '''
-Tests the "launchCommands" with extra launching settings
+Tests the "luanchCommands" with extra launching settings
 '''
 self.build_and_create_debug_adaptor()
 program = self.getBuildArtifact("a.out")

diff  --git a/lldb/tools/lldb-vscode/VSCode.cpp 
b/lldb/tools/lldb-vscode/VSCode.cpp
index a6fe7f840a566..3209eea4a897f 100644
--- a/lldb/tools/lldb-vscode/VSCode.cpp
+++ b/lldb/tools/lldb-vscode/VSCode.cpp
@@ -528,58 +528,6 @@ void VSCode::RegisterRequestCallback(std::string request,
   request_handlers[request] = callback;
 }
 
-lldb::SBError VSCode::WaitForProcessToStop(uint32_t seconds) {
-  // Wait for the process hit a stopped state. When running a launch (with or
-  // without "launchCommands") or attach (with or without)= "attachCommands"),
-  // the calls might take some time to stop at the entry point since the 
command
-  // is asynchronous. So we need to sync up with the process and make sure it 
is
-  // stopped before we proceed to do anything else as we will soon be asked to
-  // set breakpoints and other things that require the process to be stopped.
-  // We must use polling because attach doesn't send a process state change
-  // event for the first stop, while launching does. Since both 
"attachCommands"
-  // and "launchCommands" could end up using any combination of LLDB commands,
-  // we must ensure we can also catch when the process stops, so we must poll
-  // the process to make sure we handle all cases.
-
-  lldb::SBError error;
-  lldb::SBProcess process = target.GetProcess();
-  if (!process.IsValid()) {
-error.SetErrorString("invalid process");
-return error;
-  }
-  auto timeout_time =
-  std::chrono::high_resolution_clock::now() + 
std::chrono::seconds(seconds);
-  while (std::chrono::high_resolution_clock::now() < timeout_time) {
-const auto state = process.GetState();
-switch (state) {
-  case lldb::eStateAttaching:
-  case lldb::eStateConnected:
-  case lldb::eStateInvalid:
-  case lldb::eStateLaunching:
-  case lldb::eStateRunning:
-  case lldb::eStateStepping:
-  case lldb::eStateSuspended:
-break;
-  case lldb::eStateDetached:
-error.SetErrorString("process detached during launch or attach");
-return error;
-  case lldb::eStateExited:
-error.SetErrorString("process exited during launch or attach");
-return error;
-  case lldb::eStateUnloaded:
-error.SetErrorString("process unloaded during launch or attach");
-return error;
-  case lldb::eStateCrashed:
-  case lldb::eStateStopped:
-return lldb::SBError(); // Success!
-}
-std::this_thread::sleep_for(std::chrono::microseconds(

[Lldb-commits] [lldb] 6c99a34 - [lldb] Add support for a "global" lldbinit file

[Pavel Labath via lldb-commits]

Author: Pavel Labath
Date: 2022-02-18T12:30:22+01:00
New Revision: 6c99a3469d9c0a48fb2a9fec845d284ef39338ee

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

LOG: [lldb] Add support for a "global" lldbinit file

This patch adds introduces a new kind of an lldbinit file. Unlike the
lldbinit in the home directory (useful for customizing lldb to the needs
of a particular user), or the cwd lldbinit file (useful for
project-specific settings), this file can be used to customize an entire
lldb installation to a particular environment.

The feature is enabled at build time, by setting the
LLDB_GLOBAL_INIT_DIRECTORY variable to a path to a directory which
should contain an "lldbinit" file. Lldb will then load the file at
startup, if it exists, and if automatic init loading has not been
disabled. Relative paths will be resolved (at runtime) relative to the
location of the lldb library (liblldb or LLDB.framework).

The system-wide lldbinit file will be loaded first, before any
$HOME/.lldbinit and $CWD/.lldbinit files are processed, so that those
can override any system-wide settings.

More information can be found on the RFC thread at
.

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

Added: 


Modified: 
lldb/cmake/modules/LLDBConfig.cmake
lldb/include/lldb/API/SBCommandInterpreter.h
lldb/include/lldb/Host/Config.h.cmake
lldb/include/lldb/Interpreter/CommandInterpreter.h
lldb/source/API/SBCommandInterpreter.cpp
lldb/source/API/SBDebugger.cpp
lldb/source/Interpreter/CommandInterpreter.cpp
lldb/tools/driver/Driver.cpp

Removed: 




diff  --git a/lldb/cmake/modules/LLDBConfig.cmake 
b/lldb/cmake/modules/LLDBConfig.cmake
index e12e548ad0c41..69aaadf29ef64 100644
--- a/lldb/cmake/modules/LLDBConfig.cmake
+++ b/lldb/cmake/modules/LLDBConfig.cmake
@@ -72,6 +72,10 @@ option(LLDB_USE_SYSTEM_DEBUGSERVER "Use the system's 
debugserver for testing (Da
 option(LLDB_SKIP_STRIP "Whether to skip stripping of binaries when installing 
lldb." OFF)
 option(LLDB_SKIP_DSYM "Whether to skip generating a dSYM when installing 
lldb." OFF)
 
+set(LLDB_GLOBAL_INIT_DIRECTORY "" CACHE STRING
+  "Path to the global lldbinit directory. Relative paths are resolved relative 
to the
+  directory containing the LLDB library.")
+
 if (LLDB_USE_SYSTEM_DEBUGSERVER)
   # The custom target for the system debugserver has no install target, so we
   # need to remove it from the LLVM_DISTRIBUTION_COMPONENTS list.

diff  --git a/lldb/include/lldb/API/SBCommandInterpreter.h 
b/lldb/include/lldb/API/SBCommandInterpreter.h
index 4ebcc797d5bb6..0d344fc7fbcbf 100644
--- a/lldb/include/lldb/API/SBCommandInterpreter.h
+++ b/lldb/include/lldb/API/SBCommandInterpreter.h
@@ -147,6 +147,8 @@ class SBCommandInterpreter {
  const char *help, const char *syntax,
  const char *auto_repeat_command);
 
+  void SourceInitFileInGlobalDirectory(lldb::SBCommandReturnObject &result);
+
   void SourceInitFileInHomeDirectory(lldb::SBCommandReturnObject &result);
   void SourceInitFileInHomeDirectory(lldb::SBCommandReturnObject &result,
  bool is_repl);

diff  --git a/lldb/include/lldb/Host/Config.h.cmake 
b/lldb/include/lldb/Host/Config.h.cmake
index ffe919aa99561..c24603f866d6b 100644
--- a/lldb/include/lldb/Host/Config.h.cmake
+++ b/lldb/include/lldb/Host/Config.h.cmake
@@ -53,4 +53,6 @@
 
 #define LLDB_LIBDIR_SUFFIX "${LLVM_LIBDIR_SUFFIX}"
 
+#cmakedefine LLDB_GLOBAL_INIT_DIRECTORY R"(${LLDB_GLOBAL_INIT_DIRECTORY})"
+
 #endif // #ifndef LLDB_HOST_CONFIG_H

diff  --git a/lldb/include/lldb/Interpreter/CommandInterpreter.h 
b/lldb/include/lldb/Interpreter/CommandInterpreter.h
index af4117fcc4867..938d36ba0f3fc 100644
--- a/lldb/include/lldb/Interpreter/CommandInterpreter.h
+++ b/lldb/include/lldb/Interpreter/CommandInterpreter.h
@@ -253,6 +253,7 @@ class CommandInterpreter : public Broadcaster,
 
   void SourceInitFileCwd(CommandReturnObject &result);
   void SourceInitFileHome(CommandReturnObject &result, bool is_repl);
+  void SourceInitFileGlobal(CommandReturnObject &result);
 
   bool AddCommand(llvm::StringRef name, const lldb::CommandObjectSP &cmd_sp,
   bool can_replace);

diff  --git a/lldb/source/API/SBCommandInterpreter.cpp 
b/lldb/source/API/SBCommandInterpreter.cpp
index 0a8c83f51f207..a19ad48dde042 100644
--- a/lldb/source/API/SBCommandInterpreter.cpp
+++ b/lldb/source/API/SBCommandInterpreter.cpp
@@ -423,6 +423,22 @@ void SBCommandInterpreter::reset(
   m_opaque_ptr = interpreter;
 }
 
+void SBCommandInterpreter::SourceInitFileInGlobalDirectory(
+SBCommandReturnObject &result) {
+  LLDB_INSTRUMENT_VA(this, result);
+
+  result.Clea

[Lldb-commits] [PATCH] D119831: [lldb] Add support for a "global" lldbinit file

[Pavel Labath via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG6c99a3469d9c: [lldb] Add support for a "global" 
lldbinit file (authored by labath).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119831

Files:
  lldb/cmake/modules/LLDBConfig.cmake
  lldb/include/lldb/API/SBCommandInterpreter.h
  lldb/include/lldb/Host/Config.h.cmake
  lldb/include/lldb/Interpreter/CommandInterpreter.h
  lldb/source/API/SBCommandInterpreter.cpp
  lldb/source/API/SBDebugger.cpp
  lldb/source/Interpreter/CommandInterpreter.cpp
  lldb/tools/driver/Driver.cpp

Index: lldb/tools/driver/Driver.cpp
===
--- lldb/tools/driver/Driver.cpp
+++ lldb/tools/driver/Driver.cpp
@@ -452,9 +452,14 @@
 
   SBCommandInterpreter sb_interpreter = m_debugger.GetCommandInterpreter();
 
-  // Before we handle any options from the command line, we parse the
-  // REPL init file or the default file in the user's home directory.
+  // Process lldbinit files before handling any options from the command line.
   SBCommandReturnObject result;
+  sb_interpreter.SourceInitFileInGlobalDirectory(result);
+  if (m_option_data.m_debug_mode) {
+result.PutError(m_debugger.GetErrorFile());
+result.PutOutput(m_debugger.GetOutputFile());
+  }
+
   sb_interpreter.SourceInitFileInHomeDirectory(result, m_option_data.m_repl);
   if (m_option_data.m_debug_mode) {
 result.PutError(m_debugger.GetErrorFile());
Index: lldb/source/Interpreter/CommandInterpreter.cpp
===
--- lldb/source/Interpreter/CommandInterpreter.cpp
+++ lldb/source/Interpreter/CommandInterpreter.cpp
@@ -2380,6 +2380,21 @@
   SourceInitFile(FileSpec(init_file.str()), result);
 }
 
+void CommandInterpreter::SourceInitFileGlobal(CommandReturnObject &result) {
+#ifdef LLDB_GLOBAL_INIT_DIRECTORY
+  if (!m_skip_lldbinit_files) {
+FileSpec init_file(LLDB_GLOBAL_INIT_DIRECTORY);
+if (init_file)
+  init_file.MakeAbsolute(HostInfo::GetShlibDir());
+
+init_file.AppendPathComponent("lldbinit");
+SourceInitFile(init_file, result);
+return;
+  }
+#endif
+  result.SetStatus(eReturnStatusSuccessFinishNoResult);
+}
+
 const char *CommandInterpreter::GetCommandPrefix() {
   const char *prefix = GetDebugger().GetIOHandlerCommandPrefix();
   return prefix == nullptr ? "" : prefix;
Index: lldb/source/API/SBDebugger.cpp
===
--- lldb/source/API/SBDebugger.cpp
+++ lldb/source/API/SBDebugger.cpp
@@ -236,6 +236,7 @@
 interp.get()->SkipLLDBInitFiles(false);
 interp.get()->SkipAppInitFiles(false);
 SBCommandReturnObject result;
+interp.SourceInitFileInGlobalDirectory(result);
 interp.SourceInitFileInHomeDirectory(result, false);
   } else {
 interp.get()->SkipLLDBInitFiles(true);
Index: lldb/source/API/SBCommandInterpreter.cpp
===
--- lldb/source/API/SBCommandInterpreter.cpp
+++ lldb/source/API/SBCommandInterpreter.cpp
@@ -423,6 +423,22 @@
   m_opaque_ptr = interpreter;
 }
 
+void SBCommandInterpreter::SourceInitFileInGlobalDirectory(
+SBCommandReturnObject &result) {
+  LLDB_INSTRUMENT_VA(this, result);
+
+  result.Clear();
+  if (IsValid()) {
+TargetSP target_sp(m_opaque_ptr->GetDebugger().GetSelectedTarget());
+std::unique_lock lock;
+if (target_sp)
+  lock = std::unique_lock(target_sp->GetAPIMutex());
+m_opaque_ptr->SourceInitFileGlobal(result.ref());
+  } else {
+result->AppendError("SBCommandInterpreter is not valid");
+  }
+}
+
 void SBCommandInterpreter::SourceInitFileInHomeDirectory(
 SBCommandReturnObject &result) {
   LLDB_INSTRUMENT_VA(this, result);
Index: lldb/include/lldb/Interpreter/CommandInterpreter.h
===
--- lldb/include/lldb/Interpreter/CommandInterpreter.h
+++ lldb/include/lldb/Interpreter/CommandInterpreter.h
@@ -253,6 +253,7 @@
 
   void SourceInitFileCwd(CommandReturnObject &result);
   void SourceInitFileHome(CommandReturnObject &result, bool is_repl);
+  void SourceInitFileGlobal(CommandReturnObject &result);
 
   bool AddCommand(llvm::StringRef name, const lldb::CommandObjectSP &cmd_sp,
   bool can_replace);
Index: lldb/include/lldb/Host/Config.h.cmake
===
--- lldb/include/lldb/Host/Config.h.cmake
+++ lldb/include/lldb/Host/Config.h.cmake
@@ -53,4 +53,6 @@
 
 #define LLDB_LIBDIR_SUFFIX "${LLVM_LIBDIR_SUFFIX}"
 
+#cmakedefine LLDB_GLOBAL_INIT_DIRECTORY R"(${LLDB_GLOBAL_INIT_DIRECTORY})"
+
 #endif // #ifndef LLDB_HOST_CONFIG_H
Index: lldb/include/lldb/API/SBCommandInterpreter.h
===
--- lldb/include/lldb/API/SBCommandInterpreter.h
+++ lldb/include/lldb

[Lldb-commits] [lldb] f20f9f5 - [lldb] Add llvm_unreachable in RichManglingContext

[Dave Lee via lldb-commits]

Author: Dave Lee
Date: 2022-02-18T08:38:03-08:00
New Revision: f20f9f5a32c02e7df3fc9a9d48643471dc6d41a5

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

LOG: [lldb] Add llvm_unreachable in RichManglingContext

Add `llvm_unreachable` to prevent warnings/errors in gcc and msvc.

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

Added: 


Modified: 
lldb/source/Core/RichManglingContext.cpp

Removed: 




diff  --git a/lldb/source/Core/RichManglingContext.cpp 
b/lldb/source/Core/RichManglingContext.cpp
index f1e81be417b0e..64b18b401f2d6 100644
--- a/lldb/source/Core/RichManglingContext.cpp
+++ b/lldb/source/Core/RichManglingContext.cpp
@@ -123,6 +123,7 @@ llvm::StringRef 
RichManglingContext::ParseFunctionBaseName() {
   case None:
 return {};
   }
+  llvm_unreachable("Fully covered switch above!");
 }
 
 llvm::StringRef RichManglingContext::ParseFunctionDeclContextName() {
@@ -139,6 +140,7 @@ llvm::StringRef 
RichManglingContext::ParseFunctionDeclContextName() {
   case None:
 return {};
   }
+  llvm_unreachable("Fully covered switch above!");
 }
 
 llvm::StringRef RichManglingContext::ParseFullName() {
@@ -156,4 +158,5 @@ llvm::StringRef RichManglingContext::ParseFullName() {
   case None:
 return {};
   }
+  llvm_unreachable("Fully covered switch above!");
 }



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

[Lldb-commits] [PATCH] D119737: [lldb] Add llvm_unreachable in RichManglingContext

[Dave Lee via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGf20f9f5a32c0: [lldb] Add llvm_unreachable in 
RichManglingContext (authored by kastiglione).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119737

Files:
  lldb/source/Core/RichManglingContext.cpp


Index: lldb/source/Core/RichManglingContext.cpp
===
--- lldb/source/Core/RichManglingContext.cpp
+++ lldb/source/Core/RichManglingContext.cpp
@@ -123,6 +123,7 @@
   case None:
 return {};
   }
+  llvm_unreachable("Fully covered switch above!");
 }
 
 llvm::StringRef RichManglingContext::ParseFunctionDeclContextName() {
@@ -139,6 +140,7 @@
   case None:
 return {};
   }
+  llvm_unreachable("Fully covered switch above!");
 }
 
 llvm::StringRef RichManglingContext::ParseFullName() {
@@ -156,4 +158,5 @@
   case None:
 return {};
   }
+  llvm_unreachable("Fully covered switch above!");
 }


Index: lldb/source/Core/RichManglingContext.cpp
===
--- lldb/source/Core/RichManglingContext.cpp
+++ lldb/source/Core/RichManglingContext.cpp
@@ -123,6 +123,7 @@
   case None:
 return {};
   }
+  llvm_unreachable("Fully covered switch above!");
 }
 
 llvm::StringRef RichManglingContext::ParseFunctionDeclContextName() {
@@ -139,6 +140,7 @@
   case None:
 return {};
   }
+  llvm_unreachable("Fully covered switch above!");
 }
 
 llvm::StringRef RichManglingContext::ParseFullName() {
@@ -156,4 +158,5 @@
   case None:
 return {};
   }
+  llvm_unreachable("Fully covered switch above!");
 }
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D119548: [lldb] Fix race condition between lldb-vscode and stop hooks executor

[Jim Ingham via Phabricator via lldb-commits]

jingham added a comment.

Yes, that looks great.  Thanks for persisting!


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

https://reviews.llvm.org/D119548

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

[Lldb-commits] [lldb] e4a03b2 - [lldb] Default initialize CommandOptions fields (NFC)

[Jonas Devlieghere via lldb-commits]

Author: Jonas Devlieghere
Date: 2022-02-18T09:07:25-08:00
New Revision: e4a03b26898e9ca5917a425fc4b089bf5ba19272

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

LOG: [lldb] Default initialize CommandOptions fields (NFC)

Make sure all fields are default initialized to the same values.

Added: 


Modified: 
lldb/source/Commands/CommandObjectCommands.cpp

Removed: 




diff  --git a/lldb/source/Commands/CommandObjectCommands.cpp 
b/lldb/source/Commands/CommandObjectCommands.cpp
index ebb84bce7323f..a828ba16e8781 100644
--- a/lldb/source/Commands/CommandObjectCommands.cpp
+++ b/lldb/source/Commands/CommandObjectCommands.cpp
@@ -1480,7 +1480,7 @@ class CommandObjectCommandsScriptAdd : public 
CommandObjectParsed,
 std::string m_class_name;
 std::string m_funct_name;
 std::string m_short_help;
-bool m_overwrite;
+bool m_overwrite = false;
 ScriptedCommandSynchronicity m_synchronicity =
 eScriptedCommandSynchronicitySynchronous;
   };
@@ -1637,8 +1637,9 @@ class CommandObjectCommandsScriptAdd : public 
CommandObjectParsed,
   std::string m_cmd_name;
   CommandObjectMultiword *m_container = nullptr;
   std::string m_short_help;
-  bool m_overwrite;
-  ScriptedCommandSynchronicity m_synchronicity;
+  bool m_overwrite = false;
+  ScriptedCommandSynchronicity m_synchronicity =
+  eScriptedCommandSynchronicitySynchronous;
 };
 
 // CommandObjectCommandsScriptList



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

[Lldb-commits] [PATCH] D120101: [lldb] Fix (unintentional) recursion in CommandObjectRegexCommand

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere updated this revision to Diff 409963.
JDevlieghere added a comment.

Use Pavel's //not-as-cool// solution.


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

https://reviews.llvm.org/D120101

Files:
  lldb/source/Commands/CommandObjectRegexCommand.cpp
  lldb/source/Commands/CommandObjectRegexCommand.h
  lldb/unittests/Interpreter/CMakeLists.txt
  lldb/unittests/Interpreter/TestRegexCommand.cpp

Index: lldb/unittests/Interpreter/TestRegexCommand.cpp
===
--- /dev/null
+++ lldb/unittests/Interpreter/TestRegexCommand.cpp
@@ -0,0 +1,50 @@
+//===-- TestRegexCommand.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 "Commands/CommandObjectRegexCommand.h"
+
+#include "gtest/gtest.h"
+
+using namespace lldb_private;
+using namespace lldb;
+
+namespace {
+class TestRegexCommand : public CommandObjectRegexCommand {
+public:
+  using CommandObjectRegexCommand::SubstituteVariables;
+};
+} // namespace
+
+TEST(RegexCommandTest, SubstituteVariables) {
+  const llvm::SmallVector substitutions = {"UNUSED", "foo",
+   "bar", "baz"};
+
+  EXPECT_EQ(TestRegexCommand::SubstituteVariables("%0", substitutions), "%0");
+  EXPECT_EQ(TestRegexCommand::SubstituteVariables("%1", substitutions), "foo");
+  EXPECT_EQ(TestRegexCommand::SubstituteVariables("%2", substitutions), "bar");
+  EXPECT_EQ(TestRegexCommand::SubstituteVariables("%3", substitutions), "baz");
+  EXPECT_EQ(TestRegexCommand::SubstituteVariables("%1%2%3", substitutions),
+"foobarbaz");
+  EXPECT_EQ(TestRegexCommand::SubstituteVariables("%1%2%3%4", substitutions),
+"foobarbaz%4");
+  EXPECT_EQ(TestRegexCommand::SubstituteVariables("#%1#%2#%3#", substitutions),
+"#foo#bar#baz#");
+  EXPECT_EQ(TestRegexCommand::SubstituteVariables("%11", substitutions), "%11");
+}
+
+TEST(RegexCommandTest, SubstituteVariablesNoRecursion) {
+  const llvm::SmallVector substitutions = {"UNUSED", "%2",
+   "%3", "%4"};
+
+  EXPECT_EQ(TestRegexCommand::SubstituteVariables("%0", substitutions), "%0");
+  EXPECT_EQ(TestRegexCommand::SubstituteVariables("%1", substitutions), "%2");
+  EXPECT_EQ(TestRegexCommand::SubstituteVariables("%2", substitutions), "%3");
+  EXPECT_EQ(TestRegexCommand::SubstituteVariables("%3", substitutions), "%4");
+  EXPECT_EQ(TestRegexCommand::SubstituteVariables("%1%2%3", substitutions),
+"%2%3%4");
+}
Index: lldb/unittests/Interpreter/CMakeLists.txt
===
--- lldb/unittests/Interpreter/CMakeLists.txt
+++ lldb/unittests/Interpreter/CMakeLists.txt
@@ -4,6 +4,7 @@
   TestOptionArgParser.cpp
   TestOptionValue.cpp
   TestOptionValueFileColonLine.cpp
+  TestRegexCommand.cpp
 
   LINK_LIBS
   lldbCore
Index: lldb/source/Commands/CommandObjectRegexCommand.h
===
--- lldb/source/Commands/CommandObjectRegexCommand.h
+++ lldb/source/Commands/CommandObjectRegexCommand.h
@@ -39,6 +39,15 @@
 protected:
   bool DoExecute(llvm::StringRef command, CommandReturnObject &result) override;
 
+  /// Substitute variables of the format %1 in the input string.
+  ///
+  /// The replacements vector is expected to be the result of a regex match
+  /// with the first element being the full match. That means that %1 will be
+  /// matched with replacements[1] and not replacements[0].
+  static std::string SubstituteVariables(
+  llvm::StringRef input,
+  const llvm::SmallVectorImpl &replacements);
+
   struct Entry {
 RegularExpression regex;
 std::string command;
Index: lldb/source/Commands/CommandObjectRegexCommand.cpp
===
--- lldb/source/Commands/CommandObjectRegexCommand.cpp
+++ lldb/source/Commands/CommandObjectRegexCommand.cpp
@@ -25,28 +25,38 @@
 // Destructor
 CommandObjectRegexCommand::~CommandObjectRegexCommand() = default;
 
+std::string CommandObjectRegexCommand::SubstituteVariables(
+llvm::StringRef input,
+const llvm::SmallVectorImpl &replacements) {
+  std::string buffer;
+  llvm::raw_string_ostream output(buffer);
+
+  llvm::SmallVector parts;
+  input.split(parts, '%');
+
+  output << parts[0];
+  for (llvm::StringRef part : drop_begin(parts)) {
+size_t idx = 0;
+if (part.consumeInteger(10, idx))
+  output << '%';
+else if (idx > 0 && idx < replacements.size())
+  output << replacements[idx];
+else
+  output << '%' << idx;
+output << part;
+  }
+
+  return output.str();
+

[Lldb-commits] [PATCH] D120100: [lldb] Expose eBroadcastBitProgress to the SWIG SBAPI

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere added a comment.

In D120100#3331656 , @labath wrote:

> I'm not sure how we ended up with the .i files in the first place, but maybe 
> a good solution to this problem would be to ditch those and generate bindings 
> from .h files directly.
>
> It may mean that we need to put `#ifndef SWIG` around some code, but I'd say 
> that beats maintaining two separate copies of the interface. (Also, the 
> ifdefs are a pretty good way to document the bits of the "public" API that we 
> do not wish to make available to scripts.)

I've considered that in the past, but with the docstrings and the inline python 
code for things like property definitions, I'm not sure it's worth it. I assume 
we could move the majority of those out of the actual header and do a textual 
include, but then you're still on the hook for keeping that file in sync.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120100

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

[Lldb-commits] [PATCH] D120100: [lldb/bindings] Expose the progress reporting machinery to the SWIG interface

[Med Ismail Bennani via Phabricator via lldb-commits]

mib updated this revision to Diff 410023.
mib retitled this revision from "[lldb] Expose eBroadcastBitProgress to the 
SWIG SBAPI" to "[lldb/bindings] Expose the progress reporting machinery to the 
SWIG interface".
mib edited the summary of this revision.
mib added a comment.

Instead of moving the enum to `lldb-enumeration`, define it in the SBDebugger 
SWIG interface file and add a test to exercise the API.


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

https://reviews.llvm.org/D120100

Files:
  lldb/bindings/interface/SBDebugger.i
  lldb/test/API/functionalities/progress_reporting/Makefile
  lldb/test/API/functionalities/progress_reporting/TestProgressReporting.py
  lldb/test/API/functionalities/progress_reporting/main.c

Index: lldb/test/API/functionalities/progress_reporting/main.c
===
--- /dev/null
+++ lldb/test/API/functionalities/progress_reporting/main.c
@@ -0,0 +1,11 @@
+int bar(int b) { return b * b; }
+
+int foo(int f) {
+  int b = bar(f); // break here
+  return b;
+}
+
+int main() {
+  int f = foo(42);
+  return f;
+}
Index: lldb/test/API/functionalities/progress_reporting/TestProgressReporting.py
===
--- /dev/null
+++ lldb/test/API/functionalities/progress_reporting/TestProgressReporting.py
@@ -0,0 +1,57 @@
+"""
+Test that we are able to broadcast and receive progress events from lldb
+"""
+import lldb
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test.decorators import *
+import lldbsuite.test.lldbutil as lldbutil
+import threading
+
+class TestProgressReporting(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+eBroadcastBitStopProgressThread = (1 << 0)
+
+def setUp(self):
+TestBase.setUp(self)
+self.progress_events = []
+
+def fetch_events(self, test_broadcaster):
+listener = lldb.SBListener("lldb.progress.listener")
+listener.StartListeningForEvents(test_broadcaster,
+ self.eBroadcastBitStopProgressThread)
+
+progress_broadcaster = self.dbg.GetBroadcaster()
+progress_broadcaster.AddListener(listener, lldb.SBDebugger.eBroadcastBitProgress)
+
+event = lldb.SBEvent()
+
+done = False
+while not done:
+if listener.WaitForEvent(1, event):
+event_mask = event.GetType();
+if event.BroadcasterMatchesRef(test_broadcaster):
+if event_mask & self.eBroadcastBitStopProgressThread:
+done = True;
+elif event.BroadcasterMatchesRef(progress_broadcaster):
+message = lldb.SBDebugger().GetProgressFromEvent(event, 0, 0, 0, False);
+if message:
+self.progress_events.append((message, event))
+
+@skipUnlessDarwin
+def test_dwarf_symbol_loading_progress_report(self):
+"""Test that we are able to fetch dwarf symbol loading progress events"""
+self.build()
+
+test_broadcaster = lldb.SBBroadcaster('lldb.broadcaster.test')
+listener_thread = threading.Thread(target=self.fetch_events,
+   args=[test_broadcaster])
+listener_thread.start()
+
+lldbutil.run_to_source_breakpoint(self, 'break here', lldb.SBFileSpec('main.c'))
+
+test_broadcaster.BroadcastEventByType(self.eBroadcastBitStopProgressThread)
+listener_thread.join()
+
+self.assertTrue(len(self.progress_events) > 0)
Index: lldb/test/API/functionalities/progress_reporting/Makefile
===
--- /dev/null
+++ lldb/test/API/functionalities/progress_reporting/Makefile
@@ -0,0 +1,3 @@
+C_SOURCES := main.c
+
+include Makefile.rules
Index: lldb/bindings/interface/SBDebugger.i
===
--- lldb/bindings/interface/SBDebugger.i
+++ lldb/bindings/interface/SBDebugger.i
@@ -117,6 +117,22 @@
 class SBDebugger
 {
 public:
+enum
+{
+eBroadcastBitProgress = (1 << 0)
+};
+
+
+%apply uint64_t& INOUT { uint64_t& progress_id };
+%apply uint64_t& INOUT { uint64_t& completed };
+%apply uint64_t& INOUT { uint64_t& total };
+%apply bool& INOUT { bool& is_debugger_specific };
+static const char *GetProgressFromEvent(const lldb::SBEvent &event,
+uint64_t &progress_id,
+uint64_t &completed, uint64_t &total,
+bool &is_debugger_specific);
+
+SBBroadcaster GetBroadcaster();
 
 static void
 Initialize();
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D120100: [lldb/bindings] Expose the progress reporting machinery to the SWIG interface

[Jonas Devlieghere via Phabricator via lldb-commits]

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

LGTM


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

https://reviews.llvm.org/D120100

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

[Lldb-commits] [lldb] e3b9bb5 - [lldb/bindings] Expose the progress reporting machinery to the SWIG interface

[Med Ismail Bennani via lldb-commits]

Author: Med Ismail Bennani
Date: 2022-02-18T14:16:09-08:00
New Revision: e3b9bb5a1847483338190c82ee63a962e82696fd

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

LOG: [lldb/bindings] Expose the progress reporting machinery to the SWIG 
interface

This patch defines the SBDebugger::eBroadcastBitProgress enum in the SWIG
interface and exposes the SBDebugger::{GetProgressFromEvent,GetBroadcaster}
methods as well.

This allows to exercise the API from the script interpreter using python.

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

Signed-off-by: Med Ismail Bennani 

Added: 
lldb/test/API/functionalities/progress_reporting/Makefile
lldb/test/API/functionalities/progress_reporting/TestProgressReporting.py
lldb/test/API/functionalities/progress_reporting/main.c

Modified: 
lldb/bindings/interface/SBDebugger.i

Removed: 




diff  --git a/lldb/bindings/interface/SBDebugger.i 
b/lldb/bindings/interface/SBDebugger.i
index f21e60d62873..3790857b8ab6 100644
--- a/lldb/bindings/interface/SBDebugger.i
+++ b/lldb/bindings/interface/SBDebugger.i
@@ -117,6 +117,22 @@ or the equivalent arguments for 
:py:class:`SBTarget.AttachToProcessWithID` .") S
 class SBDebugger
 {
 public:
+enum
+{
+eBroadcastBitProgress = (1 << 0)
+};
+
+
+%apply uint64_t& INOUT { uint64_t& progress_id };
+%apply uint64_t& INOUT { uint64_t& completed };
+%apply uint64_t& INOUT { uint64_t& total };
+%apply bool& INOUT { bool& is_debugger_specific };
+static const char *GetProgressFromEvent(const lldb::SBEvent &event,
+uint64_t &progress_id,
+uint64_t &completed, uint64_t &total,
+bool &is_debugger_specific);
+
+SBBroadcaster GetBroadcaster();
 
 static void
 Initialize();

diff  --git a/lldb/test/API/functionalities/progress_reporting/Makefile 
b/lldb/test/API/functionalities/progress_reporting/Makefile
new file mode 100644
index ..10495940055b
--- /dev/null
+++ b/lldb/test/API/functionalities/progress_reporting/Makefile
@@ -0,0 +1,3 @@
+C_SOURCES := main.c
+
+include Makefile.rules

diff  --git 
a/lldb/test/API/functionalities/progress_reporting/TestProgressReporting.py 
b/lldb/test/API/functionalities/progress_reporting/TestProgressReporting.py
new file mode 100644
index ..b9d9953539c1
--- /dev/null
+++ b/lldb/test/API/functionalities/progress_reporting/TestProgressReporting.py
@@ -0,0 +1,57 @@
+"""
+Test that we are able to broadcast and receive progress events from lldb
+"""
+import lldb
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test.decorators import *
+import lldbsuite.test.lldbutil as lldbutil
+import threading
+
+class TestProgressReporting(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+eBroadcastBitStopProgressThread = (1 << 0)
+
+def setUp(self):
+TestBase.setUp(self)
+self.progress_events = []
+
+def fetch_events(self, test_broadcaster):
+listener = lldb.SBListener("lldb.progress.listener")
+listener.StartListeningForEvents(test_broadcaster,
+ self.eBroadcastBitStopProgressThread)
+
+progress_broadcaster = self.dbg.GetBroadcaster()
+progress_broadcaster.AddListener(listener, 
lldb.SBDebugger.eBroadcastBitProgress)
+
+event = lldb.SBEvent()
+
+done = False
+while not done:
+if listener.WaitForEvent(1, event):
+event_mask = event.GetType();
+if event.BroadcasterMatchesRef(test_broadcaster):
+if event_mask & self.eBroadcastBitStopProgressThread:
+done = True;
+elif event.BroadcasterMatchesRef(progress_broadcaster):
+message = lldb.SBDebugger().GetProgressFromEvent(event, 0, 
0, 0, False);
+if message:
+self.progress_events.append((message, event))
+
+@skipUnlessDarwin
+def test_dwarf_symbol_loading_progress_report(self):
+"""Test that we are able to fetch dwarf symbol loading progress 
events"""
+self.build()
+
+test_broadcaster = lldb.SBBroadcaster('lldb.broadcaster.test')
+listener_thread = threading.Thread(target=self.fetch_events,
+   args=[test_broadcaster])
+listener_thread.start()
+
+lldbutil.run_to_source_breakpoint(self, 'break here', 
lldb.SBFileSpec('main.c'))
+
+
test_broadcaster.BroadcastEventByType(self.eBroadcastBitStopProgressThread)
+listener_thread.join()
+
+self.assertTrue(len(self.progress_events) > 0)

diff  --git a/lldb/test/API/functionalities/pr

[Lldb-commits] [PATCH] D120100: [lldb/bindings] Expose the progress reporting machinery to the SWIG interface

[Med Ismail Bennani via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGe3b9bb5a1847: [lldb/bindings] Expose the progress reporting 
machinery to the SWIG interface (authored by mib).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120100

Files:
  lldb/bindings/interface/SBDebugger.i
  lldb/test/API/functionalities/progress_reporting/Makefile
  lldb/test/API/functionalities/progress_reporting/TestProgressReporting.py
  lldb/test/API/functionalities/progress_reporting/main.c

Index: lldb/test/API/functionalities/progress_reporting/main.c
===
--- /dev/null
+++ lldb/test/API/functionalities/progress_reporting/main.c
@@ -0,0 +1,11 @@
+int bar(int b) { return b * b; }
+
+int foo(int f) {
+  int b = bar(f); // break here
+  return b;
+}
+
+int main() {
+  int f = foo(42);
+  return f;
+}
Index: lldb/test/API/functionalities/progress_reporting/TestProgressReporting.py
===
--- /dev/null
+++ lldb/test/API/functionalities/progress_reporting/TestProgressReporting.py
@@ -0,0 +1,57 @@
+"""
+Test that we are able to broadcast and receive progress events from lldb
+"""
+import lldb
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test.decorators import *
+import lldbsuite.test.lldbutil as lldbutil
+import threading
+
+class TestProgressReporting(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+eBroadcastBitStopProgressThread = (1 << 0)
+
+def setUp(self):
+TestBase.setUp(self)
+self.progress_events = []
+
+def fetch_events(self, test_broadcaster):
+listener = lldb.SBListener("lldb.progress.listener")
+listener.StartListeningForEvents(test_broadcaster,
+ self.eBroadcastBitStopProgressThread)
+
+progress_broadcaster = self.dbg.GetBroadcaster()
+progress_broadcaster.AddListener(listener, lldb.SBDebugger.eBroadcastBitProgress)
+
+event = lldb.SBEvent()
+
+done = False
+while not done:
+if listener.WaitForEvent(1, event):
+event_mask = event.GetType();
+if event.BroadcasterMatchesRef(test_broadcaster):
+if event_mask & self.eBroadcastBitStopProgressThread:
+done = True;
+elif event.BroadcasterMatchesRef(progress_broadcaster):
+message = lldb.SBDebugger().GetProgressFromEvent(event, 0, 0, 0, False);
+if message:
+self.progress_events.append((message, event))
+
+@skipUnlessDarwin
+def test_dwarf_symbol_loading_progress_report(self):
+"""Test that we are able to fetch dwarf symbol loading progress events"""
+self.build()
+
+test_broadcaster = lldb.SBBroadcaster('lldb.broadcaster.test')
+listener_thread = threading.Thread(target=self.fetch_events,
+   args=[test_broadcaster])
+listener_thread.start()
+
+lldbutil.run_to_source_breakpoint(self, 'break here', lldb.SBFileSpec('main.c'))
+
+test_broadcaster.BroadcastEventByType(self.eBroadcastBitStopProgressThread)
+listener_thread.join()
+
+self.assertTrue(len(self.progress_events) > 0)
Index: lldb/test/API/functionalities/progress_reporting/Makefile
===
--- /dev/null
+++ lldb/test/API/functionalities/progress_reporting/Makefile
@@ -0,0 +1,3 @@
+C_SOURCES := main.c
+
+include Makefile.rules
Index: lldb/bindings/interface/SBDebugger.i
===
--- lldb/bindings/interface/SBDebugger.i
+++ lldb/bindings/interface/SBDebugger.i
@@ -117,6 +117,22 @@
 class SBDebugger
 {
 public:
+enum
+{
+eBroadcastBitProgress = (1 << 0)
+};
+
+
+%apply uint64_t& INOUT { uint64_t& progress_id };
+%apply uint64_t& INOUT { uint64_t& completed };
+%apply uint64_t& INOUT { uint64_t& total };
+%apply bool& INOUT { bool& is_debugger_specific };
+static const char *GetProgressFromEvent(const lldb::SBEvent &event,
+uint64_t &progress_id,
+uint64_t &completed, uint64_t &total,
+bool &is_debugger_specific);
+
+SBBroadcaster GetBroadcaster();
 
 static void
 Initialize();
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D119963: [LLDB] Dump valid ranges of variables

[Zequan Wu via Phabricator via lldb-commits]

zequanwu added inline comments.



Comment at: lldb/test/Shell/SymbolFile/DWARF/x86/debug_loc.s:28-29
 # CHECK: Variable{{.*}}, name = "x0", {{.*}}, scope = parameter, location =
 # CHECK-NEXT:  [0x, 0x0001): DW_OP_reg5 RDI
 # CHECK-NEXT:  [0x0001, 0x0006): DW_OP_reg0 RAX
 # CHECK: Variable{{.*}}, name = "x1", {{.*}}, scope = parameter

labath wrote:
> zequanwu wrote:
> > labath wrote:
> > > zequanwu wrote:
> > > > `image dump symfile` already prints valid ranges for variables along 
> > > > with where the value is at each range.
> > > Are you sure it does?
> > > 
> > > I was under the impression that there are two distinct range concepts 
> > > being combined here. One is the range list member of the Variable object 
> > > (as given by `GetScopeRange` -- that's the one you're printing now), and 
> > > the other is the list of ranges hidden in the DWARFExpression object, 
> > > which come from the debug_loc(lists) section (that's the one we've been 
> > > printing so far). And that the root cause of the confusion is the very 
> > > existence of these two concepts.
> > > 
> > > If I got it wrong, then do let me know, cause it would make things a lot 
> > > simpler if there is only one validity concept to think about.
> > Dwarf plugin is supposed to construct the `m_scope_range` member of an 
> > Variable, but it doesn't. `scope_ranges` is empty at 
> > https://github.com/llvm/llvm-project/blob/main/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp#L3468.
> >  
> > `image dump symfile` dumps the dwarf location list in `m_location` in 
> > `Variable`. 
> > The dwarf location list has more information than `m_scope_range` as it 
> > contains info about where the value is during each range. (e.g. which 
> > register the variable lives in). 
> > 
> > So, I think we need to use similar logic to construct `m_scope_range` when 
> > creating `Variable` in dwarf plugin like this 
> > https://github.com/llvm/llvm-project/blob/main/lldb/source/Expression/DWARFExpression.cpp#L145.
> Ok, I see where you're coming from. You're essentially saying that the fact 
> that the dwarf plugin does not fill this out is a bug.
> 
> I don't think that's the case. My interpretation was (and [[ 
> https://github.com/llvm/llvm-project/blob/main/lldb/source/Symbol/Variable.cpp#L313
>  | this comment]] confirms it) that an empty range here means the entire 
> enclosing block. (Also, DWARF was for a long time the only symbol file 
> plugin, so what it does is kinda "correct by definition").
> 
> I don't think we want to change that interpretation, as forcing a copy of the 
> range in the location list would be wasteful (it would be different if this 
> was an interface that one could query, and that the dwarf plugin could 
> implement by consulting the location list). However, since the dwarf class 
> does not actually make use of this functionality (it was [[ 
> https://reviews.llvm.org/D17449 | added ]] to support DW_AT_start_scope, then 
> broken at some point, and eventually [[ https://reviews.llvm.org/D62302 | 
> removed ]]), we do have some freedom in defining the interactions of the two 
> fields (if you still want to pursue this, that is).
> 
> So how about this: if the user passes the extra flag, then we print both the 
> range field (if it exists), and the *full* location list (in that order, 
> ideally). That way the output will be either `range = [a, b), [c, d), 
> location = DW_OP_reg47` or `location = [a,b) -> DW_OP_reg4, [c,d) -> 
> DW_OP_reg7`. If the dwarf plugin starts using the range field again then the 
> output will contain both fields, which will be slightly confusing, but at 
> least not misleading (and we can also change the format then).
Oh, I think I misunderstood `m_scope_range`. It's the range list where the 
variable is valid regardless whether its value is accessible or not (valid 
range). As for `m_location` in `Variable`, it's describing the ranges where the 
value is (value range). They are not the same. 

So, currently how NativePDB creates local Variable's range is not correct. That 
only works when it's not optimized build such that the valid range is the same 
as the value range. It still need to create dwarf location lists to correctly 
represent the value range, but as mentioned [[ 
https://reviews.llvm.org/D119508#3319113 | here ]], we need to choose a generic 
"variable location provider" interface for that.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119963

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