This repository was archived by the owner on Jun 14, 2024. It is now read-only.
Repository navigation
This repository was archived by the owner on Jun 14, 2024. It is now read-only.
Multithread debug issues #51
Description
I have just touched vim. My English is not very good, please feel free to laugh at me.
I used lldb.nvim to debug multithreaded code when there was a bug.
First, I use the "thread select" command to select a thread, and then enter the "LL next" command, lldb.nvim will automatically switch to the main thread. I have to choose my target thread over and over again.
After testing, this bug does not appear to use lldb directly.
I captured a video as follows:
Activity
critiqjo commentedon Apr 18, 2017
Wow! Thanks for the rich bug report. Unfortunately, this is probably due to the same reason as #50 (which is that it has nothing to do with this plugin; just bugs within LLDB's python API).
To elaborate a little more, commands executed using
:LLare directly processed by aSBCommandInterpreterobject. The only extra commands that are executed by the plugin are these for populating the vim buffers with relevant information. Fetching the breakpoints list for placing the bp-signs, and the program counter list for placing the pc-signs all use LLDB's python APIs, and are not supposed to affect the selected thread.In short, there's nothing I can do! (And I refuse to patch up an upstream bug in plugin either.) The more important issue is that lldb-devs don't seem to care about Python API bugs either (for some years now). I think they are expecting plugins to use their new machine interface which is developed to be compatible with GdbMI which claims to be becoming a de-facto standard (Update: link now broken, but see this project which, in a way, supports this point).
So you might ask: Does this project have no future? That's right, I'm abandoning this project!! 😅 ...in favor of gdb.vim, which uses Gdb/MI through pygdbmi! I'm hoping to resume developing it in a month or two.
PS: What tool did you use for editing the video to add those text bubbles?
lenfien commentedon Apr 18, 2017
Thank you so much ! The tool is Camtisia 3.
So, It seems the machine interface of lldb and gdb is future. This is the most useful information I get because of my novice.
I am eager to use your new plugin~ Please complete as soon as possible， just can not wait～😊
johncf commentedon Mar 11, 2018
cc #59
Remove unmaintained lldb plugin
mellery451 commentedon Apr 13, 2018
the link in the README led me here - does this mean that gdb.vim is the way forward even for LLDB users? It unclear to me if it's intended to work using lldb-mi or if it only supports gdb/mi. Any clarification appreciated.
johncf commentedon Apr 15, 2018
@mellery451 I stopped developing
gdb.vimafter I met with a roadblock from vim's side at the time (it did not redraw the buffers on windows that are not focused, when the buffers are updated remotely). Agdb.nvimproject is definitely very feasible, but currently I'm invested on other projects that I don't have time for it.ikcalB commentedon Jul 15, 2018
@lenfien old but gold ;)
what colorscheme do you use in that vid?
Regards from austria
lanza commentedon Sep 5, 2018
lldb recently had a DAP adapter tool land upstream on master - lldb-vscode. Might be of interest for a tool like this.
johncf commentedon Sep 5, 2018
@lanza Looks very interesting. I'm sure it'll have long-term support for many debuggers if something as big and popular as VSCode is backing it. Unfortunately, I won't be updating lldb.nvim anymore, nor I would review PRs for this since a large portion of the code needs to be changed and it does not make sense to make radical changes to this project in the absence of an active maintainer.
But you're free to copy any part of the source code (fork or not) if that helps you to create and maintain your own independent project.
BatmanAoD commentedon Oct 28, 2019
@critiqjo Since the
READMEpoints to your comment above, would you mind updating the gdb.vim link to point to the current location (underdbgx), since it's currently broken? I suppose you could update theREADMEinstead, and I see that you're not actively developinggdb.vim, but at least by editing the comment you'd provide a slightly more robust trail of breadcrumbs than the one I just followed! 😆