use case(record and replay workaround): record, edit and replay gdb commands

[matu3ba]

I do see that you build a plugin, which takes record and replay more serious, which the other debugging plugins unfortunately do not.

Unfortunately, rr supports not all platforms and chips and having a way to get rr-like behavior by fast manual record, edit and replay the gdb commands would be great.

So far the TODO only contains store and load breakpoints between sessions, but gdb also allows to store the complete session and source it via gdb -x SCRIPT. Some use cases like changing the environment variables like PATH='' even require the sourcing of a script before execution.

So far, script is supported, but I dont see an option to "rerun the script after modification" or API functions to setup this up on my own. Is this in scope of this plugin?

Other more nice stuff would be to describe 1. how to extract var names and var values of current breakpoint in lua, 2. how to get the state (changes) of variable (changes) from watchpoints, 3. document how to debug both child and parent processes in a fork/vfork/clone via http://www.qnx.com/developers/docs/qnxcar2/index.jsp?topic=%2Fcom.qnx.doc.neutrino.prog%2Ftopic%2Fusing_gdb_MultipleProcesses.html

It would be nice, if there would be lua API. Maybe its just not yet documented?

[dtomvan]

rr supports not all platforms and chips

Neovim doesn't either, but I do get why you would want a REPL-like behaviour for gdb.

[matu3ba]

Neovim doesn't either

Unfortunately rr does not work at my workplace.

you would want a REPL-like behaviour for gdb

I dont understand how internally nvim-gdb stores debug points and the command translation for gdb works to estimate if its worth attempting or not (if it just works). As I understand it, the plugin should be able to allow input from external sources or gdb doing its own thing.

Can I could just execute the gdb command to save the history file before quitting and sourcing via gdb -x or does this break the plugin in weird ways (not showing the breakpoints, where the program halts with events etc)?

[sakhnik]

Essentially, nvim-gdb does only two things: it queries constantly the actual breakpoint locations from gdb to display them as signs and monitors the gdb output to jump to the current frame in the source code. That said, you can execute any gdb commands like store/load sessions and it shouldn't matter to the plugin. Unless you change the prompt or GDB output format.

By the way, the Lua API is already there although not advertised: https://github.com/sakhnik/nvim-gdb/blob/4408d2c10618636101945e9cd9ef9d68fc335e19/autoload/nvimgdb.vim#L39 where NvimGdb is just require'nvim-gdb'.

[matu3ba]

Cool, this looks perfect for my use case. Thanks a lot!

[matu3ba]

I think what I actually want is an editable scratch buffer with the gdb command history and a command to load the current actual history into a scratch buffer.

I hope to find some time for a PR soon.

[matu3ba]

Some observations during playing around:

• 1. storing and loading breakpoints dynamically is as simple as save breakpoints tmp and source tmp.
• 2. Trying to run gdb -x /tmp/histfile executable` doesnt work due to the autosearch/autocomlete suggestions. Can those be turned off?
• 3. At least according to the manual there is no command to get the complete history unless one exits gdb. This is my open stackoverflow question as to not being forced to keep an append-only buffer for the actual history for the whole session and being forced to replicate the whole gdb behavior.
• 4. On which systems is this hack readlinkf(){ perl -MCwd -e 'print Cwd::abs_path shift' "$1";} still needed and realpath not sufficient?

Questions for implementation:

• I see that parser_impl the tty gets parsed (and I guess forwarded to the gdb instance), but how does the parser get the data? Does it share the same tty somehow or what components connect to which on a bigger picture?
• Would as first step logging everything into a per session named tmp buffer be sufficient?
• I think using gdb logging and stripping the sequence numbers is the most simple approach: Turns out, yes, but extracting the full log without exiting is annoyingly complex, see the accepted answer https://stackoverflow.com/questions/74214750/how-to-get-the-complete-command-history-of-gdb-before-exiting

[sakhnik]

* 2. Trying to run gdb -x /tmp/histfile executable` doesnt work due to the autosearch/autocomlete suggestions. Can those be turned off?

This should be easy: https://github.com/sakhnik/nvim-gdb/blob/127087ec368212d4d763aeb58fdf585abc6a8a0e/doc/nvimgdb.txt#L249

* 4. On which systems is this hack `readlinkf(){ perl -MCwd -e 'print Cwd::abs_path shift' "$1";}` still needed and `realpath` not sufficient?

I'm not aware of realpath, thanks for pointing it out. I suspect the function readlinkf() was used specifically to work on macos. Unfortunately, the CI is broken on macos now, and I don't have such a system to test with. So let's keep this in mind for a while.

[sakhnik]

So as it happens, there's no realpath in GitHub's macos: https://github.com/sakhnik/nvim-gdb/actions/runs/3356138869/jobs/5561131850

[matu3ba]

https://stackoverflow.com/a/40311142 os.path.realpath(os.path.expanduser('~/subdir/../data'))should work, if it uses realpath on macos.

However, I cant say much on what python uses internally with what fallback code for compatibility. Startup perf of perl should be faster than python however and the python testing code would be more verbose. I dont think that would make a big difference though, since the plugin uses python wrappers anyway.

Just for completeness, lua(filesystem) does not have realpath implemented yet https://github.com/lunarmodules/luafilesystem/issues/64.

[matu3ba]

Can you tell me how you would like to store and load persistent state of project paths of nvim-gdb? See also #180.

Some notes on the user-options: I think its better to keep things more low-level as there are many ways to define, load and store a scratch buffer. The basic principle is to use (here in comments showing abit different use cases meshed together)

M.makeNamedScratch = function(filepath, scratchname)
  local bufs = vim.api.nvim_list_bufs()
  --for i, v in ipairs(bufs) do
  --  if(vim.api.nvim_buf_get_name(v) == "abspath_tocompare") then
  --    print("matching comparison")
  --    return false
  --  end
  --  print(k, ", ", v)
  --end
  local uri = vim.uri_from_fname(filepath)
  local bufnr = vim.uri_to_bufnr(uri)
  vim.bo[bufnr].bufhidden = ""
  vim.bo[bufnr].buflisted = true
  vim.bo[bufnr].buftype = ""
  vim.bo[bufnr].readonly = false
  vim.bo[bufnr].swapfile = false
  return true
end

and one can either use for scratch only buffer a user-given table of predefined names to match against or one can use absolute paths.

Hence the things needed are

• 1. aforementioned python function (sourced within gdb and used like server pipe show all-commands | sed -e 's/[[:space:]]\+[0-9]\+[[:space:]]\+//' | head -n -1 > /tmp/gdb_allcmd)
• 2. lua function with path as variable where gdb should log execution
• 3. lua function with path as variable where gdb history should be written to
• 4. clarification from you, where and how you want to store persistent state of nvim-gdb
• 5. clarification (from neovim team) how one can pipe from shell into scratch buffers (not having an underlying file with filepath)

UPDATE A much simpler way is to use

M.makeScratch = function(scratchpath)
  local buf = vim.api.nvim_create_buf(true, true) -- listed, scratch: nomodified, nomodeline
  vim.api.nvim_win_set_buf(0, buf)
end

[sakhnik]

I'm sorry, I've been lost for a while. Is there a feature demo from the user's point of view? We could discuss the technical details later.