[Lldb-commits] [PATCH] D132415: [LLDB] Add data formatter for std::coroutine_handle

2022-08-23 Thread Adrian Vogelsgesang via Phabricator via lldb-commits 
avogelsgesang updated this revision to Diff 454728.
avogelsgesang added a comment.

remove unrelated changes


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132415

Files:
  clang/docs/tools/clang-formatted-files.txt
  lldb/packages/Python/lldbsuite/test/lldbtest.py
  lldb/source/Plugins/Language/CPlusPlus/CMakeLists.txt
  lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
  lldb/source/Plugins/Language/CPlusPlus/Coroutines.cpp
  lldb/source/Plugins/Language/CPlusPlus/Coroutines.h
  
lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/Makefile
  
lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/TestCoroutineHandle.py
  
lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/main.cpp

Index: lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/main.cpp
===
--- /dev/null
+++ lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/main.cpp
@@ -0,0 +1,36 @@
+#include 
+
+// `int_generator` is a stripped down, minimal coroutine generator
+// type.
+struct int_generator {
+  struct promise_type {
+int current_value = -1;
+
+auto get_return_object() {
+  return std::coroutine_handle::from_promise(*this);
+}
+auto initial_suspend() { return std::suspend_always(); }
+auto final_suspend() noexcept { return std::suspend_always(); }
+auto return_void() { return std::suspend_always(); }
+void unhandled_exception() { __builtin_unreachable(); }
+auto yield_value(int v) {
+  current_value = v;
+  return std::suspend_always();
+}
+  };
+
+  std::coroutine_handle hdl;
+
+  int_generator(std::coroutine_handle h) : hdl(h) {}
+  ~int_generator() { hdl.destroy(); }
+};
+
+int_generator my_generator_func() { co_yield 42; }
+
+int main() {
+  int_generator gen = my_generator_func();
+  std::coroutine_handle<> type_erased_hdl = gen.hdl;
+  gen.hdl.resume(); // Break at initial_suspend
+  gen.hdl.resume(); // Break after co_yield
+  // Break at final_suspend
+}
Index: lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/TestCoroutineHandle.py
===
--- /dev/null
+++ lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/TestCoroutineHandle.py
@@ -0,0 +1,75 @@
+"""
+Test lldb data formatter subsystem.
+"""
+
+
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+USE_LIBSTDCPP = "USE_LIBSTDCPP"
+USE_LIBCPP = "USE_LIBCPP"
+
+class TestCoroutineHandle(TestBase):
+def do_test(self, stdlib_type):
+"""Test std::coroutine_handle is displayed correctly."""
+self.build(dictionary={stdlib_type: "1"})
+
+test_generator_func_ptr_re = re.compile(
+r"^\(a.out`my_generator_func\(\) at main.cpp:[0-9]*\)$")
+
+lldbutil.run_to_source_breakpoint(self, '// Break at initial_suspend',
+lldb.SBFileSpec("main.cpp", False))
+# Check that we show the correct function pointers and the `promise`. 
+self.expect_expr("gen.hdl",
+result_summary=re.compile("^coro frame = 0x[0-9a-f]*$"),
+result_children=[
+ValueCheck(name="resume", summary = test_generator_func_ptr_re),
+ValueCheck(name="destroy", summary = test_generator_func_ptr_re),
+ValueCheck(name="promise", children=[
+ValueCheck(name="current_value", value = "-1"),
+])
+])
+# For type-erased `coroutine_handle<>` we are missing the `promise`
+# but still show `resume` and `destroy`.
+self.expect_expr("type_erased_hdl",
+result_summary=re.compile("^coro frame = 0x[0-9a-f]*$"),
+result_children=[
+ValueCheck(name="resume", summary = test_generator_func_ptr_re),
+ValueCheck(name="destroy", summary = test_generator_func_ptr_re),
+])
+
+lldbutil.run_to_source_breakpoint(self, '// Break after co_yield',
+lldb.SBFileSpec("main.cpp", False))
+# We correctly show the updated value inside `prommise.current_value`.
+self.expect_expr("gen.hdl",
+result_children=[
+ValueCheck(name="resume", summary = test_generator_func_ptr_re),
+ValueCheck(name="destroy", summary = test_generator_func_ptr_re),
+ValueCheck(name="promise", children=[
+ValueCheck(name="current_value", value = "42"),
+])
+])
+
+lldbutil.run_to_source_breakpoint(self, '// Break at final_suspend',
+lldb.SB

[Lldb-commits] [PATCH] D131159: [lldb] Use WSAEventSelect for MainLoop polling on windows

2022-08-23 Thread Martin Storsjö via Phabricator via lldb-commits 
mstorsjo added a comment.

FYI, this patch added some new compilation warnings:

  [4055/7050] Building CXX object 
tools/lldb/source/Host/CMakeFiles/lldbHost.dir/windows/MainLoopWindows.cpp.obj
  llvm-project/lldb/source/Host/windows/MainLoopWindows.cpp:28:9: warning: 
unused variable 'result' [-Wunused-variable]
  int result = WSAEventSelect(fd, info.event, FD_READ | FD_ACCEPT | 
FD_CLOSE);
  ^
  llvm-project/lldb/source/Host/windows/MainLoopWindows.cpp:38:9: warning: 
unused variable 'result' [-Wunused-variable]
  int result = WSAEventSelect(fd.first, WSA_INVALID_EVENT, 0);
  ^
  llvm-project/lldb/source/Host/windows/MainLoopWindows.cpp:86:8: warning: 
unused variable 'result' [-Wunused-variable]
BOOL result = WSACloseEvent(it->second.event);
 ^
  3 warnings generated.

(They're only used in asserts.) I guess we should add void casts to mark the 
variables as used outside of asserts.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131159

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

[Lldb-commits] [PATCH] D132307: [lldb] Switch RegularExpression from llvm::Regex to std::regex

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



Comment at: lldb/source/Utility/CMakeLists.txt:29
+  PROPERTIES COMPILE_OPTIONS
+  "-fcxx-exceptions"
+)

kastiglione wrote:
> labath wrote:
> > kastiglione wrote:
> > > kastiglione wrote:
> > > > JDevlieghere wrote:
> > > > > kastiglione wrote:
> > > > > > the `std::regex` constructor throws `std::regex_error` if the 
> > > > > > pattern is invalid. For this reason, exceptions are enabled for 
> > > > > > this one file.
> > > > > What happens when exceptions are disabled? What does it mean to have 
> > > > > this enabled for a single file? I don't know if it's part of the LLVM 
> > > > > developer guide, but LLVM is supposed to build without RTTI and 
> > > > > without exceptions. 
> > > > > What happens when exceptions are disabled?
> > > > 
> > > > This cmake config enables exceptions for this one file, independent of 
> > > > `LLVM_ENABLE_EH`. No other source files will be allowed to catch or 
> > > > throw exceptions.
> > > > 
> > > > > What does it mean to have this enabled for a single file?
> > > > 
> > > > It means this file can compile with a try/catch, and that inside this 
> > > > file, exceptions can be caught.
> > > > 
> > > > > I don't know if it's part of the LLVM developer guide, but LLVM is 
> > > > > supposed to build without RTTI and without exceptions.
> > > > 
> > > > llvm has `LLVM_ENABLE_EH` which allows llvm to be built with exceptions 
> > > > support enabled. Similarly, `LLVM_ENABLE_RTTI` allows RTTI to be 
> > > > enabled. It seems that both are disabled as a default, but not as a 
> > > > hard requirement.
> > > > 
> > > > I wondered if enabling RTTI would needed for exceptions, but at least 
> > > > for this code, the answer is no. The `catch (const std::regex_error 
> > > > &e)` block is exercised by `TestBreakpointRegexError.py`, so we know 
> > > > this code can and does catch an exception of that type, and accesses 
> > > > the error's member functions.
> > > > 
> > > > 
> > > What makes me believe this use of exceptions is ok is that the API 
> > > boundary continues to be exception free, callers continue to be exception 
> > > disabled. Only the internal implementation, knows about exceptions.
> > That is definitely not ok. ODR madness awaits therein. The standard library 
> > is full of functions that effectively do
> > ```
> > #ifdef EXCEPTIONS
> >   something();
> > #else
> >   something_else();
> > #endif
> > ```
> > Compiling just one file with exceptions enabled can cause two different 
> > versions of those functions to appear. It is sufficient that this file 
> > instantiates one function whose behavior is dependent on exceptions being 
> > available. When linking, the linker has to choose one of the two versions, 
> > and there's no telling which one will it use. This means that exceptions 
> > can creep in into the supposedly exception-free code, or vice-versa.
> > 
> > The only way this would be safe is if this code was in a shared library, 
> > and we took care to restrict the visibility of all symbols except the 
> > exported api of that library. And I don't think that's worth it.
> @labath thanks for pointing that out. I had incomplete understanding and 
> thought it could still work, but I see now that it could be an issue.
> 
> > The only way this would be safe is if this code was in a shared library, 
> > and we took care to restrict the visibility of all symbols except the 
> > exported api of that library. And I don't think that's worth it.
> 
> what are your concerns with this approach?
> 
> btw I spoke to Louis Dionne of libc++ and he said that it could be possible 
> to include whether `-fno-exceptions` is used in the libc++ ABI tag, which 
> would allow mixing files built with and without exceptions.
> > The only way this would be safe is if this code was in a shared library, 
> > and we took care to restrict the visibility of all symbols except the 
> > exported api of that library. And I don't think that's worth it.
> 
> what are your concerns with this approach?

Well.. I don't even know where to start.

For one, since a shared library is a shippable artifact, it requires adjustment 
to all distribution methods up- and down-stream. I know this would definitely 
be an issue for us, since google's internal build system has a strong distaste 
for shared libraries. This is more on the extreme end, but I expect that most 
of the other build/deployment systems would need to be adjusted as well.

Now you should shrug that off as a "downstream problem", but there's also 
something to be said about consistency. Even as things stand now, LLDB is 
pretty much the only llvm component, which _requires_ to be built with shared 
libraries. For this case, we at least have a fairly good reason for it -- 
python extension modules must be shared libraries (although one could still 
imagine building a extension-free lldb in static mode). Everything else in llvm 
works both in static and in dynamic mod

[Lldb-commits] [PATCH] D131159: [lldb] Use WSAEventSelect for MainLoop polling on windows

2022-08-23 Thread Michał Górny via Phabricator via lldb-commits 
mgorny added a comment.

In D131159#3742235 , @mstorsjo wrote:

> (They're only used in asserts.) I guess we should add void casts to mark the 
> variables as used outside of asserts.

Actually, there's a dedicated `UNUSED_IF_ASSERT_DISABLED` macro for that. 
Please use it instead.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131159

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

[Lldb-commits] [PATCH] D132395: [lldb] [gdb-remote] Use Communication::WriteAll() over Write()

2022-08-23 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.

> Ideally, we'd remove Write() from the public API.

That might be a bit too extreme. Although I agree that the "All" version is 
what one wants in most cases, there are use cases (and plenty of historical 
precedent) for the other version.

I could imagine renaming things such that one is discouraged (or at least 
forced to think) from using automatically the `Write` function. Maybe call it 
`WriteSome`, `WritePartial`, ...

However we'd also need to think about consistency with all our other classes 
which have `Write` methods.


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

https://reviews.llvm.org/D132395

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

[Lldb-commits] [PATCH] D131159: [lldb] Use WSAEventSelect for MainLoop polling on windows

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

In D131159#3742364 , @mgorny wrote:

> In D131159#3742235 , @mstorsjo 
> wrote:
>
>> (They're only used in asserts.) I guess we should add void casts to mark the 
>> variables as used outside of asserts.
>
> Actually, there's a dedicated `UNUSED_IF_ASSERT_DISABLED` macro for that. 
> Please use it instead.

One of these days, I'm going to have to delete it. If void casts are good 
enough for the rest of llvm, I don't see why should we be any different.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131159

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

[Lldb-commits] [PATCH] D132395: [lldb] [gdb-remote] Use Communication::WriteAll() over Write()

2022-08-23 Thread Michał Górny via Phabricator via lldb-commits 
This revision was automatically updated to reflect the committed changes.
Closed by commit rG03b8f79048bf: [lldb] [gdb-remote] Use 
Communication::WriteAll() over Write() (authored by mgorny).
Herald added a project: LLDB.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132395

Files:
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
  lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
  lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationTest.cpp


Index: lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationTest.cpp
===
--- lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationTest.cpp
+++ lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationTest.cpp
@@ -39,7 +39,7 @@
 
   bool Write(llvm::StringRef packet) {
 ConnectionStatus status;
-return server.Write(packet.data(), packet.size(), status, nullptr) ==
+return server.WriteAll(packet.data(), packet.size(), status, nullptr) ==
packet.size();
   }
 };
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
@@ -2880,7 +2880,7 @@
   Status &error) {
   if (m_stdio_communication.IsConnected()) {
 ConnectionStatus status;
-m_stdio_communication.Write(src, src_len, status, nullptr);
+m_stdio_communication.WriteAll(src, src_len, status, nullptr);
   } else if (m_stdin_forward) {
 m_gdb_comm.SendStdinNotification(src, src_len);
   }
Index: 
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
===
--- lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
+++ lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
@@ -2441,7 +2441,7 @@
 // remote host
 ConnectionStatus status;
 Status error;
-m_stdio_communication.Write(tmp, read, status, &error);
+m_stdio_communication.WriteAll(tmp, read, status, &error);
 if (error.Fail()) {
   return SendErrorResponse(0x15);
 }


Index: lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationTest.cpp
===
--- lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationTest.cpp
+++ lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationTest.cpp
@@ -39,7 +39,7 @@
 
   bool Write(llvm::StringRef packet) {
 ConnectionStatus status;
-return server.Write(packet.data(), packet.size(), status, nullptr) ==
+return server.WriteAll(packet.data(), packet.size(), status, nullptr) ==
packet.size();
   }
 };
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
@@ -2880,7 +2880,7 @@
   Status &error) {
   if (m_stdio_communication.IsConnected()) {
 ConnectionStatus status;
-m_stdio_communication.Write(src, src_len, status, nullptr);
+m_stdio_communication.WriteAll(src, src_len, status, nullptr);
   } else if (m_stdin_forward) {
 m_gdb_comm.SendStdinNotification(src, src_len);
   }
Index: lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
===
--- lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
+++ lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
@@ -2441,7 +2441,7 @@
 // remote host
 ConnectionStatus status;
 Status error;
-m_stdio_communication.Write(tmp, read, status, &error);
+m_stdio_communication.WriteAll(tmp, read, status, &error);
 if (error.Fail()) {
   return SendErrorResponse(0x15);
 }
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] 03b8f79 - [lldb] [gdb-remote] Use Communication::WriteAll() over Write()

2022-08-23 Thread Michał Górny via lldb-commits 

Author: Michał Górny
Date: 2022-08-23T15:49:16+02:00
New Revision: 03b8f79048bfc32ade0404df3d3931266a06dc92

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

LOG: [lldb] [gdb-remote] Use Communication::WriteAll() over Write()

Replace the uses of Communication::Write() with WriteAll() to avoid
partial writes.  None of the call sites actually accounted for that
possibility and even if it is unlikely to actually happen, there doesn't
seem to be any real harm from using WriteAll() instead.

Ideally, we'd remove Write() from the public API.  However, that would
change the API of SBCommunication.  The alternative would be to alias it
to WriteAll().

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

Added: 


Modified: 
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationTest.cpp

Removed: 




diff  --git 
a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp 
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
index 34753d5f8128a..bc9ccad29afb1 100644
--- 
a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
+++ 
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
@@ -2441,7 +2441,7 @@ 
GDBRemoteCommunicationServerLLGS::Handle_I(StringExtractorGDBRemote &packet) {
 // remote host
 ConnectionStatus status;
 Status error;
-m_stdio_communication.Write(tmp, read, status, &error);
+m_stdio_communication.WriteAll(tmp, read, status, &error);
 if (error.Fail()) {
   return SendErrorResponse(0x15);
 }

diff  --git a/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp 
b/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
index fbc7ab9180e77..37272d3afabd3 100644
--- a/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -2880,7 +2880,7 @@ size_t ProcessGDBRemote::PutSTDIN(const char *src, size_t 
src_len,
   Status &error) {
   if (m_stdio_communication.IsConnected()) {
 ConnectionStatus status;
-m_stdio_communication.Write(src, src_len, status, nullptr);
+m_stdio_communication.WriteAll(src, src_len, status, nullptr);
   } else if (m_stdin_forward) {
 m_gdb_comm.SendStdinNotification(src, src_len);
   }

diff  --git a/lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationTest.cpp 
b/lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationTest.cpp
index 4289a8393808f..7b17ec98a5cb4 100644
--- a/lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationTest.cpp
+++ b/lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationTest.cpp
@@ -39,7 +39,7 @@ class GDBRemoteCommunicationTest : public GDBRemoteTest {
 
   bool Write(llvm::StringRef packet) {
 ConnectionStatus status;
-return server.Write(packet.data(), packet.size(), status, nullptr) ==
+return server.WriteAll(packet.data(), packet.size(), status, nullptr) ==
packet.size();
   }
 };



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

[Lldb-commits] [PATCH] D132316: [CMake] `${LLVM_BINARY_DIR}/lib(${LLVM_LIBDIR_SUFFIX})?` -> `${LLVM_LIBRARY_DIR}`

2022-08-23 Thread John Ericson via Phabricator via lldb-commits 
Ericson2314 updated this revision to Diff 454829.
Ericson2314 added a comment.

Redo sed mandating ending on word boundary


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132316

Files:
  bolt/lib/Target/AArch64/CMakeLists.txt
  bolt/lib/Target/X86/CMakeLists.txt
  bolt/unittests/Core/CMakeLists.txt
  clang/cmake/modules/CMakeLists.txt
  clang/lib/Tooling/CMakeLists.txt
  flang/cmake/modules/CMakeLists.txt
  lld/cmake/modules/CMakeLists.txt
  lldb/cmake/modules/LLDBConfig.cmake
  llvm/CMakeLists.txt
  llvm/cmake/modules/AddLLVM.cmake
  llvm/cmake/modules/CMakeLists.txt
  llvm/tools/llvm-exegesis/lib/AArch64/CMakeLists.txt
  llvm/tools/llvm-exegesis/lib/Mips/CMakeLists.txt
  llvm/tools/llvm-exegesis/lib/PowerPC/CMakeLists.txt
  llvm/tools/llvm-exegesis/lib/X86/CMakeLists.txt
  llvm/unittests/Target/ARM/CMakeLists.txt
  llvm/unittests/Target/DirectX/CMakeLists.txt
  llvm/unittests/tools/llvm-exegesis/AArch64/CMakeLists.txt
  llvm/unittests/tools/llvm-exegesis/ARM/CMakeLists.txt
  llvm/unittests/tools/llvm-exegesis/Mips/CMakeLists.txt
  llvm/unittests/tools/llvm-exegesis/PowerPC/CMakeLists.txt
  llvm/unittests/tools/llvm-exegesis/X86/CMakeLists.txt
  llvm/unittests/tools/llvm-mca/X86/CMakeLists.txt
  mlir/cmake/modules/CMakeLists.txt
  polly/cmake/CMakeLists.txt
  polly/test/CMakeLists.txt

Index: polly/test/CMakeLists.txt
===
--- polly/test/CMakeLists.txt
+++ polly/test/CMakeLists.txt
@@ -46,7 +46,7 @@
 
 set(LLVM_BINARY_DIR "${LLVM_BINARY_DIR}")
 set(LLVM_TOOLS_DIR "${LLVM_TOOLS_BINARY_DIR}")
-set(LLVM_LIBS_DIR "${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}")
+set(LLVM_LIBS_DIR "${LLVM_LIBRARY_DIR}")
 if (CMAKE_LIBRARY_OUTPUT_DIRECTORY)
   set(POLLY_LIB_DIR ${CMAKE_LIBRARY_OUTPUT_DIRECTORY})
 else()
Index: polly/cmake/CMakeLists.txt
===
--- polly/cmake/CMakeLists.txt
+++ polly/cmake/CMakeLists.txt
@@ -12,7 +12,7 @@
 set(LLVM_INSTALL_PACKAGE_DIR "${CMAKE_INSTALL_PACKAGEDIR}/llvm" CACHE STRING
   "Path for CMake subdirectory for LLVM (defaults to '${CMAKE_INSTALL_PACKAGEDIR}/llvm')")
 # CMAKE_INSTALL_PACKAGEDIR might be absolute, so don't reuse below.
-set(llvm_cmake_builddir "${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/cmake/llvm")
+set(llvm_cmake_builddir "${LLVM_LIBRARY_DIR}/cmake/llvm")
 
 if (CMAKE_CONFIGURATION_TYPES)
   set(POLLY_EXPORTS_FILE_NAME "PollyExports-$>.cmake")
Index: mlir/cmake/modules/CMakeLists.txt
===
--- mlir/cmake/modules/CMakeLists.txt
+++ mlir/cmake/modules/CMakeLists.txt
@@ -15,7 +15,7 @@
 set(LLVM_INSTALL_PACKAGE_DIR "${CMAKE_INSTALL_PACKAGEDIR}/llvm" CACHE STRING
   "Path for CMake subdirectory for LLVM (defaults to '${CMAKE_INSTALL_PACKAGEDIR}/llvm')")
 # CMAKE_INSTALL_PACKAGEDIR might be absolute, so don't reuse below.
-set(llvm_cmake_builddir "${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/cmake/llvm")
+set(llvm_cmake_builddir "${LLVM_LIBRARY_DIR}/cmake/llvm")
 
 get_property(MLIR_EXPORTS GLOBAL PROPERTY MLIR_EXPORTS)
 export(TARGETS ${MLIR_EXPORTS} FILE ${mlir_cmake_builddir}/MLIRTargets.cmake)
Index: llvm/unittests/tools/llvm-mca/X86/CMakeLists.txt
===
--- llvm/unittests/tools/llvm-mca/X86/CMakeLists.txt
+++ llvm/unittests/tools/llvm-mca/X86/CMakeLists.txt
@@ -1,6 +1,6 @@
 add_llvm_mca_unittest_includes(
   ${LLVM_MAIN_SRC_DIR}/lib/Target/X86
-  ${LLVM_BINARY_DIR}/lib/Target/X86
+  ${LLVM_LIBRARY_DIR}/Target/X86
   )
 
 add_llvm_mca_unittest_sources(
Index: llvm/unittests/tools/llvm-exegesis/X86/CMakeLists.txt
===
--- llvm/unittests/tools/llvm-exegesis/X86/CMakeLists.txt
+++ llvm/unittests/tools/llvm-exegesis/X86/CMakeLists.txt
@@ -1,6 +1,6 @@
 add_llvm_exegesis_unittest_includes(
   ${LLVM_MAIN_SRC_DIR}/lib/Target/X86
-  ${LLVM_BINARY_DIR}/lib/Target/X86
+  ${LLVM_LIBRARY_DIR}/Target/X86
   ${LLVM_MAIN_SRC_DIR}/tools/llvm-exegesis/lib
   )
 
Index: llvm/unittests/tools/llvm-exegesis/PowerPC/CMakeLists.txt
===
--- llvm/unittests/tools/llvm-exegesis/PowerPC/CMakeLists.txt
+++ llvm/unittests/tools/llvm-exegesis/PowerPC/CMakeLists.txt
@@ -1,6 +1,6 @@
 add_llvm_exegesis_unittest_includes(
   ${LLVM_MAIN_SRC_DIR}/lib/Target/PowerPC
-  ${LLVM_BINARY_DIR}/lib/Target/PowerPC
+  ${LLVM_LIBRARY_DIR}/Target/PowerPC
   ${LLVM_MAIN_SRC_DIR}/tools/llvm-exegesis/lib
   )
 
Index: llvm/unittests/tools/llvm-exegesis/Mips/CMakeLists.txt
===
--- llvm/unittests/tools/llvm-exegesis/Mips/CMakeLists.txt
+++ llvm/unittests/tools/llvm-exegesis/Mips/CMakeLists.txt
@@ -1,6 +1,6 @@
 add_llvm_exegesis_unittest_includes(
   ${LLVM_MAIN_SRC_DIR}/lib/Target/Mips
-  ${LLVM_BINARY_DIR}/lib/

[Lldb-commits] [PATCH] D132415: [LLDB] Add data formatter for std::coroutine_handle

2022-08-23 Thread Adrian Vogelsgesang via Phabricator via lldb-commits 
avogelsgesang updated this revision to Diff 454830.
avogelsgesang added a comment.

clang-format


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132415

Files:
  clang/docs/tools/clang-formatted-files.txt
  lldb/packages/Python/lldbsuite/test/lldbtest.py
  lldb/source/Plugins/Language/CPlusPlus/CMakeLists.txt
  lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
  lldb/source/Plugins/Language/CPlusPlus/Coroutines.cpp
  lldb/source/Plugins/Language/CPlusPlus/Coroutines.h
  
lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/Makefile
  
lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/TestCoroutineHandle.py
  
lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/main.cpp

Index: lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/main.cpp
===
--- /dev/null
+++ lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/main.cpp
@@ -0,0 +1,36 @@
+#include 
+
+// `int_generator` is a stripped down, minimal coroutine generator
+// type.
+struct int_generator {
+  struct promise_type {
+int current_value = -1;
+
+auto get_return_object() {
+  return std::coroutine_handle::from_promise(*this);
+}
+auto initial_suspend() { return std::suspend_always(); }
+auto final_suspend() noexcept { return std::suspend_always(); }
+auto return_void() { return std::suspend_always(); }
+void unhandled_exception() { __builtin_unreachable(); }
+auto yield_value(int v) {
+  current_value = v;
+  return std::suspend_always();
+}
+  };
+
+  std::coroutine_handle hdl;
+
+  int_generator(std::coroutine_handle h) : hdl(h) {}
+  ~int_generator() { hdl.destroy(); }
+};
+
+int_generator my_generator_func() { co_yield 42; }
+
+int main() {
+  int_generator gen = my_generator_func();
+  std::coroutine_handle<> type_erased_hdl = gen.hdl;
+  gen.hdl.resume(); // Break at initial_suspend
+  gen.hdl.resume(); // Break after co_yield
+  // Break at final_suspend
+}
Index: lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/TestCoroutineHandle.py
===
--- /dev/null
+++ lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/TestCoroutineHandle.py
@@ -0,0 +1,75 @@
+"""
+Test lldb data formatter subsystem.
+"""
+
+
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+USE_LIBSTDCPP = "USE_LIBSTDCPP"
+USE_LIBCPP = "USE_LIBCPP"
+
+class TestCoroutineHandle(TestBase):
+def do_test(self, stdlib_type):
+"""Test std::coroutine_handle is displayed correctly."""
+self.build(dictionary={stdlib_type: "1"})
+
+test_generator_func_ptr_re = re.compile(
+r"^\(a.out`my_generator_func\(\) at main.cpp:[0-9]*\)$")
+
+lldbutil.run_to_source_breakpoint(self, '// Break at initial_suspend',
+lldb.SBFileSpec("main.cpp", False))
+# Check that we show the correct function pointers and the `promise`. 
+self.expect_expr("gen.hdl",
+result_summary=re.compile("^coro frame = 0x[0-9a-f]*$"),
+result_children=[
+ValueCheck(name="resume", summary = test_generator_func_ptr_re),
+ValueCheck(name="destroy", summary = test_generator_func_ptr_re),
+ValueCheck(name="promise", children=[
+ValueCheck(name="current_value", value = "-1"),
+])
+])
+# For type-erased `coroutine_handle<>` we are missing the `promise`
+# but still show `resume` and `destroy`.
+self.expect_expr("type_erased_hdl",
+result_summary=re.compile("^coro frame = 0x[0-9a-f]*$"),
+result_children=[
+ValueCheck(name="resume", summary = test_generator_func_ptr_re),
+ValueCheck(name="destroy", summary = test_generator_func_ptr_re),
+])
+
+lldbutil.run_to_source_breakpoint(self, '// Break after co_yield',
+lldb.SBFileSpec("main.cpp", False))
+# We correctly show the updated value inside `prommise.current_value`.
+self.expect_expr("gen.hdl",
+result_children=[
+ValueCheck(name="resume", summary = test_generator_func_ptr_re),
+ValueCheck(name="destroy", summary = test_generator_func_ptr_re),
+ValueCheck(name="promise", children=[
+ValueCheck(name="current_value", value = "42"),
+])
+])
+
+lldbutil.run_to_source_breakpoint(self, '// Break at final_suspend',
+lldb.SBFileSpec("ma

[Lldb-commits] [PATCH] D132316: [CMake] `${LLVM_BINARY_DIR}/lib(${LLVM_LIBDIR_SUFFIX})?` -> `${LLVM_LIBRARY_DIR}`

2022-08-23 Thread John Ericson via Phabricator via lldb-commits 
Ericson2314 marked an inline comment as done.
Ericson2314 added inline comments.



Comment at: llvm/tools/llvm-shlib/CMakeLists.txt:91
 
   set(LIB_DIR ${LLVM_BINARY_DIR}/${CMAKE_CFG_INTDIR}/lib${LLVM_LIBDIR_SUFFIX})
   set(LIB_NAME ${LIB_DIR}/${CMAKE_SHARED_LIBRARY_PREFIX}LLVM)

sebastian-ne wrote:
> Should this be `set(LIB_DIR ${LLVM_LIBRARY_DIR})`?
I am not sure what is up with `CMAKE_CFG_INTDIR`, so I rather leave that for a 
later revision.



Comment at: llvm/tools/llvm-shlib/CMakeLists.txt:139
   foreach(lib ${LIB_NAMES})
 list(APPEND FULL_LIB_NAMES 
${LLVM_BINARY_DIR}/${CMAKE_CFG_INTDIR}/lib/${lib}.lib)
   endforeach()

sebastian-ne wrote:
> This should probably use LLVM_LIBRARY_DIR as well.
Ditto, rather tackle things with `CMAKE_CFG_INTDIR` separately.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132316

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

[Lldb-commits] [PATCH] D132316: [CMake] `${LLVM_BINARY_DIR}/lib(${LLVM_LIBDIR_SUFFIX})?` -> `${LLVM_LIBRARY_DIR}`

2022-08-23 Thread Sebastian Neubauer via Phabricator via lldb-commits 
sebastian-ne added inline comments.



Comment at: llvm/tools/llvm-shlib/CMakeLists.txt:91
 
   set(LIB_DIR ${LLVM_BINARY_DIR}/${CMAKE_CFG_INTDIR}/lib${LLVM_LIBDIR_SUFFIX})
   set(LIB_NAME ${LIB_DIR}/${CMAKE_SHARED_LIBRARY_PREFIX}LLVM)

Ericson2314 wrote:
> sebastian-ne wrote:
> > Should this be `set(LIB_DIR ${LLVM_LIBRARY_DIR})`?
> I am not sure what is up with `CMAKE_CFG_INTDIR`, so I rather leave that for 
> a later revision.
`LLVM_LIBRARY_DIR` includes `CMAKE_CFG_INTDIR` as it’s set through
```
set(LLVM_LIBRARY_OUTPUT_INTDIR 
${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_CFG_INTDIR}/lib${LLVM_LIBDIR_SUFFIX})
set(LLVM_LIBRARY_DIR  ${LLVM_LIBRARY_OUTPUT_INTDIR})
```

As far as I understand, `CMAKE_CFG_INTDIR` is set to `.`, unless one does a 
multi-config build, i.e. one build directory for debug and release builds. 
multi-config builds are the default when creating Visual Studio solutions and 
ninja supports multi-config builds since some time (rather recently).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132316

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

[Lldb-commits] [PATCH] D132395: [lldb] [gdb-remote] Use Communication::WriteAll() over Write()

2022-08-23 Thread Michał Górny via Phabricator via lldb-commits 
mgorny added a comment.
Herald added a subscriber: JDevlieghere.

In D132395#3742365 , @labath wrote:

>> Ideally, we'd remove Write() from the public API.
>
> That might be a bit too extreme. Although I agree that the "All" version is 
> what one wants in most cases, there are use cases (and plenty of historical 
> precedent) for the other version.

To be honest, I can't think of a real use case where aliasing `Write()` to 
`WriteAll()` would make a caller-visible difference. I mean, `Write()` could 
technically write less but isn't guaranteed to, right? So if `Write()` started 
using `WriteAll()` internally, would there be any real difference, except for 
the technical difference in how it works internally (and perhaps some 
performance loss if someone specifically didn't need the `WriteAll()` behavior)?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132395

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

[Lldb-commits] [PATCH] D132415: [LLDB] Add data formatter for std::coroutine_handle

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



Comment at: lldb/source/Plugins/Language/CPlusPlus/Coroutines.h:1
+//===-- Coroutines.h ---*- 
C++//-*-===//
+//

typo: `-*- C++ -*-`



Comment at: lldb/source/Plugins/Language/CPlusPlus/Coroutines.h:20
+
+// libc++, libstdc++ and MSVC STL: std::coroutine_handle
+bool StdlibCoroutineHandleSummaryProvider(ValueObject &valobj, Stream &stream,

Can you convert this to a slightly more verbose Doxygen comment? It's not clear 
to me what exactly this comment means.



Comment at: lldb/source/Plugins/Language/CPlusPlus/Coroutines.h:21
+// libc++, libstdc++ and MSVC STL: std::coroutine_handle
+bool StdlibCoroutineHandleSummaryProvider(ValueObject &valobj, Stream &stream,
+  const TypeSummaryOptions &options);

It would be nice to add Doxygen comments here, too. At least for the class 
itself.



Comment at: 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/TestCoroutineHandle.py:15
+
+class TestCoroutineHandle(TestBase):
+def do_test(self, stdlib_type):

Nice test!



Comment at: 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/TestCoroutineHandle.py:44
+
+lldbutil.run_to_source_breakpoint(self, '// Break after co_yield',
+lldb.SBFileSpec("main.cpp", False))

Does this launch a new process? It might be faster to just set an additional 
breakpoint and run `process.Continue()`.



Comment at: 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/main.cpp:35
+  gen.hdl.resume(); // Break after co_yield
+  // Break at final_suspend
+}

This looks risky, can you add a call to an empty function here, so we can be 
reasonably sure that there is code at this line?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132415

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

[Lldb-commits] [PATCH] D132415: [LLDB] Add data formatter for std::coroutine_handle

2022-08-23 Thread Adrian Vogelsgesang via Phabricator via lldb-commits 
avogelsgesang updated this revision to Diff 454911.
avogelsgesang marked 6 inline comments as done.
avogelsgesang added a comment.

addressed comments from @aprantl


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132415

Files:
  clang/docs/tools/clang-formatted-files.txt
  lldb/packages/Python/lldbsuite/test/lldbtest.py
  lldb/source/Plugins/Language/CPlusPlus/CMakeLists.txt
  lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
  lldb/source/Plugins/Language/CPlusPlus/Coroutines.cpp
  lldb/source/Plugins/Language/CPlusPlus/Coroutines.h
  
lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/Makefile
  
lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/TestCoroutineHandle.py
  
lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/main.cpp

Index: lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/main.cpp
===
--- /dev/null
+++ lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/main.cpp
@@ -0,0 +1,40 @@
+#include 
+
+// `int_generator` is a stripped down, minimal coroutine generator
+// type.
+struct int_generator {
+  struct promise_type {
+int current_value = -1;
+
+auto get_return_object() {
+  return std::coroutine_handle::from_promise(*this);
+}
+auto initial_suspend() { return std::suspend_always(); }
+auto final_suspend() noexcept { return std::suspend_always(); }
+auto return_void() { return std::suspend_always(); }
+void unhandled_exception() { __builtin_unreachable(); }
+auto yield_value(int v) {
+  current_value = v;
+  return std::suspend_always();
+}
+  };
+
+  std::coroutine_handle hdl;
+
+  int_generator(std::coroutine_handle h) : hdl(h) {}
+  ~int_generator() { hdl.destroy(); }
+};
+
+int_generator my_generator_func() { co_yield 42; }
+
+// This is an empty function which we call just so the debugger has
+// a place to reliably set a breakpoint on.
+void empty_function_so_we_can_set_a_breakpoint() {}
+
+int main() {
+  int_generator gen = my_generator_func();
+  std::coroutine_handle<> type_erased_hdl = gen.hdl;
+  gen.hdl.resume(); // Break at initial_suspend
+  gen.hdl.resume(); // Break after co_yield
+  empty_function_so_we_can_set_a_breakpoint(); // Break at final_suspend
+}
Index: lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/TestCoroutineHandle.py
===
--- /dev/null
+++ lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/TestCoroutineHandle.py
@@ -0,0 +1,87 @@
+"""
+Test lldb data formatter subsystem.
+"""
+
+
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+USE_LIBSTDCPP = "USE_LIBSTDCPP"
+USE_LIBCPP = "USE_LIBCPP"
+
+class TestCoroutineHandle(TestBase):
+def continue_to_source_breakpoint(self, bkpt_pattern, source_spec):
+target = self.target()
+breakpoint = target.BreakpointCreateBySourceRegex(
+bkpt_pattern, source_spec, None)
+self.assertTrue(breakpoint, VALID_BREAKPOINT)
+threads = lldbutil.continue_to_breakpoint(self.process(), breakpoint)
+self.assertEqual(len(threads), 1)
+
+
+def do_test(self, stdlib_type):
+"""Test std::coroutine_handle is displayed correctly."""
+self.build(dictionary={stdlib_type: "1"})
+
+test_generator_func_ptr_re = re.compile(
+r"^\(a.out`my_generator_func\(\) at main.cpp:[0-9]*\)$")
+
+# Run until the initial suspension point
+lldbutil.run_to_source_breakpoint(self, '// Break at initial_suspend',
+lldb.SBFileSpec("main.cpp", False))
+# Check that we show the correct function pointers and the `promise`. 
+self.expect_expr("gen.hdl",
+result_summary=re.compile("^coro frame = 0x[0-9a-f]*$"),
+result_children=[
+ValueCheck(name="resume", summary = test_generator_func_ptr_re),
+ValueCheck(name="destroy", summary = test_generator_func_ptr_re),
+ValueCheck(name="promise", children=[
+ValueCheck(name="current_value", value = "-1"),
+])
+])
+# For type-erased `coroutine_handle<>` we are missing the `promise`
+# but still show `resume` and `destroy`.
+self.expect_expr("type_erased_hdl",
+result_summary=re.compile("^coro frame = 0x[0-9a-f]*$"),
+result_children=[
+ValueCheck(name="resume", summary = test_generator_func_ptr_re),
+ValueCheck(name="destroy", summary = test_generator_func_ptr_re),
+

[Lldb-commits] [PATCH] D131159: [lldb] Use WSAEventSelect for MainLoop polling on windows

2022-08-23 Thread Martin Storsjö via Phabricator via lldb-commits 
mstorsjo added a comment.

In D131159#3742370 , @labath wrote:

> In D131159#3742364 , @mgorny wrote:
>
>> In D131159#3742235 , @mstorsjo 
>> wrote:
>>
>>> (They're only used in asserts.) I guess we should add void casts to mark 
>>> the variables as used outside of asserts.
>>
>> Actually, there's a dedicated `UNUSED_IF_ASSERT_DISABLED` macro for that. 
>> Please use it instead.
>
> One of these days, I'm going to have to delete it. If void casts are good 
> enough for the rest of llvm, I don't see why should we be any different.

Ok, so is this discussion settled and I can go ahead and use void casts for 
these trivial fixups? (I usually just push such patches directly without 
passing via review.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131159

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

[Lldb-commits] [PATCH] D132415: [LLDB] Add data formatter for std::coroutine_handle

2022-08-23 Thread Adrian Vogelsgesang via Phabricator via lldb-commits 
avogelsgesang marked an inline comment as done.
avogelsgesang added inline comments.



Comment at: 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/TestCoroutineHandle.py:44
+
+lldbutil.run_to_source_breakpoint(self, '// Break after co_yield',
+lldb.SBFileSpec("main.cpp", False))

aprantl wrote:
> Does this launch a new process? It might be faster to just set an additional 
> breakpoint and run `process.Continue()`.
somehow, I assumed `run_to_source_breakpoint` would actually continue the 
running process instead of starting a new process. But looking into 
`run_to_source_breakpoint`, you are right, this launches a new process...

I changed this to instead continue execution of the already launched process


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132415

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

[Lldb-commits] [PATCH] D132433: [lldb] Teach LLDB about filesets (WIP)

2022-08-23 Thread Jason Molenda via Phabricator via lldb-commits 
jasonmolenda accepted this revision.
jasonmolenda added a comment.
This revision is now accepted and ready to land.

This all looks great.

I am working on a patch that will build on this, but I will be working with a 
memory image which needs the `CreateMemoryInstance()` ObjectFile interface 
implemented, and in my case, I'm very much hoping to avoid reading the entire 
fileset out of memory -- I'd like it if we don't read more than the mach header 
& load commands from the fileset, so I can query for a single entry by name in 
the fileset (e.g. "com.apple.kernel").  If the memory 
ObjectContainerMachOFileset created a memory ObjectFile for that name, that's 
fine, I'll be reading it from memory soon to get the UUID anyway out of the 
load commands.  (ObjectFileMachO will only read the header + load commands for 
a memory module, until you touch the symbol table.)


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

https://reviews.llvm.org/D132433

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

[Lldb-commits] [PATCH] D132316: [CMake] `${LLVM_BINARY_DIR}/lib(${LLVM_LIBDIR_SUFFIX})?` -> `${LLVM_LIBRARY_DIR}`

2022-08-23 Thread John Ericson via Phabricator via lldb-commits 
Ericson2314 updated this revision to Diff 454982.
Ericson2314 added a comment.

Convert `CMAKE_CFG_INTDIR` as @sebastian-ne suggests, also .../bin


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132316

Files:
  bolt/lib/Target/AArch64/CMakeLists.txt
  bolt/lib/Target/X86/CMakeLists.txt
  bolt/unittests/Core/CMakeLists.txt
  clang/cmake/modules/CMakeLists.txt
  clang/lib/Tooling/CMakeLists.txt
  flang/cmake/modules/CMakeLists.txt
  lld/cmake/modules/CMakeLists.txt
  lldb/cmake/modules/LLDBConfig.cmake
  lldb/test/API/CMakeLists.txt
  llvm/CMakeLists.txt
  llvm/cmake/modules/AddLLVM.cmake
  llvm/cmake/modules/CMakeLists.txt
  llvm/tools/llvm-exegesis/lib/AArch64/CMakeLists.txt
  llvm/tools/llvm-exegesis/lib/Mips/CMakeLists.txt
  llvm/tools/llvm-exegesis/lib/PowerPC/CMakeLists.txt
  llvm/tools/llvm-exegesis/lib/X86/CMakeLists.txt
  llvm/tools/llvm-shlib/CMakeLists.txt
  llvm/unittests/Target/ARM/CMakeLists.txt
  llvm/unittests/Target/DirectX/CMakeLists.txt
  llvm/unittests/tools/llvm-exegesis/AArch64/CMakeLists.txt
  llvm/unittests/tools/llvm-exegesis/ARM/CMakeLists.txt
  llvm/unittests/tools/llvm-exegesis/Mips/CMakeLists.txt
  llvm/unittests/tools/llvm-exegesis/PowerPC/CMakeLists.txt
  llvm/unittests/tools/llvm-exegesis/X86/CMakeLists.txt
  llvm/unittests/tools/llvm-mca/X86/CMakeLists.txt
  mlir/cmake/modules/CMakeLists.txt
  polly/cmake/CMakeLists.txt
  polly/test/CMakeLists.txt

Index: polly/test/CMakeLists.txt
===
--- polly/test/CMakeLists.txt
+++ polly/test/CMakeLists.txt
@@ -46,7 +46,7 @@
 
 set(LLVM_BINARY_DIR "${LLVM_BINARY_DIR}")
 set(LLVM_TOOLS_DIR "${LLVM_TOOLS_BINARY_DIR}")
-set(LLVM_LIBS_DIR "${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}")
+set(LLVM_LIBS_DIR "${LLVM_LIBRARY_DIR}")
 if (CMAKE_LIBRARY_OUTPUT_DIRECTORY)
   set(POLLY_LIB_DIR ${CMAKE_LIBRARY_OUTPUT_DIRECTORY})
 else()
Index: polly/cmake/CMakeLists.txt
===
--- polly/cmake/CMakeLists.txt
+++ polly/cmake/CMakeLists.txt
@@ -12,7 +12,7 @@
 set(LLVM_INSTALL_PACKAGE_DIR "${CMAKE_INSTALL_PACKAGEDIR}/llvm" CACHE STRING
   "Path for CMake subdirectory for LLVM (defaults to '${CMAKE_INSTALL_PACKAGEDIR}/llvm')")
 # CMAKE_INSTALL_PACKAGEDIR might be absolute, so don't reuse below.
-set(llvm_cmake_builddir "${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/cmake/llvm")
+set(llvm_cmake_builddir "${LLVM_LIBRARY_DIR}/cmake/llvm")
 
 if (CMAKE_CONFIGURATION_TYPES)
   set(POLLY_EXPORTS_FILE_NAME "PollyExports-$>.cmake")
Index: mlir/cmake/modules/CMakeLists.txt
===
--- mlir/cmake/modules/CMakeLists.txt
+++ mlir/cmake/modules/CMakeLists.txt
@@ -15,7 +15,7 @@
 set(LLVM_INSTALL_PACKAGE_DIR "${CMAKE_INSTALL_PACKAGEDIR}/llvm" CACHE STRING
   "Path for CMake subdirectory for LLVM (defaults to '${CMAKE_INSTALL_PACKAGEDIR}/llvm')")
 # CMAKE_INSTALL_PACKAGEDIR might be absolute, so don't reuse below.
-set(llvm_cmake_builddir "${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/cmake/llvm")
+set(llvm_cmake_builddir "${LLVM_LIBRARY_DIR}/cmake/llvm")
 
 get_property(MLIR_EXPORTS GLOBAL PROPERTY MLIR_EXPORTS)
 export(TARGETS ${MLIR_EXPORTS} FILE ${mlir_cmake_builddir}/MLIRTargets.cmake)
Index: llvm/unittests/tools/llvm-mca/X86/CMakeLists.txt
===
--- llvm/unittests/tools/llvm-mca/X86/CMakeLists.txt
+++ llvm/unittests/tools/llvm-mca/X86/CMakeLists.txt
@@ -1,6 +1,6 @@
 add_llvm_mca_unittest_includes(
   ${LLVM_MAIN_SRC_DIR}/lib/Target/X86
-  ${LLVM_BINARY_DIR}/lib/Target/X86
+  ${LLVM_LIBRARY_DIR}/Target/X86
   )
 
 add_llvm_mca_unittest_sources(
Index: llvm/unittests/tools/llvm-exegesis/X86/CMakeLists.txt
===
--- llvm/unittests/tools/llvm-exegesis/X86/CMakeLists.txt
+++ llvm/unittests/tools/llvm-exegesis/X86/CMakeLists.txt
@@ -1,6 +1,6 @@
 add_llvm_exegesis_unittest_includes(
   ${LLVM_MAIN_SRC_DIR}/lib/Target/X86
-  ${LLVM_BINARY_DIR}/lib/Target/X86
+  ${LLVM_LIBRARY_DIR}/Target/X86
   ${LLVM_MAIN_SRC_DIR}/tools/llvm-exegesis/lib
   )
 
Index: llvm/unittests/tools/llvm-exegesis/PowerPC/CMakeLists.txt
===
--- llvm/unittests/tools/llvm-exegesis/PowerPC/CMakeLists.txt
+++ llvm/unittests/tools/llvm-exegesis/PowerPC/CMakeLists.txt
@@ -1,6 +1,6 @@
 add_llvm_exegesis_unittest_includes(
   ${LLVM_MAIN_SRC_DIR}/lib/Target/PowerPC
-  ${LLVM_BINARY_DIR}/lib/Target/PowerPC
+  ${LLVM_LIBRARY_DIR}/Target/PowerPC
   ${LLVM_MAIN_SRC_DIR}/tools/llvm-exegesis/lib
   )
 
Index: llvm/unittests/tools/llvm-exegesis/Mips/CMakeLists.txt
===
--- llvm/unittests/tools/llvm-exegesis/Mips/CMakeLists.txt
+++ llvm/unittests/tools/llvm-exegesis/Mips/CMakeLists.txt
@@ -1,6 +1,6 @@
 add_llvm_

[Lldb-commits] [PATCH] D132316: [CMake] `${LLVM_BINARY_DIR}/lib(${LLVM_LIBDIR_SUFFIX})?` -> `${LLVM_LIBRARY_DIR}`

2022-08-23 Thread John Ericson via Phabricator via lldb-commits 
Ericson2314 marked 3 inline comments as done.
Ericson2314 added inline comments.



Comment at: llvm/tools/llvm-shlib/CMakeLists.txt:91
 
   set(LIB_DIR ${LLVM_BINARY_DIR}/${CMAKE_CFG_INTDIR}/lib${LLVM_LIBDIR_SUFFIX})
   set(LIB_NAME ${LIB_DIR}/${CMAKE_SHARED_LIBRARY_PREFIX}LLVM)

sebastian-ne wrote:
> Ericson2314 wrote:
> > sebastian-ne wrote:
> > > Should this be `set(LIB_DIR ${LLVM_LIBRARY_DIR})`?
> > I am not sure what is up with `CMAKE_CFG_INTDIR`, so I rather leave that 
> > for a later revision.
> `LLVM_LIBRARY_DIR` includes `CMAKE_CFG_INTDIR` as it’s set through
> ```
> set(LLVM_LIBRARY_OUTPUT_INTDIR 
> ${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_CFG_INTDIR}/lib${LLVM_LIBDIR_SUFFIX})
> set(LLVM_LIBRARY_DIR  ${LLVM_LIBRARY_OUTPUT_INTDIR})
> ```
> 
> As far as I understand, `CMAKE_CFG_INTDIR` is set to `.`, unless one does a 
> multi-config build, i.e. one build directory for debug and release builds. 
> multi-config builds are the default when creating Visual Studio solutions and 
> ninja supports multi-config builds since some time (rather recently).
Oh I see. Silly me. That is a fine reason to convert then.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132316

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

[Lldb-commits] [PATCH] D132510: [RISCV][LLDB] Add initial SysV ABI support

2022-08-23 Thread kasper via Phabricator via lldb-commits 
kasper81 created this revision.
kasper81 added reviewers: DavidSpickett, Emmmer, tzb99.
kasper81 added a project: LLDB.
Herald added subscribers: sunshaoce, VincentWu, luke957, vkmr, frasercrmck, 
evandro, luismarques, apazos, sameer.abuasal, JDevlieghere, s.egerton, Jim, 
benna, psnobl, jocewei, PkmX, the_o, brucehoult, MartinMosbeck, rogfer01, 
edward-jones, zzheng, jrtc27, shiva0217, kito-cheng, niosHD, sabuasal, 
simoncook, johnrusso, rbar, asb, arichardson, mgorny.
Herald added a project: All.
kasper81 requested review of this revision.
Herald added subscribers: lldb-commits, pcwang-thead, eopXD, MaskRay.

Supersedes https://reviews.llvm.org/D62732, since author is not working on it 
anymore (https://reviews.llvm.org/D62732?vs=on&id=341471#3561717).

This is to get the basic stuff working with DefaultUnwindPlan. We can 
incrementally add more plans in the future and make the implementation more 
robust. |


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D132510

Files:
  lldb/source/Plugins/ABI/CMakeLists.txt
  lldb/source/Plugins/ABI/RISCV/ABISysV_riscv.cpp
  lldb/source/Plugins/ABI/RISCV/ABISysV_riscv.h
  lldb/source/Plugins/ABI/RISCV/CMakeLists.txt
  lldb/source/Target/Platform.cpp

Index: lldb/source/Target/Platform.cpp
===
--- lldb/source/Target/Platform.cpp
+++ lldb/source/Target/Platform.cpp
@@ -1928,10 +1928,17 @@
 
   case llvm::Triple::riscv32:
   case llvm::Triple::riscv64: {
+static const uint8_t g_riscv_c_opcode[] = {0x02, 0x90}; // c_ebreak
 static const uint8_t g_riscv_opcode[] = {0x73, 0x00, 0x10, 0x00}; // ebreak
-trap_opcode = g_riscv_opcode;
-trap_opcode_size = sizeof(g_riscv_opcode);
-  } break;
+if (arch.GetFlags() & ArchSpec::eRISCV_rvc) {
+  trap_opcode = g_riscv_c_opcode;
+  trap_opcode_size = sizeof(g_riscv_c_opcode);
+} else {
+  trap_opcode = g_riscv_opcode;
+  trap_opcode_size = sizeof(g_riscv_opcode);
+}
+break;
+  }
 
   default:
 return 0;
Index: lldb/source/Plugins/ABI/RISCV/CMakeLists.txt
===
--- /dev/null
+++ lldb/source/Plugins/ABI/RISCV/CMakeLists.txt
@@ -0,0 +1,10 @@
+add_lldb_library(lldbPluginABISysV_riscv PLUGIN
+  ABISysV_riscv.cpp
+
+  LINK_LIBS
+lldbCore
+lldbSymbol
+lldbTarget
+  LINK_COMPONENTS
+Support
+)
Index: lldb/source/Plugins/ABI/RISCV/ABISysV_riscv.h
===
--- /dev/null
+++ lldb/source/Plugins/ABI/RISCV/ABISysV_riscv.h
@@ -0,0 +1,119 @@
+//===-- ABISysV_riscv.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_SOURCE_PLUGINS_ABI_RISCV_ABISYSV_RISCV_H
+#define LLDB_SOURCE_PLUGINS_ABI_RISCV_ABISYSV_RISCV_H
+
+#include "lldb/Target/ABI.h"
+#include "lldb/lldb-private.h"
+
+class ABISysV_riscv : public lldb_private::MCBasedABI {
+  bool isRV64;
+
+public:
+  ~ABISysV_riscv() override = default;
+
+  size_t GetRedZoneSize() const override { return 0; }
+
+  bool PrepareTrivialCall(lldb_private::Thread &thread, lldb::addr_t sp,
+  lldb::addr_t functionAddress,
+  lldb::addr_t returnAddress,
+  llvm::ArrayRef args) const override {
+// TODO: Implement
+return false;
+  }
+
+  bool GetArgumentValues(lldb_private::Thread &thread,
+ lldb_private::ValueList &values) const override {
+// TODO: Implement
+return false;
+  }
+
+  lldb_private::Status
+  SetReturnValueObject(lldb::StackFrameSP &frame_sp,
+   lldb::ValueObjectSP &new_value) override {
+// TODO: Implement
+lldb_private::Status error;
+error.SetErrorString("Not yet implemented");
+return error;
+  }
+
+  lldb::ValueObjectSP
+  GetReturnValueObjectImpl(lldb_private::Thread &thread,
+   lldb_private::CompilerType &type) const override {
+// TODO: Implement
+lldb::ValueObjectSP return_valobj;
+return return_valobj;
+  }
+
+  bool
+  CreateFunctionEntryUnwindPlan(lldb_private::UnwindPlan &unwind_plan) override;
+
+  bool CreateDefaultUnwindPlan(lldb_private::UnwindPlan &unwind_plan) override;
+
+  bool RegisterIsVolatile(const lldb_private::RegisterInfo *reg_info) override;
+
+  bool CallFrameAddressIsValid(lldb::addr_t cfa) override {
+// Assume any address except zero is valid
+if (cfa == 0)
+  return false;
+return true;
+  }
+
+  bool CodeAddressIsValid(lldb::addr_t pc) override {
+// Ensure addresses are smaller than XLEN bits wide. Calls can use the least
+// significant bit to store auxiliary information, so no s

[Lldb-commits] [PATCH] D132415: [LLDB] Add data formatter for std::coroutine_handle

2022-08-23 Thread Jim Ingham via Phabricator via lldb-commits 
jingham added inline comments.



Comment at: 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/TestCoroutineHandle.py:15
+
+class TestCoroutineHandle(TestBase):
+def do_test(self, stdlib_type):

aprantl wrote:
> Nice test!
Would you mind changing moving this into lldbutil.py?  This seems generally 
useful.  If you return the thread & breakpoint it would be even more generally 
useful?



Comment at: 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/TestCoroutineHandle.py:44
+
+lldbutil.run_to_source_breakpoint(self, '// Break after co_yield',
+lldb.SBFileSpec("main.cpp", False))

avogelsgesang wrote:
> aprantl wrote:
> > Does this launch a new process? It might be faster to just set an 
> > additional breakpoint and run `process.Continue()`.
> somehow, I assumed `run_to_source_breakpoint` would actually continue the 
> running process instead of starting a new process. But looking into 
> `run_to_source_breakpoint`, you are right, this launches a new process...
> 
> I changed this to instead continue execution of the already launched process
There is also lldbutil.continue_to_breakpoint,


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132415

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

[Lldb-commits] [PATCH] D132415: [LLDB] Add data formatter for std::coroutine_handle

2022-08-23 Thread Jim Ingham via Phabricator via lldb-commits 
jingham added inline comments.



Comment at: 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/TestCoroutineHandle.py:44
+
+lldbutil.run_to_source_breakpoint(self, '// Break after co_yield',
+lldb.SBFileSpec("main.cpp", False))

jingham wrote:
> avogelsgesang wrote:
> > aprantl wrote:
> > > Does this launch a new process? It might be faster to just set an 
> > > additional breakpoint and run `process.Continue()`.
> > somehow, I assumed `run_to_source_breakpoint` would actually continue the 
> > running process instead of starting a new process. But looking into 
> > `run_to_source_breakpoint`, you are right, this launches a new process...
> > 
> > I changed this to instead continue execution of the already launched process
> There is also lldbutil.continue_to_breakpoint,
Forgot to delete that inline comment before saving...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132415

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

[Lldb-commits] [PATCH] D132514: [lldb] Remove obsolete Android-specific definitions

2022-08-23 Thread Pirama Arumuga Nainar via Phabricator via lldb-commits 
pirama created this revision.
Herald added subscribers: danielkiss, pengfei, krytarowski.
Herald added a project: All.
pirama requested review of this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

Bionic's  defines the necessary symbols.  Remove the
specialization for Android and the now-unnecessary include of
.  This also helps resolve issues when building the
x86/x86_64 lldb-server for Android.

Curiously, the default branch to include  doesn't seem
necessary on Linux.  I'll remove it and add it back if it breaks other
builders.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D132514

Files:
  lldb/source/Plugins/Process/Linux/Procfs.h


Index: lldb/source/Plugins/Process/Linux/Procfs.h
===
--- lldb/source/Plugins/Process/Linux/Procfs.h
+++ lldb/source/Plugins/Process/Linux/Procfs.h
@@ -6,32 +6,10 @@
 //
 
//===--===//
 
-// source/Plugins/Process/Linux/Procfs.h defines the symbols we need from
-// sys/procfs.h on Android/Linux for all supported architectures.
-
 #include "lldb/lldb-types.h"
 #include "llvm/Support/Error.h"
-#include 
 #include 
 
-#ifdef __ANDROID__
-#if defined(__arm64__) || defined(__aarch64__)
-typedef unsigned long elf_greg_t;
-typedef elf_greg_t
-elf_gregset_t[(sizeof(struct user_pt_regs) / sizeof(elf_greg_t))];
-typedef struct user_fpsimd_state elf_fpregset_t;
-#ifndef NT_FPREGSET
-#define NT_FPREGSET NT_PRFPREG
-#endif // NT_FPREGSET
-#elif defined(__mips__)
-#ifndef NT_FPREGSET
-#define NT_FPREGSET NT_PRFPREG
-#endif // NT_FPREGSET
-#endif
-#else // __ANDROID__
-#include 
-#endif // __ANDROID__
-
 namespace lldb_private {
 namespace process_linux {
 


Index: lldb/source/Plugins/Process/Linux/Procfs.h
===
--- lldb/source/Plugins/Process/Linux/Procfs.h
+++ lldb/source/Plugins/Process/Linux/Procfs.h
@@ -6,32 +6,10 @@
 //
 //===--===//
 
-// source/Plugins/Process/Linux/Procfs.h defines the symbols we need from
-// sys/procfs.h on Android/Linux for all supported architectures.
-
 #include "lldb/lldb-types.h"
 #include "llvm/Support/Error.h"
-#include 
 #include 
 
-#ifdef __ANDROID__
-#if defined(__arm64__) || defined(__aarch64__)
-typedef unsigned long elf_greg_t;
-typedef elf_greg_t
-elf_gregset_t[(sizeof(struct user_pt_regs) / sizeof(elf_greg_t))];
-typedef struct user_fpsimd_state elf_fpregset_t;
-#ifndef NT_FPREGSET
-#define NT_FPREGSET NT_PRFPREG
-#endif // NT_FPREGSET
-#elif defined(__mips__)
-#ifndef NT_FPREGSET
-#define NT_FPREGSET NT_PRFPREG
-#endif // NT_FPREGSET
-#endif
-#else // __ANDROID__
-#include 
-#endif // __ANDROID__
-
 namespace lldb_private {
 namespace process_linux {
 
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D132415: [LLDB] Add data formatter for std::coroutine_handle

2022-08-23 Thread Adrian Vogelsgesang via Phabricator via lldb-commits 
avogelsgesang updated this revision to Diff 455022.
avogelsgesang marked 4 inline comments as done.

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

https://reviews.llvm.org/D132415

Files:
  clang/docs/tools/clang-formatted-files.txt
  lldb/packages/Python/lldbsuite/test/lldbtest.py
  lldb/packages/Python/lldbsuite/test/lldbutil.py
  lldb/source/Plugins/Language/CPlusPlus/CMakeLists.txt
  lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
  lldb/source/Plugins/Language/CPlusPlus/Coroutines.cpp
  lldb/source/Plugins/Language/CPlusPlus/Coroutines.h
  
lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/Makefile
  
lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/TestCoroutineHandle.py
  
lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/main.cpp

Index: lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/main.cpp
===
--- /dev/null
+++ lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/main.cpp
@@ -0,0 +1,40 @@
+#include 
+
+// `int_generator` is a stripped down, minimal coroutine generator
+// type.
+struct int_generator {
+  struct promise_type {
+int current_value = -1;
+
+auto get_return_object() {
+  return std::coroutine_handle::from_promise(*this);
+}
+auto initial_suspend() { return std::suspend_always(); }
+auto final_suspend() noexcept { return std::suspend_always(); }
+auto return_void() { return std::suspend_always(); }
+void unhandled_exception() { __builtin_unreachable(); }
+auto yield_value(int v) {
+  current_value = v;
+  return std::suspend_always();
+}
+  };
+
+  std::coroutine_handle hdl;
+
+  int_generator(std::coroutine_handle h) : hdl(h) {}
+  ~int_generator() { hdl.destroy(); }
+};
+
+int_generator my_generator_func() { co_yield 42; }
+
+// This is an empty function which we call just so the debugger has
+// a place to reliably set a breakpoint on.
+void empty_function_so_we_can_set_a_breakpoint() {}
+
+int main() {
+  int_generator gen = my_generator_func();
+  std::coroutine_handle<> type_erased_hdl = gen.hdl;
+  gen.hdl.resume();// Break at initial_suspend
+  gen.hdl.resume();// Break after co_yield
+  empty_function_so_we_can_set_a_breakpoint(); // Break at final_suspend
+}
Index: lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/TestCoroutineHandle.py
===
--- /dev/null
+++ lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/TestCoroutineHandle.py
@@ -0,0 +1,79 @@
+"""
+Test lldb data formatter subsystem.
+"""
+
+
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+USE_LIBSTDCPP = "USE_LIBSTDCPP"
+USE_LIBCPP = "USE_LIBCPP"
+
+class TestCoroutineHandle(TestBase):
+def do_test(self, stdlib_type):
+"""Test std::coroutine_handle is displayed correctly."""
+self.build(dictionary={stdlib_type: "1"})
+
+test_generator_func_ptr_re = re.compile(
+r"^\(a.out`my_generator_func\(\) at main.cpp:[0-9]*\)$")
+
+# Run until the initial suspension point
+lldbutil.run_to_source_breakpoint(self, '// Break at initial_suspend',
+lldb.SBFileSpec("main.cpp", False))
+# Check that we show the correct function pointers and the `promise`. 
+self.expect_expr("gen.hdl",
+result_summary=re.compile("^coro frame = 0x[0-9a-f]*$"),
+result_children=[
+ValueCheck(name="resume", summary = test_generator_func_ptr_re),
+ValueCheck(name="destroy", summary = test_generator_func_ptr_re),
+ValueCheck(name="promise", children=[
+ValueCheck(name="current_value", value = "-1"),
+])
+])
+# For type-erased `coroutine_handle<>` we are missing the `promise`
+# but still show `resume` and `destroy`.
+self.expect_expr("type_erased_hdl",
+result_summary=re.compile("^coro frame = 0x[0-9a-f]*$"),
+result_children=[
+ValueCheck(name="resume", summary = test_generator_func_ptr_re),
+ValueCheck(name="destroy", summary = test_generator_func_ptr_re),
+])
+
+# Run until after the `co_yield`
+process = self.process()
+lldbutil.continue_to_source_breakpoint(self, process,
+'// Break after co_yield', lldb.SBFileSpec("main.cpp", False))
+# We correctly show the updated value inside `prommise.current_value`.
+self.expect_expr("gen.hdl",
+result_children=[
+ValueCh

[Lldb-commits] [PATCH] D132415: [LLDB] Add data formatter for std::coroutine_handle

2022-08-23 Thread Adrian Vogelsgesang via Phabricator via lldb-commits 
avogelsgesang added inline comments.



Comment at: 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/TestCoroutineHandle.py:15
+
+class TestCoroutineHandle(TestBase):
+def do_test(self, stdlib_type):

jingham wrote:
> aprantl wrote:
> > Nice test!
> Would you mind changing moving this into lldbutil.py?  This seems generally 
> useful.  If you return the thread & breakpoint it would be even more 
> generally useful?
> moving this into lldbutil.py

done


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

https://reviews.llvm.org/D132415

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

[Lldb-commits] [PATCH] D132415: [LLDB] Add data formatter for std::coroutine_handle

2022-08-23 Thread Shafik Yaghmour via Phabricator via lldb-commits 
shafik added inline comments.



Comment at: lldb/source/Plugins/Language/CPlusPlus/Coroutines.cpp:39
+  CompilerType coro_func_type = ast_ctx.CreateFunctionType(
+  /*result_type*/ void_type, /*args*/ &void_type, /*num_args*/ 1,
+  /*is_variadic*/ false, /*qualifiers*/ 0);

`/*result_type=*/` see 
https://clang.llvm.org/extra/clang-tidy/checks/bugprone/argument-comment.html

applies to the rest of them as well.


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

https://reviews.llvm.org/D132415

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

[Lldb-commits] [PATCH] D132510: [RISCV][LLDB] Add initial SysV ABI support

2022-08-23 Thread Jason Molenda via Phabricator via lldb-commits 
jasonmolenda added a comment.

I think this DefaultUnwindPlan has the same problem that the previous patch did 
-- this looks like the unwind state on function entry.  There is an 
`ABI::CreateFunctionEntryUnwindPlan()` for the unwind state on the first 
instruction of a function, but the idea of DefaultUnwindPlan is for backtracing 
through jitted code, once the stack frame has been set up -- usually the stack 
pointer is copied into the frame pointer, maybe with a decrement, and the 
original frame pointer & return address registers are spilled to stack memory.  
Any of the arm ABI plugins are good examples of this kind of architecture.

Beyond DefaultUnwindPlan, usually the next place we get unwind information is 
from eh_frame, and lldb uses an instruction emulation system as a source of 
unwind information.  A static scan of all the instructions in the function, 
tracking branches and register spills, stack pointer/frame pointer 
manipulations, and creates an UnwindPlan from those.  That's a pretty big chunk 
of work though.  although lol I missed that this has already been started, v. 
lldb/source/Plugins/Instruction/RISCV/EmulateInstructionRISCV.cpp.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132510

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

[Lldb-commits] [PATCH] D132510: [RISCV][LLDB] Add initial SysV ABI support

2022-08-23 Thread Emmmer S via Phabricator via lldb-commits 
Emmmer added a comment.

Currently, `lldb/source/Plugins/Instruction/RISCV/EmulateInstructionRISCV.cpp` 
only handles a few jump instructions, we can refine it further if needed.




Comment at: lldb/source/Plugins/ABI/RISCV/ABISysV_riscv.cpp:38
+
+enum riscv_dwarf_regnums {
+  dwarf_x0 = 0,

This enum can be included from `lldb/source/Utility/RISCV_DWARF_Registers.h`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132510

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