dbgx / lldb.nvim

No longer maintained. Possible alternative: https://github.com/rcarriga/nvim-dap-ui
Other
262 stars 20 forks source link

How to debug an interactive command line application? #43

Closed guyzmo closed 7 years ago

guyzmo commented 7 years ago

I'm using lldb to debug an ncurses application, and because the debugged process' output is thrown in the logs buffer ­— and input looks like it's ignored, it's impossible to interact with the application.

Would it be possible to have lldb.nvim have a :term like interface where it'd run the UI of that kind of application?

critiqjo commented 7 years ago

You have to run the application externally and attach to the process. See FAQ for more information.

(Closing since implementing an internal :term-like interface is not possible AFAIK)

guyzmo commented 7 years ago

(Closing since implementing an internal :term-like interface is not possible AFAIK)

actually, that's somehow possible… basically what would need to be done is to create a new window split, and in there run:

:term <name of the executable target>
:let target_pid = b:terminal_job_pid
:ex('LL process attach ' . target_pid)

so the question would be how could I extend lldb.vim to make a new kind of split windows set and insert that in the debugging of the app?

guyzmo commented 7 years ago

the best way to do so would be to have a layout setup that could just do that when starting the app (making sure when the restarting the debugging session the app gets killed etc…).

or at least, make a little vim function that would issue the correct sequence of commands so that lldb.vim gets started, then the term with the debuggee, then lldb attaching that tool…

critiqjo commented 7 years ago

basically what would need to be done is to create a new window split, and in there run: [...]

For the attach to work, Neovim has to be run as super user, which I don't think is a good idea.

guyzmo commented 7 years ago

not necessarily, it works nice if you do:

echo 0 > /proc/sys/kernel/yama/ptrace_scope

before debugging your code (and setting it back is a good idea).

critiqjo commented 7 years ago

I see... Didn't know about that. I just read this AskUbuntu answer about it. So it does seem much cleaner to not have the editor run as root, but now the whole system becomes vulnerable during that period, right? (Though the risk is probabilistically very low.) It's like a choice between two evils! :smile:

Anyway, the more important thing is that I've stopped developing new features for this project. PRs are welcome!

PS: I'm actually secretly looking for someone who might be really interested to take over the project! And just transfer repository ownership!

guyzmo commented 7 years ago

ok, I figured out a way that's working fine:

:vsplit term://./program | exec(":LL process attach -p " . b:terminal_job_pid)

where program is the target program you want to debug. But for better security, your link is actually providing a better alternative than disabling ptrace_scope, which is to give unscoped ptrace capability to lldb only:

sudo setcap cap_sys_ptrace=eip /usr/bin/lldb

So I'm just going to make a PR for updating the FAQ ☺

Anyway, the more important thing is that I've stopped developing new features for this project.

AFAICT, the project seems pretty complete, but I'm only starting to use it in a more thorough way, so who knows ☺ But happy to see you're still around and not leaving this project to dry.

PS: I'm actually secretly looking for someone who might be really interested to take over the project! And just transfer repository ownership!

I'd be happy to help, but I'm trying to focus on a few projects at a time, I got my hand full ATM ☺