►
From YouTube: Lightning Talk: Implementing Wasm Debugging with .net in vscode - Thays Tagliaferri de Grazia
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-21. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Lightning Talk: Implementing Wasm Debugging with .net in vscode - Thays Tagliaferri de Grazia, Microsoft
Explain some tricks we used to get debug information about a running app, how the call stack and the variable values are retrieved from the runtime when it’s paused on the debugger. This talk helps people to understand how C# debugger works over the Chrome DevTools Protocol, and what was implemented recently to be able to debug also on Firefox. Encourage people to implement support to any other browser that they want. Hopefully debugging a multithreaded runtime will be working at the time of the talk, so we can discuss how to debug in a multithreaded environment, what are the challenges, and what were the changes to make it possible.
A
Hi
I
am
Thais
and
I
have
been
working
at
Microsoft
for
four
years,
taking
care
of
the
the
burger
mainly
for
mobile
devices
and
webassembly.
Also
I
am
Brazilian.
So
I
would
like
to
say
sorry
about
my
English
and
I
hope.
You
all
can
understand
what
I
am
trying
to
explain.
The
goals
of
this
presentation
are
show
you.
A
The
first
thing
that
I
will
try
to
explain
is
why
we
use
the
Chrome
Dev
tools,
protocol,
which
we
will
call
CDP
from
now
on.
So,
to
start,
I
have
to
say
that,
as
our
runtime
already
works
for
other
platforms,
we
already
had
a
protocol
to
talk
to
our
runtime
called
Soft
debugger
protocol,
and
we
will
call
it
sdb
from
now
on.
The
only
way
to
talk
to
our
runtime
using
STP
was
via
socket
and
it
was
not
possible
as
far
as
I
know,
to
open
a
socket
in
was
me
running
inside
the
browser.
A
A
A
In
our
version,
we
put
a
proxy
in
the
middle
which
ends
up
intercepting
all
the
messages
between
between
IDE
and
the
browser
and
checks.
If
that
message
has
any
relevance
for
C
sharp
C
sharp
code,
whether
it
does
what's
necessary
and
if
it's
not,
we
only
forward
the
message
now,
you
show
you
some
details
of
the
code
in
case
you
wanted
to
start
to
understand
where
that
is
in
this
slide
are
all
the
links.
A
A
The
next
method
is
where
it
writes
in
a
stringy
buffer
following
the
sdb
protocol.
Everything
that
we
need
to
really
insert
the
breakpoint
in
the
manager's
code
here
is
where
it
calls
the
JavaScript
to
function
using
the
runtime,
evaluate
message
from
CDP,
so
we
are
in
a
c-sharp
code.
We
will
call
runtime
evaluation
from
using
this
CDP
message
and
then
we
will
secure
to
this
function
on
browser.
We
will
use
it
with
this
JavaScript
function
on
browser
site.
A
Here
is
the
JavaScript
to
wrapper
function,
which
we'll
call
the
native
function,
and
the
last
one
is
the
native
function
that
we'll
call
the
debugger
functions
that
already
existed
in
our
runtime,
so
it
will
decode
the
message
buffer
following
the
STP
protocol
and
do
what
needs
to
be
done
now.
You
might
be
curious
to
see
what
happens
when
it
hits
to
a
breakpoint
which
is
the
inverse
path.
So
again,
the
links
and
the
Snippets
is
executed.
A
A
Then
we
call
this
another
method
which
will
check
what
kind
of
it
will
decode
this
the
message
in
sdb
format
and
we'll
check
if
what
kind
of
files
we
receive.
If
we
need
information
like
how
stack
locations
and
Etc,
and
so
it
sends
the
message
to
runtime,
to
ask
for
the
informations
in
the
same
way
that
I
explained
it
to
set
a
breakpoint
using
their
runtime
evaluation
message.
A
A
question
that
you
might
be
asking:
is
it
possible
to
support
debugging
in
other
browsers?
The
answer
is
yes,
we
can
follow
the
same
idea
to
support
the
button
in
any
other
browser
that
has
remote
debugging
feature.
We
already
have
an
experimental
support
for
Firefox,
and
this
is
the
ink
station
that
we
use
when
we
went
to
debug
from
vs
code
here
a
curiosity
recently.
Our
runtime
is
supporting
mode
thread
and
we
had
to
change
some
things
to
make
the
debugger
work.
A
A
You
can
see
locals
and
also
cardstock.
Now,
let's
talk
about
the
debugger
in
the
Wazi
environment
or
webassembly
running
outside
the
browser.
It
was
really
quick
to
implement
because
we
already
had
the
debugger
listening
on
socket
because
we
already
used
it
for
mobile
device
and
we
were
able
to
reuse
a
lot
of
it.
We
already
had
a
vs
code
extension
that
knows
how
to
talk
to
the
runtime
and
these
extensions
uses.
This
is
another
Library,
which
has
all
the
logic
to
communicate.
A
A
We
could
make
it
so,
and
here
is
the
link
where
we
did
it
and
the
Second
Challenge
is
that
our
debugger
uses
an
exclusive
exclusive
thread
for
communication,
the
way
that
was
implemented
before
and
there
isn't
support
for
moods
thread
in
the
wild
environment.
So
we
had
to
communicate
with
the
debugger
on
the
same
thread
of
the
execution.
That
is
whenever
we
find
a
sequency
point.
A
We
see
if
there
is
something
in
the
communication
buffer
like
setting
a
breakpoint,
and
then
we
execute
it
also
when
it
stops
at
a
breakpoint,
we're
keeping
up
in
this
communication,
Loop
receiving
and
sending
messages
about,
Costa
locals,
watches
and
to
receive
ISTEP
or
a
resume,
and
then
it
comes
it
continues.
The
execution
here
is
a
video
debugging
in
vs
code,
a
c-sharp
program
running
in
Wazi,
and
for
that
we
use
the
mono
extension
for
vs
code
and
the
link
is
here.
A
And
we
can
resume
look
at
variables
and
also
call
stack,
and
here
on
the
last
slide,
I
show
you
all
the
possible
configurations
to
debug
c-sharp
running
on
edge
Firefox
and
was
me
time
without
the
browser.
The
first
and
the
second
configurations
use
this
proxy.
So
we
you,
we
set
the
part
of
the
proc
where
the
proxy
is
listening
and
the
third
configurations
uses
a
socket
that
communicates
directly
with
runtime.