Support GDB

[orhun]

Is your feature request related to a problem? Please describe.

Quoting from @[email protected]:

If I were to request some feature it would be a TUI front end to GDB similar to how PWNDBG or GEF does it, but that would probably be way too ambitious

Describe the solution you'd like

Throwing this here for brainstorming purposes.

Describe alternatives you've considered

None.

Additional context

• https://github.com/hugsy/gef
• https://github.com/pwndbg/pwndbg

[TornaxO7]

Suggestion: Maybe we could go even further and create something like an interface for debuggers so that we can probably call something like bugstalker instead of gdb.

[orhun]

That's a very good idea!

In fact I would like to invite the author of bugstalker @godzie44 here for asking his opinion and potentially collaborating on this :)

[godzie44]

Hey! I also think that this is a cool idea, and I am ready to help in its implementation.

I think it would be nice to have a command like binsider inside bs. But, maybe you have a different vision of such integration.

[orhun]

I was thinking more like having a separate tab inside binsider for running bs with a TUI somehow. In some prompt you can enter debugger commands and get the output.

Also, see what I did for heh, we can potentially use the whole app as a TUI widget inside bs :)

What do you think?

[godzie44]

I like both options. But I'm not sure how ready bs is to work as a widget, because it relies heavily on the tuirealm framework. I'll try to do some RND on that.

[godzie44]

About bs in binsider

Unfortunately, as i expect, the possibility to integrate tui of bs into tui of binsider looks difficult to implement, because bs uses tuirealm (with ratatui 26) and binsider uses latest ratatui. It seems that such integration requires a very large refactoring of bs.

About binsider in bs

It seems like it would be much easier to do this. Especially, If binsider introduce interface like heh. I'm trying to integrate bs with heh and it's looks cool (and easy for implement), see godzie44/BugStalker@1757c1c.

A small demo:

[orhun]

That's cool! I would want to see this implemented in two ways at the end of the day but putting binsider in bs seems like super easy and convenient :)

Especially, If binsider introduce interface like heh

Would you be interested in contributing that? 👀 As a reference: ndd7xv/heh#120

[godzie44]

Of course, i think i can do this

[orhun]

Perfect!

[godzie44]

Hey @orhun , i'm try to implement binsider as a widget, but face with the problem - binsider should reset (or re-create) a whole terminal for properly work. I think this makes a problem when binsider widget will be using in another tui (like window in window). What do you think about it? Is it possible to don't reset (re-create) a terminal? Or even, should we think about reject binsider as a widget idea, and just implement embedding into terminal application (for bugstlaker this will be enough)?

[orhun]

should reset (or re-create) a whole terminal for properly work.

Hmm, can you expand on this a bit? Not sure if I get the problem here.

just implement embedding into terminal application (for bugstlaker this will be enough)?

What do you mean by embedding it? 👀

[godzie44]

Hmm, can you expand on this a bit? Not sure if I get the problem here.

As i see for heh, just exposed two methods: draw and handle_input

terminal.draw(|frame| {
    heh.render_frame(frame, frame.area());
});
heh.handle_input(&ratatui::crossterm::event::Event::Key(/* */)).unwrap();

This interface give a possibility to create own Terminal instance and control it by user. In other side, binsider highly coupled with Tui structure that own a Terminal, and contains method like init/reset/exit so user of binsider widget cannot control it by its own. I'm not so good at tui as you, but i think this may be a problem, is it so?

What do you mean by embedding it? 👀

Instead of draw and handle_input just expose start_tui function for user, so binsider will control all terminal lifecycle as now. But better solution, as i see, make some refactor for decople from Tui component.

[orhun]

Ah I see. I gave this a shot and realized it is actually possible without changing the API: #52 (just a small tweak in the prelude)

I think that's a good start. What do you think? :)

[godzie44]

It's looks very good for me, and fully covers integration with bugstalker. The only downside is the rather complex interface for the caller, but I don't see any simple solutions here.

[orhun]

yup, do you think you can give it a shot implementing it? I'm also down to simplify the API based on your usage btw

[godzie44]

@orhun JFYI godzie44/BugStalker#45

yup, do you think you can give it a shot implementing it? I'm also down to simplify the API based on your usage btw

yep, i can try

[godzie44]

@orhun please check this draft #73, if you ok with it - i will make code cleaner

[wcampbell0x2a]

FYI: I started writing an architecture agnostic gdb tui frontend. It's still in the early days of testing and performance: https://github.com/wcampbell0x2a/heretek

[orhun]

That's awesome!

I fell a bit behind on integrating BugStalker (and overall maintenance of this project) but that's something that I want to have as a functionality in the future!

I'm not sure if you would be open to designing your API in a way that follows #52 (or #73), but if you do, definitely let me know when the project reaches semi-stable state and it would be great to discuss potential collaborations :)