Comments (11)
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.
from nvim-gdb.
Some observations during playing around:
-
- storing and loading breakpoints dynamically is as simple as
save breakpoints tmp
andsource tmp
.
- storing and loading breakpoints dynamically is as simple as
-
- Trying to run gdb -x /tmp/histfile executable` doesnt work due to the autosearch/autocomlete suggestions. Can those be turned off?
-
- 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.
-
- On which systems is this hack
readlinkf(){ perl -MCwd -e 'print Cwd::abs_path shift' "$1";}
still needed andrealpath
not sufficient?
- On which systems is this hack
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
from nvim-gdb.
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.
from nvim-gdb.
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)?
from nvim-gdb.
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:
Line 39 in 4408d2c
where
NvimGdb
is just require'nvim-gdb'
.from nvim-gdb.
Cool, this looks perfect for my use case. Thanks a lot!
from nvim-gdb.
* 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:
Line 249 in 127087e
* 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.
from nvim-gdb.
So as it happens, there's no realpath
in GitHub's macos: https://github.com/sakhnik/nvim-gdb/actions/runs/3356138869/jobs/5561131850
from nvim-gdb.
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 lunarmodules/luafilesystem#64.
from nvim-gdb.
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
-
- 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
)
- aforementioned python function (sourced within gdb and used like
-
- lua function with path as variable where gdb should log execution
-
- lua function with path as variable where gdb history should be written to
-
- clarification from you, where and how you want to store persistent state of nvim-gdb
-
- 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
from nvim-gdb.
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.
from nvim-gdb.
Related Issues (20)
- Error using lldb HOT 7
- Is it possible to disable default keybindings? HOT 1
- Implement checkhealth
- Feature Request: Make vim the owner of breakpoints and not the debugger HOT 3
- Error detected while processing TabLeave Autocommands for "*" on tabnew: GdbStartPDB HOT 7
- [Solved] Unknown sign: GdbBreakpoint0 after merging d7504a52e3f5f1b6d7f62a006646681bde65a310 HOT 2
- 'GdbStart...' error if delete buffer at event 'NvimGdbCleanup' HOT 2
- mingw support? HOT 6
- Port the test suite to be based on Lua
- Port launch scripts to Lua
- Port PTY proxy to Lua
- Support PerlDB HOT 4
- gdb attach mode HOT 1
- My environment breaks the plugin HOT 2
- error calling thread_get_state for gp registers for thread 0x1d3 HOT 9
- nvim_config_override works with vimscript functions but not lua functions HOT 1
- DWARF2 Queue Guard Internal Error on run HOT 6
- showing variables when debugging with bashdb HOT 3
- [Question] unable to run lldb on Mac HOT 2
- GDB crashes with Fatal signal: Segmentation fault
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from nvim-gdb.