►
From YouTube: Tom Tromey discusses debugging support in rustc
Description
The talk gives a high-level overview of how Rust integration with gdb, lldb, and so forth work. It discusses some of the steps that are needed to add extensions to the DWARF standard for Rust-specific features.
Speaker: Tom Tromey, who added Rust support to gdb, and implemented the rust-lldb debugger.
A
A
A
A
There
is
also
some
special
code
in
the
dwarf
reader
in
gdb,
so
we'll
talk
a
little
bit
more
about
dwarf
from
the
dwarf
extensions
and
stuff
later,
but
two
examples
of
that
are
like
the
GTV
dwarf
reader
needed
special
support
for
rust,
enum
types
and
then
the
expression
you
know
like
in
because
the
because
the
expression
subset
doesn't
include
matches.
If
you
want
to
access
fields
of
an
enum,
you
know
like
you,
can
just
type
in
own
value
dot
the
name
of
the
field
in
the
currently
active
email
branch.
If
that
makes
sense
how.
B
A
The
debuggers
have
a
step
like
that
where
they,
you
know,
Dorf
is
kind
of
this
compressed
format.
That's
not
super
great
to
work
with,
as
like
a
data
format,
you
know,
so
they
both
sort
of
read
it
and
explode
it
into
data
structures
that
you
yeah,
they're,
more
natural
to
use,
and
so
yes,
so
you
know
this
enum
stuff
gdb
understands
about
the
RUS.
Compiler,
writes
information
about
an
enum
into
the
dwarf
and
then
gdb
reads
the
dwarf.
To
understand
like
where
is
the
tag
field?
A
Is
there
a
tag
field
because
you
can
have
univariant
in
ohms
or
is
the
tag
slot
shared
with?
You
know
like
the
non
zero?
Optimization
is
the
tag
slot
shared
with
some
other
slot
and
if
so,
which
special
values
mean
which
enum
branch
and
stuff
that's
all
described
in
the
dwarf,
so
another
extension
gdb
supports
is
dissecting
trait
objects,
and
this
leg
of
you
look
on
the
slide.
It
says
this
thing
about
V
tables.
We
made
a
little
dwarf
extension,
where
a
trait
object
will
a
trait
objects.
A
Description
in
the
dwarf
also
points
to
like
sort
of
a
stub
description
of
the
corresponding
V
table
and
then
that
in
turn,
points
to
the
concrete
type
for
which
this
trait
object
exists,
and
what
that
means
is,
if
you
have
a
trait
object,
you
can
like
print
star
object
and
gdb
understands
how
to
understands
how
to
find
the
correct
type
of
the
payload
in
the
trade
object.
So
you
know
so
it's
like
nice
for
debugging.
A
B
A
That's
right
so,
when
you
print
an
enum
value,
you
know
previously,
if
you
use
gdb
before
like
say
a
lot
of
this
ease
now
more
quaint
and/or.
If
you
know,
if
you
printed
an
enum
value
that
used
to
look
like
kind
of
like
basically
a
C
Union
in
the
dwarf
in
the
dwarf,
and
so
you
would
just
get
this
thing
with
all
the
different
member.
You
know
all
the
different
variants
and
try
to
figure
it
out
on
your
own.
But
now
gdb
does
that
work
for
you,
so
it
will
only
print
the
currently.
A
Yeah,
and
so
all
this
work
is
upstream,
it's
just
part
of
gdb
and
GB
has
uses
bugzilla.
You
can
easily
go
and
find
the
existing
bugs.
There's
I
think
on
the
order
of
25
or
something
you
know
anyway,
so
that's
kind
of
it
for
gdb
I.
Are
there
any
more
questions
about?
How
would
you
move
on
I?
Don't
know
all
right.
You.
A
A
A
A
A
Reader
also
understands
the
stuff
that
needed
to
be
done
for
you
gnomes,
you
know,
that's
something
I
call
out,
because
it's
something
that's
in
dwarf
like
dwarf,
has
this
whole
thing
about
variant
types
and
all
this
stuff,
but
no
compiler
ever
admitted
it
and
no
debugger
ever
read
it
until
we
needed
it
for
rust.
So
it's
like
a
special
thing.
You
can
see
there's
a
link
to
the
repository
it's
in
rustling
nursery,
however,
upstream
LLVM
is
moving
to
this
mono
repo
and
so
rust
is
following
I.
A
C
A
A
C
A
Email
thread,
or
in
that
month,
there's
just
some
discussion
about
that.
Ldb
recently
went
through
this
thing,
where
they
removed
all
the
other
language
plugins
due
to
lack
of
maintenance,
and
so
they
didn't
want
to
accept
any
new
ones.
So
none
of
this
is
upstream
it's
a
and
L
LD
B
has
a
plug-in
architecture
where
you
can
write
plugins
as
their
shared
libraries
or
something,
however,
that
doesn't
work
for
language
support,
so
we
had
to
fork
the
whole
thing.
A
We'll
get
to
that,
there's
no
answer
there,
but
yes,
that's
kind
of
the
recommendation
at
the
time
when
I
did
this.
The
issue
I
had
was
I,
wasn't
sure
how
I
wanted
to
solve
this
problem
of
hello.
Db
has
a
Python
dependency
and
I
wasn't
sure.
I
wasn't
sure
how
I
wanted
to
deal
with
that
on
Linux
and
so
on,
Mac
OS
that
was
reasonably
easy
to
solve.
We
can
just
rely
on
the
system
one,
but
you
know
the
Linux
world
is
hairier
in
this
regard.
A
A
It's
a
it's
a
multi-language
and
extensible
format
and
the
main
part
that
describes
like
types
and
things
like
that
is
also
extensible.
It's
like
this
tree,
structured
thing.
Where
you
can
it's
got
tags
and
attributes
and
you
can
actually
invent
to
a
certain
extent,
your
own
tags
and
your
own
attributes
and
debuggers
normally
are
expected
to
ignore
anything.
They
don't
understand.
A
A
A
That
require
dwarf
extensions,
so
we
have
a
few
dwarf
extensions
that
that
the
RUS
compiler
emits
and
that
the
debuggers
understand
that
are
not
in
the
dwarf
standard.
One
was
that
vtable
thing
that
required
an
extension
I
feel
like
there's
another
one
and
not
remembering
what
it
was
anyway.
They're
documented
in
the
debuggers
like
in
comments
or
in
LLVM,
and
comments
and
I
think
I
submitted
one
or
two
dwarf
standard
bug
reports
asking
for
some
changes.
Now
some
things
will
require
bigger
changes
so
traits
which
I
think
I
have
all
slide.
A
What
the
Russ
compiler
does
is
omits
fields
with
names
like
underscore
underscore
0
and
then
the
debuggers
like
look
for
a
sequence
of
such
field
names
which
it's
kind
of
ugly.
If
you
remove
the
underscores,
it
might
be
better
because
it
would
remove
the
ambiguity,
so
that
might
be
a
possibility.
It
didn't
seem
super
vital.
You
know.
B
A
A
I
didn't
do
the
archaeology,
but
I
feel
like
those
were
probably
added,
because
before
the
debuggers
had
rust
support,
if
you
wanted
to
extract
the
value
of
a
field
you
needed
to
type
it
into
like
GDP
and
GDP
would
say:
well,
X,
dot.
Zero
being
is
a
syntax
error,
whereas
X
dot
underscore
underscore
zero
is
fine.
A
A
A
A
So
that
required
so
actually
shipping
gdb
requires
some
kind
of
change
to
like
the
rust
up
delivery
system,
so
that
gdb
could
be
built
as
its
own
entity
and
then
the
artifacts
that
are
created
that
way
can
be
stuck
into
rust
up
without
requiring
it
to
be
part
of
one
giant
rust
build
now
the
reason
to
ship
up.
So
if,
however,
this
PR
that
it
exists
is
still
useful
because
to
look
at
because
it,
the
main
issue
with
things
like
GEB
is
setting
up
their
dependencies.
Remember
with
the
ll
DB
thing
I
was
talking
about.
A
Shipping
on
Linux
is
tricky
because
of
a
Python
dependency,
and
that's
true
for
gdb
as
well.
So
I
thought
there
was.
We
can
rely
on
the
least
common
denominator,
which
is
Python
2.7,
most
of
the
distros
ship
it
and
then
what
I
did
for
gdb
was
like,
like
ll
DB
or
like
LLVM.
We
have
our
own
Fork
of
gdb.
This
is
and
I'll
talk
about
this
in,
to
make
it
really
clear
what
this
means,
but
we'll
have
our
own
fork.
A
That
has
where
we
import
stock
upstream
jeebies
and
apply
a
few
patches,
and
that's
the
one
that
we
build
and
ship
to
rust
up
and
one
of
those
patches
is
a
change
to
heavy
driver
that
actually
runs
gdb
and
the
driver
will
check
for
the
existence
of
the
correct
version
version
of
Python
and
tell
you
hey,
you
didn't
install
Python,
2.7
and
please
and
install
it.
However,
you
do
that
for
your
distro
and
the
Rees
for
that.
B
A
A
So,
for
example,
I
have
some
chibi
scripts
that
do
that.
So
so
most
things
in
this
build
like
in
the
PR.
You
know
it
statically
links
most
dependencies
except
for
Python.
Now
why
to
do?
Why
do
this?
You
know
the
the
reason
to
do
it
is
so
that
it's
easier
to
like
make
a
compiler
change
to
change
the
debug
info
and
then
immediately
ship
debuggers.
That
can
understand
it,
and
so
that
way
we
don't
have
this
problem.
Where
we're
reluctant
to
turn
on
new
debug
info
features
for
fear
of
breaking
things.
A
A
Most
changes
should
go
upstream,
first
or
at
least
be
in
the
process
of
being
up
streamed
before
they
get
stuck
into
the
rust
tree,
and
the
rust
tree
would
be
primarily
about
delivering
things
to
users
before
or
you
know,
actual
upstream
releases
GEB
only
releases
there
every
six
months.
So
you
know
it's,
it's
a
really
different,
cadence.
B
A
A
B
A
Okay,
so
that's
gdb
and
rest
up
still
valuable
to
do,
but
it
requires
this
rust
up
flash
infrastructure
groundwork.
First,
that
I
actually
don't
know
the
state
of
that
you
al
excite.
Okay,
next,
all
right
debug
on
Mac
OS.
There
are
these
features
called
sip
which
system
integrity,
protection,
I,
think,
basically,
it
prevents
processes
from
using
the
P
trace
system,
column
and
processes
that
want
to
use
it
have
to
be
code
signed,
you
know,
certainly,
and
the
certificate
or
whatever
that
you
used
to
sign.
It
has
to
be
trusted
on
your
machine.
Now.
A
What
that
means
is
debuggers
out
of
the
box.
Don't
work
now
you
can.
You
can
sign
these
programs,
however,
to
sign
them
and
have
it
work
where
the
user
installs
the
program
and
it
just
works.
You
have
to
get
an
official
certificate
like
through
some
Mac.
You
know,
through
some
Apple
process,
I
was
hoping
we
could
work
around
this
by
relying
on
users
that
already
have
like
the
ll
DB
debug
server
installed.
In
fact,
that's
what
we
do
today,
which
is
not
very
ideal.
A
A
A
Maybe
the
route
forward
is
that
there
has
to
be
a
rust
legal
entity
that
can
get
these
keys
through
Apple
and
manage
them
itself.
So
this
is
a
tricky
problem.
Oh
it's
not
really
a
technical
problem
at
all.
Once
you
have
key
it's
kind
of
like
making
sure
the
build
server
hasn't
backing
out
a
scenic
patch
I
mean
you
know
that
part's
not
too
hard,
but.
A
You
know
so
unsolved
problem
and
the
impact
of
this
problem
is
pretty
big
like
you
either
have
to
install
Xcode
for
lld,
be
torque
or
it
just
doesn't
work
so
on
Mac
OS.
Now,
if
we
had
such
a
key,
we
could
also
sign
gdb
and
ship
gdb
for
people
like
that.
I
don't
know,
but
yeah.
Okay,
any
questions
about
this
one.
A
A
So,
okay,
something
that's
totally
missing
this
a
bit
in
the
future
stuff
section
maybe
is
Windows,
is
a
complete,
unknown.
I,
don't
really
know
anything
about
Windows
Windows
has
its
own
debugging
format.
Pdb.
There
is
some
support
in
LLVM
free,
mitting
PDB.
However,
what
is
not
known
to
me
is
how
well
does
it
handle
the
things
that
are
part
of
Rus,
but
not
part
of
C++,
like
a
really
good
example,
would
be
going
back
to
the
dwarf
stuff.
How
would
we
describe
enums
rusty
gnomes
PDB?
A
A
A
A
really
typical
bug
report
is
I,
wanted
to
call
a
method,
print,
X,
dot
method
and
it
didn't
work
well.
The
reason
it
didn't
work
is
that
method
is
implemented
via
a
tree.
You
know
as
opposed
to
in
pull
type,
and
that
information
is
just
not
there
like
some
of
it
is
there,
but
there's
no
association
between
like
the
type
of
X
and
how
to
find
some
route
through
the
debug
info
to
find
the
methods
you
know
that
are
implemented
on
it
by
traits.
Okay,
so
dwarf
does
have
this
notion
of
like
interface
types.
A
A
B
A
A
So
the
idea
would
be
tre,
you
know
it
can't
dwarf
only
deals
with
concrete
things.
It
doesn't
deal
with
like
generic
things
so
like
in
C++.
It
only
done.
It
only
describes
template
instantiations,
not
the
templates
in
themselves,
and
the
same
would
be
true
for
rust,
so
the
idea
would
be
given
implementation
and
implementation
of
a
trait
for
a
type
would
be
one
of
these
interface.
You
know
DW
tag,
interface,
type
or
whatever,
and
then
the
type
for
which
it's
implemented
right,
like
you,
implemented
it
for
I-32.
A
Way
a
debugger
could
say:
AHA
print,
X,
dot
method.
Well,
X
has
type
I
32
I
can
go.
Look
that
up
in
the
dwarf.
Oh
here's
all
the
interfaces
that
implements
I
can
go
search
through
all
of
those
to
find
the
method
to
call.
So
that's
how
that
would
work
now.
That
requires
to
first
of
all
that
requires
a
dwarf
extension.
If
you
go
and
read
the
dwarf
standard
you'll
see
that
interfaces
are
only
really
defined
for
structure
types
structures
and
classes,
not
for
any
type,
but
rust
needs
on
for
any
type.
A
Now,
that's
the
exactly
the
kind
of
thing
where
it's
totally
fine
to
just
emit
dwarf,
that
does
that
o
debuggers
are
expected
to
skip
things.
They
don't
understand
and
they
would
certainly
just
ignore
those
attributes,
so
that's
safe
to
just
do,
but
it's
the
kind
of
thing
where,
because
LLVM
does
not
emit
interface
types
at
all,
you
need
to
implement
this
in
LLVM
and
get
sign-off
from
the
LLVM
debug
maintainer
x'
that
it's
a
good
idea.
A
So,
oh
so
you
know
you
think
well,
I
should
file
a
dwarf
root,
bug
report,
but
if
you
look
at
the
to
do,
if
you
look
at
this
slide,
it's
like
that's
the
last
thing
you
should
do,
because
normally
what
you
want
to
do
is
implement
the
entire
thing
so
that
any
problems
in
the
process
can
be
caught
before
you.
Try
to
you
know,
standardize
this
now
the
LLVM
maintainer
x'
have
been
pretty
pretty
good
about
this.
So
it's
not
like
a
giant
problem
or
some
complicated
negotiation.
They're.
B
C
A
A
Then
the
way
I
do
these
projects
as
next
I.
Well,
usually,
what
I
actually
do
is
I.
Do
this
end
to
end
I.
Do
all
the
patches
first
before
submitting
anything
to
make
sure
it
actually
works,
but
you
still
want
to
stage
how
you
land
things.
So
after
you
land
the
LLVM
changes,
then
you
land
the
debugger
changes.
A
A
B
A
Llvm
has
this
there's
this
whole
thing
called
di
builders,
debug
info
builders,
and
that's
the
primary
thing
that
rust
calls
into.
If
you
look
at
like
the
rust
LLVM
API,
that's
in
the
tree,
like
is
it
called
rust,
wrapper
I
feel
like
I,
have
a
rust,
wrapper,
dot,
cpp
and
there's
some
file
with
the
funny
name:
FF
ID
IRS,
like
in
Lib
rusty
code,
Chen
LLVM.
Basically,
what
you
do
is
yes,
this
is
a
kind
of
metadata
that
you
construct
and
it
just
kind
of
hand
off
to
LLVM
and
ignore
so
the
rust.
A
B
C
A
I
just
didn't
because
I
don't
know
what
P
DBT
meant.
You
know,
I
like
I
know
absolutely
nothing
about
that,
and
my
impression
was
that
in
LOV
M
that
is
not
required,
because
no
one
even
mentioned
it.
So
you
know
I,
think
I,
don't
know.
The
impression
I
was
left
with
is
that
the
pdb
stuff
is
relatively
immature,
and
so
it's
not
like
I
something
that
they
require
when
you
change
to
bug
info
builder
stuff,
so
yeah
I.
A
A
You
know,
but
so
anyway,
so
we're
at
the
stage
where
you
update
the
debuggers,
for
you
know
to
understand
this
stuff,
and
you
know
you
can
punt
on
that,
a
little
if
you
need
to
you
or
whatever,
like
I,
pictured,
probably
trying
to
implement
the
method,
calls
but
not
operator
overloading
at
first
just
trying
to
make
the
problem
a
little
simpler
and
also
because,
in
my
experience,
people
actually
report
bugs
about
method
calls.
But
nobody
has
ever
reported
a
bug
about
operator
overloading.
A
A
Now-
and
this
is
the
step
where
see
if
we
had
both
debuggers
in
rostov,
this
would
be
much
more
seamless
because
you
could
land
the
debugger
changes
and
then
land
the
RUS,
compiler
change
and
people
on
nightly.
You
know
when
they
updated
everything
would
keep
working
or
they
would
just
have
immediate
access
to.
The
new
features
like
in
this
case.
A
The
butters
would
you
know,
Aldi
butters
would
still
work
fine
because
they
would
just
ignore
the
extension,
but
there
are
other
cases,
maybe
where
you
omit
something
new.
You
know
like
the
enum
changes
home
were
more
in
a
quandary
where,
if
you
change
the
debug
output,
old
debuggers
will
just
stop
working,
but
on
the
other
hand
it
fixed
other
bugs
in
the
older
bunch
and
yeah
so
yeah.
B
C
B
A
Right
that
would
be.
That
would
be
preferable
because
it
would
let
us
control
our
own
destiny,
a
little
better
then,
but
you
know,
like
you
know.
That
said,
like
my
view,
is
generally
it's
better
to
work
with
upstream
so
I
like
to
try
to
get
things
into.
You
know
like
to
like
the
last
step
here:
file
a
dwarf
bug
with
an
explanation
you
know
dwarf,
is
a
pretty
opaque
process,
so
you
know
like
you'll
file
a
bug
and
it's.
A
You
file
a
bug
and
it's
just
there
and
you
can
comment
on
it.
You
file
a
bug
and
then
a
few
weeks
later
someone
emails
you
and
says:
thanks:
we've
accepted
your
body.
Now
it's
like
a
page
on
a
website,
that's
read-only!
So
that's
it's
kind
of
a
weird
thing,
but
it's
still
good
to
kind
of
close
the
loop
or,
like
you
know,
GB
patches
should
go
into
GB
and
I
tried
to
get
the
hello
DB
patches
into
L.
A
A
This
process
that
kind
of
outlined
here
is
the
typical
process
for
a
big
debug
info
change
and
it's
not
uncommon
to
do
multiple
passes
through
it.
Where
you
write
some
changes
and
then
you
have
to
go
back
and
do
things
again
like
maybe
the
LLVM
review
wanted
API
changes.
So
then
you
have
to
tweak
LLVM
and
the
compiler
again
or
maybe
the
LLVM
review
wanted
the
dwarf
to
be
written
differently.
So
then
you
have
to
change
the
debuggers
again
well,
so
it's
not
too
unusual
dye
have
to
repeat
all
this.
A
A
A
Still
on
things
missing,
there's
this
open
bug
about
macro,
stepping
where
the
question
is
like
what
is
the
location
you
remit
for
a
macro
expansion.
You
have
multiple
choices.
You
can
omit
a
location
of
the
invocation
of
the
macro.
You
can
omit
the
location
of
the
definition
of
the
macro
or,
if
you
have
a
really
complicated
macro,
you
can
even
omit
locations
for
the
contents
of
the
macro.
You
know
or
like
the
arguments,
some
of
them,
or
maybe
all
of
them.
So
there's
this
RFC
about
it.
A
You
know
like
further
say
a
simple
case:
the
print
line
macro
should
just
be
like
a
function.
Call
you
step
onto
that
line
of
source
and
then
the
next
time
you
hit.
Next
it
goes
to
the
next
line
of
source,
and
you
don't
try
to
go
off
into
wherever
print
line.
The
macro
was
defined,
but
other
ones
may
be
different.
This
is
one
that
this
is
a
debugging
bug
that
can
be
done
entirely
in
the
RUS
compiler
yeah.
What's
up.
A
C
A
C
C
Doesn't
change
exactly
what's
going
on
yeah
and
I'm?
Also
thinking
about
where
you're,
using
once
you
know
another
procedural
macro
inside
of
a
different
macro,
you
know,
for
example,
we
read
your
procedural
macro
and
inside
there
you've
got
a
Bex
it.
You
know
BEC
macro
or
a
print
line
or
something
else.
So
now
now
you
technically
have
a
whole
stack
of
execution
frames
or
contacts
or
whatever
you
want
to
call
them.
B
A
You
know
I
think
this
is
yes.
There's
I
have
not
looked
at
this
problem.
I
I
consider
it
kind
of
a
separate
problem,
but
it's
definitely
something
that
needs
to
be
solved.
Like
you
know,
my
experience
with
C++
is
like
you
can
write
these
hairy
contexts,
BRR
things
that
are
run
at
compile
time.
You
know
whole
functions
and
stuff,
and
how
do
you
debug
those
there's
no
way?
Well,
there
should
be
a
way
because
you're
writing
code
and
it's
gonna
have
bugs
and
it's
tricky
to
get
in
there.
A
C
B
B
I
have
a
question
also
yeah
go
ahead.
I
realized
I
forgot
to
reason
it
sort
of
relates
to
the
trade
dispatching
thing.
One
of
the
things
I
would
like
to
at
some
point
doing
in
Russy
is
to
generate
one
copy
of
a
function.
I
take
what
would
be
multiple
monomorphic
functions
and
collapse
them
into
one
bit
of
generated
code.
Yeah.
Is
there
anything
like
that
indoor
today,
Swift
I
know
does
this,
but
they
probably
just
don't
use.
C
B
A
B
A
A
But
to
really
do
that,
you
need
to
write
new
D
manglers
one
has
to
go
in
this
thing
called
Liberty,
which
is
shared
by
GCC
and
GB
and
a
bonito.
You
know
the
ganoub
in
utils,
but
it's
in
the
GCC
source
tree.
That's
where
its
canonically
maintained,
so
you'd
have
to
write
a
new
rusty
mango
there
and
then
lld
B
also
has
a
deep
angler,
or
maybe
it's
in
LVM.
Now
I
things
change
there
and
I
didn't
really
follow
what
was
going
on.
But
so
you
need
to
write
new
ones
and
land
them.
A
A
You
know.
Maybe
you
could
just
skip
that
part
I.
Don't
know
okay,
so
that's
one
thing
that
needs
to
be
done
in
the
future
and
another
one
is.
This
idea
comes
up
a
lot
about
of
instead
of
having
the
debuggers
implement
their
own
sorta
half-assed
expression
parsers.
Why
not
just
reuse
the
rest,
compiler
and
a
good
idea?
A
One
way
it's
a
good
idea
is
that
the
debuggers
by
and
large,
don't
try
to
implement
type
inference,
it's
just
too
hard.
So
it
means
that
when
you're
typing
in
the
debugger,
sometimes
you
need
to
be
much
more
explicit
than
you
would
normally
need
to
be
in
your
actual
rough
source
code.
You
know,
like
there's
a
sort
of
principle
that
the
ideal
for
a
debugger
would
be.
A
You
could
copy
a
piece
of
like
say
an
expression
from
your
source,
paste
it
into
the
debugger
and
it
would
evaluate
it
and
get
the
same
answer,
but
without
all
the
features
of
the
compiler
like
type
inference
that
can't
reasonably
be
done
so
reusing.
The
compilers
parser
is
certainly
doable.
It's
a
large
project.
You
still
need
some
kind
of
bridge
to
the
debugger,
because
the
debugger
is
the
only
thing
that
has
access
to
memory,
so
they
need
to
communicate
now.
A
Both
lld
be
handy
to
be
do
some
do
have
features
like
this
lldp
uses
clang
to
compile
code
to
get
into
the
inferior
and
gb
can
do
that
with
GCC
as
well.
So
it
could
be
done.
However,
there's
also
this
issue
where
both
of
these,
both
of
the
debuggers
expression
evaluators,
implement
both
a
superset
and
a
subset
and
a
subset
and
a
superset
of
rust,
so
they
implement
just
the
expression
language,
but
they
also
add
some
extensions.
Like
GEB
has
this
thing
called
convenience
variables
and.
A
Ella
debe
has
some
similar
of
similar
kind
of
things,
but
there's
also
some
other
extensions
for,
like
you
know
in
rust,
your
kind
of
you
declare
what
you're
going
to
use
the
file
that
you're
doing
like
which
crates
you
might
refer
to,
but
in
debuggers
it's
convenient
to
just
be
able
to
refer
to
anything
anywhere
at
any
time.
So,
like
gb
has
an
extension
to
let
you
do
that.