search

sakhnik / nvim-gdb

Neovim thin wrapper for GDB, LLDB, PDB/PDB++ and BashDB
718 stars 38 forks source link

[Feature Request] backtrace to quickfix and breakpoints to quickfix #122

Closed kevinhwang91 closed 3 years ago

kevinhwang91 commented 3 years ago

I know these two features have listed in todo, I open this issue to let you know I care about them. :)

sakhnik commented 3 years ago

Right, there was a TODO list, but I completely forgot about it. Now I admit that these features would be really helpful. As well as another one that I realized when participated in the advent of code this year. To be able to store and restore breakpoints between debugging sessions. Luckily I'm just going to have holidays at the beginning of 2021. So stand by.

sakhnik commented 3 years ago

The idea is the following:

It's worth keeping the jump window focused to keep the terminal window visible.

sakhnik commented 3 years ago

@kevinhwang91, could you please check out the branch quickfix (https://github.com/sakhnik/nvim-gdb/tree/quickfix)? Let me know your opinion on the new commands GdbCopenBreakpoints and GdbCopenBacktrace before I merge the branch.

kevinhwang91 commented 3 years ago
  1. The format of GdbCopenBreakpoints is so weird.
  2. Please support custom layouts like topleft, botright, and so on.
  3. Do you know that copen or cwindow is buggy when multiple windows in a tab? Do you consider use location as an option?
  4. Neither information of breakpoints nor backtrace in quickfix window can't change with the user actions.
sakhnik commented 3 years ago

Thanks for your comments. Could you please elaborate on every point for me to understand better? Maybe with examples. I can only comment on the following at the moment:

  1. I'm reluctant to add too many features into the plugin that may be very taste-specific. I think of this as the separation of mechanism and policy. The plugin defines and implements the mechanism and users are free to set up their own policies in their config files.
  2. I don't know, actually. What bugs are we talking about? I only noticed that sometimes the terminal buffer window may be used when navigating the quickfix with :cnext or :cprev. So I had to make sure the jump window is focused before populating the quickfix in the tests. I'm afraid, the location list can hardly be used instead of the quickfix list. It is buffer-specific and contains locations in a single file. Whereas both backtrace and breakpoints can jump between different files randomly.
kevinhwang91 commented 3 years ago
  1. Here's the asciicast I recored: https://asciinema.org/a/384744
  2. Yes, I can't agree with you anymore. But vim has a <mods>, I found that GdbCopenBreakpoints and GdbCopenBacktrace don't support it.

  3. I only noticed that sometimes the terminal buffer window may be used when navigating the quickfix with :cnext or :cprev. So I had to make sure the jump window is focused before populating the quickfix in the tests.

I think you have already encountered this issue. If you vsplit A and B window, and then run copen in A, the quickfix window will split under B. quickfix window seems global, but buggy. Some qf plugin will fix this issue by using wincmd J in after/ftplugin/qf.vim

I'm afraid, the location list can hardly be used instead of the quickfix list. It is buffer-specific and contains locations in a single file. Whereas both backtrace and breakpoints can jump between different files randomly.

location is related to a window, not a specified buffer or file. You can run :h location-list for more details. If I want to make breakpoints or backtrace attach the debug window instead of the raw gdb terminal window, it's a good choice for using location rather than quickfix.

  1. If I have opened the quickfix window for breakpoints, and then add extra breakpoints inside the debug window, I expect the info of extra breakpoints will be added into quickfix.
sakhnik commented 3 years ago

Well, I see there's a lot more for me to investigate. Thanks!

sakhnik commented 3 years ago

I've changed the code to populate the code window's location list and implemented <mods>. Now, it's possible to make the list auto-updating itself by just defining the following autocmd: au User NvimGdbQuery GdbLopenBreakpoints. But I wonder whether it's worth just documenting the possibility instead of programming it. It's not clear when to disable the auto-update.

The last issue (the first in your original list) was about the breakpoint format. Well, it roughly corresponds to the breakpoint location lines obtained with info breakpoints. Except for the indentation. Perhaps we could ignore the issue.

kevinhwang91 commented 3 years ago

I will try it tomorrow, and feedback as possible as I could.

I've changed the code to populate the code window's location list and implemented <mods>. Now, it's possible to make the list auto-updating itself by just defining the following autocmd: au User NvimGdbQuery GdbLopenBreakpoints. But I wonder whether it's worth just documenting the possibility instead of programming it. It's not clear when to disable the auto-update.

I think to expose an event is enough. Embedded this function will trap you into quickfix black hole. Let users take these risks.

The last issue (the first in your original list) was about the breakpoint format. Well, it roughly corresponds to the breakpoint location lines obtained with info breakpoints. Except for the indentation. Perhaps we could ignore the issue.

Could we ignore this line? The valid field in this item is 0.

sakhnik commented 3 years ago

Could we ignore this line? The valid field in this item is 0.

Sure, I've updated the code. There could be more to it. For example, GDB reports how many times a particular breakpoint has been hit. I believe such info should be preserved.

kevinhwang91 commented 3 years ago
  1. Found an issue about file path. https://github.com/sakhnik/nvim-gdb/blob/3efa9032b7d0fa7b20f9132367edf736af207da4/rplugin/python3/gdb/backend/gdb.py#L115-L117

Relative/full file path of gdb should be consistent with nvim's. For instance, I test under directory /home/kevin/.config/nvim/plugged/nvim-gdb/test/src and run nvim +'GdbStart gdb ./a.out', I can get the correct buffer with locationlist. But if I under /home/kevin/.config/nvim/plugged/nvim-gdb/test and run nvim +'GdbStart gdb src/a.out', the target file of gdb is test.cpp, but in nvim, this relative path is not existed, I got an empty buffer for test.cpp with locationlist.

  1. I think these texts also should be filtered. image

BTW, which event could I use for subscribing to a breakpoint that is updated?

kevinhwang91 commented 3 years ago

Self-promotion: I just released a plugin related to quickfix. https://github.com/kevinhwang91/nvim-bqf Any feedbacks are welcome!

sakhnik commented 3 years ago

  1. The paths may be tricky if relative ones were embedded into the binary. Currently, it's expected that the user handles this: https://github.com/sakhnik/nvim-gdb/blob/81930348bbb1398635cc0ecbbc88e3defd8aaa0f/doc/nvimgdb.txt#L291 . But I'm open to suggestions. I wonder how GDB-TUI is handling the issue.

  2. I wouldn't filter out the breakpoint hit counters. They may be useful in the actual debugging. And they seem to be harmless in the navigation.

  3. The event is User NvimGdbQuery. I tested the following command: au User NvimGdbQuery GdbLopenBreakpoints.

kevinhwang91 commented 3 years ago

If GdbLopenBreakpoints and GdbCopenBacktrace could update items base on the quickfix id is better. For now, They are always creating new quickfix list instead of updating items if one exists.

Nevermind, this is an improvement, no other issues I found.

sakhnik commented 3 years ago

Thanks! Please let me know if there are more ideas.

sakhnik commented 3 years ago

By the way, I've just discovered that GDB has a neat option: set filename-display absolute. And suddenly the files will be located just fine from any directory as long as GDB is able to do so.

125

kevinhwang91 commented 3 years ago

By the way, I've just discovered that GDB has a neat option: set filename-display absolute. And suddenly the files will be located just fine from any directory as long as GDB is able to do so.

125

I can confirm that it works!