================ @@ -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