Re: Debug setup in emacs

[Catonano]

Hi Fredrik,

Il giorno sab 5 set 2020 alle ore 02:53 Fredrik Salomonsson <
plattfot@posteo.net> ha scritto:

>
> Hi,
>
> I've been playing around with guile for awhile and really liking it. One
> thing I haven't figured out is how to setup a good debugging environment
> in emacs, similar to edebug for elisp or gdb i.e. have a buffer that
> shows me were I am in the code.
>
> The manual (from what I have found) only shows me how to run that in a
> REPL. And I didn't find much when searching in the mailing archive. Is
> there a way to set this up or is the REPL the way to go?
>
> I'm currently using guile-2.2.7 and I'm using guile-hall-0.3.1 [1] for
> building and running my tests.
>
> Thanks
>
> [1] https://gitlab.com/a-sassmannshausen/guile-hall
>
> --
> s/Fred[re]+i[ck]+/Fredrik/g
>
>
you already received an answer about the integration between the Guile
debugger and Emacs GUD

I'd like to illuminate a different point here

The Guile debugger currently isn't able to show local variables in many
cases

So even if you could achieve full integration between it and Emacs GUD, you
probably still wouldn't get full information in your GUD based human
interface

That is, the guile debugger in its current incarnation is broken, it
doesn't debug

The reason why this happens is explained, to some extent, in a post by Andy
Wingo on his blog about some tasks to improve the compiler he'd like to
have implemented,

it's here (read the "basic register allocation" task)
https://wingolog.org/archives/2016/02/04/guile-compiler-tasks

In a more recent post, Andy extended his argument on the implementation of
debugging
https://wingolog.org/archives/2018/02/07/design-notes-on-inline-caches-in-guile

This is a relevant paragraph

"Honestly I struggle a lot with the idea of debugging native code. GDB does
the least-overhead, most-generic thing, which is patching code directly;
but it runs from a separate process, and in Guile we need in-process
portable debugging. The debugging use case is a clear area where you want
adaptive optimization, so that you can emit debugging ceremony from the
hottest code, knowing that you can fall back on some earlier tier. Perhaps
Guile should bite the bullet and go this way too."

So there seem to be deep reasons that have to do with optimization, runtime
support for offering a full debugging experience in Guile

Anyway, the info I want to convey is that even of you manage to have the
communication between the Guile debugger and Emacs GUD set up, you still
might be disappointed by the result

I think it's important that you know this before pouring effort in having
your GUD based thing going