[Lldb-commits] [PATCH] D133628: [lldb/test][TestingSupport] Add a helper class to send all LLDB logs to stderr in unit tests.

2022-09-09 Thread Jordan Rupprecht via Phabricator via lldb-commits
rupprecht created this revision.
Herald added a subscriber: mgorny.
Herald added a project: All.
rupprecht requested review of this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

This helper class can be useful to see what `LLDB_LOG` messages are happening 
when debugging the LLDB C++ unit tests. It isn't pretty, but on the other hand, 
it's meant for temporary debugging and not something one would want to check in 
anyway, so maybe that's OK.

This can be used like so:

  TEST(FooTest, HasABug) {
Func1(); // LLDB_LOG statements this makes won't go anywhere
{
  auto logger = TestStderrLogger::Scoped(LLDBLog::AST | 
LLDBLog::Breakpoints);
  Func2(); // Now they'll go to stderr.
}
Func3(); // Now they go nowhere again.
  }

It can be created in a way that mirrors `GetLog()` calls, i.e. deducing from 
the enum, or by directly using the strings that are registered.

Right now this only works for the LLDBLog enum, but it should be trivial to add 
more. I don't know of a good generic way to handle arbitrary enums.

I was able to use this to debug a flaky unit test that was failing ~1/100 
times, so my approach was to enable logs and compare good vs bad log methods. I 
didn't find an easier way than this helper class.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D133628

Files:
  lldb/unittests/TestingSupport/CMakeLists.txt
  lldb/unittests/TestingSupport/TestStderrLogger.cpp
  lldb/unittests/TestingSupport/TestStderrLogger.h
  lldb/unittests/TestingSupport/tests/CMakeLists.txt
  lldb/unittests/TestingSupport/tests/TestStderrLoggerTest.cpp

Index: lldb/unittests/TestingSupport/tests/TestStderrLoggerTest.cpp
===
--- /dev/null
+++ lldb/unittests/TestingSupport/tests/TestStderrLoggerTest.cpp
@@ -0,0 +1,59 @@
+//===-- TestStderrLoggerTest.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 "TestingSupport/TestStderrLogger.h"
+#include "gtest/gtest.h"
+
+using namespace lldb_private;
+using namespace lldb;
+
+TEST(TestStderrLoggerTest, Strings) {
+  LLDB_LOG(GetLog(LLDBLog::AST), "This won't be logged");
+  {
+auto logger = TestStderrLogger::Scoped("lldb", {"ast"});
+LLDB_LOG(GetLog(LLDBLog::AST), "This will be logged");
+  }
+  LLDB_LOG(GetLog(LLDBLog::AST), "This won't be logged either");
+}
+
+TEST(TestStderrLoggerTest, Special) {
+  EXPECT_EQ(1, 2);
+  {
+auto logger = TestStderrLogger::Scoped("lldb", {"all"});
+LLDB_LOG(GetLog(LLDBLog::Breakpoints), "break is part of all");
+  }
+  {
+auto logger = TestStderrLogger::Scoped("lldb", {"default"});
+LLDB_LOG(GetLog(LLDBLog::AST), "ast is not part of default");
+LLDB_LOG(GetLog(LLDBLog::Breakpoints), "break is part of default");
+  }
+}
+
+TEST(TestStderrLoggerTest, Enums) {
+  auto logger = TestStderrLogger::Scoped(LLDBLog::AST | LLDBLog::Breakpoints);
+  LLDB_LOG(GetLog(LLDBLog::AST), "AST lines are logged");
+  LLDB_LOG(GetLog(LLDBLog::Breakpoints), "Breakpoint lines are logged");
+  LLDB_LOG(GetLog(LLDBLog::Unwind), "Unwind lines are not logged");
+}
+
+TEST(TestStderrLoggerTest, SwitchSource) {
+  std::string log_dest;
+  llvm::raw_string_ostream ostream_dest(log_dest);
+
+  {
+auto logger = TestStderrLogger::Scoped("lldb", {"ast"}, /*log_options=*/0,
+   ostream_dest);
+LLDB_LOG(GetLog(LLDBLog::AST), "This goes to a stream");
+  }
+
+  {
+auto logger = TestStderrLogger::Scoped("lldb", {"ast"});
+LLDB_LOG(GetLog(LLDBLog::AST), "This goes to stderr");
+  }
+  EXPECT_EQ(log_dest, "This goes to a stream\n");
+}
Index: lldb/unittests/TestingSupport/tests/CMakeLists.txt
===
--- /dev/null
+++ lldb/unittests/TestingSupport/tests/CMakeLists.txt
@@ -0,0 +1,9 @@
+# Note: "TestingSupportTests" already exists in LLVM. Prefix with "LLDB" to
+# make it unique.
+add_lldb_unittest(LLDBTestingSupportTests
+  TestStderrLoggerTest.cpp
+
+  LINK_LIBS
+lldbUtilityHelpers
+  )
+  
\ No newline at end of file
Index: lldb/unittests/TestingSupport/TestStderrLogger.h
===
--- /dev/null
+++ lldb/unittests/TestingSupport/TestStderrLogger.h
@@ -0,0 +1,89 @@
+//===- TestStderrLogger.h ---*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef 

[Lldb-commits] [PATCH] D133519: Document some of the clang-specific DWARF extensions supported by LLDB

2022-09-09 Thread Adrian Prantl via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG1f47352ce7e8: Document some of the clang-specific DWARF 
extensions supported by LLDB (authored by aprantl).
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

Changed prior to commit:
  https://reviews.llvm.org/D133519?vs=458839=459241#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133519

Files:
  lldb/docs/index.rst
  lldb/docs/use/extensions.rst

Index: lldb/docs/use/extensions.rst
===
--- /dev/null
+++ lldb/docs/use/extensions.rst
@@ -0,0 +1,135 @@
+DWARF Extensions supported by LLDB
+==
+
+LLDB supports some DWARF extensions produced by Clang.
+
+Clang ``-gmodules`` debug info
+--
+
+On Darwin platforms, including Apple macOS and iOS, Clang can emit
+DWARF debug info for types found in `Clang
+modules`_ more efficiently.
+
+From an on-disk storage perspective, Clang modules are precompiled
+header files that contain serialized Clang ASTs of all the
+declarations found in a Clang module. In traditional DWARF debug info,
+two object files that were built from sources that imported the same
+header file will both contain DWARF debug type info for types in that
+header file. This can lead to a lot of redundant `debug
+info`_.
+
+When Clang compiles a Clang module or precompiled header with the
+``-gmodules`` option, the precompiled header (``.pch``) or module
+(``.pcm``) files become object file containers (on Darwin: Mach-O)
+that hold a ``__clang_ast`` section with the serialized Clang AST and
+various DWARF sections containing debug info for the type declarations
+found in the header or module.
+
+This allows Clang to omit these type definitions from the object
+(``.o``) files and replace them with forward declarations to save
+space. Type declarations in a Clang module are nested inside one
+``DW_TAG_module``, or -- in the case of submodules -- multiple levels
+of ``DW_TAG_module``. If a DWARF DIE needs to reference a type DIE
+from another module, Clang emits a forward declaration of the
+referenced DIE into a ``DW_TAG_module`` inside the same compile unit.
+
+When a consumer sees a forward declaration that is nested inside a
+``DW_TAG_module``, it knows that it can find the full type declaration
+in an external ``.pcm`` or ``.pch`` file. To facilitate locating these
+external dependencies, Clang emits skeleton CUs into each object file
+that references external modules. Clang uses the same mechanism that
+is used to locate external ``.dwo`` files on ELF-based platforms. The
+``DW_AT_GNU_dwo_name`` contains the absolute path to the ``.pcm``
+file, and the ``DW_AT_GNU_dwo_id`` is a hash of the contents that is
+repeated in the ``DW_TAG_compile_unit`` of the ``.pcm`` file.
+
+For example:
+
+M.h
+
+::
+
+   struct A {
+ int x;
+   };
+
+
+M.pcm
+
+::
+   DW_TAG_compile_unit
+ DW_AT_GNU_dwo_id  (0xabcdef)
+ DW_TAG_module
+   DW_AT_name "M"
+   DW_TAG_structure
+ DW_AT_name "A"
+ DW_TAG_member
+   DW_AT_name "x"
+   
+A.c
+   
+::
+   A a;
+
+A.o
+
+::
+   DW_TAG_compile_unit
+ DW_TAG_module
+   DW_AT_name "M"
+   DW_TAG_structure
+ DW_AT_name "A"
+ DW_AT_declaration (true)
+ DW_TAG_variable
+   DW_AT_name "a"
+   DW_AT_type (local ref to fwd decl "A")
+
+   DW_TAG_compile_unit
+ DW_AT_GNU_dwo_id  (0xabcdef)
+ DW_AT_GNU_dwo_name("M.pcm")
+   
+The debug info inside a ``.pcm`` file may recursively reference
+further external types that are defined in other ``.pcm`` files. Clang
+generates external references (and debug info inside the modules) for
+the following types:
+
+C:
+
+- ``struct``
+- ``union``
+- ``enum``
+- ``typedef``
+
+Objective-C:
+
+- all the C types listed above
+- ``@interface``
+
+C++:
+
+- all the C types listed above
+- ``namespace``
+- any explicit ``extern template`` specializations
+
+LLDB supports this DWARF extension only when debugging from ``.o``
+files. The ``dsymutil`` debug info linker also understands this format
+and will resolve all module type references to point straight to the
+underlying defining declaration. Because of this a ``.dSYM`` bundle
+will never contain any ``-gmodules``-style references.
+
+Apple SDK information
+-
+
+Clang and the Swift compiler emit information about the Xcode SDK that
+was used to build a translation unit into the ``DW_TAG_compile_unit``.
+The ``DW_AT_LLVM_sysroot`` attribute points to the SDK root
+(equivalent to Clang's ``-isysroot`` option). The ``DW_AT_APPLE_sdk``
+attribute contains the name of the SDK, for example ``MacOSX.sdk``.
+
+Objective-C runtime
+---
+
+Clang emits the Objective-C runtime 

[Lldb-commits] [lldb] 1f47352 - Document some of the clang-specific DWARF extensions supported by LLDB

2022-09-09 Thread Adrian Prantl via lldb-commits

Author: Adrian Prantl
Date: 2022-09-09T17:49:11-07:00
New Revision: 1f47352ce7e84b2d2692aecdab19932f7abff589

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

LOG: Document some of the clang-specific DWARF extensions supported by LLDB

This patch adds a new page to the LLDB documentation that documents,
among other things the -gmodules debug info format.

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

Added: 
lldb/docs/use/extensions.rst

Modified: 
lldb/docs/index.rst

Removed: 




diff  --git a/lldb/docs/index.rst b/lldb/docs/index.rst
index 0d873189759d7..02d446573900a 100644
--- a/lldb/docs/index.rst
+++ b/lldb/docs/index.rst
@@ -133,6 +133,7 @@ interesting areas to contribute to lldb.
use/variable
use/symbolication
use/symbols
+   use/extensions
use/python
use/python-reference
use/remote

diff  --git a/lldb/docs/use/extensions.rst b/lldb/docs/use/extensions.rst
new file mode 100644
index 0..4a3f1ac177abc
--- /dev/null
+++ b/lldb/docs/use/extensions.rst
@@ -0,0 +1,135 @@
+DWARF Extensions supported by LLDB
+==
+
+LLDB supports some DWARF extensions produced by Clang.
+
+Clang ``-gmodules`` debug info
+--
+
+On Darwin platforms, including Apple macOS and iOS, Clang can emit
+DWARF debug info for types found in `Clang
+modules`_ more efficiently.
+
+From an on-disk storage perspective, Clang modules are precompiled
+header files that contain serialized Clang ASTs of all the
+declarations found in a Clang module. In traditional DWARF debug info,
+two object files that were built from sources that imported the same
+header file will both contain DWARF debug type info for types in that
+header file. This can lead to a lot of redundant `debug
+info`_.
+
+When Clang compiles a Clang module or precompiled header with the
+``-gmodules`` option, the precompiled header (``.pch``) or module
+(``.pcm``) files become object file containers (on Darwin: Mach-O)
+that hold a ``__clang_ast`` section with the serialized Clang AST and
+various DWARF sections containing debug info for the type declarations
+found in the header or module.
+
+This allows Clang to omit these type definitions from the object
+(``.o``) files and replace them with forward declarations to save
+space. Type declarations in a Clang module are nested inside one
+``DW_TAG_module``, or -- in the case of submodules -- multiple levels
+of ``DW_TAG_module``. If a DWARF DIE needs to reference a type DIE
+from another module, Clang emits a forward declaration of the
+referenced DIE into a ``DW_TAG_module`` inside the same compile unit.
+
+When a consumer sees a forward declaration that is nested inside a
+``DW_TAG_module``, it knows that it can find the full type declaration
+in an external ``.pcm`` or ``.pch`` file. To facilitate locating these
+external dependencies, Clang emits skeleton CUs into each object file
+that references external modules. Clang uses the same mechanism that
+is used to locate external ``.dwo`` files on ELF-based platforms. The
+``DW_AT_GNU_dwo_name`` contains the absolute path to the ``.pcm``
+file, and the ``DW_AT_GNU_dwo_id`` is a hash of the contents that is
+repeated in the ``DW_TAG_compile_unit`` of the ``.pcm`` file.
+
+For example:
+
+M.h
+
+::
+
+   struct A {
+ int x;
+   };
+
+
+M.pcm
+
+::
+   DW_TAG_compile_unit
+ DW_AT_GNU_dwo_id  (0xabcdef)
+ DW_TAG_module
+   DW_AT_name "M"
+   DW_TAG_structure
+ DW_AT_name "A"
+ DW_TAG_member
+   DW_AT_name "x"
+   
+A.c
+   
+::
+   A a;
+
+A.o
+
+::
+   DW_TAG_compile_unit
+ DW_TAG_module
+   DW_AT_name "M"
+   DW_TAG_structure
+ DW_AT_name "A"
+ DW_AT_declaration (true)
+ DW_TAG_variable
+   DW_AT_name "a"
+   DW_AT_type (local ref to fwd decl "A")
+
+   DW_TAG_compile_unit
+ DW_AT_GNU_dwo_id  (0xabcdef)
+ DW_AT_GNU_dwo_name("M.pcm")
+   
+The debug info inside a ``.pcm`` file may recursively reference
+further external types that are defined in other ``.pcm`` files. Clang
+generates external references (and debug info inside the modules) for
+the following types:
+
+C:
+
+- ``struct``
+- ``union``
+- ``enum``
+- ``typedef``
+
+Objective-C:
+
+- all the C types listed above
+- ``@interface``
+
+C++:
+
+- all the C types listed above
+- ``namespace``
+- any explicit ``extern template`` specializations
+
+LLDB supports this DWARF extension only when debugging from ``.o``
+files. The ``dsymutil`` debug info linker also understands this format
+and will resolve all module type references to point straight to the
+underlying defining declaration. Because of this a 

[Lldb-commits] [PATCH] D133626: [LLDB][NativePDB] Add local variables with no location info.

2022-09-09 Thread Zequan Wu via Phabricator via lldb-commits
zequanwu created this revision.
zequanwu added reviewers: labath, rnk.
Herald added a project: All.
zequanwu requested review of this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

If we don't add local variables with no location info, when trying to print it,
lldb won't find it in the its parent DeclContext, which makes lldb to spend more
time to search all the way up in DeclContext hierarchy until found same name
variable or failed. Dwarf plugin also add local vars even if they don't have
location info.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D133626

Files:
  lldb/source/Plugins/SymbolFile/NativePDB/PdbUtil.cpp
  lldb/source/Plugins/SymbolFile/NativePDB/PdbUtil.h
  lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
  lldb/test/Shell/SymbolFile/NativePDB/inline_sites.test

Index: lldb/test/Shell/SymbolFile/NativePDB/inline_sites.test
===
--- lldb/test/Shell/SymbolFile/NativePDB/inline_sites.test
+++ lldb/test/Shell/SymbolFile/NativePDB/inline_sites.test
@@ -71,6 +71,7 @@
 # CHECK: Blocks: id = {{.*}}, range = [0x140001000-0x140001046)
 # CHECK-NEXT:id = {{.*}}, ranges = [0x140001004-0x140001039)[0x14000103f-0x140001046), name = "Namespace1::foo", decl = a.h:4
 # CHECK:   LineEntry: [0x000140001004-0x00014000100c): /tmp/a.h:5
+# CHECK-NEXT:  Variable: id = {{.*}}, name = "x", type = "int", valid ranges = , location = , decl =
 # CHECK-NEXT:  Variable: id = {{.*}}, name = "foo_local", type = "int", valid ranges = , location = [0x000140001004, 0x000140001039) -> DW_OP_breg7 RSP+44
 # CHECK-NEXT:  Variable: id = {{.*}}, name = "argc", type = "int", valid ranges = , location = [0x000140001000, 0x00014000102d) -> DW_OP_reg26 XMM9
 # CHECK-NEXT:  Variable: id = {{.*}}, name = "argv", type = "char **", valid ranges = , location = [0x000140001000, 0x000140001045) -> DW_OP_reg3 RBX
@@ -83,6 +84,7 @@
 # CHECK: Blocks: id = {{.*}}, range = [0x140001000-0x140001046)
 # CHECK-NEXT:id = {{.*}}, ranges = [0x140001004-0x140001039)[0x14000103f-0x140001046), name = "Namespace1::foo", decl = a.h:4
 # CHECK:   LineEntry: [0x000140001010-0x000140001018): /tmp/a.h:7
+# CHECK-NEXT:  Variable: id = {{.*}}, name = "x", type = "int", valid ranges = , location = , decl =
 # CHECK-NEXT:  Variable: id = {{.*}}, name = "foo_local", type = "int", valid ranges = , location = [0x000140001004, 0x000140001039) -> DW_OP_breg7 RSP+44
 # CHECK-NEXT:  Variable: id = {{.*}}, name = "argc", type = "int", valid ranges = , location = [0x000140001000, 0x00014000102d) -> DW_OP_reg26 XMM9
 # CHECK-NEXT:  Variable: id = {{.*}}, name = "argv", type = "char **", valid ranges = , location = [0x000140001000, 0x000140001045) -> DW_OP_reg3 RBX
@@ -99,6 +101,7 @@
 # CHECK:   LineEntry: [0x00014000101c-0x000140001022): /tmp/b.h:5
 # CHECK-NEXT:  Variable: id = {{.*}}, name = "x", type = "int", valid ranges = , location = [0x00014000101c, 0x00014000101e) -> DW_OP_reg24 XMM7
 # CHECK-NEXT:  Variable: id = {{.*}}, name = "bar_local", type = "int", valid ranges = , location = [0x00014000101c, 0x000140001039) -> DW_OP_breg7 RSP+52
+# CHECK-NEXT:  Variable: id = {{.*}}, name = "x", type = "int", valid ranges = , location = , decl =
 # CHECK-NEXT:  Variable: id = {{.*}}, name = "foo_local", type = "int", valid ranges = , location = [0x000140001004, 0x000140001039) -> DW_OP_breg7 RSP+44
 # CHECK-NEXT:  Variable: id = {{.*}}, name = "argc", type = "int", valid ranges = , location = [0x000140001000, 0x00014000102d) -> DW_OP_reg26 XMM9
 # CHECK-NEXT:  Variable: id = {{.*}}, name = "argv", type = "char **", valid ranges = , location = [0x000140001000, 0x000140001045) -> DW_OP_reg3 RBX
@@ -118,6 +121,7 @@
 # CHECK-NEXT:  Variable: id = {{.*}}, name = "x", type = "int", valid ranges = , location = [0x00014000102a, 0x000140001039) -> DW_OP_reg24 XMM7
 # CHECK-NEXT:  Variable: id = {{.*}}, name = "func_local", type = "int", valid ranges = , location = [0x00014000102a, 0x000140001039) -> DW_OP_breg7 RSP+48
 # CHECK-NEXT:  Variable: id = {{.*}}, name = "bar_local", type = "int", valid ranges = , location = [0x00014000101c, 0x000140001039) -> DW_OP_breg7 RSP+52
+# CHECK-NEXT:  Variable: id = {{.*}}, name = "x", type = "int", valid ranges = , location = , decl =
 # CHECK-NEXT:  Variable: id = {{.*}}, name = "foo_local", type = "int", valid ranges = , location = [0x000140001004, 0x000140001039) -> DW_OP_breg7 RSP+44
 # CHECK-NEXT:  Variable: id = {{.*}}, name = "argc", type = "int", valid ranges = , location = [0x000140001000, 0x00014000102d) -> DW_OP_reg26 XMM9
 # CHECK-NEXT:  Variable: id = {{.*}}, name = "argv", type = "char **", valid ranges = , location = [0x000140001000, 0x000140001045) -> DW_OP_reg3 RBX
@@ -138,6 +142,7 @@
 # 

[Lldb-commits] [PATCH] D133534: Complete support of loading a darwin kernel over a live gdb-remote connection given the address of a mach-o fileset

2022-09-09 Thread Jason Molenda via Phabricator via lldb-commits
jasonmolenda added inline comments.



Comment at: lldb/source/Plugins/Platform/MacOSX/CMakeLists.txt:47
 lldbUtility
+lldbPluginDynamicLoaderDarwinKernel
+lldbPluginObjectContainerMachOFileset

jasonmolenda wrote:
> thakis wrote:
> > This causes a dependency cycle:
> > 
> >   //lldb/source/Plugins/Platform/MacOSX:MacOSX ->
> >   //lldb/source/Plugins/DynamicLoader/Darwin-Kernel:Darwin-Kernel ->
> >   //lldb/source/Plugins/Platform/MacOSX:MacOSX
> Ach, naturally.  DynamicLoaderDarwinKernel has to create a 
> PlatformDarwinKernel to set in the Target when it is initializing itself.  :/ 
>  Maybe I'll just add DynamicLoaderDarwinKernel to the unit tests that have 
> PlatformMacOSX in them.
I removed the dependency in DynamicLoaderDarwinKernel, a very specialized 
plugin, and left the dependency in PlatformMacOSX which includes all of the 
darwin platforms and is a common one to import.  I believe any target that is 
linking against DynamicLoaderDarwinKernel will also have a dependency on 
PlatformMacOSX already.  I landed this as 
30578c08568bc8de79dea72e41f49899ba10ea55 to make sure this causes no problems, 
we can fix it better if someone has a suggestion.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133534

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


[Lldb-commits] [lldb] 30578c0 - dependency cycle fix in DynamicLoaderDarwinKernel

2022-09-09 Thread Jason Molenda via lldb-commits

Author: Jason Molenda
Date: 2022-09-09T17:37:46-07:00
New Revision: 30578c08568bc8de79dea72e41f49899ba10ea55

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

LOG: dependency cycle fix in DynamicLoaderDarwinKernel

DynamicLoaderDarwinKernel calls in to PlatformDarwinKernel, and
with my changes in https://reviews.llvm.org/D133534, PlatformDarwinKernel
calls in to DynamicLoaderDarwinKernel.  This results in a cmake
dependency if accurately included in the link libraries list.

lldbPluginDynamicLoaderDarwinKernel is specfically for kernel
debugging and is uncommonly linked in to anything except a full
lldb.  lldbPluginPlatformMacOSX is any Darwin platform, including
PlatformDarwinKernel, and is referenced a number of time in shell
tests, for instance.

I believe anything linking the darwin kernel DynamicLoader plugin
will already have lldbPluginPlatformMacOSX in its dependency list,
so not explicitly expressing this dependency is safe.

Added: 


Modified: 
lldb/source/Plugins/DynamicLoader/Darwin-Kernel/CMakeLists.txt

Removed: 




diff  --git a/lldb/source/Plugins/DynamicLoader/Darwin-Kernel/CMakeLists.txt 
b/lldb/source/Plugins/DynamicLoader/Darwin-Kernel/CMakeLists.txt
index e29ddca343f9..fb838f42489d 100644
--- a/lldb/source/Plugins/DynamicLoader/Darwin-Kernel/CMakeLists.txt
+++ b/lldb/source/Plugins/DynamicLoader/Darwin-Kernel/CMakeLists.txt
@@ -17,7 +17,6 @@ add_lldb_library(lldbPluginDynamicLoaderDarwinKernel PLUGIN
 lldbSymbol
 lldbTarget
 lldbUtility
-lldbPluginPlatformMacOSX
   )
 
 add_dependencies(lldbPluginDynamicLoaderDarwinKernel



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


[Lldb-commits] [PATCH] D133534: Complete support of loading a darwin kernel over a live gdb-remote connection given the address of a mach-o fileset

2022-09-09 Thread Jason Molenda via Phabricator via lldb-commits
jasonmolenda added inline comments.



Comment at: lldb/source/Plugins/Platform/MacOSX/CMakeLists.txt:47
 lldbUtility
+lldbPluginDynamicLoaderDarwinKernel
+lldbPluginObjectContainerMachOFileset

thakis wrote:
> This causes a dependency cycle:
> 
>   //lldb/source/Plugins/Platform/MacOSX:MacOSX ->
>   //lldb/source/Plugins/DynamicLoader/Darwin-Kernel:Darwin-Kernel ->
>   //lldb/source/Plugins/Platform/MacOSX:MacOSX
Ach, naturally.  DynamicLoaderDarwinKernel has to create a PlatformDarwinKernel 
to set in the Target when it is initializing itself.  :/  Maybe I'll just add 
DynamicLoaderDarwinKernel to the unit tests that have PlatformMacOSX in them.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133534

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


[Lldb-commits] [PATCH] D133623: Fix DW_OP_convert to resolve the CU relative offset correctly.

2022-09-09 Thread Greg Clayton via Phabricator via lldb-commits
clayborg added a comment.
Herald added a subscriber: Michael137.

Adrian: not sure how to test this. This all seems to be unit tested with your 
unit tests. If you have any ideas of how to modify the tests to verify this let 
me know.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133623

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


[Lldb-commits] [PATCH] D133623: Fix DW_OP_convert to resolve the CU relative offset correctly.

2022-09-09 Thread Greg Clayton via Phabricator via lldb-commits
clayborg created this revision.
clayborg added reviewers: labath, JDevlieghere, aprantl.
Herald added a project: All.
clayborg requested review of this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

Debugging some DWARF5 binaries was causing errors to appear when 
DWARFExpression::Evaluate was called:

  error: GetDIE for DIE 0x31 is outside of its CU 0x123450

The issue is in the DWARF expression evaluator. Fixed with this.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D133623

Files:
  lldb/source/Expression/DWARFExpression.cpp


Index: lldb/source/Expression/DWARFExpression.cpp
===
--- lldb/source/Expression/DWARFExpression.cpp
+++ lldb/source/Expression/DWARFExpression.cpp
@@ -2354,7 +2354,7 @@
   "Expression stack needs at least 1 item for DW_OP_convert.");
 return false;
   }
-  const uint64_t die_offset = opcodes.GetULEB128();
+  uint64_t die_offset = opcodes.GetULEB128();
   uint64_t bit_size;
   bool sign;
   if (die_offset == 0) {
@@ -2374,7 +2374,9 @@
   return false;
 }
   } else {
-// Retrieve the type DIE that the value is being converted to.
+// Retrieve the type DIE that the value is being converted to. This
+// offset is compile unit relative so we need to fix it up.
+die_offset += dwarf_cu->GetOffset();
 // FIXME: the constness has annoying ripple effects.
 DWARFDIE die = const_cast(dwarf_cu)->GetDIE(die_offset);
 if (!die) {


Index: lldb/source/Expression/DWARFExpression.cpp
===
--- lldb/source/Expression/DWARFExpression.cpp
+++ lldb/source/Expression/DWARFExpression.cpp
@@ -2354,7 +2354,7 @@
   "Expression stack needs at least 1 item for DW_OP_convert.");
 return false;
   }
-  const uint64_t die_offset = opcodes.GetULEB128();
+  uint64_t die_offset = opcodes.GetULEB128();
   uint64_t bit_size;
   bool sign;
   if (die_offset == 0) {
@@ -2374,7 +2374,9 @@
   return false;
 }
   } else {
-// Retrieve the type DIE that the value is being converted to.
+// Retrieve the type DIE that the value is being converted to. This
+// offset is compile unit relative so we need to fix it up.
+die_offset += dwarf_cu->GetOffset();
 // FIXME: the constness has annoying ripple effects.
 DWARFDIE die = const_cast(dwarf_cu)->GetDIE(die_offset);
 if (!die) {
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D133129: [lldb] Add boilerplate for debugger interrupts

2022-09-09 Thread Jim Ingham via Phabricator via lldb-commits
jingham added a comment.

In D133129#3780028 , @labath wrote:

> In D133129#3778125 , @jingham wrote:
>
>> To be clear, I'm not trying to implement a preemptive interrupt using these 
>> callbacks.  There are so many places where lldb is doing work that you 
>> really can't interrupt - e.g. we can't drop symbol parsing and then pick it 
>> up again later - that that doesn't really even make sense.
>>
>> I started out with the goal of extending the current 
>> InterruptCommand/WasInterrupted style of voluntary interruption to more 
>> places in lldb.  A voluntary "I'm doing something in a loop that can be 
>> interrupted, so I'll check for interruption at the top of the loop" 
>> mechanism seems like the best fit for lldb, so that structure makes sense.  
>> But we only check for interruption a few place in the "target modules" 
>> commands.  It would be useful to have other places check - e.g. if you did a 
>> `bt` and there were 4 frames and you don't want to wait for us to print 
>> them all out...  So I was going to look into adding more interrupt checks.
>>
>> But then it seemed a shame that setting this interrupt only works when you 
>> are running command line commands, there's no reason this can't work for SB 
>> API calls as well, then UI's could also allow this sort of interruption.  If 
>> the UI code is doing something in a loop, then it's up to the UI code to 
>> handle interrupting that operation.
>
> I agree with all that.
>
>> So all I'm trying to do is set the interrupt flag for use while the 
>> currently executing SB API is in flight, then turning it off when that call 
>> exits.
>
> The problem is that, even with a single SB call, it's very hard to tell the 
> difference between "I am doing X" vs. "I am about to do X" vs. "I have just 
> completed X (but haven't told anyone about it)". And I don't see a way to do 
> that reliably through any kind of automatic API boundary tracking.

I didn't see it as our job to make this distinction.  If an IDE is about to do 
X or is just done with X and the user hits the IDE's pause button, then it's up 
to the IDE to pause whatever it was doing before and after SB API calls.  We're 
not going to be able to interrupt anything that goes on between SB API calls 
anyway, so I thought it would be easier for UI's to reason about if all we did 
was interrupt in the current in-flight API call, which we should be able to use 
boundary tracking for.

>> The debugger is the one setting the interrupt flag, so we always know who is 
>> sending the interrupt.  The tricky bit is how to turn off the 
>> "WasInterrupted" flag after the API that was in flight when the flag was set 
>> finishes.
>
> Maybe the solution is to not (automatically) turn off the flag -- but put it 
> in the hands of the user instead? If the interrupt flag was sticky (with 
> explicit SetInterrupt/ClearInterrupt actions), then one can handle all of the 
> scenarios above fairly easily.
> It doesn't matter that whether SetInterrupt is called before the blocking 
> call or not -- the call is going to be interrupted anyway. And one can 
> explicitly clear the interrupt flag after the blocking call returns (either 
> successfully or because it was interrupted).

That's an interesting thought.  If we did that we'd have to separate the 
command line interrupt flags from the SB API ones w.r.t. setting/unsetting: a 
sticky flag is not the behavior you want for commands, but then check both in 
WasInterrupted.  I can't see a reason why we'd need to distinguish the two 
sources of interrupt at the point where we go to check.  We'd also have to 
never set the flag ourselves, having UI's have to spam turning this off would 
be super annoying, so this would have to be strictly controlled from outside 
lldb.  But that should be okay, if we want this behavior in the driver we can 
implement it outside the lldb library in the driver.   That just leaves me with 
the problem (even more acute with a sticky flag) of not interrupting API calls 
for the Debugger that didn't issue the interrupt.


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

https://reviews.llvm.org/D133129

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


[Lldb-commits] [PATCH] D133534: Complete support of loading a darwin kernel over a live gdb-remote connection given the address of a mach-o fileset

2022-09-09 Thread Nico Weber via Phabricator via lldb-commits
thakis added inline comments.



Comment at: lldb/source/Plugins/Platform/MacOSX/CMakeLists.txt:47
 lldbUtility
+lldbPluginDynamicLoaderDarwinKernel
+lldbPluginObjectContainerMachOFileset

This causes a dependency cycle:

  //lldb/source/Plugins/Platform/MacOSX:MacOSX ->
  //lldb/source/Plugins/DynamicLoader/Darwin-Kernel:Darwin-Kernel ->
  //lldb/source/Plugins/Platform/MacOSX:MacOSX


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133534

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


[Lldb-commits] [PATCH] D133164: Add the ability to show when variables fails to be available when debug info is valid.

2022-09-09 Thread Greg Clayton via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG9af089f5179d: Add the ability to show when variables fails 
to be available when debug info is… (authored by clayborg).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133164

Files:
  lldb/bindings/interface/SBValueList.i
  lldb/include/lldb/API/SBError.h
  lldb/include/lldb/API/SBValueList.h
  lldb/include/lldb/Symbol/SymbolFile.h
  lldb/include/lldb/Target/StackFrame.h
  lldb/packages/Python/lldbsuite/test/builders/builder.py
  lldb/packages/Python/lldbsuite/test/lldbtest.py
  lldb/source/API/SBFrame.cpp
  lldb/source/API/SBValueList.cpp
  lldb/source/Commands/CommandObjectFrame.cpp
  lldb/source/Core/IOHandlerCursesGUI.cpp
  lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
  lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
  lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.h
  lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
  lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
  lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
  lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.h
  lldb/source/Symbol/Variable.cpp
  lldb/source/Target/StackFrame.cpp
  lldb/test/API/commands/frame/var/TestFrameVar.py
  lldb/test/API/functionalities/archives/Makefile
  lldb/test/API/functionalities/archives/TestBSDArchives.py

Index: lldb/test/API/functionalities/archives/TestBSDArchives.py
===
--- lldb/test/API/functionalities/archives/TestBSDArchives.py
+++ lldb/test/API/functionalities/archives/TestBSDArchives.py
@@ -6,10 +6,16 @@
 from lldbsuite.test.decorators import *
 from lldbsuite.test.lldbtest import *
 from lldbsuite.test import lldbutil
-
+import os
+import time
 
 class BSDArchivesTestCase(TestBase):
 
+# If your test case doesn't stress debug info, then
+# set this to true.  That way it won't be run once for
+# each debug info format.
+NO_DEBUG_INFO_TESTCASE = True
+
 def setUp(self):
 # Call super's setUp().
 TestBase.setUp(self)
@@ -17,8 +23,6 @@
 self.line = line_number(
 'a.c', '// Set file and line breakpoint inside a().')
 
-# Doesn't depend on any specific debug information.
-@no_debug_info_test
 @expectedFailureAll(
 oslist=["windows"],
 bugnumber="llvm.org/pr24527.  Makefile.rules doesn't know how to build static libs on Windows")
@@ -65,3 +69,80 @@
 num_specs = module_specs.GetSize()
 self.assertEqual(num_specs, 1)
 self.assertEqual(module_specs.GetSpecAtIndex(0).GetObjectName(), "c.o")
+
+
+def check_frame_variable_errors(self, thread, error_strings):
+command_result = lldb.SBCommandReturnObject()
+interp = self.dbg.GetCommandInterpreter()
+result = interp.HandleCommand("frame variable", command_result)
+self.assertEqual(result, lldb.eReturnStatusFailed,
+ "frame var succeeded unexpectedly")
+command_error = command_result.GetError()
+
+frame = thread.GetFrameAtIndex(0)
+var_list = frame.GetVariables(True, True, False, True)
+self.assertEqual(var_list.GetSize(), 0)
+api_error = var_list.GetError().GetCString()
+
+for s in error_strings:
+self.assertTrue(s in command_error, 'Make sure "%s" exists in the command error "%s"' % (s, command_error))
+for s in error_strings:
+self.assertTrue(s in api_error, 'Make sure "%s" exists in the API error "%s"' % (s, api_error))
+
+@skipIfRemote
+@skipUnlessDarwin
+def test_frame_var_errors_when_archive_missing(self):
+"""
+Break inside a() and remove libfoo.a to make sure we can't load
+the debug information and report an appropriate error when doing
+'frame variable'.
+"""
+self.build()
+exe = self.getBuildArtifact("a.out")
+libfoo_path = self.getBuildArtifact("libfoo.a")
+# Delete the main.o file that contains the debug info so we force an
+# error when we run to main and try to get variables for the a()
+# function. Since the libfoo.a is missing, the debug info won't be
+# loaded and we should see an error when trying to read varibles.
+os.unlink(libfoo_path)
+
+(target, process, thread, bkpt) = lldbutil.run_to_name_breakpoint(
+self, 'a', bkpt_module=exe)
+
+error_strings = [
+'debug map object file "',
+'libfoo.a(a.o)" containing debug info does not exist, debug info will not be loaded'
+]
+self.check_frame_variable_errors(thread, error_strings)
+
+@skipIfRemote
+@skipUnlessDarwin
+def test_frame_var_errors_when_mtime_mistmatch_for_object_in_archive(self):
+"""
+Break inside a() and modify 

[Lldb-commits] [lldb] 9af089f - Add the ability to show when variables fails to be available when debug info is valid.

2022-09-09 Thread Greg Clayton via lldb-commits

Author: Greg Clayton
Date: 2022-09-09T16:14:46-07:00
New Revision: 9af089f5179d52c6561ec27532880edcfb6253af

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

LOG: Add the ability to show when variables fails to be available when debug 
info is valid.

Many times when debugging variables might not be available even though a user 
can successfully set breakpoints and stops somewhere. Letting the user know 
will help users fix these kinds of issues and have a better debugging 
experience.

Examples of this include:
- enabling -gline-tables-only and being able to set file and line breakpoints 
and yet see no variables
- unable to open object file for DWARF in .o file debugging for darwin targets 
due to modification time mismatch or not being able to locate the N_OSO file.

This patch adds an new API to SBValueList:

  lldb::SBError lldb::SBValueList::GetError();

object so that if you request a stack frame's variables using SBValueList 
SBFrame::GetVariables(...), you can get an error the describes why the 
variables were not available.

This patch adds the ability to get an error back when requesting variables from 
a lldb_private::StackFrame when calling GetVariableList.

It also now shows an error in response to "frame variable" if we have debug 
info and are unable to get varialbes due to an error as mentioned above:

(lldb) frame variable
error: "a.o" object from the "/tmp/libfoo.a" archive: either the .o file 
doesn't exist in the archive or the modification time (0x63111541) of the .o 
file doesn't match

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

Added: 


Modified: 
lldb/bindings/interface/SBValueList.i
lldb/include/lldb/API/SBError.h
lldb/include/lldb/API/SBValueList.h
lldb/include/lldb/Symbol/SymbolFile.h
lldb/include/lldb/Target/StackFrame.h
lldb/packages/Python/lldbsuite/test/builders/builder.py
lldb/packages/Python/lldbsuite/test/lldbtest.py
lldb/source/API/SBFrame.cpp
lldb/source/API/SBValueList.cpp
lldb/source/Commands/CommandObjectFrame.cpp
lldb/source/Core/IOHandlerCursesGUI.cpp
lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.h
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.h
lldb/source/Symbol/Variable.cpp
lldb/source/Target/StackFrame.cpp
lldb/test/API/commands/frame/var/TestFrameVar.py
lldb/test/API/functionalities/archives/Makefile
lldb/test/API/functionalities/archives/TestBSDArchives.py

Removed: 




diff  --git a/lldb/bindings/interface/SBValueList.i 
b/lldb/bindings/interface/SBValueList.i
index 76fa937b98764..32543af17413b 100644
--- a/lldb/bindings/interface/SBValueList.i
+++ b/lldb/bindings/interface/SBValueList.i
@@ -102,6 +102,8 @@ public:
 lldb::SBValue
 GetFirstValueByName (const char* name) const;
 
+lldb::SBError GetError();
+
 %extend {
%nothreadallow;
std::string lldb::SBValueList::__str__ (){

diff  --git a/lldb/include/lldb/API/SBError.h b/lldb/include/lldb/API/SBError.h
index f8289e2fcbb3a..b34014aecc441 100644
--- a/lldb/include/lldb/API/SBError.h
+++ b/lldb/include/lldb/API/SBError.h
@@ -64,6 +64,7 @@ class LLDB_API SBError {
   friend class SBCommunication;
   friend class SBData;
   friend class SBDebugger;
+  friend class SBFile;
   friend class SBHostOS;
   friend class SBPlatform;
   friend class SBProcess;
@@ -73,8 +74,8 @@ class LLDB_API SBError {
   friend class SBThread;
   friend class SBTrace;
   friend class SBValue;
+  friend class SBValueList;
   friend class SBWatchpoint;
-  friend class SBFile;
 
   friend class lldb_private::ScriptInterpreter;
 

diff  --git a/lldb/include/lldb/API/SBValueList.h 
b/lldb/include/lldb/API/SBValueList.h
index dc8389b752938..a5017bccc5053 100644
--- a/lldb/include/lldb/API/SBValueList.h
+++ b/lldb/include/lldb/API/SBValueList.h
@@ -43,6 +43,33 @@ class LLDB_API SBValueList {
 
   const lldb::SBValueList =(const lldb::SBValueList );
 
+  // Get an error for why this list is empty.
+  //
+  // If this list is empty, check for an underlying error in the debug
+  // information that prevented this list from being populated. This is not
+  // meant to return an error if there is no debug information as it is ok for 
a
+  // value list to be empty and no error should be returned in that case. If 
the
+  // debug info is for an assembly file or language that doesn't have any
+  // variables, no error should be returned.
+  //
+  // This is designed as a way to 

[Lldb-commits] [PATCH] D133618: Adapt LLDB dataformatters for libcxx change D129386

2022-09-09 Thread Michael Buch via Phabricator via lldb-commits
Michael137 added a comment.
Herald added a subscriber: JDevlieghere.

LGTM thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133618

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


[Lldb-commits] [PATCH] D133618: Adapt LLDB dataformatters for libcxx change D129386

2022-09-09 Thread Adrian Prantl via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG2f4a66eed688: Adapt LLDB dataformatters for libcxx change 
D129386 (authored by aprantl).
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133618

Files:
  lldb/include/lldb/DataFormatters/VectorIterator.h
  lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
  lldb/source/Plugins/Language/CPlusPlus/LibCxx.h
  lldb/source/Plugins/Language/CPlusPlus/LibCxxMap.cpp
  lldb/source/Plugins/Language/CPlusPlus/LibCxxSpan.cpp
  lldb/source/Plugins/Language/CPlusPlus/LibCxxVariant.cpp
  lldb/source/Plugins/Language/CPlusPlus/LibCxxVariant.h
  lldb/source/Plugins/Language/CPlusPlus/LibStdcpp.cpp
  
lldb/test/API/commands/expression/import-std-module/deque-basic/TestDequeFromStdModule.py
  
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/iterator/TestDataFormatterLibccIterator.py
  
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/span/TestDataFormatterLibcxxSpan.py
  
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/string_view/TestDataFormatterLibcxxStringView.py
  
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/variant/TestDataFormatterLibcxxVariant.py

Index: lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/variant/TestDataFormatterLibcxxVariant.py
===
--- lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/variant/TestDataFormatterLibcxxVariant.py
+++ lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/variant/TestDataFormatterLibcxxVariant.py
@@ -19,7 +19,6 @@
 @skipIf(compiler="gcc", compiler_version=['<', '5.1'])
 ## std::get is unavailable for std::variant before macOS 10.14
 @skipIf(macos_version=["<", "10.14"])
-@expectedFailureDarwin # FIXME: May need to force system libcxx here.
 def test_with_run_command(self):
 """Test that that file and class static variables display correctly."""
 self.build()
Index: lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/string_view/TestDataFormatterLibcxxStringView.py
===
--- lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/string_view/TestDataFormatterLibcxxStringView.py
+++ lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/string_view/TestDataFormatterLibcxxStringView.py
@@ -21,7 +21,6 @@
 self.line2 = line_number('main.cpp', '// Break here to look at bad string view.' )
 
 @add_test_categories(["libc++"])
-@expectedFailureDarwin # FIXME: May need to force system libcxx here.
 @expectedFailureAll(bugnumber="llvm.org/pr36109", debug_info="gmodules", triple=".*-android")
 # Inline namespace is randomly ignored as Clang due to broken lookup inside
 # the std namespace.
Index: lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/span/TestDataFormatterLibcxxSpan.py
===
--- lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/span/TestDataFormatterLibcxxSpan.py
+++ lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/span/TestDataFormatterLibcxxSpan.py
@@ -43,7 +43,6 @@
 self.expect_var_path(f'{var_name}[4]', type='int', value='12345')
 
 @add_test_categories(['libc++'])
-@expectedFailureDarwin # FIXME: May need to force system libcxx here.
 @skipIf(compiler='clang', compiler_version=['<', '11.0'])
 def test_with_run_command(self):
 """Test that std::span variables are formatted correctly when printed."""
Index: lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/iterator/TestDataFormatterLibccIterator.py
===
--- lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/iterator/TestDataFormatterLibccIterator.py
+++ lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/iterator/TestDataFormatterLibccIterator.py
@@ -19,7 +19,6 @@
 self.line = line_number('main.cpp', '// Set break point at this line.')
 self.namespace = 'std'
 
-@expectedFailureDarwin # FIXME: May need to force system libcxx here.
 @add_test_categories(["libc++"])
 def test_with_run_command(self):
 """Test that libc++ iterators format properly."""
Index: lldb/test/API/commands/expression/import-std-module/deque-basic/TestDequeFromStdModule.py
===
--- lldb/test/API/commands/expression/import-std-module/deque-basic/TestDequeFromStdModule.py
+++ 

[Lldb-commits] [lldb] 2f4a66e - Adapt LLDB dataformatters for libcxx change D129386

2022-09-09 Thread Adrian Prantl via lldb-commits

Author: Adrian Prantl
Date: 2022-09-09T15:58:55-07:00
New Revision: 2f4a66eed68804929efa1ad3c10fc040a67fb3ff

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

LOG: Adapt LLDB dataformatters for libcxx change D129386

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

Added: 


Modified: 
lldb/include/lldb/DataFormatters/VectorIterator.h
lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
lldb/source/Plugins/Language/CPlusPlus/LibCxx.h
lldb/source/Plugins/Language/CPlusPlus/LibCxxMap.cpp
lldb/source/Plugins/Language/CPlusPlus/LibCxxSpan.cpp
lldb/source/Plugins/Language/CPlusPlus/LibCxxVariant.cpp
lldb/source/Plugins/Language/CPlusPlus/LibCxxVariant.h
lldb/source/Plugins/Language/CPlusPlus/LibStdcpp.cpp

lldb/test/API/commands/expression/import-std-module/deque-basic/TestDequeFromStdModule.py

lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/iterator/TestDataFormatterLibccIterator.py

lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/span/TestDataFormatterLibcxxSpan.py

lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/string_view/TestDataFormatterLibcxxStringView.py

lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/variant/TestDataFormatterLibcxxVariant.py

Removed: 




diff  --git a/lldb/include/lldb/DataFormatters/VectorIterator.h 
b/lldb/include/lldb/DataFormatters/VectorIterator.h
index 33650a3dac8fc..3414298f255b6 100644
--- a/lldb/include/lldb/DataFormatters/VectorIterator.h
+++ b/lldb/include/lldb/DataFormatters/VectorIterator.h
@@ -15,13 +15,14 @@
 #include "lldb/DataFormatters/TypeSynthetic.h"
 #include "lldb/Target/ExecutionContext.h"
 #include "lldb/Utility/ConstString.h"
+#include "llvm/ADT/SmallVector.h"
 
 namespace lldb_private {
 namespace formatters {
 class VectorIteratorSyntheticFrontEnd : public SyntheticChildrenFrontEnd {
 public:
   VectorIteratorSyntheticFrontEnd(lldb::ValueObjectSP valobj_sp,
-  ConstString item_name);
+  llvm::ArrayRef item_names);
 
   size_t CalculateNumChildren() override;
 
@@ -35,7 +36,7 @@ class VectorIteratorSyntheticFrontEnd : public 
SyntheticChildrenFrontEnd {
 
 private:
   ExecutionContextRef m_exe_ctx_ref;
-  ConstString m_item_name;
+  llvm::SmallVector m_item_names;
   lldb::ValueObjectSP m_item_sp;
 };
 

diff  --git a/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp 
b/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
index 3b04b3a1b2acc..2480dbf8a2a60 100644
--- a/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
+++ b/lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
@@ -34,6 +34,17 @@ using namespace lldb;
 using namespace lldb_private;
 using namespace lldb_private::formatters;
 
+lldb::ValueObjectSP lldb_private::formatters::GetChildMemberWithName(
+ValueObject , llvm::ArrayRef alternative_names) {
+  for (ConstString name : alternative_names) {
+lldb::ValueObjectSP child_sp = obj.GetChildMemberWithName(name, true);
+
+if (child_sp)
+  return child_sp;
+  }
+  return {};
+}
+
 bool lldb_private::formatters::LibcxxOptionalSummaryProvider(
 ValueObject , Stream , const TypeSummaryOptions ) {
   ValueObjectSP valobj_sp(valobj.GetNonSyntheticValue());
@@ -538,12 +549,9 @@ 
lldb_private::formatters::LibCxxUnorderedMapIteratorSyntheticFrontEndCreator(
 SyntheticChildrenFrontEnd *
 lldb_private::formatters::LibCxxVectorIteratorSyntheticFrontEndCreator(
 CXXSyntheticChildren *, lldb::ValueObjectSP valobj_sp) {
-  static ConstString g_item_name;
-  if (!g_item_name)
-g_item_name.SetCString("__i");
-  return (valobj_sp
-  ? new VectorIteratorSyntheticFrontEnd(valobj_sp, g_item_name)
-  : nullptr);
+  return (valobj_sp ? new VectorIteratorSyntheticFrontEnd(
+  valobj_sp, {ConstString("__i_"), ConstString("__i")})
+: nullptr);
 }
 
 lldb_private::formatters::LibcxxSharedPtrSyntheticFrontEnd::
@@ -992,11 +1000,10 @@ bool 
lldb_private::formatters::LibcxxStringSummaryProviderUTF32(
 
 static std::tuple
 LibcxxExtractStringViewData(ValueObject& valobj) {
-  ConstString g_data_name("__data");
-  ConstString g_size_name("__size");
-  auto dataobj = valobj.GetChildMemberWithName(g_data_name, true);
-  auto sizeobj = valobj.GetChildMemberWithName(g_size_name, true);
-
+  auto dataobj = GetChildMemberWithName(
+  valobj, {ConstString("__data_"), ConstString("__data")});
+  auto sizeobj = GetChildMemberWithName(
+  valobj, {ConstString("__size_"), ConstString("__size")});
   if (!dataobj || !sizeobj)
 return std::make_tuple(false, {}, {});
 

diff  --git a/lldb/source/Plugins/Language/CPlusPlus/LibCxx.h 

[Lldb-commits] [PATCH] D133618: Adapt LLDB dataformatters for libcxx change D129386

2022-09-09 Thread Adrian Prantl via Phabricator via lldb-commits
aprantl added inline comments.



Comment at: lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp:1004
+  auto dataobj = GetChildMemberWithName(
+  valobj, {ConstString("__data_"), ConstString("__data")});
+  auto sizeobj = GetChildMemberWithName(

ldionne wrote:
> IIUC you're trying to support both the old and the new naming?
Yes, otherwise the matrix bot, which tests that LLDB can debug code compiled 
with older releases of clang (and libcxx) would fail. Currently it builds the 
testsuite with every other release since Clang 5.0

https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-matrix/


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

https://reviews.llvm.org/D133618

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


[Lldb-commits] [PATCH] D133618: Adapt LLDB dataformatters for libcxx change D129386

2022-09-09 Thread Louis Dionne via Phabricator via lldb-commits
ldionne accepted this revision.
ldionne added inline comments.
This revision is now accepted and ready to land.



Comment at: lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp:1004
+  auto dataobj = GetChildMemberWithName(
+  valobj, {ConstString("__data_"), ConstString("__data")});
+  auto sizeobj = GetChildMemberWithName(

IIUC you're trying to support both the old and the new naming?


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

https://reviews.llvm.org/D133618

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


[Lldb-commits] [PATCH] D133618: Adapt LLDB dataformatters for libcxx change D129386

2022-09-09 Thread Adrian Prantl via Phabricator via lldb-commits
aprantl updated this revision to Diff 459214.

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

https://reviews.llvm.org/D133618

Files:
  lldb/include/lldb/DataFormatters/VectorIterator.h
  lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
  lldb/source/Plugins/Language/CPlusPlus/LibCxx.h
  lldb/source/Plugins/Language/CPlusPlus/LibCxxMap.cpp
  lldb/source/Plugins/Language/CPlusPlus/LibCxxSpan.cpp
  lldb/source/Plugins/Language/CPlusPlus/LibCxxVariant.cpp
  lldb/source/Plugins/Language/CPlusPlus/LibCxxVariant.h
  lldb/source/Plugins/Language/CPlusPlus/LibStdcpp.cpp
  
lldb/test/API/commands/expression/import-std-module/deque-basic/TestDequeFromStdModule.py
  
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/iterator/TestDataFormatterLibccIterator.py
  
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/span/TestDataFormatterLibcxxSpan.py
  
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/string_view/TestDataFormatterLibcxxStringView.py
  
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/variant/TestDataFormatterLibcxxVariant.py

Index: lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/variant/TestDataFormatterLibcxxVariant.py
===
--- lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/variant/TestDataFormatterLibcxxVariant.py
+++ lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/variant/TestDataFormatterLibcxxVariant.py
@@ -19,7 +19,6 @@
 @skipIf(compiler="gcc", compiler_version=['<', '5.1'])
 ## std::get is unavailable for std::variant before macOS 10.14
 @skipIf(macos_version=["<", "10.14"])
-@expectedFailureDarwin # FIXME: May need to force system libcxx here.
 def test_with_run_command(self):
 """Test that that file and class static variables display correctly."""
 self.build()
Index: lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/string_view/TestDataFormatterLibcxxStringView.py
===
--- lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/string_view/TestDataFormatterLibcxxStringView.py
+++ lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/string_view/TestDataFormatterLibcxxStringView.py
@@ -21,7 +21,6 @@
 self.line2 = line_number('main.cpp', '// Break here to look at bad string view.' )
 
 @add_test_categories(["libc++"])
-@expectedFailureDarwin # FIXME: May need to force system libcxx here.
 @expectedFailureAll(bugnumber="llvm.org/pr36109", debug_info="gmodules", triple=".*-android")
 # Inline namespace is randomly ignored as Clang due to broken lookup inside
 # the std namespace.
Index: lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/span/TestDataFormatterLibcxxSpan.py
===
--- lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/span/TestDataFormatterLibcxxSpan.py
+++ lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/span/TestDataFormatterLibcxxSpan.py
@@ -43,7 +43,6 @@
 self.expect_var_path(f'{var_name}[4]', type='int', value='12345')
 
 @add_test_categories(['libc++'])
-@expectedFailureDarwin # FIXME: May need to force system libcxx here.
 @skipIf(compiler='clang', compiler_version=['<', '11.0'])
 def test_with_run_command(self):
 """Test that std::span variables are formatted correctly when printed."""
Index: lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/iterator/TestDataFormatterLibccIterator.py
===
--- lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/iterator/TestDataFormatterLibccIterator.py
+++ lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/iterator/TestDataFormatterLibccIterator.py
@@ -19,7 +19,6 @@
 self.line = line_number('main.cpp', '// Set break point at this line.')
 self.namespace = 'std'
 
-@expectedFailureDarwin # FIXME: May need to force system libcxx here.
 @add_test_categories(["libc++"])
 def test_with_run_command(self):
 """Test that libc++ iterators format properly."""
Index: lldb/test/API/commands/expression/import-std-module/deque-basic/TestDequeFromStdModule.py
===
--- lldb/test/API/commands/expression/import-std-module/deque-basic/TestDequeFromStdModule.py
+++ lldb/test/API/commands/expression/import-std-module/deque-basic/TestDequeFromStdModule.py
@@ -10,7 +10,7 @@
 class TestBasicDeque(TestBase):
 
 @add_test_categories(["libc++"])
-@expectedFailureDarwin
+@expectedFailureDarwin # FIXME: May need to force system libcxx here.
 

[Lldb-commits] [PATCH] D133461: [LLDB][NativePDB] Set block address range.

2022-09-09 Thread Zequan Wu via Phabricator via lldb-commits
zequanwu marked 2 inline comments as done.
zequanwu added inline comments.



Comment at: lldb/test/Shell/SymbolFile/NativePDB/blocks.cpp:17
+
+// CHECK:  Function: id = {{.*}}, name = "main", range = 
[0x000140001000-0x00014000104b)
+// CHECK-NEXT: FuncType: id = {{.*}}, byte-size = 0, compiler_type = "int 
(void)"

labath wrote:
> I fear this test is going to be extremely fragile (susceptible to changes in 
> codegen AND debug info generation). I'd probably write it in asm (you could 
> even test the error msg then).
Done in https://reviews.llvm.org/rG603793698928c1f32772248840a45ddcf4914bd2.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133461

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


[Lldb-commits] [lldb] 6037936 - [LLDB][NativePDB] Replace blocks.cpp with blocks.s so the test won't be affected by codegen changes.

2022-09-09 Thread Zequan Wu via lldb-commits

Author: Zequan Wu
Date: 2022-09-09T15:47:27-07:00
New Revision: 603793698928c1f32772248840a45ddcf4914bd2

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

LOG: [LLDB][NativePDB] Replace blocks.cpp with blocks.s so the test won't be 
affected by codegen changes.

Added: 
lldb/test/Shell/SymbolFile/NativePDB/blocks.s

Modified: 
lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp

Removed: 
lldb/test/Shell/SymbolFile/NativePDB/blocks.cpp



diff  --git a/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp 
b/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
index 75bff62404cc3..2781ae0c87abf 100644
--- a/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
+++ b/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
@@ -369,9 +369,8 @@ Block ::CreateBlock(PdbCompilandSymId 
block_id) {
 m_index->MakeVirtualAddress(block.Segment, block.CodeOffset);
 lldb::addr_t func_base =
 func->GetAddressRange().GetBaseAddress().GetFileAddress();
-Block::Range range = Block::Range(block_base - func_base, block.CodeSize);
 if (block_base >= func_base)
-  child_block->AddRange(range);
+  child_block->AddRange(Block::Range(block_base - func_base, 
block.CodeSize));
 else {
   GetObjectFile()->GetModule()->ReportError(
   "S_BLOCK32 at modi: %d offset: %d: adding range [0x%" PRIx64

diff  --git a/lldb/test/Shell/SymbolFile/NativePDB/blocks.cpp 
b/lldb/test/Shell/SymbolFile/NativePDB/blocks.cpp
deleted file mode 100644
index 1d7431847921d..0
--- a/lldb/test/Shell/SymbolFile/NativePDB/blocks.cpp
+++ /dev/null
@@ -1,20 +0,0 @@
-// clang-format off
-// REQUIRES: lld, x86
-
-// Test block range is set.
-// RUN: %clang_cl --target=x86_64-windows-msvc -Od -Z7 -GS- -c /Fo%t.obj -- %s
-// RUN: lld-link -debug:full -nodefaultlib -entry:main -base:0x14000 
%t.obj -out:%t.exe -pdb:%t.pdb
-// RUN: env LLDB_USE_NATIVE_PDB_READER=1 %lldb %t.exe -o "image lookup -a 
0x140001014 -v" | FileCheck %s
-
-int main() {
-  int count = 0;
-  for (int i = 0; i < 3; ++i) {
-++count;
-  }
-  return count;
-}
-
-// CHECK:  Function: id = {{.*}}, name = "main", range = 
[0x000140001000-0x00014000104b)
-// CHECK-NEXT: FuncType: id = {{.*}}, byte-size = 0, compiler_type = "int 
(void)"
-// CHECK-NEXT:   Blocks: id = {{.*}}, range = [0x140001000-0x14000104b)
-// CHECK-NEXT:   id = {{.*}}, range = [0x140001014-0x140001042)

diff  --git a/lldb/test/Shell/SymbolFile/NativePDB/blocks.s 
b/lldb/test/Shell/SymbolFile/NativePDB/blocks.s
new file mode 100644
index 0..7a124702e4757
--- /dev/null
+++ b/lldb/test/Shell/SymbolFile/NativePDB/blocks.s
@@ -0,0 +1,213 @@
+// clang-format off
+// REQUIRES: lld, x86
+
+// Test block range is set.
+// RUN: llvm-mc -triple=x86_64-windows-msvc --filetype=obj %s > %t.obj
+// RUN: lld-link /debug:full /nodefaultlib /entry:main %t.obj /out:%t.exe 
/base:0x14000
+// RUN: env LLDB_USE_NATIVE_PDB_READER=1 %lldb %t.exe -o "image lookup -a 
0x140001014 -v" -o "exit" | FileCheck %s
+
+// CHECK:  Function: id = {{.*}}, name = "main", range = 
[0x000140001000-0x000140001044)
+// CHECK-NEXT: FuncType: id = {{.*}}, byte-size = 0, compiler_type = "int 
(void)"
+// CHECK-NEXT:   Blocks: id = {{.*}}, range = [0x140001000-0x140001044)
+// CHECK-NEXT:   id = {{.*}}, range = [0x140001014-0x14000103b)
+
+
+   .text
+   .def@feat.00;
+   .scl3;
+   .type   0;
+   .endef
+   .globl  @feat.00
+.set @feat.00, 0
+   .intel_syntax noprefix
+   .file   "blocks.cpp"
+   .defmain;
+   .scl2;
+   .type   32;
+   .endef
+   .globl  main# -- Begin function main
+   .p2align4, 0x90
+main:   # @main
+.Lfunc_begin0:
+   .cv_func_id 0
+   .cv_file1 "/tmp/blocks.cpp" "4CC0785E17ACF09C657F740775661395" 1
+   .cv_loc 0 1 1 0 # blocks.cpp:1:0
+.seh_proc main
+# %bb.0:# %entry
+   sub rsp, 16
+   .seh_stackalloc 16
+   .seh_endprologue
+   mov dword ptr [rsp + 12], 0
+.Ltmp0:
+   .cv_loc 0 1 2 0 # blocks.cpp:2:0
+   mov dword ptr [rsp + 8], 0
+.Ltmp1:
+   .cv_loc 0 1 3 0 # blocks.cpp:3:0
+   mov dword ptr [rsp + 4], 0
+.LBB0_1:# %for.cond
+# =>This Inner Loop Header: Depth=1
+   cmp dword ptr [rsp + 4], 3
+   jge .LBB0_4
+# %bb.2:# %for.body
+#   in Loop: Header=BB0_1 Depth=1
+.Ltmp2:
+ 

[Lldb-commits] [PATCH] D133618: Adapt LLDB dataformatters for libcxx change D129386

2022-09-09 Thread Adrian Prantl via Phabricator via lldb-commits
aprantl created this revision.
aprantl added reviewers: Michael137, fdeazeve, ldionne, philnik.
Herald added a project: All.
aprantl requested review of this revision.

We at first misattributed this to a CMake configuration change that happened on 
green dragon at the same time, hence the delay.


https://reviews.llvm.org/D133618

Files:
  lldb/include/lldb/DataFormatters/VectorIterator.h
  lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
  lldb/source/Plugins/Language/CPlusPlus/LibCxx.h
  lldb/source/Plugins/Language/CPlusPlus/LibCxxMap.cpp
  lldb/source/Plugins/Language/CPlusPlus/LibCxxSpan.cpp
  lldb/source/Plugins/Language/CPlusPlus/LibCxxVariant.cpp
  lldb/source/Plugins/Language/CPlusPlus/LibCxxVariant.h
  lldb/source/Plugins/Language/CPlusPlus/LibStdcpp.cpp
  
lldb/test/API/commands/expression/import-std-module/deque-basic/TestDequeFromStdModule.py
  
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/iterator/TestDataFormatterLibccIterator.py
  
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/span/TestDataFormatterLibcxxSpan.py
  
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/string_view/TestDataFormatterLibcxxStringView.py
  
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/variant/TestDataFormatterLibcxxVariant.py

Index: lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/variant/TestDataFormatterLibcxxVariant.py
===
--- lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/variant/TestDataFormatterLibcxxVariant.py
+++ lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/variant/TestDataFormatterLibcxxVariant.py
@@ -19,7 +19,6 @@
 @skipIf(compiler="gcc", compiler_version=['<', '5.1'])
 ## std::get is unavailable for std::variant before macOS 10.14
 @skipIf(macos_version=["<", "10.14"])
-@expectedFailureDarwin # FIXME: May need to force system libcxx here.
 def test_with_run_command(self):
 """Test that that file and class static variables display correctly."""
 self.build()
Index: lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/string_view/TestDataFormatterLibcxxStringView.py
===
--- lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/string_view/TestDataFormatterLibcxxStringView.py
+++ lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/string_view/TestDataFormatterLibcxxStringView.py
@@ -21,7 +21,6 @@
 self.line2 = line_number('main.cpp', '// Break here to look at bad string view.' )
 
 @add_test_categories(["libc++"])
-@expectedFailureDarwin # FIXME: May need to force system libcxx here.
 @expectedFailureAll(bugnumber="llvm.org/pr36109", debug_info="gmodules", triple=".*-android")
 # Inline namespace is randomly ignored as Clang due to broken lookup inside
 # the std namespace.
Index: lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/span/TestDataFormatterLibcxxSpan.py
===
--- lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/span/TestDataFormatterLibcxxSpan.py
+++ lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/span/TestDataFormatterLibcxxSpan.py
@@ -43,7 +43,6 @@
 self.expect_var_path(f'{var_name}[4]', type='int', value='12345')
 
 @add_test_categories(['libc++'])
-@expectedFailureDarwin # FIXME: May need to force system libcxx here.
 @skipIf(compiler='clang', compiler_version=['<', '11.0'])
 def test_with_run_command(self):
 """Test that std::span variables are formatted correctly when printed."""
Index: lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/iterator/TestDataFormatterLibccIterator.py
===
--- lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/iterator/TestDataFormatterLibccIterator.py
+++ lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/iterator/TestDataFormatterLibccIterator.py
@@ -19,7 +19,6 @@
 self.line = line_number('main.cpp', '// Set break point at this line.')
 self.namespace = 'std'
 
-@expectedFailureDarwin # FIXME: May need to force system libcxx here.
 @add_test_categories(["libc++"])
 def test_with_run_command(self):
 """Test that libc++ iterators format properly."""
Index: lldb/test/API/commands/expression/import-std-module/deque-basic/TestDequeFromStdModule.py
===
--- lldb/test/API/commands/expression/import-std-module/deque-basic/TestDequeFromStdModule.py
+++ lldb/test/API/commands/expression/import-std-module/deque-basic/TestDequeFromStdModule.py
@@ -10,7 +10,7 @@
 class 

[Lldb-commits] [PATCH] D133534: Complete support of loading a darwin kernel over a live gdb-remote connection given the address of a mach-o fileset

2022-09-09 Thread Jason Molenda via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
jasonmolenda marked an inline comment as done.
Closed by commit rG1a608cfb5ca8: Recognize a platform binary in 
ProcessGDBRemote which determines plugins (authored by jasonmolenda).

Changed prior to commit:
  https://reviews.llvm.org/D133534?vs=459191=459209#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133534

Files:
  lldb/include/lldb/Target/Platform.h
  lldb/include/lldb/Target/Process.h
  lldb/source/Core/DynamicLoader.cpp
  lldb/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp
  lldb/source/Plugins/Platform/MacOSX/CMakeLists.txt
  lldb/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.cpp
  lldb/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.h
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
  lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
  lldb/source/Target/Platform.cpp
  lldb/source/Target/Process.cpp

Index: lldb/source/Target/Process.cpp
===
--- lldb/source/Target/Process.cpp
+++ lldb/source/Target/Process.cpp
@@ -2653,6 +2653,10 @@
   return m_dyld_up.get();
 }
 
+void Process::SetDynamicLoader(DynamicLoaderUP dyld_up) {
+  m_dyld_up = std::move(dyld_up);
+}
+
 DataExtractor Process::GetAuxvData() { return DataExtractor(); }
 
 llvm::Expected Process::SaveCore(llvm::StringRef outfile) {
Index: lldb/source/Target/Platform.cpp
===
--- lldb/source/Target/Platform.cpp
+++ lldb/source/Target/Platform.cpp
@@ -2079,3 +2079,21 @@
   m_platforms.push_back(platform_sp);
   return platform_sp;
 }
+
+bool PlatformList::LoadPlatformBinaryAndSetup(Process *process,
+  lldb::addr_t addr, bool notify) {
+  std::lock_guard guard(m_mutex);
+
+  PlatformCreateInstance create_callback;
+  for (int idx = 0;
+   (create_callback = PluginManager::GetPlatformCreateCallbackAtIndex(idx));
+   ++idx) {
+ArchSpec arch;
+PlatformSP platform_sp = create_callback(true, );
+if (platform_sp) {
+  if (platform_sp->LoadPlatformBinaryAndSetup(process, addr, notify))
+return true;
+}
+  }
+  return false;
+}
Index: lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
===
--- lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -593,8 +593,19 @@
 UUID uuid;
 const bool value_is_slide = false;
 for (addr_t addr : bin_addrs) {
-  const bool force_symbol_search = true;
   const bool notify = true;
+  // First see if this is a special platform
+  // binary that may determine the DynamicLoader and
+  // Platform to be used in this Process/Target in the
+  // process of loading it.
+  if (GetTarget()
+  .GetDebugger()
+  .GetPlatformList()
+  .LoadPlatformBinaryAndSetup(this, addr, notify))
+continue;
+
+  const bool force_symbol_search = true;
+  // Second manually load this binary into the Target.
   DynamicLoader::LoadBinaryWithUUIDAndAddress(
   this, uuid, addr, value_is_slide, force_symbol_search, notify);
 }
Index: lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
===
--- lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
+++ lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
@@ -2206,12 +2206,13 @@
 ++num_keys_decoded;
   }
 } else if (name.equals("binary-addresses")) {
-  addr_t addr;
-  while (!value.empty()) {
-llvm::StringRef addr_str;
-std::tie(addr_str, value) = value.split(',');
-if (!addr_str.getAsInteger(16, addr))
-  m_binary_addresses.push_back(addr);
+  m_binary_addresses.clear();
+  ++num_keys_decoded;
+  for (llvm::StringRef x : llvm::split(value, ',')) {
+addr_t vmaddr;
+x.consume_front("0x");
+if (llvm::to_integer(x, vmaddr, 16))
+  m_binary_addresses.push_back(vmaddr);
   }
 }
   }
Index: lldb/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.h
===
--- lldb/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.h
+++ lldb/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.h
@@ -154,6 +154,9 @@
 const UUID , const ArchSpec ,
 lldb::ModuleSP _module_sp);
 
+  bool LoadPlatformBinaryAndSetup(Process *process, 

[Lldb-commits] [lldb] 1a608cf - Recognize a platform binary in ProcessGDBRemote which determines plugins

2022-09-09 Thread Jason Molenda via lldb-commits

Author: Jason Molenda
Date: 2022-09-09T14:57:08-07:00
New Revision: 1a608cfb5ca81d7b1d8ebd6b21c6be9db59c837a

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

LOG: Recognize a platform binary in ProcessGDBRemote which determines plugins

Complete support of the binary-addresses key in the qProcessInfo packet
in ProcessGDBRemote, for detecting if one of the binaries needs to be
handled by a Platform plugin, and can be used to set the Process'
DynamicLoader plugin and the Target's Platform plugin.

Implement this method in PlatformDarwinKernel to recognize a kernel
fileset at that address, find the actual kernel address in the
fileset, set DynamicLoaderDarwinKernel and PlatformDarwinKernel
in the Process/Target; register the kernel address with the dynamic
loader so it will be loaded later during attach.

This patch only addresses the live debug scenario with a gdb remote
serial protocol connection. I'll handle corefiles in a subsequent
patch that builds on this.

Differential Revision: https://reviews.llvm.org/D133534
rdar://98754861

Added: 


Modified: 
lldb/include/lldb/Target/Platform.h
lldb/include/lldb/Target/Process.h
lldb/source/Core/DynamicLoader.cpp

lldb/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp
lldb/source/Plugins/Platform/MacOSX/CMakeLists.txt
lldb/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.cpp
lldb/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.h
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
lldb/source/Target/Platform.cpp
lldb/source/Target/Process.cpp

Removed: 




diff  --git a/lldb/include/lldb/Target/Platform.h 
b/lldb/include/lldb/Target/Platform.h
index 868f10689bb18..5f8cd467847de 100644
--- a/lldb/include/lldb/Target/Platform.h
+++ b/lldb/include/lldb/Target/Platform.h
@@ -846,6 +846,34 @@ class Platform : public PluginInterface {
 return nullptr;
   }
 
+  /// Detect a binary in memory that will determine which Platform and
+  /// DynamicLoader should be used in this target/process, and update
+  /// the Platform/DynamicLoader.
+  /// The binary will be loaded into the Target, or will be registered with
+  /// the DynamicLoader so that it will be loaded at a later stage.  Returns
+  /// true to indicate that this is a platform binary and has been
+  /// loaded/registered, no further action should be taken by the caller.
+  ///
+  /// \param[in] process
+  /// Process read memory from, a Process must be provided.
+  ///
+  /// \param[in] addr
+  /// Address of a binary in memory.
+  ///
+  /// \param[in] notify
+  /// Whether ModulesDidLoad should be called, if a binary is loaded.
+  /// Caller may prefer to call ModulesDidLoad for multiple binaries
+  /// that were loaded at the same time.
+  ///
+  /// \return
+  /// Returns true if the binary was loaded in the target (or will be
+  /// via a DynamicLoader).  Returns false if the binary was not
+  /// loaded/registered, and the caller must load it into the target.
+  virtual bool LoadPlatformBinaryAndSetup(Process *process, lldb::addr_t addr,
+  bool notify) {
+return false;
+  }
+
   virtual CompilerType GetSiginfoType(const llvm::Triple );
   
   virtual Args GetExtraStartupCommands();
@@ -1026,6 +1054,32 @@ class PlatformList {
 
   lldb::PlatformSP Create(llvm::StringRef name);
 
+  /// Detect a binary in memory that will determine which Platform and
+  /// DynamicLoader should be used in this target/process, and update
+  /// the Platform/DynamicLoader.
+  /// The binary will be loaded into the Target, or will be registered with
+  /// the DynamicLoader so that it will be loaded at a later stage.  Returns
+  /// true to indicate that this is a platform binary and has been
+  /// loaded/registered, no further action should be taken by the caller.
+  ///
+  /// \param[in] process
+  /// Process read memory from, a Process must be provided.
+  ///
+  /// \param[in] addr
+  /// Address of a binary in memory.
+  ///
+  /// \param[in] notify
+  /// Whether ModulesDidLoad should be called, if a binary is loaded.
+  /// Caller may prefer to call ModulesDidLoad for multiple binaries
+  /// that were loaded at the same time.
+  ///
+  /// \return
+  /// Returns true if the binary was loaded in the target (or will be
+  /// via a DynamicLoader).  Returns false if the binary was not
+  /// loaded/registered, and the caller must load it into the target.
+  bool LoadPlatformBinaryAndSetup(Process *process, lldb::addr_t addr,
+  bool notify);
+
 protected:
   typedef std::vector collection;
   mutable 

[Lldb-commits] [PATCH] D133038: Add SBDebugger::GetSetting() public API

2022-09-09 Thread jeffrey tan via Phabricator via lldb-commits
yinghuitan updated this revision to Diff 459208.
yinghuitan added a comment.

Address review comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133038

Files:
  lldb/bindings/interface/SBDebugger.i
  lldb/include/lldb/API/SBDebugger.h
  lldb/include/lldb/Core/UserSettingsController.h
  lldb/include/lldb/Interpreter/OptionValue.h
  lldb/include/lldb/Interpreter/OptionValueArray.h
  lldb/include/lldb/Interpreter/OptionValueBoolean.h
  lldb/include/lldb/Interpreter/OptionValueChar.h
  lldb/include/lldb/Interpreter/OptionValueDictionary.h
  lldb/include/lldb/Interpreter/OptionValueFileSpec.h
  lldb/include/lldb/Interpreter/OptionValueFormat.h
  lldb/include/lldb/Interpreter/OptionValueFormatEntity.h
  lldb/include/lldb/Interpreter/OptionValueLanguage.h
  lldb/include/lldb/Interpreter/OptionValuePathMappings.h
  lldb/include/lldb/Interpreter/OptionValueProperties.h
  lldb/include/lldb/Interpreter/OptionValueRegex.h
  lldb/include/lldb/Interpreter/OptionValueSInt64.h
  lldb/include/lldb/Interpreter/OptionValueString.h
  lldb/include/lldb/Interpreter/OptionValueUInt64.h
  lldb/include/lldb/Interpreter/OptionValueUUID.h
  lldb/include/lldb/Target/PathMappingList.h
  lldb/source/API/SBDebugger.cpp
  lldb/source/Core/UserSettingsController.cpp
  lldb/source/Interpreter/OptionValueArray.cpp
  lldb/source/Interpreter/OptionValueDictionary.cpp
  lldb/source/Interpreter/OptionValueFormat.cpp
  lldb/source/Interpreter/OptionValueFormatEntity.cpp
  lldb/source/Interpreter/OptionValueLanguage.cpp
  lldb/source/Interpreter/OptionValuePathMappings.cpp
  lldb/source/Interpreter/OptionValueProperties.cpp
  lldb/source/Target/PathMappingList.cpp
  lldb/test/API/commands/settings/TestSettings.py
  lldb/test/API/functionalities/source-map/TestTargetSourceMap.py

Index: lldb/test/API/functionalities/source-map/TestTargetSourceMap.py
===
--- lldb/test/API/functionalities/source-map/TestTargetSourceMap.py
+++ lldb/test/API/functionalities/source-map/TestTargetSourceMap.py
@@ -1,11 +1,45 @@
 import lldb
 from lldbsuite.test.lldbtest import *
 from lldbsuite.test.decorators import *
+import json
 import os
 
 
 class TestTargetSourceMap(TestBase):
 
+@no_debug_info_test
+def test_source_map_via_setting_api(self):
+"""
+Test that ensures SBDebugger::GetSetting("target.source-map") API
+can correctly fetch source mapping entries.
+"""
+# Set the target soure map to map "./" to the current test directory
+src_dir = self.getSourceDir()
+
+source_map_setting_path = "target.source-map"
+initial_source_map = self.dbg.GetSetting(source_map_setting_path)
+self.assertEquals(initial_source_map.GetSize(), 0,
+"Initial source map should be empty")
+
+src_dir = self.getSourceDir()
+self.runCmd('settings set %s . "%s"' % (source_map_setting_path, src_dir))
+
+source_map = self.dbg.GetSetting(source_map_setting_path)
+self.assertEquals(source_map.GetSize(), 1,
+"source map should be have one appended entry")
+
+stream = lldb.SBStream()
+source_map.GetAsJSON(stream)
+serialized_source_map = json.loads(stream.GetData())
+
+self.assertEquals(len(serialized_source_map[0]), 2,
+"source map entry should have two parts")
+self.assertEquals(serialized_source_map[0][0], ".",
+"source map entry's first part does not match")
+self.assertEquals(serialized_source_map[0][1], src_dir,
+"source map entry's second part does not match")
+
+
 @no_debug_info_test
 def test_source_map(self):
 """Test target.source-map' functionality."""
Index: lldb/test/API/commands/settings/TestSettings.py
===
--- lldb/test/API/commands/settings/TestSettings.py
+++ lldb/test/API/commands/settings/TestSettings.py
@@ -3,7 +3,7 @@
 """
 
 
-
+import json
 import os
 import re
 import lldb
@@ -274,7 +274,7 @@
 self.assertEqual(launch_info.GetArgumentAtIndex(0), "A")
 self.assertEqual(launch_info.GetArgumentAtIndex(1), "B")
 self.assertEqual(launch_info.GetArgumentAtIndex(2), "C")
-
+
 self.expect(
 'target show-launch-environment',
 substrs=["MY_ENV_VAR=YES"])
@@ -787,3 +787,59 @@
 
 # A known option should fail if its argument is invalid.
 self.expect("settings set auto-confirm bogus", error=True)
+
+def get_setting_json(self, setting_path = None):
+settings_data = self.dbg.GetSetting(setting_path)
+stream = lldb.SBStream()
+settings_data.GetAsJSON(stream)
+return json.loads(stream.GetData())
+
+def verify_setting_value_json(self, setting_path, setting_value):
+self.runCmd("settings set %s %s" % 

[Lldb-commits] [PATCH] D133534: Complete support of loading a darwin kernel over a live gdb-remote connection given the address of a mach-o fileset

2022-09-09 Thread Jason Molenda via Phabricator via lldb-commits
jasonmolenda marked 2 inline comments as done.
jasonmolenda added inline comments.



Comment at: lldb/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.cpp:924
+   addr_t input_addr) {
+  Status error;
+  WritableDataBufferSP header_data(new DataBufferHeap(512, 0));

JDevlieghere wrote:
> Looks like we're never checking this status below. Is there any chance that 
> `ReadMemory` succeeds but the status is set to an error? If not, should we 
> add an assert? 
Good point.  `Process::ReadMemoryFromInferior` returns the number of bytes 
read, and a Status object.  So if were were only able to read part of the mach 
header object, this would not return an error condition.  (and we'd have 
uninitialized fields and could try to read too many load commands or something)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133534

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


[Lldb-commits] [PATCH] D133534: Complete support of loading a darwin kernel over a live gdb-remote connection given the address of a mach-o fileset

2022-09-09 Thread Jonas Devlieghere via Phabricator via lldb-commits
JDevlieghere accepted this revision.
JDevlieghere added a comment.
This revision is now accepted and ready to land.

A small comment but otherwise this LGTM.




Comment at: lldb/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.cpp:924
+   addr_t input_addr) {
+  Status error;
+  WritableDataBufferSP header_data(new DataBufferHeap(512, 0));

Looks like we're never checking this status below. Is there any chance that 
`ReadMemory` succeeds but the status is set to an error? If not, should we add 
an assert? 



Comment at: lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp:597-601
+  if (GetTarget()
+  .GetDebugger()
+  .GetPlatformList()
+  .LoadPlatformBinaryAndSetup(this, addr, notify))
+continue;

This is the crux of the patch. I think it would be helpful here to explain 
what's going on, i.e. that we give the platform a chance first, before 
deferring to the DynamicLoader.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133534

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


[Lldb-commits] [PATCH] D133393: [test] Use either `127.0.0.1` or `[::1]` to run in ipv6-only environments.

2022-09-09 Thread Jordan Rupprecht via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG1b988ff092a0: [test] Use either `127.0.0.1` or `[::1]` to 
run in ipv6-only environments. (authored by rupprecht).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133393

Files:
  lldb/unittests/TestingSupport/Host/SocketTestUtilities.cpp
  lldb/unittests/TestingSupport/Host/SocketTestUtilities.h
  lldb/unittests/tools/lldb-server/tests/CMakeLists.txt
  lldb/unittests/tools/lldb-server/tests/TestClient.cpp


Index: lldb/unittests/tools/lldb-server/tests/TestClient.cpp
===
--- lldb/unittests/tools/lldb-server/tests/TestClient.cpp
+++ lldb/unittests/tools/lldb-server/tests/TestClient.cpp
@@ -7,6 +7,7 @@
 
//===--===//
 
 #include "TestClient.h"
+#include "TestingSupport/Host/SocketTestUtilities.h"
 #include "lldb/Host/HostInfo.h"
 #include "lldb/Host/common/TCPSocket.h"
 #include "lldb/Host/posix/ConnectionFileDescriptorPosix.h"
@@ -77,14 +78,20 @@
   args.AppendArgument("--log-flags=0x80");
   }
 
+  auto LocalhostIPOrErr = GetLocalhostIP();
+  if (!LocalhostIPOrErr)
+return LocalhostIPOrErr.takeError();
+  const std::string  = *LocalhostIPOrErr;
+
   Status status;
   TCPSocket listen_socket(true, false);
-  status = listen_socket.Listen("127.0.0.1:0", 5);
+  status = listen_socket.Listen(LocalhostIP + ":0", 5);
   if (status.Fail())
 return status.ToError();
 
   args.AppendArgument(
-  ("127.0.0.1:" + Twine(listen_socket.GetLocalPortNumber())).str());
+  formatv("{0}:{1}", LocalhostIP, listen_socket.GetLocalPortNumber())
+  .str());
 
   for (StringRef arg : ServerArgs)
 args.AppendArgument(arg);
Index: lldb/unittests/tools/lldb-server/tests/CMakeLists.txt
===
--- lldb/unittests/tools/lldb-server/tests/CMakeLists.txt
+++ lldb/unittests/tools/lldb-server/tests/CMakeLists.txt
@@ -7,6 +7,7 @@
   LINK_LIBS
 lldbHost
 lldbCore
+lldbHostHelpers
 lldbInterpreter
 lldbTarget
 lldbPluginPlatformLinux
Index: lldb/unittests/TestingSupport/Host/SocketTestUtilities.h
===
--- lldb/unittests/TestingSupport/Host/SocketTestUtilities.h
+++ lldb/unittests/TestingSupport/Host/SocketTestUtilities.h
@@ -42,6 +42,13 @@
 
 bool HostSupportsIPv6();
 bool HostSupportsIPv4();
+
+/// Return an IP for localhost based on host support.
+///
+/// This will return either "127.0.0.1" if IPv4 is detected, or "[::1]" if IPv6
+/// is detected. If neither are detected, return an error.
+llvm::Expected GetLocalhostIP();
+
 } // namespace lldb_private
 
 #endif
Index: lldb/unittests/TestingSupport/Host/SocketTestUtilities.cpp
===
--- lldb/unittests/TestingSupport/Host/SocketTestUtilities.cpp
+++ lldb/unittests/TestingSupport/Host/SocketTestUtilities.cpp
@@ -126,3 +126,13 @@
 bool lldb_private::HostSupportsIPv6() {
   return CheckIPSupport("IPv6", "[::1]:0");
 }
+
+llvm::Expected lldb_private::GetLocalhostIP() {
+  if (HostSupportsIPv4())
+return "127.0.0.1";
+  if (HostSupportsIPv6())
+return "[::1]";
+  return llvm::make_error(
+  "Neither IPv4 nor IPv6 appear to be supported",
+  llvm::inconvertibleErrorCode());
+}


Index: lldb/unittests/tools/lldb-server/tests/TestClient.cpp
===
--- lldb/unittests/tools/lldb-server/tests/TestClient.cpp
+++ lldb/unittests/tools/lldb-server/tests/TestClient.cpp
@@ -7,6 +7,7 @@
 //===--===//
 
 #include "TestClient.h"
+#include "TestingSupport/Host/SocketTestUtilities.h"
 #include "lldb/Host/HostInfo.h"
 #include "lldb/Host/common/TCPSocket.h"
 #include "lldb/Host/posix/ConnectionFileDescriptorPosix.h"
@@ -77,14 +78,20 @@
   args.AppendArgument("--log-flags=0x80");
   }
 
+  auto LocalhostIPOrErr = GetLocalhostIP();
+  if (!LocalhostIPOrErr)
+return LocalhostIPOrErr.takeError();
+  const std::string  = *LocalhostIPOrErr;
+
   Status status;
   TCPSocket listen_socket(true, false);
-  status = listen_socket.Listen("127.0.0.1:0", 5);
+  status = listen_socket.Listen(LocalhostIP + ":0", 5);
   if (status.Fail())
 return status.ToError();
 
   args.AppendArgument(
-  ("127.0.0.1:" + Twine(listen_socket.GetLocalPortNumber())).str());
+  formatv("{0}:{1}", LocalhostIP, listen_socket.GetLocalPortNumber())
+  .str());
 
   for (StringRef arg : ServerArgs)
 args.AppendArgument(arg);
Index: lldb/unittests/tools/lldb-server/tests/CMakeLists.txt
===
--- lldb/unittests/tools/lldb-server/tests/CMakeLists.txt
+++ 

[Lldb-commits] [lldb] 1b988ff - [test] Use either `127.0.0.1` or `[::1]` to run in ipv6-only environments.

2022-09-09 Thread Jordan Rupprecht via lldb-commits

Author: Jordan Rupprecht
Date: 2022-09-09T14:00:35-07:00
New Revision: 1b988ff092a0a713f0bb4712bfe6cb5ba85b725c

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

LOG: [test] Use either `127.0.0.1` or `[::1]` to run in ipv6-only environments.

Test for both IPv4 and IPv6 support to determine if either `127.0.0.1` or 
`[::1]` are appropriate IP addresses to attempt to connect to. In an IPv6-only 
environment, `127.0.0.1` is not available.

Using `localhost` is problematic because we might not be able to get the same 
port on each IP flavor, and later try to connect to the wrong thing.

Reviewed By: labath

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

Added: 


Modified: 
lldb/unittests/TestingSupport/Host/SocketTestUtilities.cpp
lldb/unittests/TestingSupport/Host/SocketTestUtilities.h
lldb/unittests/tools/lldb-server/tests/CMakeLists.txt
lldb/unittests/tools/lldb-server/tests/TestClient.cpp

Removed: 




diff  --git a/lldb/unittests/TestingSupport/Host/SocketTestUtilities.cpp 
b/lldb/unittests/TestingSupport/Host/SocketTestUtilities.cpp
index 4ab65aa6208c8..2455a4f6f5d49 100644
--- a/lldb/unittests/TestingSupport/Host/SocketTestUtilities.cpp
+++ b/lldb/unittests/TestingSupport/Host/SocketTestUtilities.cpp
@@ -126,3 +126,13 @@ bool lldb_private::HostSupportsIPv4() {
 bool lldb_private::HostSupportsIPv6() {
   return CheckIPSupport("IPv6", "[::1]:0");
 }
+
+llvm::Expected lldb_private::GetLocalhostIP() {
+  if (HostSupportsIPv4())
+return "127.0.0.1";
+  if (HostSupportsIPv6())
+return "[::1]";
+  return llvm::make_error(
+  "Neither IPv4 nor IPv6 appear to be supported",
+  llvm::inconvertibleErrorCode());
+}

diff  --git a/lldb/unittests/TestingSupport/Host/SocketTestUtilities.h 
b/lldb/unittests/TestingSupport/Host/SocketTestUtilities.h
index 2130cc33dd5b0..efd17428ceefb 100644
--- a/lldb/unittests/TestingSupport/Host/SocketTestUtilities.h
+++ b/lldb/unittests/TestingSupport/Host/SocketTestUtilities.h
@@ -42,6 +42,13 @@ void CreateDomainConnectedSockets(llvm::StringRef path,
 
 bool HostSupportsIPv6();
 bool HostSupportsIPv4();
+
+/// Return an IP for localhost based on host support.
+///
+/// This will return either "127.0.0.1" if IPv4 is detected, or "[::1]" if IPv6
+/// is detected. If neither are detected, return an error.
+llvm::Expected GetLocalhostIP();
+
 } // namespace lldb_private
 
 #endif

diff  --git a/lldb/unittests/tools/lldb-server/tests/CMakeLists.txt 
b/lldb/unittests/tools/lldb-server/tests/CMakeLists.txt
index cb9e138fbe61b..1d5f0c789a364 100644
--- a/lldb/unittests/tools/lldb-server/tests/CMakeLists.txt
+++ b/lldb/unittests/tools/lldb-server/tests/CMakeLists.txt
@@ -7,6 +7,7 @@ add_lldb_unittest(LLDBServerTests
   LINK_LIBS
 lldbHost
 lldbCore
+lldbHostHelpers
 lldbInterpreter
 lldbTarget
 lldbPluginPlatformLinux

diff  --git a/lldb/unittests/tools/lldb-server/tests/TestClient.cpp 
b/lldb/unittests/tools/lldb-server/tests/TestClient.cpp
index 46ca10a03f69a..f762fbc1c9c24 100644
--- a/lldb/unittests/tools/lldb-server/tests/TestClient.cpp
+++ b/lldb/unittests/tools/lldb-server/tests/TestClient.cpp
@@ -7,6 +7,7 @@
 
//===--===//
 
 #include "TestClient.h"
+#include "TestingSupport/Host/SocketTestUtilities.h"
 #include "lldb/Host/HostInfo.h"
 #include "lldb/Host/common/TCPSocket.h"
 #include "lldb/Host/posix/ConnectionFileDescriptorPosix.h"
@@ -77,14 +78,20 @@ Expected> 
TestClient::launchCustom(StringRef Log, Ar
   args.AppendArgument("--log-flags=0x80");
   }
 
+  auto LocalhostIPOrErr = GetLocalhostIP();
+  if (!LocalhostIPOrErr)
+return LocalhostIPOrErr.takeError();
+  const std::string  = *LocalhostIPOrErr;
+
   Status status;
   TCPSocket listen_socket(true, false);
-  status = listen_socket.Listen("127.0.0.1:0", 5);
+  status = listen_socket.Listen(LocalhostIP + ":0", 5);
   if (status.Fail())
 return status.ToError();
 
   args.AppendArgument(
-  ("127.0.0.1:" + Twine(listen_socket.GetLocalPortNumber())).str());
+  formatv("{0}:{1}", LocalhostIP, listen_socket.GetLocalPortNumber())
+  .str());
 
   for (StringRef arg : ServerArgs)
 args.AppendArgument(arg);



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


[Lldb-commits] [PATCH] D133038: Add SBDebugger::GetSetting() public API

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

Just a comment fix and allow the "char" option value to be saved as zero and 
this will be good to go.




Comment at: lldb/include/lldb/API/SBDebugger.h:120-121
+  /// Client can specify empty string or null to get all settings.
+  /// Any setting path that is accepted by "settings show" can be accepted
+  /// here.
+  ///

This comment is no longer true right? Any setting args that are accepted by 
settings show not longer is true right? It is just a single setting value you 
can either specify or not right?



Comment at: lldb/include/lldb/Interpreter/OptionValueChar.h:34-37
+if (m_current_value != '\0')
+  return m_current_value;
+else
+  return "(null)";





Comment at: lldb/include/lldb/Interpreter/OptionValueChar.h:34-37
+if (m_current_value != '\0')
+  return m_current_value;
+else
+  return "(null)";

yinghuitan wrote:
> clayborg wrote:
> > Since this is actually a character, it should store what ever the character 
> > value is. So if the character is zero, it should store zero, not a string 
> > "(null)"
> I am not sure about this. This mimics what `OptionValueChar::DumpValue()` 
> does. Do we want to keep consistence here?
if we want to set/restore this value, it should have the correct value. We 
aren't trying to mimic dump value here. So we should allow it to be set to zero.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133038

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


[Lldb-commits] [PATCH] D114288: [NFC] Refactor symbol table parsing.

2022-09-09 Thread Greg Clayton via Phabricator via lldb-commits
clayborg added a comment.

In D114288#3781084 , @kastiglione 
wrote:

> @clayborg friendly ping

Do you have an repro case that will show this issue? I would need to debug it. 
The main issue is ObjectFileJIT::ParseSymtab() is doing global lookups when it 
is creating it's own symbol table, which causes the deadlock


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114288

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


[Lldb-commits] [PATCH] D133534: Complete support of loading a darwin kernel over a live gdb-remote connection given the address of a mach-o fileset

2022-09-09 Thread Jason Molenda via Phabricator via lldb-commits
jasonmolenda updated this revision to Diff 459191.
jasonmolenda marked 5 inline comments as done.
jasonmolenda added a comment.

Update patch to incorporate Jonas & Pavel's feedback.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133534

Files:
  lldb/include/lldb/Target/Platform.h
  lldb/include/lldb/Target/Process.h
  lldb/source/Core/DynamicLoader.cpp
  lldb/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp
  lldb/source/Plugins/Platform/MacOSX/CMakeLists.txt
  lldb/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.cpp
  lldb/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.h
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
  lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
  lldb/source/Target/Platform.cpp
  lldb/source/Target/Process.cpp

Index: lldb/source/Target/Process.cpp
===
--- lldb/source/Target/Process.cpp
+++ lldb/source/Target/Process.cpp
@@ -2653,6 +2653,10 @@
   return m_dyld_up.get();
 }
 
+void Process::SetDynamicLoader(DynamicLoaderUP dyld_up) {
+  m_dyld_up = std::move(dyld_up);
+}
+
 DataExtractor Process::GetAuxvData() { return DataExtractor(); }
 
 llvm::Expected Process::SaveCore(llvm::StringRef outfile) {
Index: lldb/source/Target/Platform.cpp
===
--- lldb/source/Target/Platform.cpp
+++ lldb/source/Target/Platform.cpp
@@ -2079,3 +2079,21 @@
   m_platforms.push_back(platform_sp);
   return platform_sp;
 }
+
+bool PlatformList::LoadPlatformBinaryAndSetup(Process *process,
+  lldb::addr_t addr, bool notify) {
+  std::lock_guard guard(m_mutex);
+
+  PlatformCreateInstance create_callback;
+  for (int idx = 0;
+   (create_callback = PluginManager::GetPlatformCreateCallbackAtIndex(idx));
+   ++idx) {
+ArchSpec arch;
+PlatformSP platform_sp = create_callback(true, );
+if (platform_sp) {
+  if (platform_sp->LoadPlatformBinaryAndSetup(process, addr, notify))
+return true;
+}
+  }
+  return false;
+}
Index: lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
===
--- lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -593,8 +593,14 @@
 UUID uuid;
 const bool value_is_slide = false;
 for (addr_t addr : bin_addrs) {
-  const bool force_symbol_search = true;
   const bool notify = true;
+  if (GetTarget()
+  .GetDebugger()
+  .GetPlatformList()
+  .LoadPlatformBinaryAndSetup(this, addr, notify))
+continue;
+
+  const bool force_symbol_search = true;
   DynamicLoader::LoadBinaryWithUUIDAndAddress(
   this, uuid, addr, value_is_slide, force_symbol_search, notify);
 }
Index: lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
===
--- lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
+++ lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
@@ -2206,12 +2206,13 @@
 ++num_keys_decoded;
   }
 } else if (name.equals("binary-addresses")) {
-  addr_t addr;
-  while (!value.empty()) {
-llvm::StringRef addr_str;
-std::tie(addr_str, value) = value.split(',');
-if (!addr_str.getAsInteger(16, addr))
-  m_binary_addresses.push_back(addr);
+  m_binary_addresses.clear();
+  ++num_keys_decoded;
+  for (llvm::StringRef x : llvm::split(value, ',')) {
+addr_t vmaddr;
+x.consume_front("0x");
+if (llvm::to_integer(x, vmaddr, 16))
+  m_binary_addresses.push_back(vmaddr);
   }
 }
   }
Index: lldb/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.h
===
--- lldb/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.h
+++ lldb/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.h
@@ -154,6 +154,9 @@
 const UUID , const ArchSpec ,
 lldb::ModuleSP _module_sp);
 
+  bool LoadPlatformBinaryAndSetup(Process *process, lldb::addr_t addr,
+  bool notify) override;
+
   // Most of the ivars are assembled under FileSystem::EnumerateDirectory calls
   // where the function being called for each file/directory must be static.
   // We'll pass a this pointer as a baton and access the ivars directly.
Index: lldb/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.cpp

[Lldb-commits] [PATCH] D133534: Complete support of loading a darwin kernel over a live gdb-remote connection given the address of a mach-o fileset

2022-09-09 Thread Jason Molenda via Phabricator via lldb-commits
jasonmolenda marked 8 inline comments as done.
jasonmolenda added inline comments.



Comment at: lldb/include/lldb/Target/Platform.h:870-874
+  virtual bool LoadSpecialBinaryAndSetDynamicLoader(Process *process,
+lldb::addr_t addr,
+bool notify) {
+return false;
+  }

JDevlieghere wrote:
> What makes the binary special? The comment above doesn't say. Can we give 
> this a more descriptive name or omit the "Special" part?
I'm still not happy with this method name, I agree this name isn't clear.  I'll 
try to think of something better.



Comment at: 
lldb/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp:133
 
+static bool module_is_a_kernel(Module *module) {
+  if (!module)

JDevlieghere wrote:
> This seems needless verbose: `is_kernel` conveys the same information. 
Good point, will do.



Comment at: 
lldb/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp:668-669
   bool is_kernel = false;
-  if (memory_module_sp->GetObjectFile()) {
-if (memory_module_sp->GetObjectFile()->GetType() ==
-ObjectFile::eTypeExecutable &&
-memory_module_sp->GetObjectFile()->GetStrata() ==
-ObjectFile::eStrataKernel) {
-  is_kernel = true;
-} else if (memory_module_sp->GetObjectFile()->GetType() ==
-   ObjectFile::eTypeSharedLibrary) {
-  is_kernel = false;
-}
-  }
+  if (module_is_a_kernel(memory_module_sp.get()))
+is_kernel = true;
 

JDevlieghere wrote:
> `is_kernel = is_kernel(memory_module_sp.get())`
ah yes, it made more sense previously when the conditional expression was 
larger.



Comment at: 
lldb/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp:747-752
+ModuleList module_list = target.GetImages();
+std::lock_guard guard(module_list.GetMutex());
+const size_t num_modules = module_list.GetSize();
+ModuleList incorrect_kernels;
+for (size_t i = 0; i < num_modules; i++) {
+  ModuleSP module_sp = module_list.GetModuleAtIndex(i);

JDevlieghere wrote:
> The `ModuleList` has a `Modules()` function that returns a  locking iterator. 
> You can rewrite this as:
> 
> ```
> for(ModuleSP module : target.GetImages().Modules()) {
>   ...
> }
> ```
Ach, thanks, missed that.



Comment at: lldb/unittests/Interpreter/CMakeLists.txt:17-18
   lldbInterpreter
+  lldbPluginDynamicLoaderDarwinKernel
+  lldbPluginObjectContainerMachOFileset
   lldbPluginPlatformMacOSX

labath wrote:
> These dependencies should be added to the PlatformDarwinKernel 
> CMakeLists.txt, not to the every file that depends on it.
Thanks Pavel, I should have thought of that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133534

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


[Lldb-commits] [PATCH] D114288: [NFC] Refactor symbol table parsing.

2022-09-09 Thread Dave Lee via Phabricator via lldb-commits
kastiglione added a comment.
Herald added a reviewer: ributzka.

@clayborg friendly ping


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114288

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


[Lldb-commits] [PATCH] D133601: [LLDB][NativePDB] ResolveSymbolContext should return the innermost block

2022-09-09 Thread Zequan Wu via Phabricator via lldb-commits
zequanwu created this revision.
zequanwu added reviewers: labath, rnk.
Herald added a project: All.
zequanwu requested review of this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

Before, it returns the outermost blocks if nested blocks have the same
address range. That casuses lldb unable to find variables that are inside
inner blocks.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D133601

Files:
  lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
  lldb/test/Shell/SymbolFile/NativePDB/nested-blocks-same-address.s

Index: lldb/test/Shell/SymbolFile/NativePDB/nested-blocks-same-address.s
===
--- /dev/null
+++ lldb/test/Shell/SymbolFile/NativePDB/nested-blocks-same-address.s
@@ -0,0 +1,473 @@
+# clang-format off
+# REQUIRES: lld, x86
+
+# Test when nested S_BLOCK32 have same address range, ResolveSymbolContext should return the innnermost block.
+# RUN: llvm-mc -triple=x86_64-windows-msvc --filetype=obj %s > %t.obj
+# RUN: lld-link /debug:full /nodefaultlib /entry:main %t.obj /out:%t.exe /base:0x14000
+# RUN: env LLDB_USE_NATIVE_PDB_READER=1 %lldb -f %t.exe -o "image lookup -a 0x14000103c -v" -o "exit" | FileCheck %s
+
+# This file is compiled from following source file:
+# $ clang-cl /Z7 /GS- /c /O2 test.cpp /Fatest.s
+# __attribute__((optnone)) bool func(const char* cp, volatile char p[]) {
+#   return false;
+# }
+#
+# int main() {
+#   const char* const kMfDLLs[] = {"a"};
+#   asm("nop");
+#   for (const char* kMfDLL : kMfDLLs) {
+# volatile char path[10] = {0};
+# if (func(kMfDLL, path))
+#   break;
+#   }
+#   return 0;
+# }
+
+# CHECK:   Function: id = {{.*}}, name = "main", range = [0x000140001020-0x00014000104d)
+# CHECK-NEXT:  FuncType: id = {{.*}}, byte-size = 0, compiler_type = "int (void)"
+# CHECK-NEXT:Blocks: id = {{.*}}, range = [0x140001020-0x14000104d)
+# CHECK-NEXT:id = {{.*}}, range = [0x140001025-0x140001046)
+# CHECK-NEXT:id = {{.*}}, range = [0x140001025-0x140001046)
+# CHECK-NEXT:id = {{.*}}, range = [0x140001025-0x140001046)
+# CHECK-NEXT: LineEntry: [0x000140001035-0x000140001046): /tmp/test.cpp:10
+# CHECK-NEXT:  Variable: id = {{.*}}, name = "path", type = "volatile char[10]", valid ranges = , location = [0x000140001025, 0x000140001046) -> DW_OP_breg7 RSP+40, decl =
+# CHECK-NEXT:  Variable: id = {{.*}}, name = "kMfDLL", type = "const char *", valid ranges = , location = [0x00014000103c, 0x000140001046) -> DW_OP_reg2 RCX, decl =
+# CHECK-NEXT:  Variable: id = {{.*}}, name = "kMfDLLs", type = "const char *const[1]", valid ranges = , location = [0x00014000103c, 0x000140001046) -> DW_OP_reg2 RCX, decl =
+
+
+	.text
+	.def	@feat.00;
+	.scl	3;
+	.type	0;
+	.endef
+	.globl	@feat.00
+.set @feat.00, 0
+	.intel_syntax noprefix
+	.file	"test.cpp"
+	.def	"?func@@YA_NPEBDQECD@Z";
+	.scl	2;
+	.type	32;
+	.endef
+	.section	.text,"xr",one_only,"?func@@YA_NPEBDQECD@Z"
+	.globl	"?func@@YA_NPEBDQECD@Z" # -- Begin function ?func@@YA_NPEBDQECD@Z
+	.p2align	4, 0x90
+"?func@@YA_NPEBDQECD@Z":# @"?func@@YA_NPEBDQECD@Z"
+.Lfunc_begin0:
+	.cv_func_id 0
+	.cv_file	1 "/tmp/test.cpp" "8CDAA03EE93954606427F9B409CE7638" 1
+	.cv_loc	0 1 1 0 # test.cpp:1:0
+.seh_proc "?func@@YA_NPEBDQECD@Z"
+# %bb.0:# %entry
+	sub	rsp, 16
+	.seh_stackalloc 16
+	.seh_endprologue
+	mov	qword ptr [rsp + 8], rdx
+	mov	qword ptr [rsp], rcx
+.Ltmp0:
+	.cv_loc	0 1 2 0 # test.cpp:2:0
+	xor	eax, eax
+	and	al, 1
+	movzx	eax, al
+	add	rsp, 16
+	ret
+.Ltmp1:
+.Lfunc_end0:
+	.seh_endproc
+# -- End function
+	.def	main;
+	.scl	2;
+	.type	32;
+	.endef
+	.section	.text,"xr",one_only,main
+	.globl	main# -- Begin function main
+	.p2align	4, 0x90
+main:   # @main
+.Lfunc_begin1:
+	.cv_func_id 1
+	.cv_loc	1 1 5 0 # test.cpp:5:0
+.seh_proc main
+# %bb.0:# %entry
+	sub	rsp, 56
+	.seh_stackalloc 56
+	.seh_endprologue
+.Ltmp2:
+	.cv_loc	1 1 7 0 # test.cpp:7:0
+	#APP
+	nop
+	#NO_APP
+.Ltmp3:
+	#DEBUG_VALUE: __range1 <- undef
+	#DEBUG_VALUE: __begin1 <- undef
+	#DEBUG_VALUE: __end1 <- [DW_OP_plus_uconst 8, DW_OP_stack_value] undef
+	.cv_loc	1 1 9 0 # test.cpp:9:0
+	mov	word ptr [rsp + 48], 0
+	mov	qword ptr [rsp + 40], 0
+	.cv_loc	1 1 10 0# test.cpp:10:0
+	lea	rcx, [rip + "??_C@_01MCMALHOG@a?$AA@"]
+.Ltmp4:
+	#DEBUG_VALUE: main:kMfDLLs <- $rcx
+	#DEBUG_VALUE: kMfDLL <- $rcx
+	lea	rdx, [rsp + 40]
+	call	"?func@@YA_NPEBDQECD@Z"
+.Ltmp5:
+	#DEBUG_VALUE: __begin1 <- [DW_OP_LLVM_arg 0, DW_OP_LLVM_arg 1, DW_OP_constu 8, DW_OP_mul, DW_OP_plus, DW_OP_stack_value] undef, undef
+	.cv_loc	1 1 14 0

[Lldb-commits] [PATCH] D133446: [LLDB][NativePDB] Global ctor and dtor should be global decls.

2022-09-09 Thread Zequan Wu via Phabricator via lldb-commits
zequanwu added a comment.

In D133446#3779600 , @labath wrote:

> I believe that this fixes the crash, but the names of generated functions 
> still look fairly weird. Could we create them using their mangled name 
> instead? That way, someone might actually call them, if he was so inclined.

It looks like they don't have mangled name stored in pdb.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133446

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


[Lldb-commits] [PATCH] D133446: [LLDB][NativePDB] Global ctor and dtor should be global decls.

2022-09-09 Thread Zequan Wu via Phabricator via lldb-commits
zequanwu updated this revision to Diff 459145.
zequanwu added a comment.

Update test case after moving the check into `CreateDeclInfoForUndecoratedName`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133446

Files:
  lldb/source/Plugins/SymbolFile/NativePDB/PdbAstBuilder.cpp
  lldb/test/Shell/SymbolFile/NativePDB/global-ctor-dtor.cpp


Index: lldb/test/Shell/SymbolFile/NativePDB/global-ctor-dtor.cpp
===
--- /dev/null
+++ lldb/test/Shell/SymbolFile/NativePDB/global-ctor-dtor.cpp
@@ -0,0 +1,30 @@
+// clang-format off
+// REQUIRES: lld, x86
+
+// Global ctor and dtor should be globals decls.
+// RUN: %clang_cl --target=x86_64-windows-msvc -Od -Z7 -GS- -fno-addrsig -c 
/Fo%t.obj -- %s
+// RUN: lld-link -debug:full -nodefaultlib -entry:main %t.obj -out:%t.exe 
-pdb:%t.pdb -force
+// RUN: env LLDB_USE_NATIVE_PDB_READER=1 lldb-test symbols --dump-ast %t.exe | 
FileCheck %s
+
+struct A {
+  ~A() {};
+};
+struct B {
+  static A glob;
+};
+
+A B::glob = A();
+int main() {
+  return 0;
+}
+
+// CHECK:  static void B::`dynamic initializer for 'glob'();
+// CHECK-NEXT: static void B::`dynamic atexit destructor for 'glob'();
+// CHECK-NEXT: int main();
+// CHECK-NEXT: static void _GLOBAL__sub_I_global_ctor_dtor.cpp();
+// CHECK-NEXT: struct A {
+// CHECK-NEXT: ~A();
+// CHECK-NEXT: };
+// CHECK-NEXT: struct B {
+// CHECK-NEXT: static A glob;
+// CHECK-NEXT: };
Index: lldb/source/Plugins/SymbolFile/NativePDB/PdbAstBuilder.cpp
===
--- lldb/source/Plugins/SymbolFile/NativePDB/PdbAstBuilder.cpp
+++ lldb/source/Plugins/SymbolFile/NativePDB/PdbAstBuilder.cpp
@@ -534,11 +534,15 @@
 
 std::pair
 PdbAstBuilder::CreateDeclInfoForUndecoratedName(llvm::StringRef name) {
+  clang::DeclContext *context =
+  FromCompilerDeclContext(GetTranslationUnitDecl());
+  // Global ctor and dtor are global decls.
+  if (name.contains("dynamic initializer for") ||
+  name.contains("dynamic atexit destructor for"))
+return {context, std::string(name)};
   MSVCUndecoratedNameParser parser(name);
   llvm::ArrayRef specs = parser.GetSpecifiers();
 
-  auto context = FromCompilerDeclContext(GetTranslationUnitDecl());
-
   llvm::StringRef uname = specs.back().GetBaseName();
   specs = specs.drop_back();
   if (specs.empty())
@@ -1226,7 +1230,6 @@
   llvm::StringRef proc_name = proc.Name;
   proc_name.consume_front(context_name);
   proc_name.consume_front("::");
-
   clang::FunctionDecl *function_decl =
   CreateFunctionDecl(func_id, proc_name, proc.FunctionType, func_ct,
  func_type->getNumParams(), storage, false, parent);


Index: lldb/test/Shell/SymbolFile/NativePDB/global-ctor-dtor.cpp
===
--- /dev/null
+++ lldb/test/Shell/SymbolFile/NativePDB/global-ctor-dtor.cpp
@@ -0,0 +1,30 @@
+// clang-format off
+// REQUIRES: lld, x86
+
+// Global ctor and dtor should be globals decls.
+// RUN: %clang_cl --target=x86_64-windows-msvc -Od -Z7 -GS- -fno-addrsig -c /Fo%t.obj -- %s
+// RUN: lld-link -debug:full -nodefaultlib -entry:main %t.obj -out:%t.exe -pdb:%t.pdb -force
+// RUN: env LLDB_USE_NATIVE_PDB_READER=1 lldb-test symbols --dump-ast %t.exe | FileCheck %s
+
+struct A {
+  ~A() {};
+};
+struct B {
+  static A glob;
+};
+
+A B::glob = A();
+int main() {
+  return 0;
+}
+
+// CHECK:  static void B::`dynamic initializer for 'glob'();
+// CHECK-NEXT: static void B::`dynamic atexit destructor for 'glob'();
+// CHECK-NEXT: int main();
+// CHECK-NEXT: static void _GLOBAL__sub_I_global_ctor_dtor.cpp();
+// CHECK-NEXT: struct A {
+// CHECK-NEXT: ~A();
+// CHECK-NEXT: };
+// CHECK-NEXT: struct B {
+// CHECK-NEXT: static A glob;
+// CHECK-NEXT: };
Index: lldb/source/Plugins/SymbolFile/NativePDB/PdbAstBuilder.cpp
===
--- lldb/source/Plugins/SymbolFile/NativePDB/PdbAstBuilder.cpp
+++ lldb/source/Plugins/SymbolFile/NativePDB/PdbAstBuilder.cpp
@@ -534,11 +534,15 @@
 
 std::pair
 PdbAstBuilder::CreateDeclInfoForUndecoratedName(llvm::StringRef name) {
+  clang::DeclContext *context =
+  FromCompilerDeclContext(GetTranslationUnitDecl());
+  // Global ctor and dtor are global decls.
+  if (name.contains("dynamic initializer for") ||
+  name.contains("dynamic atexit destructor for"))
+return {context, std::string(name)};
   MSVCUndecoratedNameParser parser(name);
   llvm::ArrayRef specs = parser.GetSpecifiers();
 
-  auto context = FromCompilerDeclContext(GetTranslationUnitDecl());
-
   llvm::StringRef uname = specs.back().GetBaseName();
   specs = specs.drop_back();
   if (specs.empty())
@@ -1226,7 +1230,6 @@
   llvm::StringRef proc_name = proc.Name;
   proc_name.consume_front(context_name);
   proc_name.consume_front("::");
-
   clang::FunctionDecl 

[Lldb-commits] [lldb] c988965 - Temporarily XFAIL libcxx tests.

2022-09-09 Thread Adrian Prantl via lldb-commits

Author: Adrian Prantl
Date: 2022-09-09T10:43:03-07:00
New Revision: c988965efb2ce8fd867b86d4b893654943d11642

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

LOG: Temporarily XFAIL libcxx tests.

These tests started failing on green dragon after a configuration change that 
compiles tests using the just-built libcxx. We may need to force the system 
libcxx here, or change LLDB to import the std module from the just-built 
libcxx, too.

Added: 


Modified: 

lldb/test/API/commands/expression/import-std-module/deque-basic/TestDequeFromStdModule.py

lldb/test/API/commands/expression/import-std-module/deque-dbg-info-content/TestDbgInfoContentDequeFromStdModule.py

lldb/test/API/commands/expression/import-std-module/vector-dbg-info-content/TestDbgInfoContentVectorFromStdModule.py

lldb/test/API/commands/expression/import-std-module/vector/TestVectorFromStdModule.py

lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/iterator/TestDataFormatterLibccIterator.py

lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/span/TestDataFormatterLibcxxSpan.py

lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/string_view/TestDataFormatterLibcxxStringView.py

lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/variant/TestDataFormatterLibcxxVariant.py

Removed: 




diff  --git 
a/lldb/test/API/commands/expression/import-std-module/deque-basic/TestDequeFromStdModule.py
 
b/lldb/test/API/commands/expression/import-std-module/deque-basic/TestDequeFromStdModule.py
index 44327c9895d5b..7b514b0c6dd77 100644
--- 
a/lldb/test/API/commands/expression/import-std-module/deque-basic/TestDequeFromStdModule.py
+++ 
b/lldb/test/API/commands/expression/import-std-module/deque-basic/TestDequeFromStdModule.py
@@ -10,6 +10,7 @@
 class TestBasicDeque(TestBase):
 
 @add_test_categories(["libc++"])
+@expectedFailureDarwin
 @skipIf(compiler=no_match("clang"))
 def test(self):
 self.build()

diff  --git 
a/lldb/test/API/commands/expression/import-std-module/deque-dbg-info-content/TestDbgInfoContentDequeFromStdModule.py
 
b/lldb/test/API/commands/expression/import-std-module/deque-dbg-info-content/TestDbgInfoContentDequeFromStdModule.py
index ff32eed026204..8b98a527c6012 100644
--- 
a/lldb/test/API/commands/expression/import-std-module/deque-dbg-info-content/TestDbgInfoContentDequeFromStdModule.py
+++ 
b/lldb/test/API/commands/expression/import-std-module/deque-dbg-info-content/TestDbgInfoContentDequeFromStdModule.py
@@ -10,6 +10,7 @@
 class TestDbgInfoContentDeque(TestBase):
 
 @add_test_categories(["libc++"])
+@expectedFailureDarwin # FIXME: May need to force system libcxx here.
 @skipIf(compiler=no_match("clang"))
 def test(self):
 self.build()

diff  --git 
a/lldb/test/API/commands/expression/import-std-module/vector-dbg-info-content/TestDbgInfoContentVectorFromStdModule.py
 
b/lldb/test/API/commands/expression/import-std-module/vector-dbg-info-content/TestDbgInfoContentVectorFromStdModule.py
index c2044ceee778f..8d0e926081661 100644
--- 
a/lldb/test/API/commands/expression/import-std-module/vector-dbg-info-content/TestDbgInfoContentVectorFromStdModule.py
+++ 
b/lldb/test/API/commands/expression/import-std-module/vector-dbg-info-content/TestDbgInfoContentVectorFromStdModule.py
@@ -11,6 +11,7 @@
 class TestDbgInfoContentVector(TestBase):
 
 @add_test_categories(["libc++"])
+@expectedFailureDarwin # FIXME: May need to force system libcxx here.
 @skipIf(compiler=no_match("clang"))
 def test(self):
 self.build()

diff  --git 
a/lldb/test/API/commands/expression/import-std-module/vector/TestVectorFromStdModule.py
 
b/lldb/test/API/commands/expression/import-std-module/vector/TestVectorFromStdModule.py
index 59b3e4f71ad7c..44bee3df614c6 100644
--- 
a/lldb/test/API/commands/expression/import-std-module/vector/TestVectorFromStdModule.py
+++ 
b/lldb/test/API/commands/expression/import-std-module/vector/TestVectorFromStdModule.py
@@ -10,6 +10,7 @@
 class TestBasicVector(TestBase):
 
 @add_test_categories(["libc++"])
+@expectedFailureDarwin # FIXME: May need to force system libcxx here.
 @skipIf(compiler=no_match("clang"))
 def test(self):
 self.build()

diff  --git 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/iterator/TestDataFormatterLibccIterator.py
 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/iterator/TestDataFormatterLibccIterator.py
index 55db9c2051cca..b6682e5c7e930 100644
--- 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/iterator/TestDataFormatterLibccIterator.py
+++ 

[Lldb-commits] [PATCH] D133038: Add SBDebugger::GetSetting() public API

2022-09-09 Thread jeffrey tan via Phabricator via lldb-commits
yinghuitan updated this revision to Diff 459120.
yinghuitan added a comment.

Address review comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133038

Files:
  lldb/bindings/interface/SBDebugger.i
  lldb/include/lldb/API/SBDebugger.h
  lldb/include/lldb/Core/UserSettingsController.h
  lldb/include/lldb/Interpreter/OptionValue.h
  lldb/include/lldb/Interpreter/OptionValueArray.h
  lldb/include/lldb/Interpreter/OptionValueBoolean.h
  lldb/include/lldb/Interpreter/OptionValueChar.h
  lldb/include/lldb/Interpreter/OptionValueDictionary.h
  lldb/include/lldb/Interpreter/OptionValueFileSpec.h
  lldb/include/lldb/Interpreter/OptionValueFormat.h
  lldb/include/lldb/Interpreter/OptionValueFormatEntity.h
  lldb/include/lldb/Interpreter/OptionValueLanguage.h
  lldb/include/lldb/Interpreter/OptionValuePathMappings.h
  lldb/include/lldb/Interpreter/OptionValueProperties.h
  lldb/include/lldb/Interpreter/OptionValueRegex.h
  lldb/include/lldb/Interpreter/OptionValueSInt64.h
  lldb/include/lldb/Interpreter/OptionValueString.h
  lldb/include/lldb/Interpreter/OptionValueUInt64.h
  lldb/include/lldb/Interpreter/OptionValueUUID.h
  lldb/include/lldb/Target/PathMappingList.h
  lldb/source/API/SBDebugger.cpp
  lldb/source/Core/UserSettingsController.cpp
  lldb/source/Interpreter/OptionValueArray.cpp
  lldb/source/Interpreter/OptionValueDictionary.cpp
  lldb/source/Interpreter/OptionValueFormat.cpp
  lldb/source/Interpreter/OptionValueFormatEntity.cpp
  lldb/source/Interpreter/OptionValueLanguage.cpp
  lldb/source/Interpreter/OptionValuePathMappings.cpp
  lldb/source/Interpreter/OptionValueProperties.cpp
  lldb/source/Target/PathMappingList.cpp
  lldb/test/API/commands/settings/TestSettings.py
  lldb/test/API/functionalities/source-map/TestTargetSourceMap.py

Index: lldb/test/API/functionalities/source-map/TestTargetSourceMap.py
===
--- lldb/test/API/functionalities/source-map/TestTargetSourceMap.py
+++ lldb/test/API/functionalities/source-map/TestTargetSourceMap.py
@@ -1,11 +1,45 @@
 import lldb
 from lldbsuite.test.lldbtest import *
 from lldbsuite.test.decorators import *
+import json
 import os
 
 
 class TestTargetSourceMap(TestBase):
 
+@no_debug_info_test
+def test_source_map_via_setting_api(self):
+"""
+Test that ensures SBDebugger::GetSetting("target.source-map") API
+can correctly fetch source mapping entries.
+"""
+# Set the target soure map to map "./" to the current test directory
+src_dir = self.getSourceDir()
+
+source_map_setting_path = "target.source-map"
+initial_source_map = self.dbg.GetSetting(source_map_setting_path)
+self.assertEquals(initial_source_map.GetSize(), 0,
+"Initial source map should be empty")
+
+src_dir = self.getSourceDir()
+self.runCmd('settings set %s . "%s"' % (source_map_setting_path, src_dir))
+
+source_map = self.dbg.GetSetting(source_map_setting_path)
+self.assertEquals(source_map.GetSize(), 1,
+"source map should be have one appended entry")
+
+stream = lldb.SBStream()
+source_map.GetAsJSON(stream)
+serialized_source_map = json.loads(stream.GetData())
+
+self.assertEquals(len(serialized_source_map[0]), 2,
+"source map entry should have two parts")
+self.assertEquals(serialized_source_map[0][0], ".",
+"source map entry's first part does not match")
+self.assertEquals(serialized_source_map[0][1], src_dir,
+"source map entry's second part does not match")
+
+
 @no_debug_info_test
 def test_source_map(self):
 """Test target.source-map' functionality."""
Index: lldb/test/API/commands/settings/TestSettings.py
===
--- lldb/test/API/commands/settings/TestSettings.py
+++ lldb/test/API/commands/settings/TestSettings.py
@@ -3,7 +3,7 @@
 """
 
 
-
+import json
 import os
 import re
 import lldb
@@ -274,7 +274,7 @@
 self.assertEqual(launch_info.GetArgumentAtIndex(0), "A")
 self.assertEqual(launch_info.GetArgumentAtIndex(1), "B")
 self.assertEqual(launch_info.GetArgumentAtIndex(2), "C")
-
+
 self.expect(
 'target show-launch-environment',
 substrs=["MY_ENV_VAR=YES"])
@@ -787,3 +787,59 @@
 
 # A known option should fail if its argument is invalid.
 self.expect("settings set auto-confirm bogus", error=True)
+
+def get_setting_json(self, setting_path = None):
+settings_data = self.dbg.GetSetting(setting_path)
+stream = lldb.SBStream()
+settings_data.GetAsJSON(stream)
+return json.loads(stream.GetData())
+
+def verify_setting_value_json(self, setting_path, setting_value):
+self.runCmd("settings set %s %s" % 

[Lldb-commits] [PATCH] D133038: Add SBDebugger::GetSetting() public API

2022-09-09 Thread jeffrey tan via Phabricator via lldb-commits
yinghuitan added inline comments.



Comment at: lldb/include/lldb/Interpreter/OptionValueChar.h:34-37
+if (m_current_value != '\0')
+  return m_current_value;
+else
+  return "(null)";

clayborg wrote:
> Since this is actually a character, it should store what ever the character 
> value is. So if the character is zero, it should store zero, not a string 
> "(null)"
I am not sure about this. This mimics what `OptionValueChar::DumpValue()` does. 
Do we want to keep consistence here?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133038

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


[Lldb-commits] [PATCH] D133534: Complete support of loading a darwin kernel over a live gdb-remote connection given the address of a mach-o fileset

2022-09-09 Thread Jason Molenda via Phabricator via lldb-commits
jasonmolenda updated this revision to Diff 459094.
jasonmolenda added a comment.

Update patch to include more surrounding context.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133534

Files:
  lldb/include/lldb/Target/Platform.h
  lldb/include/lldb/Target/Process.h
  lldb/source/Core/DynamicLoader.cpp
  lldb/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp
  lldb/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.cpp
  lldb/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.h
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
  lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
  lldb/source/Target/Platform.cpp
  lldb/source/Target/Process.cpp
  lldb/unittests/Core/CMakeLists.txt
  lldb/unittests/Interpreter/CMakeLists.txt
  lldb/unittests/Platform/CMakeLists.txt
  lldb/unittests/Process/CMakeLists.txt
  lldb/unittests/SymbolFile/DWARF/CMakeLists.txt

Index: lldb/unittests/SymbolFile/DWARF/CMakeLists.txt
===
--- lldb/unittests/SymbolFile/DWARF/CMakeLists.txt
+++ lldb/unittests/SymbolFile/DWARF/CMakeLists.txt
@@ -10,10 +10,12 @@
 lldbCore
 lldbHost
 lldbSymbol
+lldbPluginDynamicLoaderDarwinKernel
 lldbPluginObjectFilePECOFF
 lldbPluginSymbolFileDWARF
 lldbPluginSymbolFilePDB
 lldbPluginTypeSystemClang
+lldbPluginObjectContainerMachOFileset
 lldbPluginPlatformMacOSX
 lldbUtilityHelpers
 lldbSymbolHelpers
Index: lldb/unittests/Process/CMakeLists.txt
===
--- lldb/unittests/Process/CMakeLists.txt
+++ lldb/unittests/Process/CMakeLists.txt
@@ -17,5 +17,7 @@
   lldbUtility
   lldbUtilityHelpers
   lldbInterpreter
+  lldbPluginDynamicLoaderDarwinKernel
+  lldbPluginObjectContainerMachOFileset
   lldbPluginPlatformMacOSX
   )
Index: lldb/unittests/Platform/CMakeLists.txt
===
--- lldb/unittests/Platform/CMakeLists.txt
+++ lldb/unittests/Platform/CMakeLists.txt
@@ -6,6 +6,8 @@
   PlatformTest.cpp
 
   LINK_LIBS
+lldbPluginDynamicLoaderDarwinKernel
+lldbPluginObjectContainerMachOFileset
 lldbPluginPlatformFreeBSD
 lldbPluginPlatformLinux
 lldbPluginPlatformMacOSX
Index: lldb/unittests/Interpreter/CMakeLists.txt
===
--- lldb/unittests/Interpreter/CMakeLists.txt
+++ lldb/unittests/Interpreter/CMakeLists.txt
@@ -14,6 +14,8 @@
   lldbUtility
   lldbUtilityHelpers
   lldbInterpreter
+  lldbPluginDynamicLoaderDarwinKernel
+  lldbPluginObjectContainerMachOFileset
   lldbPluginPlatformMacOSX
   LLVMTestingSupport
 )
Index: lldb/unittests/Core/CMakeLists.txt
===
--- lldb/unittests/Core/CMakeLists.txt
+++ lldb/unittests/Core/CMakeLists.txt
@@ -14,9 +14,11 @@
   LINK_LIBS
 lldbCore
 lldbHost
+lldbPluginDynamicLoaderDarwinKernel
 lldbPluginObjectFileELF
 lldbPluginObjectFileMachO
 lldbPluginObjectFilePECOFF
+lldbPluginObjectContainerMachOFileset
 lldbPluginPlatformMacOSX
 lldbPluginSymbolFileSymtab
 lldbSymbol
Index: lldb/source/Target/Process.cpp
===
--- lldb/source/Target/Process.cpp
+++ lldb/source/Target/Process.cpp
@@ -2653,6 +2653,10 @@
   return m_dyld_up.get();
 }
 
+void Process::SetDynamicLoader(DynamicLoaderUP dyld_up) {
+  m_dyld_up = std::move(dyld_up);
+}
+
 DataExtractor Process::GetAuxvData() { return DataExtractor(); }
 
 llvm::Expected Process::SaveCore(llvm::StringRef outfile) {
Index: lldb/source/Target/Platform.cpp
===
--- lldb/source/Target/Platform.cpp
+++ lldb/source/Target/Platform.cpp
@@ -2079,3 +2079,23 @@
   m_platforms.push_back(platform_sp);
   return platform_sp;
 }
+
+bool PlatformList::LoadSpecialBinaryAndSetDynamicLoader(Process *process,
+lldb::addr_t addr,
+bool notify) {
+  std::lock_guard guard(m_mutex);
+
+  PlatformCreateInstance create_callback;
+  for (int idx = 0;
+   (create_callback = PluginManager::GetPlatformCreateCallbackAtIndex(idx));
+   ++idx) {
+ArchSpec arch;
+PlatformSP platform_sp = create_callback(true, );
+if (platform_sp) {
+  if (platform_sp->LoadSpecialBinaryAndSetDynamicLoader(process, addr,
+notify))
+return true;
+}
+  }
+  return false;
+}
Index: lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
===
--- 

[Lldb-commits] [PATCH] D133534: Complete support of loading a darwin kernel over a live gdb-remote connection given the address of a mach-o fileset

2022-09-09 Thread Jonas Devlieghere via Phabricator via lldb-commits
JDevlieghere added a comment.

The current patch didn't have context so I just left a bunch of nits.




Comment at: lldb/include/lldb/Target/Platform.h:870-874
+  virtual bool LoadSpecialBinaryAndSetDynamicLoader(Process *process,
+lldb::addr_t addr,
+bool notify) {
+return false;
+  }

What makes the binary special? The comment above doesn't say. Can we give this 
a more descriptive name or omit the "Special" part?



Comment at: 
lldb/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp:133
 
+static bool module_is_a_kernel(Module *module) {
+  if (!module)

This seems needless verbose: `is_kernel` conveys the same information. 



Comment at: 
lldb/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp:574-577
+  if (module_is_a_kernel(module_sp.get()))
+m_kernel_image = true;
+  else
+m_kernel_image = false;

`m_kernel_image = is_kernel(module_sp.get())`



Comment at: 
lldb/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp:668-669
   bool is_kernel = false;
-  if (memory_module_sp->GetObjectFile()) {
-if (memory_module_sp->GetObjectFile()->GetType() ==
-ObjectFile::eTypeExecutable &&
-memory_module_sp->GetObjectFile()->GetStrata() ==
-ObjectFile::eStrataKernel) {
-  is_kernel = true;
-} else if (memory_module_sp->GetObjectFile()->GetType() ==
-   ObjectFile::eTypeSharedLibrary) {
-  is_kernel = false;
-}
-  }
+  if (module_is_a_kernel(memory_module_sp.get()))
+is_kernel = true;
 

`is_kernel = is_kernel(memory_module_sp.get())`



Comment at: 
lldb/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp:747-752
+ModuleList module_list = target.GetImages();
+std::lock_guard guard(module_list.GetMutex());
+const size_t num_modules = module_list.GetSize();
+ModuleList incorrect_kernels;
+for (size_t i = 0; i < num_modules; i++) {
+  ModuleSP module_sp = module_list.GetModuleAtIndex(i);

The `ModuleList` has a `Modules()` function that returns a  locking iterator. 
You can rewrite this as:

```
for(ModuleSP module : target.GetImages().Modules()) {
  ...
}
```



Comment at: lldb/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.cpp:929
+return LLDB_INVALID_ADDRESS;
+  ModuleSP module_sp(new Module(ModuleSpec()));
+  ObjectContainerSP container_sp(

```ModuleSP module_sp = std::make_shared()```



Comment at: lldb/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.cpp:970
+  PlatformDarwinKernel::GetPluginNameStatic());
+  if (platform_sp.get())
+process->GetTarget().SetPlatform(platform_sp);

```if(platform_sp)```



Comment at: lldb/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.cpp:973-974
+
+  DynamicLoaderUP dyld_up(
+  new DynamicLoaderDarwinKernel(process, actual_address));
+  if (!dyld_up)

std::make_shared


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133534

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


[Lldb-commits] [PATCH] D111509: [clang] use getCommonSugar in an assortment of places

2022-09-09 Thread Matheus Izvekov via Phabricator via lldb-commits
mizvekov added a comment.

In D111509#3778883 , @MaskRay wrote:

> Sorry, I just reverted it:) You may check whether the fix fixes GCC 
> libstdc++-v3/src/c++98/complex_io.cc

I confirm it does not crash on my system with this patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111509

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


[Lldb-commits] [PATCH] D111509: [clang] use getCommonSugar in an assortment of places

2022-09-09 Thread Matheus Izvekov via Phabricator via lldb-commits
mizvekov added inline comments.



Comment at: clang/lib/Sema/SemaExpr.cpp:1091-1150
+QualType fpTy = ComplexTy->castAs()->getElementType();
 IntExpr = S.ImpCastExprToType(IntExpr.get(), fpTy, CK_IntegralToFloating);
 IntExpr = S.ImpCastExprToType(IntExpr.get(), ComplexTy,
   CK_FloatingRealToComplex);
   } else {
 assert(IntTy->isComplexIntegerType());
 IntExpr = S.ImpCastExprToType(IntExpr.get(), ComplexTy,

@shafik let's continue revision of D133522 in this patch, since that one was a 
quick fix that I attempted in order to avoid reverting it. But now that it was 
reverted, I will abandon the other one.

I have highlighted with this comment the areas affected by D133522 so we can 
continue here.

But now I have refactored the whole thing to be simpler / more readable.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111509

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


[Lldb-commits] [PATCH] D133427: [gdb-remote] Move broadcasting logic down to GDBRemoteClientBase

2022-09-09 Thread Michał Górny via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGbdb4468d3949: [gdb-remote] Move broadcasting logic down to 
GDBRemoteClientBase (authored by mgorny).
Herald added a project: LLDB.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133427

Files:
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteClientBase.cpp
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteClientBase.h
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.h
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.h
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.h
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
  
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerPlatform.cpp
  lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
  lldb/unittests/Process/gdb-remote/GDBRemoteClientBaseTest.cpp
  lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationTest.cpp
  lldb/unittests/Process/gdb-remote/GDBRemoteTestUtils.h

Index: lldb/unittests/Process/gdb-remote/GDBRemoteTestUtils.h
===
--- lldb/unittests/Process/gdb-remote/GDBRemoteTestUtils.h
+++ lldb/unittests/Process/gdb-remote/GDBRemoteTestUtils.h
@@ -53,8 +53,7 @@
 
 class MockServer : public GDBRemoteCommunicationServer {
 public:
-  MockServer()
-  : GDBRemoteCommunicationServer("mock-server", "mock-server.listener") {
+  MockServer() : GDBRemoteCommunicationServer() {
 m_send_acks = false;
 m_send_error_strings = true;
   }
Index: lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationTest.cpp
===
--- lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationTest.cpp
+++ lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationTest.cpp
@@ -17,8 +17,7 @@
 
 class TestClient : public GDBRemoteCommunication {
 public:
-  TestClient()
-  : GDBRemoteCommunication("test.client", "test.client.listener") {}
+  TestClient() : GDBRemoteCommunication() {}
 
   PacketResult ReadPacket(StringExtractorGDBRemote ) {
 return GDBRemoteCommunication::ReadPacket(response, std::chrono::seconds(1),
Index: lldb/unittests/Process/gdb-remote/GDBRemoteClientBaseTest.cpp
===
--- lldb/unittests/Process/gdb-remote/GDBRemoteClientBaseTest.cpp
+++ lldb/unittests/Process/gdb-remote/GDBRemoteClientBaseTest.cpp
@@ -39,7 +39,7 @@
 };
 
 struct TestClient : public GDBRemoteClientBase {
-  TestClient() : GDBRemoteClientBase("test.client", "test.client.listener") {
+  TestClient() : GDBRemoteClientBase("test.client") {
 m_send_acks = false;
   }
 };
Index: lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
===
--- lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -1168,7 +1168,7 @@
   ListenerSP listener_sp(
   Listener::MakeListener("gdb-remote.resume-packet-sent"));
   if (listener_sp->StartListeningForEvents(
-  _gdb_comm, GDBRemoteCommunication::eBroadcastBitRunPacketSent)) {
+  _gdb_comm, GDBRemoteClientBase::eBroadcastBitRunPacketSent)) {
 listener_sp->StartListeningForEvents(
 _async_broadcaster,
 ProcessGDBRemote::eBroadcastBitAsyncThreadDidExit);
Index: lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerPlatform.cpp
===
--- lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerPlatform.cpp
+++ lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerPlatform.cpp
@@ -109,8 +109,7 @@
 // GDBRemoteCommunicationServerPlatform constructor
 GDBRemoteCommunicationServerPlatform::GDBRemoteCommunicationServerPlatform(
 const Socket::SocketProtocol socket_protocol, const char *socket_scheme)
-: GDBRemoteCommunicationServerCommon("gdb-remote.server",
- "gdb-remote.server.rx_packet"),
+: GDBRemoteCommunicationServerCommon(),
   m_socket_protocol(socket_protocol), m_socket_scheme(socket_scheme),
   m_spawned_pids_mutex(), m_port_map(), m_port_offset(0) {
   m_pending_gdb_server.pid = LLDB_INVALID_PROCESS_ID;
Index: lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
===
--- lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
+++ 

[Lldb-commits] [lldb] bdb4468 - [gdb-remote] Move broadcasting logic down to GDBRemoteClientBase

2022-09-09 Thread Michał Górny via lldb-commits

Author: Michał Górny
Date: 2022-09-09T17:13:08+02:00
New Revision: bdb4468d39496088fc05d8c5575647fac9c8062a

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

LOG: [gdb-remote] Move broadcasting logic down to GDBRemoteClientBase

Move the broadcasting support from GDBRemoteCommunication
to GDBRemoteClientBase since this is where it is actually used.  Remove
GDBRemoteCommunication and subclass constructor arguments left over
after Communication cleanup.

Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D133427

Added: 


Modified: 
lldb/source/Plugins/Process/gdb-remote/GDBRemoteClientBase.cpp
lldb/source/Plugins/Process/gdb-remote/GDBRemoteClientBase.h
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.h
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.h

lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.h
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp

lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerPlatform.cpp
lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
lldb/unittests/Process/gdb-remote/GDBRemoteClientBaseTest.cpp
lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationTest.cpp
lldb/unittests/Process/gdb-remote/GDBRemoteTestUtils.h

Removed: 




diff  --git a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteClientBase.cpp 
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteClientBase.cpp
index e3a3cfc4f23e..ae85dbc68336 100644
--- a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteClientBase.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteClientBase.cpp
@@ -31,10 +31,9 @@ static const seconds kWakeupInterval(5);
 
 GDBRemoteClientBase::ContinueDelegate::~ContinueDelegate() = default;
 
-GDBRemoteClientBase::GDBRemoteClientBase(const char *comm_name,
- const char *listener_name)
-: GDBRemoteCommunication(comm_name, listener_name), m_async_count(0),
-  m_is_running(false), m_should_stop(false) {}
+GDBRemoteClientBase::GDBRemoteClientBase(const char *comm_name)
+: GDBRemoteCommunication(), Broadcaster(nullptr, comm_name),
+  m_async_count(0), m_is_running(false), m_should_stop(false) {}
 
 StateType GDBRemoteClientBase::SendContinuePacketAndWaitForResponse(
 ContinueDelegate , const UnixSignals ,

diff  --git a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteClientBase.h 
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteClientBase.h
index 43a5313eae6a..4dd67a2b11f7 100644
--- a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteClientBase.h
+++ b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteClientBase.h
@@ -16,8 +16,12 @@
 namespace lldb_private {
 namespace process_gdb_remote {
 
-class GDBRemoteClientBase : public GDBRemoteCommunication {
+class GDBRemoteClientBase : public GDBRemoteCommunication, public Broadcaster {
 public:
+  enum {
+eBroadcastBitRunPacketSent = (1u << 0),
+  };
+
   struct ContinueDelegate {
 virtual ~ContinueDelegate();
 virtual void HandleAsyncStdout(llvm::StringRef out) = 0;
@@ -31,7 +35,7 @@ class GDBRemoteClientBase : public GDBRemoteCommunication {
 virtual void HandleAsyncStructuredDataPacket(llvm::StringRef data) = 0;
   };
 
-  GDBRemoteClientBase(const char *comm_name, const char *listener_name);
+  GDBRemoteClientBase(const char *comm_name);
 
   bool SendAsyncSignal(int signo, std::chrono::seconds interrupt_timeout);
 

diff  --git a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp 
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
index 33e041bb6e3e..b0cec915bc34 100644
--- a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
@@ -58,9 +58,8 @@ using namespace lldb_private;
 using namespace lldb_private::process_gdb_remote;
 
 // GDBRemoteCommunication constructor
-GDBRemoteCommunication::GDBRemoteCommunication(const char *comm_name,
-   const char *listener_name)
-: Communication(), Broadcaster(nullptr, comm_name),
+GDBRemoteCommunication::GDBRemoteCommunication()
+: Communication(),
 #ifdef LLDB_CONFIGURATION_DEBUG
   m_packet_timeout(1000),
 #else

diff  --git a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.h 
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.h

[Lldb-commits] [PATCH] D111509: [clang] use getCommonSugar in an assortment of places

2022-09-09 Thread Matheus Izvekov via Phabricator via lldb-commits
mizvekov edited the summary of this revision.
mizvekov updated this revision to Diff 459070.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111509

Files:
  clang-tools-extra/clangd/unittests/tweaks/ExtractVariableTests.cpp
  
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines/narrowing-conversions-ignoreconversionfromtypes-option.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/test/AST/ast-dump-fpfeatures.cpp
  clang/test/CodeGen/compound-assign-overflow.c
  clang/test/Sema/complex-int.c
  clang/test/Sema/matrix-type-operators.c
  clang/test/Sema/nullability.c
  clang/test/Sema/sugar-common-types.c
  clang/test/SemaCXX/complex-conversion.cpp
  clang/test/SemaCXX/matrix-type-operators.cpp
  clang/test/SemaCXX/sugar-common-types.cpp
  clang/test/SemaCXX/sugared-auto.cpp
  clang/test/SemaObjC/format-strings-objc.m
  compiler-rt/test/ubsan/TestCases/Integer/add-overflow.cpp
  compiler-rt/test/ubsan/TestCases/Integer/no-recover.cpp
  compiler-rt/test/ubsan/TestCases/Integer/sub-overflow.cpp
  compiler-rt/test/ubsan/TestCases/Integer/uadd-overflow.cpp
  compiler-rt/test/ubsan/TestCases/Integer/umul-overflow.cpp
  compiler-rt/test/ubsan/TestCases/Integer/usub-overflow.cpp
  lldb/test/API/commands/expression/rdar42038760/main.c
  lldb/test/API/commands/expression/rdar44436068/main.c

Index: lldb/test/API/commands/expression/rdar44436068/main.c
===
--- lldb/test/API/commands/expression/rdar44436068/main.c
+++ lldb/test/API/commands/expression/rdar44436068/main.c
@@ -3,6 +3,6 @@
 __int128_t n = 1;
 n = n + n;
 return n; //%self.expect("p n", substrs=['(__int128_t) $0 = 2'])
-  //%self.expect("p n + 6", substrs=['(__int128) $1 = 8'])
-  //%self.expect("p n + n", substrs=['(__int128) $2 = 4'])
+  //%self.expect("p n + 6", substrs=['(__int128_t) $1 = 8'])
+  //%self.expect("p n + n", substrs=['(__int128_t) $2 = 4'])
 }
Index: lldb/test/API/commands/expression/rdar42038760/main.c
===
--- lldb/test/API/commands/expression/rdar42038760/main.c
+++ lldb/test/API/commands/expression/rdar42038760/main.c
@@ -10,7 +10,7 @@
   struct S0 l_19;
   l_19.f2 = 419;
   uint32_t l_4037 = 4294967295UL;
-  l_19.f2 = g_463; //%self.expect("expr ((l_4037 % (-(g_463))) | l_19.f2)", substrs=['(unsigned int) $0 = 358717883'])
+  l_19.f2 = g_463; //%self.expect("expr ((l_4037 % (-(g_463))) | l_19.f2)", substrs=['(uint32_t) $0 = 358717883'])
 }
 int main()
 {
Index: compiler-rt/test/ubsan/TestCases/Integer/usub-overflow.cpp
===
--- compiler-rt/test/ubsan/TestCases/Integer/usub-overflow.cpp
+++ compiler-rt/test/ubsan/TestCases/Integer/usub-overflow.cpp
@@ -12,12 +12,12 @@
 
 #ifdef SUB_I32
   (void)(uint32_t(1) - uint32_t(2));
-  // CHECK-SUB_I32: usub-overflow.cpp:[[@LINE-1]]:22: runtime error: unsigned integer overflow: 1 - 2 cannot be represented in type 'unsigned int'
+  // CHECK-SUB_I32: usub-overflow.cpp:[[@LINE-1]]:22: runtime error: unsigned integer overflow: 1 - 2 cannot be represented in type '{{uint32_t|unsigned int}}'
 #endif
 
 #ifdef SUB_I64
   (void)(uint64_t(800ll) - uint64_t(900ll));
-  // CHECK-SUB_I64: 800 - 900 cannot be represented in type 'unsigned {{long( long)?}}'
+  // CHECK-SUB_I64: 800 - 900 cannot be represented in type '{{uint64_t|unsigned long( long)?}}'
 #endif
 
 #ifdef SUB_I128
@@ -26,6 +26,6 @@
 # else
   puts("__int128 not supported\n");
 # endif
-  // CHECK-SUB_I128: {{0x4000 - 0x8000 cannot be represented in type 'unsigned __int128'|__int128 not supported}}
+  // CHECK-SUB_I128: {{0x4000 - 0x8000 cannot be represented in type '__uint128_t'|__int128 not supported}}
 #endif
 }
Index: compiler-rt/test/ubsan/TestCases/Integer/umul-overflow.cpp
===
--- compiler-rt/test/ubsan/TestCases/Integer/umul-overflow.cpp
+++ compiler-rt/test/ubsan/TestCases/Integer/umul-overflow.cpp
@@ -13,7 +13,7 @@
   (void)(uint16_t(0x) * uint16_t(0x8001));
 
   (void)(uint32_t(0x) * uint32_t(0x2));
-  // CHECK: umul-overflow.cpp:15:31: runtime error: unsigned integer overflow: 4294967295 * 2 cannot be represented in type 'unsigned int'
+  // CHECK: umul-overflow.cpp:15:31: runtime error: unsigned integer overflow: 4294967295 * 2 cannot be represented in type '{{uint32_t|unsigned int}}'
 
   return 0;
 }
Index: compiler-rt/test/ubsan/TestCases/Integer/uadd-overflow.cpp
===
--- 

[Lldb-commits] [PATCH] D111509: [clang] use getCommonSugar in an assortment of places

2022-09-09 Thread Matheus Izvekov via Phabricator via lldb-commits
mizvekov updated this revision to Diff 459067.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111509

Files:
  clang-tools-extra/clangd/unittests/tweaks/ExtractVariableTests.cpp
  
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines/narrowing-conversions-ignoreconversionfromtypes-option.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/test/AST/ast-dump-fpfeatures.cpp
  clang/test/CodeGen/compound-assign-overflow.c
  clang/test/Sema/complex-int.c
  clang/test/Sema/matrix-type-operators.c
  clang/test/Sema/nullability.c
  clang/test/Sema/sugar-common-types.c
  clang/test/SemaCXX/complex-conversion.cpp
  clang/test/SemaCXX/matrix-type-operators.cpp
  clang/test/SemaCXX/sugar-common-types.cpp
  clang/test/SemaCXX/sugared-auto.cpp
  clang/test/SemaObjC/format-strings-objc.m
  compiler-rt/test/ubsan/TestCases/Integer/add-overflow.cpp
  compiler-rt/test/ubsan/TestCases/Integer/no-recover.cpp
  compiler-rt/test/ubsan/TestCases/Integer/sub-overflow.cpp
  compiler-rt/test/ubsan/TestCases/Integer/uadd-overflow.cpp
  compiler-rt/test/ubsan/TestCases/Integer/umul-overflow.cpp
  compiler-rt/test/ubsan/TestCases/Integer/usub-overflow.cpp
  lldb/test/API/commands/expression/rdar42038760/main.c
  lldb/test/API/commands/expression/rdar44436068/main.c

Index: lldb/test/API/commands/expression/rdar44436068/main.c
===
--- lldb/test/API/commands/expression/rdar44436068/main.c
+++ lldb/test/API/commands/expression/rdar44436068/main.c
@@ -3,6 +3,6 @@
 __int128_t n = 1;
 n = n + n;
 return n; //%self.expect("p n", substrs=['(__int128_t) $0 = 2'])
-  //%self.expect("p n + 6", substrs=['(__int128) $1 = 8'])
-  //%self.expect("p n + n", substrs=['(__int128) $2 = 4'])
+  //%self.expect("p n + 6", substrs=['(__int128_t) $1 = 8'])
+  //%self.expect("p n + n", substrs=['(__int128_t) $2 = 4'])
 }
Index: lldb/test/API/commands/expression/rdar42038760/main.c
===
--- lldb/test/API/commands/expression/rdar42038760/main.c
+++ lldb/test/API/commands/expression/rdar42038760/main.c
@@ -10,7 +10,7 @@
   struct S0 l_19;
   l_19.f2 = 419;
   uint32_t l_4037 = 4294967295UL;
-  l_19.f2 = g_463; //%self.expect("expr ((l_4037 % (-(g_463))) | l_19.f2)", substrs=['(unsigned int) $0 = 358717883'])
+  l_19.f2 = g_463; //%self.expect("expr ((l_4037 % (-(g_463))) | l_19.f2)", substrs=['(uint32_t) $0 = 358717883'])
 }
 int main()
 {
Index: compiler-rt/test/ubsan/TestCases/Integer/usub-overflow.cpp
===
--- compiler-rt/test/ubsan/TestCases/Integer/usub-overflow.cpp
+++ compiler-rt/test/ubsan/TestCases/Integer/usub-overflow.cpp
@@ -12,12 +12,12 @@
 
 #ifdef SUB_I32
   (void)(uint32_t(1) - uint32_t(2));
-  // CHECK-SUB_I32: usub-overflow.cpp:[[@LINE-1]]:22: runtime error: unsigned integer overflow: 1 - 2 cannot be represented in type 'unsigned int'
+  // CHECK-SUB_I32: usub-overflow.cpp:[[@LINE-1]]:22: runtime error: unsigned integer overflow: 1 - 2 cannot be represented in type '{{uint32_t|unsigned int}}'
 #endif
 
 #ifdef SUB_I64
   (void)(uint64_t(800ll) - uint64_t(900ll));
-  // CHECK-SUB_I64: 800 - 900 cannot be represented in type 'unsigned {{long( long)?}}'
+  // CHECK-SUB_I64: 800 - 900 cannot be represented in type '{{uint64_t|unsigned long( long)?}}'
 #endif
 
 #ifdef SUB_I128
@@ -26,6 +26,6 @@
 # else
   puts("__int128 not supported\n");
 # endif
-  // CHECK-SUB_I128: {{0x4000 - 0x8000 cannot be represented in type 'unsigned __int128'|__int128 not supported}}
+  // CHECK-SUB_I128: {{0x4000 - 0x8000 cannot be represented in type '__uint128_t'|__int128 not supported}}
 #endif
 }
Index: compiler-rt/test/ubsan/TestCases/Integer/umul-overflow.cpp
===
--- compiler-rt/test/ubsan/TestCases/Integer/umul-overflow.cpp
+++ compiler-rt/test/ubsan/TestCases/Integer/umul-overflow.cpp
@@ -13,7 +13,7 @@
   (void)(uint16_t(0x) * uint16_t(0x8001));
 
   (void)(uint32_t(0x) * uint32_t(0x2));
-  // CHECK: umul-overflow.cpp:15:31: runtime error: unsigned integer overflow: 4294967295 * 2 cannot be represented in type 'unsigned int'
+  // CHECK: umul-overflow.cpp:15:31: runtime error: unsigned integer overflow: 4294967295 * 2 cannot be represented in type '{{uint32_t|unsigned int}}'
 
   return 0;
 }
Index: compiler-rt/test/ubsan/TestCases/Integer/uadd-overflow.cpp
===
--- compiler-rt/test/ubsan/TestCases/Integer/uadd-overflow.cpp
+++ 

[Lldb-commits] [PATCH] D132734: [lldb] Fix member access in GetExpressionPath

2022-09-09 Thread Andy Yankovsky via Phabricator via lldb-commits
werat accepted this revision.
werat added reviewers: clayborg, granata.enrico.
werat added a comment.
This revision is now accepted and ready to land.

Nice fix! It would be nice to remove redundant parenthesis, e.g. 
`(*(ptr)).member -> (*ptr).member`, but I see this is non-trivial with the 
current logic.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132734

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


[Lldb-commits] [PATCH] D133129: [lldb] Add boilerplate for debugger interrupts

2022-09-09 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

In D133129#3778125 , @jingham wrote:

> To be clear, I'm not trying to implement a preemptive interrupt using these 
> callbacks.  There are so many places where lldb is doing work that you really 
> can't interrupt - e.g. we can't drop symbol parsing and then pick it up again 
> later - that that doesn't really even make sense.
>
> I started out with the goal of extending the current 
> InterruptCommand/WasInterrupted style of voluntary interruption to more 
> places in lldb.  A voluntary "I'm doing something in a loop that can be 
> interrupted, so I'll check for interruption at the top of the loop" mechanism 
> seems like the best fit for lldb, so that structure makes sense.  But we only 
> check for interruption a few place in the "target modules" commands.  It 
> would be useful to have other places check - e.g. if you did a `bt` and there 
> were 4 frames and you don't want to wait for us to print them all out...  
> So I was going to look into adding more interrupt checks.
>
> But then it seemed a shame that setting this interrupt only works when you 
> are running command line commands, there's no reason this can't work for SB 
> API calls as well, then UI's could also allow this sort of interruption.  If 
> the UI code is doing something in a loop, then it's up to the UI code to 
> handle interrupting that operation.

I agree with all that.

> So all I'm trying to do is set the interrupt flag for use while the currently 
> executing SB API is in flight, then turning it off when that call exits.

The problem is that, even with a single SB call, it's very hard to tell the 
difference between "I am doing X" vs. "I am about to do X" vs. "I have just 
completed X (but haven't told anyone about it)". And I don't see a way to do 
that reliably through any kind of automatic API boundary tracking.

> The debugger is the one setting the interrupt flag, so we always know who is 
> sending the interrupt.  The tricky bit is how to turn off the 
> "WasInterrupted" flag after the API that was in flight when the flag was set 
> finishes.

Maybe the solution is to not (automatically) turn off the flag -- but put it in 
the hands of the user instead? If the interrupt flag was sticky (with explicit 
SetInterrupt/ClearInterrupt actions), then one can handle all of the scenarios 
above fairly easily.
It doesn't matter that whether SetInterrupt is called before the blocking call 
or not -- the call is going to be interrupted anyway. And one can explicitly 
clear the interrupt flag after the blocking call returns (either successfully 
or because it was interrupted).


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

https://reviews.llvm.org/D133129

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


[Lldb-commits] [PATCH] D133427: [gdb-remote] Move broadcasting logic down to GDBRemoteClientBase

2022-09-09 Thread Pavel Labath via Phabricator via lldb-commits
labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.

cool.




Comment at: lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationTest.cpp:20
 public:
-  TestClient()
-  : GDBRemoteCommunication("test.client", "test.client.listener") {}
+  TestClient() : GDBRemoteCommunication() {}
 

I think you can just delete this altogether.


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

https://reviews.llvm.org/D133427

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


[Lldb-commits] [PATCH] D132954: lldb: Add support for R_386_32 relocations to ObjectFileELF

2022-09-09 Thread Pavel Labath via Phabricator via lldb-commits
labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.

Cool. Thanks for figuring this out.


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

https://reviews.llvm.org/D132954

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


[Lldb-commits] [PATCH] D133352: [lldb-server] Report launch error in vRun packets

2022-09-09 Thread Pavel Labath via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG681d0d9e5f05: [lldb-server] Report launch error in vRun 
packets (authored by labath).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133352

Files:
  lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
  lldb/test/API/tools/lldb-server/TestGdbRemoteLaunch.py
  lldb/test/API/tools/lldb-server/TestLldbGdbServer.py

Index: lldb/test/API/tools/lldb-server/TestLldbGdbServer.py
===
--- lldb/test/API/tools/lldb-server/TestLldbGdbServer.py
+++ lldb/test/API/tools/lldb-server/TestLldbGdbServer.py
@@ -1205,128 +1205,6 @@
 self.assertEqual(read_value, expected_reg_values[thread_index])
 thread_index += 1
 
-@skipIfWindows # No pty support to test any inferior output
-@add_test_categories(["llgs"])
-def test_launch_via_A(self):
-self.build()
-exe_path = self.getBuildArtifact("a.out")
-args = [exe_path, "stderr:arg1", "stderr:arg2", "stderr:arg3"]
-hex_args = [binascii.b2a_hex(x.encode()).decode() for x in args]
-
-server = self.connect_to_debug_monitor()
-self.assertIsNotNone(server)
-self.do_handshake()
-# NB: strictly speaking we should use %x here but this packet
-# is deprecated, so no point in changing lldb-server's expectations
-self.test_sequence.add_log_lines(
-["read packet: $A %d,0,%s,%d,1,%s,%d,2,%s,%d,3,%s#00" %
- tuple(itertools.chain.from_iterable(
- [(len(x), x) for x in hex_args])),
- "send packet: $OK#00",
- "read packet: $c#00",
- "send packet: $W00#00"],
-True)
-context = self.expect_gdbremote_sequence()
-self.assertEqual(context["O_content"],
- b'arg1\r\narg2\r\narg3\r\n')
-
-@skipIfWindows # No pty support to test any inferior output
-@add_test_categories(["llgs"])
-def test_launch_via_vRun(self):
-self.build()
-exe_path = self.getBuildArtifact("a.out")
-args = [exe_path, "stderr:arg1", "stderr:arg2", "stderr:arg3"]
-hex_args = [binascii.b2a_hex(x.encode()).decode() for x in args]
-
-server = self.connect_to_debug_monitor()
-self.assertIsNotNone(server)
-self.do_handshake()
-self.test_sequence.add_log_lines(
-["read packet: $vRun;%s;%s;%s;%s#00" % tuple(hex_args),
- {"direction": "send",
-  "regex": r"^\$T([0-9a-fA-F]+)"},
- "read packet: $c#00",
- "send packet: $W00#00"],
-True)
-context = self.expect_gdbremote_sequence()
-self.assertEqual(context["O_content"],
- b'arg1\r\narg2\r\narg3\r\n')
-
-@add_test_categories(["llgs"])
-def test_launch_via_vRun_no_args(self):
-self.build()
-exe_path = self.getBuildArtifact("a.out")
-hex_path = binascii.b2a_hex(exe_path.encode()).decode()
-
-server = self.connect_to_debug_monitor()
-self.assertIsNotNone(server)
-self.do_handshake()
-self.test_sequence.add_log_lines(
-["read packet: $vRun;%s#00" % (hex_path,),
- {"direction": "send",
-  "regex": r"^\$T([0-9a-fA-F]+)"},
- "read packet: $c#00",
- "send packet: $W00#00"],
-True)
-self.expect_gdbremote_sequence()
-
-@skipIfWindows # No pty support to test any inferior output
-@add_test_categories(["llgs"])
-def test_QEnvironment(self):
-self.build()
-exe_path = self.getBuildArtifact("a.out")
-env = {"FOO": "test", "BAR": "a=z"}
-args = [exe_path, "print-env:FOO", "print-env:BAR"]
-hex_args = [binascii.b2a_hex(x.encode()).decode() for x in args]
-
-server = self.connect_to_debug_monitor()
-self.assertIsNotNone(server)
-self.do_handshake()
-
-for key, value in env.items():
-self.test_sequence.add_log_lines(
-["read packet: $QEnvironment:%s=%s#00" % (key, value),
- "send packet: $OK#00"],
-True)
-self.test_sequence.add_log_lines(
-["read packet: $vRun;%s#00" % (";".join(hex_args),),
- {"direction": "send",
-  "regex": r"^\$T([0-9a-fA-F]+)"},
- "read packet: $c#00",
- "send packet: $W00#00"],
-True)
-context = self.expect_gdbremote_sequence()
-self.assertEqual(context["O_content"], b"test\r\na=z\r\n")
-
-@skipIfWindows # No pty support to test any inferior output
-@add_test_categories(["llgs"])
-def test_QEnvironmentHexEncoded(self):
-self.build()
-exe_path = 

[Lldb-commits] [PATCH] D133410: [lldb] Fix ThreadedCommunication races

2022-09-09 Thread Pavel Labath via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG89a3691b794c: [lldb] Fix ThreadedCommunication races 
(authored by labath).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133410

Files:
  lldb/source/Core/ThreadedCommunication.cpp

Index: lldb/source/Core/ThreadedCommunication.cpp
===
--- lldb/source/Core/ThreadedCommunication.cpp
+++ lldb/source/Core/ThreadedCommunication.cpp
@@ -104,34 +104,50 @@
   return 0;
 }
 
+// No data yet, we have to start listening.
 ListenerSP listener_sp(
 Listener::MakeListener("ThreadedCommunication::Read"));
 listener_sp->StartListeningForEvents(
 this, eBroadcastBitReadThreadGotBytes | eBroadcastBitReadThreadDidExit);
-EventSP event_sp;
-while (listener_sp->GetEvent(event_sp, timeout)) {
-  const uint32_t event_type = event_sp->GetType();
-  if (event_type & eBroadcastBitReadThreadGotBytes) {
-return GetCachedBytes(dst, dst_len);
-  }
 
-  if (event_type & eBroadcastBitReadThreadDidExit) {
-// If the thread exited of its own accord, it either means it
-// hit an end-of-file condition or an error.
-status = m_pass_status;
-if (error_ptr)
-  *error_ptr = std::move(m_pass_error);
+// Re-check for data, as it might have arrived while we were setting up our
+// listener.
+cached_bytes = GetCachedBytes(dst, dst_len);
+if (cached_bytes > 0) {
+  status = eConnectionStatusSuccess;
+  return cached_bytes;
+}
 
-if (GetCloseOnEOF())
-  Disconnect(nullptr);
+EventSP event_sp;
+// Explicitly check for the thread exit, for the same reason.
+if (m_read_thread_did_exit) {
+  // We've missed the event, lets just conjure one up.
+  event_sp = std::make_shared(eBroadcastBitReadThreadDidExit);
+} else {
+  if (!listener_sp->GetEvent(event_sp, timeout)) {
+if (error_ptr)
+  error_ptr->SetErrorString("Timed out.");
+status = eConnectionStatusTimedOut;
 return 0;
   }
 }
+const uint32_t event_type = event_sp->GetType();
+if (event_type & eBroadcastBitReadThreadGotBytes) {
+  return GetCachedBytes(dst, dst_len);
+}
 
-if (error_ptr)
-  error_ptr->SetErrorString("Timed out.");
-status = eConnectionStatusTimedOut;
-return 0;
+if (event_type & eBroadcastBitReadThreadDidExit) {
+  // If the thread exited of its own accord, it either means it
+  // hit an end-of-file condition or an error.
+  status = m_pass_status;
+  if (error_ptr)
+*error_ptr = std::move(m_pass_error);
+
+  if (GetCloseOnEOF())
+Disconnect(nullptr);
+  return 0;
+}
+llvm_unreachable("Got unexpected event type!");
   }
 
   // We aren't using a read thread, just read the data synchronously in this
@@ -299,22 +315,25 @@
   m_pass_error = std::move(error);
   LLDB_LOG(log, "Communication({0}) thread exiting...", this);
 
-  // Handle threads wishing to synchronize with us.
-  {
-// Prevent new ones from showing up.
-m_read_thread_did_exit = true;
+  // Start shutting down. We need to do this in a very specific order to ensure
+  // we don't race with threads wanting to read/synchronize with us.
 
-// Unblock any existing thread waiting for the synchronization signal.
-BroadcastEvent(eBroadcastBitNoMorePendingInput);
+  // First, we signal our intent to exit. This ensures no new thread start
+  // waiting on events from us.
+  m_read_thread_did_exit = true;
 
-// Wait for the thread to finish...
+  // Unblock any existing thread waiting for the synchronization signal.
+  BroadcastEvent(eBroadcastBitNoMorePendingInput);
+
+  {
+// Wait for the synchronization thread to finish...
 std::lock_guard guard(m_synchronize_mutex);
 // ... and disconnect.
 if (disconnect)
   Disconnect();
   }
 
-  // Let clients know that this thread is exiting
+  // Finally, unblock any readers waiting for us to exit.
   BroadcastEvent(eBroadcastBitReadThreadDidExit);
   return {};
 }
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 681d0d9 - [lldb-server] Report launch error in vRun packets

2022-09-09 Thread Pavel Labath via lldb-commits

Author: Pavel Labath
Date: 2022-09-09T15:10:38+02:00
New Revision: 681d0d9e5f05405e4d0048e40796c5d08e85db93

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

LOG: [lldb-server] Report launch error in vRun packets

Uses our existing "error string" extension to provide a better
indication of why the launch failed (the client does not make use of the
error yet).

Also, fix the way we obtain the launch error message (make sure we read
the whole message, and skip trailing garbage), and reduce the size of
TestLldbGdbServer by splitting some tests into a separate file.

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

Added: 
lldb/test/API/tools/lldb-server/TestGdbRemoteLaunch.py

Modified: 
lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
lldb/test/API/tools/lldb-server/TestLldbGdbServer.py

Removed: 




diff  --git a/lldb/source/Host/posix/ProcessLauncherPosixFork.cpp 
b/lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
index 635dbb14a0271..a148c110e87b1 100644
--- a/lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
+++ b/lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
@@ -282,10 +282,19 @@ ProcessLauncherPosixFork::LaunchProcess(const 
ProcessLaunchInfo _info,
   // parent process
 
   pipe.CloseWriteFileDescriptor();
-  char buf[1000];
-  int r = read(pipe.GetReadFileDescriptor(), buf, sizeof buf);
-
-  if (r == 0)
+  llvm::SmallString<0> buf;
+  size_t pos = 0;
+  ssize_t r = 0;
+  do {
+pos += r;
+buf.resize_for_overwrite(pos + 100);
+r = llvm::sys::RetryAfterSignal(-1, read, pipe.GetReadFileDescriptor(),
+buf.begin() + pos, buf.size() - pos);
+  } while (r > 0);
+  assert(r != -1);
+
+  buf.resize(pos);
+  if (buf.empty())
 return HostProcess(pid); // No error. We're done.
 
   error.SetErrorString(buf);

diff  --git 
a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp 
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
index 6ca5c41cc1d01..089b6ee48e8bb 100644
--- 
a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
+++ 
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
@@ -3517,19 +3517,17 @@ GDBRemoteCommunicationServerLLGS::Handle_vRun(
   arg.c_str());
   }
 
-  if (!argv.empty()) {
-m_process_launch_info.GetExecutableFile().SetFile(
-m_process_launch_info.GetArguments()[0].ref(), 
FileSpec::Style::native);
-m_process_launch_error = LaunchProcess();
-if (m_process_launch_error.Success()) {
-  assert(m_current_process);
-  return SendStopReasonForState(*m_current_process,
-m_current_process->GetState(),
-/*force_synchronous=*/true);
-}
-LLDB_LOG(log, "failed to launch exe: {0}", m_process_launch_error);
-  }
-  return SendErrorResponse(8);
+  if (argv.empty())
+return SendErrorResponse(Status("No arguments"));
+  m_process_launch_info.GetExecutableFile().SetFile(
+  m_process_launch_info.GetArguments()[0].ref(), FileSpec::Style::native);
+  m_process_launch_error = LaunchProcess();
+  if (m_process_launch_error.Fail())
+return SendErrorResponse(m_process_launch_error);
+  assert(m_current_process);
+  return SendStopReasonForState(*m_current_process,
+m_current_process->GetState(),
+/*force_synchronous=*/true);
 }
 
 GDBRemoteCommunication::PacketResult

diff  --git a/lldb/test/API/tools/lldb-server/TestGdbRemoteLaunch.py 
b/lldb/test/API/tools/lldb-server/TestGdbRemoteLaunch.py
new file mode 100644
index 0..bc2ee0a5903e5
--- /dev/null
+++ b/lldb/test/API/tools/lldb-server/TestGdbRemoteLaunch.py
@@ -0,0 +1,154 @@
+import itertools
+
+import gdbremote_testcase
+import lldbgdbserverutils
+from lldbsuite.support import seven
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+
+
+class GdbRemoteLaunchTestCase(gdbremote_testcase.GdbRemoteTestCaseBase):
+
+@skipIfWindows # No pty support to test any inferior output
+@add_test_categories(["llgs"])
+def test_launch_via_A(self):
+self.build()
+exe_path = self.getBuildArtifact("a.out")
+args = [exe_path, "stderr:arg1", "stderr:arg2", "stderr:arg3"]
+hex_args = [seven.hexlify(x) for x in args]
+
+server = self.connect_to_debug_monitor()
+self.assertIsNotNone(server)
+self.do_handshake()
+# NB: strictly speaking we should use %x here but this packet
+# is deprecated, so no point in changing lldb-server's expectations
+self.test_sequence.add_log_lines(
+ 

[Lldb-commits] [lldb] 89a3691 - [lldb] Fix ThreadedCommunication races

2022-09-09 Thread Pavel Labath via lldb-commits

Author: Pavel Labath
Date: 2022-09-09T15:10:38+02:00
New Revision: 89a3691b794cee20187e14a750ecde8b6d3f7e71

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

LOG: [lldb] Fix ThreadedCommunication races

The Read function could end up blocking if data (or EOF) arrived just as
it was about to start waiting for the events. This was only discovered
now, because we did not have unit tests for this functionality before.
We need to check for data *after* we start listening for incoming
events. There were no changes to the read thread code needed, as we
already use this pattern in SynchronizeWithReadThread, so I just updated
the comments to make it clear that it is used for reading as well.

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

Added: 


Modified: 
lldb/source/Core/ThreadedCommunication.cpp

Removed: 




diff  --git a/lldb/source/Core/ThreadedCommunication.cpp 
b/lldb/source/Core/ThreadedCommunication.cpp
index ab89b474769a5..bc4c6e0214ef2 100644
--- a/lldb/source/Core/ThreadedCommunication.cpp
+++ b/lldb/source/Core/ThreadedCommunication.cpp
@@ -104,34 +104,50 @@ size_t ThreadedCommunication::Read(void *dst, size_t 
dst_len,
   return 0;
 }
 
+// No data yet, we have to start listening.
 ListenerSP listener_sp(
 Listener::MakeListener("ThreadedCommunication::Read"));
 listener_sp->StartListeningForEvents(
 this, eBroadcastBitReadThreadGotBytes | 
eBroadcastBitReadThreadDidExit);
-EventSP event_sp;
-while (listener_sp->GetEvent(event_sp, timeout)) {
-  const uint32_t event_type = event_sp->GetType();
-  if (event_type & eBroadcastBitReadThreadGotBytes) {
-return GetCachedBytes(dst, dst_len);
-  }
 
-  if (event_type & eBroadcastBitReadThreadDidExit) {
-// If the thread exited of its own accord, it either means it
-// hit an end-of-file condition or an error.
-status = m_pass_status;
-if (error_ptr)
-  *error_ptr = std::move(m_pass_error);
+// Re-check for data, as it might have arrived while we were setting up our
+// listener.
+cached_bytes = GetCachedBytes(dst, dst_len);
+if (cached_bytes > 0) {
+  status = eConnectionStatusSuccess;
+  return cached_bytes;
+}
 
-if (GetCloseOnEOF())
-  Disconnect(nullptr);
+EventSP event_sp;
+// Explicitly check for the thread exit, for the same reason.
+if (m_read_thread_did_exit) {
+  // We've missed the event, lets just conjure one up.
+  event_sp = std::make_shared(eBroadcastBitReadThreadDidExit);
+} else {
+  if (!listener_sp->GetEvent(event_sp, timeout)) {
+if (error_ptr)
+  error_ptr->SetErrorString("Timed out.");
+status = eConnectionStatusTimedOut;
 return 0;
   }
 }
+const uint32_t event_type = event_sp->GetType();
+if (event_type & eBroadcastBitReadThreadGotBytes) {
+  return GetCachedBytes(dst, dst_len);
+}
 
-if (error_ptr)
-  error_ptr->SetErrorString("Timed out.");
-status = eConnectionStatusTimedOut;
-return 0;
+if (event_type & eBroadcastBitReadThreadDidExit) {
+  // If the thread exited of its own accord, it either means it
+  // hit an end-of-file condition or an error.
+  status = m_pass_status;
+  if (error_ptr)
+*error_ptr = std::move(m_pass_error);
+
+  if (GetCloseOnEOF())
+Disconnect(nullptr);
+  return 0;
+}
+llvm_unreachable("Got unexpected event type!");
   }
 
   // We aren't using a read thread, just read the data synchronously in this
@@ -299,22 +315,25 @@ lldb::thread_result_t ThreadedCommunication::ReadThread() 
{
   m_pass_error = std::move(error);
   LLDB_LOG(log, "Communication({0}) thread exiting...", this);
 
-  // Handle threads wishing to synchronize with us.
-  {
-// Prevent new ones from showing up.
-m_read_thread_did_exit = true;
+  // Start shutting down. We need to do this in a very specific order to ensure
+  // we don't race with threads wanting to read/synchronize with us.
 
-// Unblock any existing thread waiting for the synchronization signal.
-BroadcastEvent(eBroadcastBitNoMorePendingInput);
+  // First, we signal our intent to exit. This ensures no new thread start
+  // waiting on events from us.
+  m_read_thread_did_exit = true;
 
-// Wait for the thread to finish...
+  // Unblock any existing thread waiting for the synchronization signal.
+  BroadcastEvent(eBroadcastBitNoMorePendingInput);
+
+  {
+// Wait for the synchronization thread to finish...
 std::lock_guard guard(m_synchronize_mutex);
 // ... and disconnect.
 if (disconnect)
   Disconnect();
   }
 
-  // Let clients know that this thread is exiting
+  // Finally, unblock any 

[Lldb-commits] [PATCH] D133164: Add the ability to show when variables fails to be available when debug info is valid.

2022-09-09 Thread Pavel Labath via Phabricator via lldb-commits
labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.

Looks good. Thanks.




Comment at: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:4161
+  if (command) {
+if (command->contains(" -gline-tables-only"))
+  return Status("-gline-tables-only enabled, no variable information is "

clayborg wrote:
> labath wrote:
> > clayborg wrote:
> > > labath wrote:
> > > > This isn't a particularly reliable way of detecting whether variable 
> > > > information was emitted. For example a command line `clang 
> > > > -gline-tables-only -g2` will in fact produce full debug info and `clang 
> > > > -g1` will not. Could we make that determination based on the presence 
> > > > of actual variable DIEs in the debug info? Perhaps query the index 
> > > > whether it knows of any (global) variable or any type defined within 
> > > > the compile unit?
> > > This function only gets called when there are no variables in a stack 
> > > frame at all and checks for reasons why. So if "-gline-tables-only -g2" 
> > > is used, this function won't get called if there were variables.
> > > 
> > > I planned to make a follow up patch that detected no variables in a 
> > > compile uint by checking the compile unit's abbreviation set to see if it 
> > > had any DW_TAG_variable or DW_TAG_formal_parameter definitions, and if 
> > > there weren't any respond with "-gline-tables-only might be enabled". 
> > > 
> > > If we see this option for sure and have the side affect of there being no 
> > > variables, I would like to user the users know what they can do to fix 
> > > things if at all possible. 
> > I get that, but this check is not completely correct in either direction. 
> > For example, `clang -g1` will not produce variable information, but this 
> > code will not detect it. Same goes for `clang -gmlt`. And I probably missed 
> > some other ways one can prevent variable info from being generated. Keeping 
> > up with all the changes in clang flags will just be a game of whack-a-mole. 
> > If we checked the actual debug info, then we would catch all of these 
> > cases, including the (default) case when the compiler did not embed command 
> > line information into the debug info.
> > 
> > And I don't think we need to know the precise command line to give 
> > meaningful advice to the users. In all of these cases, sticking an extra 
> > `-g` at the end of the command line will cause the variables to reappear. 
> > If we wanted to, we could also put a link to the lldb web page where we can 
> > (at length) describe the various reasons why variables may not be available 
> > and how to fix them.
> I switched over to just looking for any variable DIEs anywhere in the CU. 
> This should cover all options. Let me know if you think we should add a top 
> level web page and reference it in the error message?
I think it might be nice to have some kind of a "I can't debug" troubleshooting 
page, but I don't think we need to tie it to the future of this patch. 



Comment at: lldb/test/API/commands/frame/var/TestFrameVar.py:173
+'''
+self.build(dictionary={'CFLAGS_EXTRAS': '-gline-tables-only 
-grecord-command-line'})
+exe = self.getBuildArtifact("a.out")

I guess this isn't necessary any more.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133164

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


[Lldb-commits] [PATCH] D133461: [LLDB][NativePDB] Set block address range.

2022-09-09 Thread Pavel Labath via Phabricator via lldb-commits
labath added inline comments.



Comment at: lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp:372
+func->GetAddressRange().GetBaseAddress().GetFileAddress();
+Block::Range range = Block::Range(block_base - func_base, block.CodeSize);
+if (block_base >= func_base)

better move this inside the if block, so one does not have to think about what 
will happen when the address wraps around.



Comment at: lldb/test/Shell/SymbolFile/NativePDB/blocks.cpp:17
+
+// CHECK:  Function: id = {{.*}}, name = "main", range = 
[0x000140001000-0x00014000104b)
+// CHECK-NEXT: FuncType: id = {{.*}}, byte-size = 0, compiler_type = "int 
(void)"

I fear this test is going to be extremely fragile (susceptible to changes in 
codegen AND debug info generation). I'd probably write it in asm (you could 
even test the error msg then).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133461

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


[Lldb-commits] [PATCH] D133534: Complete support of loading a darwin kernel over a live gdb-remote connection given the address of a mach-o fileset

2022-09-09 Thread Pavel Labath via Phabricator via lldb-commits
labath added inline comments.



Comment at: lldb/unittests/Interpreter/CMakeLists.txt:17-18
   lldbInterpreter
+  lldbPluginDynamicLoaderDarwinKernel
+  lldbPluginObjectContainerMachOFileset
   lldbPluginPlatformMacOSX

These dependencies should be added to the PlatformDarwinKernel CMakeLists.txt, 
not to the every file that depends on it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133534

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


[Lldb-commits] [PATCH] D133519: Document some of the clang-specific DWARF extensions supported by LLDB

2022-09-09 Thread Pavel Labath via Phabricator via lldb-commits
labath accepted this revision.
labath added a comment.

cool




Comment at: lldb/docs/use/extensions.rst:84
+   DW_TAG_compile_unit
+ DW_AT_GNU_dwo_id  (0xabcdef)
+ DW_AT_GNU_dwo_name("M.pcm")

Michael137 wrote:
> Is it worth commenting on the difference to the `dwo` mechanism on Linux. 
> Since we aren't actually dealing with `dwo` files despite what the name 
> suggests
+1


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

https://reviews.llvm.org/D133519

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


[Lldb-commits] [PATCH] D133519: Document some of the clang-specific DWARF extensions supported by LLDB

2022-09-09 Thread Michael Buch via Phabricator via lldb-commits
Michael137 added inline comments.



Comment at: lldb/docs/use/extensions.rst:84
+   DW_TAG_compile_unit
+ DW_AT_GNU_dwo_id  (0xabcdef)
+ DW_AT_GNU_dwo_name("M.pcm")

Is it worth commenting on the difference to the `dwo` mechanism on Linux. Since 
we aren't actually dealing with `dwo` files despite what the name suggests


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

https://reviews.llvm.org/D133519

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


[Lldb-commits] [PATCH] D133519: Document some of the clang-specific DWARF extensions supported by LLDB

2022-09-09 Thread Michael Buch via Phabricator via lldb-commits
Michael137 accepted this revision.
Michael137 added a comment.
This revision is now accepted and ready to land.

LGTM


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

https://reviews.llvm.org/D133519

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


[Lldb-commits] [PATCH] D133530: [lldb] Add zstd support

2022-09-09 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

Seems fine to me, though you may want to have a llvm test for the new 
functionality, given that the patch is exclusively changing llvm code.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133530

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


[Lldb-commits] [PATCH] D133393: [test] Use either `127.0.0.1` or `[::1]` to run in ipv6-only environments.

2022-09-09 Thread Pavel Labath via Phabricator via lldb-commits
labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.

In D133393#3775995 , @rupprecht wrote:

> In D133393#3773793 , @labath wrote:
>
>> I believe the reasons are still relevant. Basically the problem is that 
>> listening on `localhost:x` creates two sockets (one for 127.0.0.1, one for 
>> ::1), and there's no way to guarantee that we'll be able to grab the same 
>> port for both (one could be taken by some other application). Our listening 
>> code will succeed if it opens at least one socket, but then if we again try 
>> to connect using the `localhost` name, we may end up connecting to the wrong 
>> thing. I think the correct fix is to take the address (ip+port) that we've 
>> *actually* started listening on, and then pass *that* as the argument to the 
>> connect command, but I'm not sure if our current Socket APIs allow you to 
>> get that information.
>
> There's `listen_socket.GetLocalIPAddress()`, but that returns an empty string 
> here.

Yeah, that probably only works on connected sockets.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133393

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


[Lldb-commits] [PATCH] D133446: [LLDB][NativePDB] Global ctor and dtor should be global decls.

2022-09-09 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

I believe that this fixes the crash, but the names of generated functions still 
look fairly weird. Could we create them using their mangled name instead? That 
way, someone might actually call them, if he was so inclined.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133446

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


[Lldb-commits] [PATCH] D133534: Complete support of loading a darwin kernel over a live gdb-remote connection given the address of a mach-o fileset

2022-09-09 Thread Jason Molenda via Phabricator via lldb-commits
jasonmolenda updated this revision to Diff 458970.
jasonmolenda added a comment.

Update the patch to address Jim's comments/suggestions.  Biggest change was to 
clean up how DynamicLoaderDarwinKernel filters out any kernels in the Target 
that don't match the UUID of the actually running kernel.  There was a vague 
attempt at this before, checking the target's ExecutableModule, but that 
assumes there was only one module loaded and it was the wrong kernel.  Easier 
to step through everything loaded in the target and eliminate these, and 
clearer what's being done.  I had the same sequence for detecting if a module 
is a kernel in a bunch of places so I added `module_is_a_kernel()` as a static 
function there.

I also renamed the method in Platform and PlatformList to 
`LoadSpecialBinaryAndSetDynamicLoader()`, to help make it clear that this is an 
uncommon use case, so someone doesn't try to use it for loading general 
binaries.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133534

Files:
  lldb/include/lldb/Target/Platform.h
  lldb/include/lldb/Target/Process.h
  lldb/source/Core/DynamicLoader.cpp
  lldb/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp
  lldb/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.cpp
  lldb/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.h
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
  lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
  lldb/source/Target/Platform.cpp
  lldb/source/Target/Process.cpp
  lldb/unittests/Core/CMakeLists.txt
  lldb/unittests/Interpreter/CMakeLists.txt
  lldb/unittests/Platform/CMakeLists.txt
  lldb/unittests/Process/CMakeLists.txt
  lldb/unittests/SymbolFile/DWARF/CMakeLists.txt

Index: lldb/unittests/SymbolFile/DWARF/CMakeLists.txt
===
--- lldb/unittests/SymbolFile/DWARF/CMakeLists.txt
+++ lldb/unittests/SymbolFile/DWARF/CMakeLists.txt
@@ -10,10 +10,12 @@
 lldbCore
 lldbHost
 lldbSymbol
+lldbPluginDynamicLoaderDarwinKernel
 lldbPluginObjectFilePECOFF
 lldbPluginSymbolFileDWARF
 lldbPluginSymbolFilePDB
 lldbPluginTypeSystemClang
+lldbPluginObjectContainerMachOFileset
 lldbPluginPlatformMacOSX
 lldbUtilityHelpers
 lldbSymbolHelpers
Index: lldb/unittests/Process/CMakeLists.txt
===
--- lldb/unittests/Process/CMakeLists.txt
+++ lldb/unittests/Process/CMakeLists.txt
@@ -17,5 +17,7 @@
   lldbUtility
   lldbUtilityHelpers
   lldbInterpreter
+  lldbPluginDynamicLoaderDarwinKernel
+  lldbPluginObjectContainerMachOFileset
   lldbPluginPlatformMacOSX
   )
Index: lldb/unittests/Platform/CMakeLists.txt
===
--- lldb/unittests/Platform/CMakeLists.txt
+++ lldb/unittests/Platform/CMakeLists.txt
@@ -6,6 +6,8 @@
   PlatformTest.cpp
 
   LINK_LIBS
+lldbPluginDynamicLoaderDarwinKernel
+lldbPluginObjectContainerMachOFileset
 lldbPluginPlatformFreeBSD
 lldbPluginPlatformLinux
 lldbPluginPlatformMacOSX
Index: lldb/unittests/Interpreter/CMakeLists.txt
===
--- lldb/unittests/Interpreter/CMakeLists.txt
+++ lldb/unittests/Interpreter/CMakeLists.txt
@@ -14,6 +14,8 @@
   lldbUtility
   lldbUtilityHelpers
   lldbInterpreter
+  lldbPluginDynamicLoaderDarwinKernel
+  lldbPluginObjectContainerMachOFileset
   lldbPluginPlatformMacOSX
   LLVMTestingSupport
 )
Index: lldb/unittests/Core/CMakeLists.txt
===
--- lldb/unittests/Core/CMakeLists.txt
+++ lldb/unittests/Core/CMakeLists.txt
@@ -14,9 +14,11 @@
   LINK_LIBS
 lldbCore
 lldbHost
+lldbPluginDynamicLoaderDarwinKernel
 lldbPluginObjectFileELF
 lldbPluginObjectFileMachO
 lldbPluginObjectFilePECOFF
+lldbPluginObjectContainerMachOFileset
 lldbPluginPlatformMacOSX
 lldbPluginSymbolFileSymtab
 lldbSymbol
Index: lldb/source/Target/Process.cpp
===
--- lldb/source/Target/Process.cpp
+++ lldb/source/Target/Process.cpp
@@ -2653,6 +2653,10 @@
   return m_dyld_up.get();
 }
 
+void Process::SetDynamicLoader(DynamicLoaderUP dyld_up) {
+  m_dyld_up = std::move(dyld_up);
+}
+
 DataExtractor Process::GetAuxvData() { return DataExtractor(); }
 
 llvm::Expected Process::SaveCore(llvm::StringRef outfile) {
Index: lldb/source/Target/Platform.cpp
===
--- lldb/source/Target/Platform.cpp
+++ lldb/source/Target/Platform.cpp
@@ -2079,3 +2079,23 @@
   m_platforms.push_back(platform_sp);
   return platform_sp;
 }
+
+bool PlatformList::LoadSpecialBinaryAndSetDynamicLoader(Process *process,
+

[Lldb-commits] [PATCH] D133038: Add SBDebugger::GetSetting() public API

2022-09-09 Thread Greg Clayton via Phabricator via lldb-commits
clayborg requested changes to this revision.
clayborg added inline comments.
This revision now requires changes to proceed.



Comment at: lldb/include/lldb/API/SBDebugger.h:119
+  /// Get all settings into SBStructuredData.
+  lldb::SBStructuredData GetSetting();
+

We still don't need two actual APIs in SBDebugger.h. Remove this.



Comment at: lldb/include/lldb/API/SBDebugger.h:136
+  ///
+  lldb::SBStructuredData GetSetting(const char *setting);
+

We can default "settings = nullptr" here so users can call without anything, 
but we should have only 1 API function for getting the settings.



Comment at: lldb/include/lldb/Interpreter/OptionValue.h:89
+  virtual llvm::json::Value ToJSON(const ExecutionContext *exe_ctx) {
+return nullptr;
+  }

Add a comment here. Suggested comment added.



Comment at: lldb/include/lldb/Interpreter/OptionValueChar.h:34-37
+if (m_current_value != '\0')
+  return m_current_value;
+else
+  return "(null)";

Since this is actually a character, it should store what ever the character 
value is. So if the character is zero, it should store zero, not a string 
"(null)"



Comment at: lldb/source/API/SBDebugger.cpp:439-443
+lldb::SBStructuredData SBDebugger::GetSetting() {
+  LLDB_INSTRUMENT_VA(this);
+  return GetSetting(nullptr);
+}
+

Remove this and only keep the one that takes a 'const char *setting"'



Comment at: lldb/source/Interpreter/OptionValueDictionary.cpp:92
+  }
+  return std::move(dict);
+}

I think this move can be removed? Watch for warnings here. Some buildbots have 
warnings as errors which could cause the submission to be reverted.



Comment at: lldb/test/API/commands/settings/TestSettings.py:799
+arg_value = "hello \"world\""
+self.runCmd('settings set target.arg0 %s' % arg_value)
+

We need to set a few more settings for anything we support the ToJSON for to 
ensure they function as expected.



Comment at: lldb/test/API/functionalities/source-map/TestTargetSourceMap.py:25
+src_dir = self.getSourceDir()
+self.runCmd('settings set target.source-map . "%s"' % src_dir)
+

hawkinsw wrote:
> yinghuitan wrote:
> > hawkinsw wrote:
> > > Sorry if this comment is not helpful, but I was wondering ...
> > > 
> > > Could we use `source_map_setting_path` here? That would make future 
> > > changes easier?
> > @hawkinsw, sorry, almost missed your comment. There is no single value for 
> > source map path but a pair of original/replacement. In this case, original 
> > is "." while the replacement is "src_dir" so I think src_dir makes sense 
> > here. 
> No problem! I am sorry I miscommunicated! I just meant, could we write 
> something like
> 
> ```
> self.runCmd('settings set %s . "%s"' % (source_map_setting_path, src_dir))
> ```
Good idea!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133038

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