Issue running make from ugdb

[ericonr]

Hey there, I loved this project! It's a great interface for gdb, specially the expression evaluation part!

However, seeing as you are probably a Rust developer, I don't believe you would have encountered this issue. I am currently using ugdb for debugging a C program, which is compiled using a Makefile. When using normal gdb, I tend to run the make command whenever I make changes to the source code. The output from make should appear inside the "interactive" part of ugdb, if it had the same behavior. Instead, the TUI is gone for a while, make runs on the normal terminal screen (with weird formatting, btw), and then it returns to the TUI. That by itself isn't much of a problem. What is, however, is that the source code displayed on ugdb isn't updated to the latest version, so if I make any changes besides changing what's already on a line, I can't be sure the breakpoints will be on the right place or anything. Because of that, if I make any changes I close ugdb and then open it again.

I can post videos showing the expected behavior on gdb and what's happening on ugdb, but my internet connection is not cooperating right now!

I want to learn Rust at some point, so I could try to make the necessary changes to the program later on, if you feel this is not a feature you want to work on. If that ends up being the case, this issue will serve as a reminder for me :D

PS: I think that the make function is pretty useful in gdb. It could be interesting to implement an option to run a cargo build command from inside ugdb.

[ftilde]

Huh, I had no idea that you could run make from within gdb. I actually use c++ with make at work, but usually run it from within vim or another terminal. I'm curious: Is there any benefit from running make from gdb other than avoiding opening another terminal or sending gdb to background? (like automatic reloading of the binary or something?)

The problem is likely that we wait for the response of gdb before continuing execution. We might get away with continuing execution without waiting for the result, but we drop error messages in that case (for example if gdb is busy and cannot execute the command currently). I've read somewhere that it is possibly to run gdb (with mi) in async mode, which might help here, but I would have to look into that more closely. Another possibility would be to add some kind of callback for the response in the GDB struct of the gdbmi module.

[ericonr]

I do it mostly in order to avoid changing/opening another terminal. In my case, I usually debug embedded applications, so loading the binary to the target is done manually, and I think it will use an updated binary independently of how it was generated. However, in my current setup, I always have a terminal next to the text editor, so running make from there is pretty easy, and the important change here would be the source code updating itself.

I'd have to study more of the architecture of both gdb and ugdb before helping in thinking up a solution.

[ftilde]

It's been a while, but I just thought of a possible solution to the make problem: Replace the widget that currently displays gdb output (an unsegen::LogViewer) with a terminal widget (from unsegen_terminal) and feed it the raw bytes from gdb stdout (when not gdbmi related). This should properly handle terminal escape codes that would mess up the whole terminal otherwise.