https://github.com/paolosevMSFT created
https://github.com/llvm/llvm-project/pull/77949
Add support for source-level debugging of WebAssembly code that runs in a
WebAssembly engine.
The idea is to use the GDB-remote protocol to connect to a Wasm engine that
implements a GDB-remote stub that o
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Paolo Severini (paolosevMSFT)
Changes
Add support for source-level debugging of WebAssembly code that runs in a
WebAssembly engine.
The idea is to use the GDB-remote protocol to connect to a Wasm engine that
implements a GDB-remote stub t
paolosevMSFT wrote:
@JDevlieghere I created a new PR and closed
[https://github.com/llvm/llvm-project/pull/76683](https://github.com/llvm/llvm-project/pull/76683)
because I made a mess with a git rebase, and since the other PR had just
started I thought it made sense to start anew. I apologize
JDevlieghere wrote:
> @JDevlieghere I created a new PR and closed #76683 because I made a mess with
> a git rebase, and since the other PR had just started I thought it made sense
> to start anew. I apologize for the confusion. Here I have already addressed
> most of your comments from 76683.
paolosevMSFT wrote:
@JDevlieghere Thank you!
I will remove the code that handles DW_OP_WASM_location as you suggest.
For what concerns testing, I took a very quick look at `GdbRemoteTestCaseBase`
and if I am not wrong, it works by spawning an inferior processor attaching to
an inferior proces
JDevlieghere wrote:
> @JDevlieghere Thank you!
>
> I will remove the code that handles DW_OP_WASM_location as you suggest.
Given we don't have a good solution for stacked commits, you don't necessarily
need to remove it here, and rebase it once the other PR has been merged.
> For what concer
@@ -0,0 +1,291 @@
+//===-- ProcessWasm.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: Ap
DavidSpickett wrote:
> A WebAssembly debugging session can be started using the new command:
> wasm [:]
What about wasm requires a new command, given that you are connecting to a GDB
server as existing targets do.
https://github.com/llvm/llvm-project/pull/77949
medismailben wrote:
> > A WebAssembly debugging session can be started using the new command:
> > wasm [:]
>
> What about wasm requires a new command, given that you are connecting to a
> GDB server as existing targets do.
+1! I don't think this needs a new command, it could just use `gdb-remo
https://github.com/paolosevMSFT updated
https://github.com/llvm/llvm-project/pull/77949
>From 30d932bb0988e1c78c3e023be2270259df5e6664 Mon Sep 17 00:00:00 2001
From: Paolo Severini
Date: Fri, 12 Jan 2024 09:10:59 -0800
Subject: [PATCH 1/2] Add support for source-level debugging of WebAssembly
github-actions[bot] wrote:
:warning: Python code formatter, darker found issues in your code. :warning:
You can test this locally with the following command:
``bash
darker --check --diff -r
f02b7770bb04b88455804b371dba1f44a86b90da...cbd046618749f229fce7221e012bf51f4789301b
lldb/
@@ -0,0 +1,291 @@
+//===-- ProcessWasm.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: Ap
paolosevMSFT wrote:
> > > A WebAssembly debugging session can be started using the new command:
> > > wasm [:]
> >
> >
> > What about wasm requires a new command, given that you are connecting to a
> > GDB server as existing targets do.
>
> +1! I don't think this needs a new command, it could
https://github.com/paolosevMSFT updated
https://github.com/llvm/llvm-project/pull/77949
>From 30d932bb0988e1c78c3e023be2270259df5e6664 Mon Sep 17 00:00:00 2001
From: Paolo Severini
Date: Fri, 12 Jan 2024 09:10:59 -0800
Subject: [PATCH 1/3] Add support for source-level debugging of WebAssembly
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff f02b7770bb04b88455804b371dba1f44a86b90da
db0bc4829b02aedf7a988824b38b56a1564a8125 --
mh4ck-Thales wrote:
Seems like support for reading Wasm local and global variables is available in
your code, but I don't understand how can one effectively read these variables
from the lldb command line. Maybe adding commands to access these can be useful
?
https://github.com/llvm/llvm-proj
jimingham wrote:
Not sure what you mean by this. "frame var" and "target var" are the lldb
command line commands for viewing local and global variables respectively. Why
are these not appropriate for Wasm?
Jim
> On Jan 22, 2024, at 6:37 AM, Quentin Michaud ***@***.***> wrote:
>
>
> Seems
mh4ck-Thales wrote:
@jimingham sorry if I wasn't clear. `frame var` and `target var` are commands
for viewing *language* local and global variables (be it C or another one).
They are indeed working with this patch. These commands are using the Wasm
linear memory, where most of the data about t
@@ -346,6 +346,16 @@ static offset_t GetOpcodeDataSize(const DataExtractor
&data,
return (offset - data_offset) + subexpr_len;
}
+ case DW_OP_WASM_location: {
+uint8_t wasm_op = data.GetU8(&offset);
+if (wasm_op == 3) {
+ data.GetU32(&offset);
+} else
DavidSpickett wrote:
> But currently a simple gdb-remote [:] does not enable the
> "wasm' plugin. Is there a way to detect that we are debugging WebAssembly at
> connect time?
Tracing down from `platform connect `, I get to
`Process::FindPlugin`, which creates a process of all the registered
@@ -0,0 +1,293 @@
+//===-- ProcessWasm.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: Ap
@@ -0,0 +1,293 @@
+//===-- ProcessWasm.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: Ap
@@ -0,0 +1,291 @@
+//===-- ProcessWasm.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: Ap
xujuntwt95329 wrote:
Thanks @paolosevMSFT for the great work! We have implemented debugger server in
[WebAssembly Micro Runtime
(WAMR)](https://github.com/bytecodealliance/wasm-micro-runtime) to work with
this, and it works well!
is part of WAMR, maybe this patch is different and will mak
xujuntwt95329 wrote:
> I already tried to use `register read` to access Wasm variables without
> success. But it was the patch available
> [here](https://github.com/bytecodealliance/wasm-micro-runtime/blob/main/build-scripts/lldb_wasm.patch)
> is part of WAMR, maybe this patch is different and
mh4ck-Thales wrote:
> Hi @mh4ck-Thales this is caused by [#77949
> (comment)](https://github.com/llvm/llvm-project/pull/77949#discussion_r1463458728),
> currently we need to modify it manually.
Thanks! That did the trick for the breakpoint and disassembly problems. When
using `read register`
xujuntwt95329 wrote:
> > Hi @mh4ck-Thales this is caused by [#77949
> > (comment)](https://github.com/llvm/llvm-project/pull/77949#discussion_r1463458728),
> > currently we need to modify it manually.
>
> Thanks! That did the trick for the breakpoint and disassembly problems. When
> using `re
mh4ck-Thales wrote:
> On the other hand, as a managed language, I think most people won't need to
> read specific local/global of an instance, just like most of the JavaScript
> developer won't care about the value of a register in V8 during debugging,
> they just care about the value of their
paolosevMSFT wrote:
> might be a noobie question, but is compatible with split dwarf ?
Yes, it is :-).
For that to work, it expects that the Wasm module contains a custom section
named `.external_debug_info` that contains the path to another Wasm module that
contains the DWARF symbols section
https://github.com/paolosevMSFT closed
https://github.com/llvm/llvm-project/pull/77949
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/paolosevMSFT reopened
https://github.com/llvm/llvm-project/pull/77949
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
paolosevMSFT wrote:
> > But currently a simple gdb-remote [:] does not enable the "wasm' plugin. Is
> > there a way to detect that we are debugging WebAssembly at connect time?
>
> Tracing down from `platform connect `, I get to
> `Process::FindPlugin`, which creates a process of all the regis
paolosevMSFT wrote:
> I see, thanks for the clarification. In the patch, the WasmLocal and
> WasmGlobal calls are done in ReadRegister, so it seems like those are being
> presented as register values? `register read` should show them. BTW, we
> shouldn't make a top level `wasm` command, we rea
paolosevMSFT wrote:
> Seems like support for reading Wasm local and global variables is available
> in your code, but I don't understand how can one effectively read these
> variables from the lldb command line. Maybe adding commands to access these
> can be useful ?
The idea for this patch w
paolosevMSFT wrote:
The logic to manage `DW_OP_WASM_location` in `DWARFExpression` is moved to a
separate PR: https://github.com/llvm/llvm-project/pull/78977, which should be
reviewed (and hopefully approved :-)) before we can complete work on this PR>
https://github.com/llvm/llvm-project/pul
DavidSpickett wrote:
> What happens now is that there is a ProcessGDBRemote that registers for
> gdb-remote and it is returned by Process::FindPlugin. > Then there is the new
> ProcessWasm which might also register for the same gdb-remote maybe.
> But the problem is that at the moment when we s
xujuntwt95329 wrote:
> > On the other hand, as a managed language, I think most people won't need to
> > read specific local/global of an instance, just like most of the JavaScript
> > developer won't care about the value of a register in V8 during debugging,
> > they just care about the value
xujuntwt95329 wrote:
> > I see, thanks for the clarification. In the patch, the WasmLocal and
> > WasmGlobal calls are done in ReadRegister, so it seems like those are being
> > presented as register values? `register read` should show them. BTW, we
> > shouldn't make a top level `wasm` comman
https://github.com/paolosevMSFT updated
https://github.com/llvm/llvm-project/pull/77949
>From 30d932bb0988e1c78c3e023be2270259df5e6664 Mon Sep 17 00:00:00 2001
From: Paolo Severini
Date: Fri, 12 Jan 2024 09:10:59 -0800
Subject: [PATCH 1/4] Add support for source-level debugging of WebAssembly
@@ -0,0 +1,293 @@
+//===-- ProcessWasm.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: Ap
paolosevMSFT wrote:
Removed the 'wasm' command and addressed all the other review comments.
https://github.com/llvm/llvm-project/pull/77949
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-c
https://github.com/paolosevMSFT updated
https://github.com/llvm/llvm-project/pull/77949
>From 30d932bb0988e1c78c3e023be2270259df5e6664 Mon Sep 17 00:00:00 2001
From: Paolo Severini
Date: Fri, 12 Jan 2024 09:10:59 -0800
Subject: [PATCH 1/5] Add support for source-level debugging of WebAssembly
@@ -24,17 +24,33 @@ def format_register_value(val):
return result
+def make_code_address(module_id, offset):
+return 0x4000 | (module_id << 32) | offset
+
xujuntwt95329 wrote:
@paolosevMSFT Seems the rule require two empty lines before cl
xwang98 wrote:
There is a strong need for this capability of LLDB from the WebAssembly Micro
Runtime community. It will be awesome to have it in the LLDB.
https://github.com/llvm/llvm-project/pull/77949
___
lldb-commits mailing list
lldb-commits@lists
@@ -2595,6 +2604,37 @@ bool DWARFExpression::Evaluate(
break;
}
+case DW_OP_WASM_location: {
+ uint8_t wasm_op = opcodes.GetU8(&offset);
+ uint32_t index;
+
+ /* LLDB doesn't have an address space to represents WebAssembly locals,
+ * globals
@@ -2595,6 +2604,37 @@ bool DWARFExpression::Evaluate(
break;
}
+case DW_OP_WASM_location: {
+ uint8_t wasm_op = opcodes.GetU8(&offset);
+ uint32_t index;
+
+ /* LLDB doesn't have an address space to represents WebAssembly locals,
+ * globals
@@ -1450,6 +1450,14 @@ class Process : public
std::enable_shared_from_this,
/// platforms where there is a difference (only Arm Thumb at this time).
lldb::addr_t FixAnyAddress(lldb::addr_t pc);
+ /// Some targets might use bits in a code address to represent additional
+
@@ -346,6 +346,15 @@ static offset_t GetOpcodeDataSize(const DataExtractor
&data,
return (offset - data_offset) + subexpr_len;
}
+ case DW_OP_WASM_location: {
+uint8_t wasm_op = data.GetU8(&offset);
+if (wasm_op == 3)
clayborg wrote:
It would
@@ -2595,6 +2604,37 @@ bool DWARFExpression::Evaluate(
break;
}
+case DW_OP_WASM_location: {
+ uint8_t wasm_op = opcodes.GetU8(&offset);
+ uint32_t index;
+
+ /* LLDB doesn't have an address space to represents WebAssembly locals,
+ * globals
@@ -0,0 +1,108 @@
+//=== wasmRegisterContext.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: Ap
@@ -0,0 +1,108 @@
+//=== wasmRegisterContext.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: Ap
@@ -2595,6 +2604,37 @@ bool DWARFExpression::Evaluate(
break;
}
+case DW_OP_WASM_location: {
+ uint8_t wasm_op = opcodes.GetU8(&offset);
+ uint32_t index;
+
+ /* LLDB doesn't have an address space to represents WebAssembly locals,
+ * globals
@@ -0,0 +1,108 @@
+//=== wasmRegisterContext.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: Ap
@@ -0,0 +1,76 @@
+//===-- UnwindWasm.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: Apa
@@ -0,0 +1,108 @@
+//=== wasmRegisterContext.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: Ap
@@ -1450,6 +1450,14 @@ class Process : public
std::enable_shared_from_this,
/// platforms where there is a difference (only Arm Thumb at this time).
lldb::addr_t FixAnyAddress(lldb::addr_t pc);
+ /// Some targets might use bits in a code address to represent additional
+
@@ -346,6 +346,15 @@ static offset_t GetOpcodeDataSize(const DataExtractor
&data,
return (offset - data_offset) + subexpr_len;
}
+ case DW_OP_WASM_location: {
+uint8_t wasm_op = data.GetU8(&offset);
+if (wasm_op == 3)
paolosevMSFT wrote:
I wil
@@ -0,0 +1,108 @@
+//=== wasmRegisterContext.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: Ap
@@ -2595,6 +2604,37 @@ bool DWARFExpression::Evaluate(
break;
}
+case DW_OP_WASM_location: {
+ uint8_t wasm_op = opcodes.GetU8(&offset);
+ uint32_t index;
+
+ /* LLDB doesn't have an address space to represents WebAssembly locals,
+ * globals
https://github.com/paolosevMSFT updated
https://github.com/llvm/llvm-project/pull/77949
>From 30d932bb0988e1c78c3e023be2270259df5e6664 Mon Sep 17 00:00:00 2001
From: Paolo Severini
Date: Fri, 12 Jan 2024 09:10:59 -0800
Subject: [PATCH 1/6] Add support for source-level debugging of WebAssembly
https://github.com/paolosevMSFT updated
https://github.com/llvm/llvm-project/pull/77949
>From 30d932bb0988e1c78c3e023be2270259df5e6664 Mon Sep 17 00:00:00 2001
From: Paolo Severini
Date: Fri, 12 Jan 2024 09:10:59 -0800
Subject: [PATCH 1/7] Add support for source-level debugging of WebAssembly
64 matches
Mail list logo
