================
@@ -0,0 +1,131 @@
+//===----------------------------------------------------------------------===//
+//
+// 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 "ProcessWasm.h"
+#include "ThreadWasm.h"
+#include "lldb/Core/Module.h"
+#include "lldb/Core/PluginManager.h"
+#include "lldb/Core/Value.h"
+#include "lldb/Utility/DataBufferHeap.h"
+
+#include "lldb/Target/UnixSignals.h"
+
+using namespace lldb;
+using namespace lldb_private;
+using namespace lldb_private::process_gdb_remote;
+using namespace lldb_private::wasm;
+
+LLDB_PLUGIN_DEFINE(ProcessWasm)
+
+ProcessWasm::ProcessWasm(lldb::TargetSP target_sp, ListenerSP listener_sp)
+    : ProcessGDBRemote(target_sp, listener_sp) {
+  // Always use Linux signals for Wasm process.
+  m_unix_signals_sp = 
UnixSignals::Create(ArchSpec{"wasm32-unknown-wasi-wasm"});
----------------
SingleAccretion wrote:

> Wasm programs are only going to generate signals if they're using WASI.

WASM doesn't have any Unix-like signals with handlers as a platform concept. It 
only has "exceptions" (i. e. an integrated `throw` instruction that 
destructively unwinds the stack but which you can catch) and "traps" (which you 
can't catch in WASM but can catch in the host).

(I don't know how these concepts are mapped / going to be mapped in the 
protocol / LLDB itself.)

https://github.com/llvm/llvm-project/pull/150143
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to