Debugging hints

[gerd-moellmann]

Just some hints for debugging Emacs with LLDB, not specific to emacs-mac:

• I've read in the debugging notes that are linked from the README.md of emacs-mac that one could use the lldb TUI on the command line or realgud to debug. That's true, but since Emacs 30, one can also use the built-in M-x lldb which works like the old M-x gdb, using Gud.

• If you start LLDB from src/it picks up src/.lldbinit which loads support commands from etc/emacs_lldb.py. Please read the comment in src/.lldbinit for how to make sure it gets loaded. By default, lldb doesn't load local init files, for security reasons.

• One convenient way to debug Emacs is to M-x lldb from src without giving lldb arguments. Then use the xattach command that is defined in src/.lldbinit. This makes LLDB wait for the next Emacs process that is started, attach to that, and continue. Once LLDB has attached to the process, you can use C-c to interrupt it and give lldb control. Sometimes it is convenient to set breakpoints before xattach to let lldb stop there after it has attached to the process.

• I am using a support modelldbx to make debugging a bit more convenient for me. This makes source buffers read-only so that one can do stuff with single-key commands. Use ? in such a buffer to pop up a transient for the available commands. To activate, M-x global-lldbx-mode.
  The web interface doesn't let me attach the file, but it can be found here: https://github.com/gerd-moellmann/emacs-with-cl-packages/blob/cl-packages/lisp/progmodes/lldbx.el

[jdtsmith]

Thanks! Good stuff.

one can also use the built-in M-x lldb which works like the old M-x gdb, using Gud.

Yeah, I use M-x lldb, but realgud overrides it (lldb is an alias for realgud--lldb in lldb/lldb.el.) It works OK, but it has many of the clang commands incorrect, such that single key quick-stepping, etc. fails. And it doesn't handle multiple threads well because it hard-codes thread number to 0 IIRC. Do you have that problem too? At least it syncs position as you step around (and I love the red/yellow/green recent trace fringe marks). Luckily empty input repeats the last command, so it's pretty quick still.

If you start LLDB from src/ it picks up src/.lldbinit which loads support commands from etc/emacs_lldb.py. Please read the comment in src/.lldbinit for how to make sure it gets loaded. By default, lldb doesn't load local init files, for security reasons.

Yes, I always do that and get Emacs debugging support has been installed., but I ended up not using these special macros like xprint too much, because lldb has so many cool ways to inspect things. E.g. br com for watchpoint type things. You can even run python scripts on the call stack to decide whether to break, for example. Been quite impressed with it.

I am using a support mode lldbx

Ooh, is that your own mode? Has it been submitted upstream? Maybe I should dump realgud in favor of this. Will take a look.

[gerd-moellmann]

JD Smith ***@***.***> writes:

Thanks! Good stuff. one can also use the built-in M-x lldb which works like the old M-x gdb, using Gud. Yeah, I use M-x lldb, but realgud overrides it (lldb is an alias for realgud--lldb in lldb/lldb.el.) It works OK, but it has many of the clang commands incorrect, such that single key quick-stepping, etc. fails. And it doesn't handle multiple threads well because it hard-codes thread number to 0 IIRC. Do you have that problem too? At least it syncs position as you step around (and I love the red/yellow/green recent trace fringe marks). Luckily empty input repeats the last command, so it's pretty quick still.

When I started using Emacs again in 2022, after 20 years, that was on an M1 mac, and the first thing I stumbled over was that GDB didn't, and still does not, support arm64 macs. I tried everything under the sun to use LLDB, including realgud, dap-mode, and what not. Nothing really worked for me with Emacs, and the emacs-specific commands in .gdbinit were of course missing, and so on. That's why I added M-x lldb and etc/emacs_lldb.py. It's still not ideal, and, as usual, I don't really know the LLDB Swig Python interface well nor was I a Python programmer. So I'm sure there are problems with it. Patches welcome is what one says in that case, I guess :-).

If you start LLDB from src/ it picks up src/.lldbinit which loads support commands from etc/emacs_lldb.py. Please read the comment in src/.lldbinit for how to make sure it gets loaded. By default, lldb doesn't load local init files, for security reasons. Yes, I always do that and get Emacs debugging support has been installed., but I ended up not using these special macros like xprint too much, because lldb has so many cool ways to inspect things. E.g. br com for watchpoint type things. You can even run python scripts on the call stack to decide whether to break, for example. Been quite impressed with it. I am using a support mode lldbx Ooh, is that your own mode? Has it been submitted upstream? Maybe I should dump realgud in favor of this. Will take a look.

Yes, it's a little private hack. I posted it to emacs-devel at some point, but there was no reaction. The interest in macOS is, erm, limited, I guess :-).

[jdtsmith]

I posted it to emacs-devel at some point, but there was no reaction.

You could always package it up and stick on MELPA or ELPA. Would then be easier to point interested users (and potential emacs-mac developers) to it. Happy to help with that if you like (it's easy).

The interest in macOS is, erm, limited, I guess :-).

I find it strange that macOS is the 2nd most used OS for Emacs by a long shot, but gets not much support. Even the go to person when there's a problem with NS is not using macOS any longer. Windows gets more support, despite being 3x less used.

[gerd-moellmann]

JD Smith ***@***.***> writes:

I posted it to emacs-devel at some point, but there was no reaction. You could always package it up and stick on MELPA or ELPA. Would then be easier to point interested users (and potential emacs-mac developers) to it. Happy to help with that if you like (it's easy).

I don't want to, and I'm sure that sounds a bit weird :-). Reason is that i don't want to maintain anything ever again. And the reason for that is, summarized: (1) fond memories of developing later Emacs 21, and later releasing and maintaining it as head maintainer. (2) I'm an early 1957 model, retiree, and I don't have the time for maintaining things, I want to do something more interesting that I didn't have the time for when working. But I find sharing stuff for free stuff only fair. BTW, if you are anyone else wants to make a package out of lldx, please do, tell me, and I'll use it. I also have another one tm.el someone could make a package of. Also posted to emacs-devel.

The interest in macOS is, erm, limited, I guess :-). I find it strange that macOS is the 2nd most used OS for Emacs by a long shot, but gets not much support. Even the go to person when there's a problem with NS is not using macOS any longer. Windows gets more support, despite being 3x less used.

I can understand them. It's simply that no one has stepped up to maintain NS. What remains are very few people trying to fix things as well as they can. It's the same for other parts of Emacs, multi-tty comes to my mind, or the Windows port, where that has the advantage that Eli is a Windows user. But Eli is also about as old as I am. Richard has stopped programming 1992, Lars has disappeared, and I don't see many commits from co-maintainer. The project is not exactly brimming with energy, ideas, and passion, from my POV. Except when making sure that there are always two spaces after a period. But I'm being mean :-).

[jdtsmith]

This all makes perfectly good sense to me. It can be a real hassle to maintain things.