I am not sure whether this is an issue with FreeBSD or lldb, please point me into the right direction.
Recently I updated from FreeBSD 11 (system llvm/clang/lldb 4.0) to FreeBSD 11.1 (system llvm/clang/lldb 5.0). Now I am back working on one of my threaded server programs and in the past I happily used the ncurses GUI which is builtin to lldb for debugging.
Unfortunately, in my present setup, stepping over and into my code is quite cumbersome, because the GUI loses after each step the focus on the thread in which the step command was issued and switches the code window to another thread showing the assembly code of the accept() function in libc. In order to continue, I need to manually select the thread of my interest in the list of threads, and then I may issue the next step, which then lets the GUI lose its focus again and so on.
For the time being I step through my code without the GUI and then start the GUI only when I want to examine some variables.
I did not see this behaviour in FreeBSD 11 (system llvm/clang/lldb 4.0).
Any ideas, what is going on here? Any ideas for a workaround? In case this is a FreeBSD issue I would be glad to hear some keywords which I can use for a bug report.
Many thanks for any replies.
Sorry, I confused the version numbers.
FreeBSD 11 came with llvm 3.8, and FreeBSD 11.1 is using llvm 4.0. However, I just ran a debugging session with lldb 5 from llvm-5-devel from the ports on FreeBSD 11.1-RELEASE (x86-64) and it showed the same issue.
I wrote the "gui" mode many years ago in hope we would get people to work on it and improve it. No changes have been made since it was originally done. I would welcome any patches to help improve "gui" mode and make it great. I was never able to take the time to improve it to where it needs to be.
That being said. I do believe selecting the single thread with a valid stop reason has been broken for a while. Not sure why it got worse in the latest release. I might more contribute that to changes in the FreeBSD codebase.
GUI mode needs the following fixes if anyone does want to help work on it:
- make sure correct thread is selected each time you stop. A few clarification on how this should work follows. If there is only one thread with a valid stop reason, that thread should be selected automatically. If there are more than one thread that have valid stop reasons, then keep the previous thread that was selected as the selected thread, or switch to the first thread with a stop reason if the previous stop was in another thread.
- we need a command line interpreter window that allows users to do command line commands. combining readline functionality with curses is tricky, especially with libedit as it is missing the functions that GDB uses to make the two work together (since GDB uses the real readline library)
Many thanks for your answers.
For me, the builtin ncurses-GUI mode of LLDB is a unique selling point compared to GDB. Only, my impression is that not many developers are aware of this fantastic feature and keep on breaking their fingers on the debuggers command line not by choice but because the GUI mode is widely unknown.
Regarding the todo list:
- A fix for the thread selection issue would be highly welcome, of course.
- Personally, I did not miss a command line in GUI mode, since the GUI
is perfect for stepping over your code and at the same time lets you examine
all the variables at once. If I need more, I exit the GUI and use the common CLI.
Perhaps, it would be sufficient to have a CLI/GUI toggle hot key.
- Once thread selection works again, I assume many people would appreciate
to become prominently informed about the builtin GUI feature. IMHO, it would
be great to add a GUI tutorial to the lldb documentation.
Well, I opened llvm/tools/lldb/source/Core/IOHandler.cpp in Xcode, and I see 5 occasions where the Process's member function GetStopID() is called. It is late now. Tomorrow, I will try a hot fix by changing line 3913 to:
const bool stop_id_changed = stop_id != m_stop_id && !m_stop_id;
And changing line 3915 to:
m_stop_id = stop_id;
Unfortunately, I am not very good in C++. I guess for a really good fix, it would be great to obtain a list of all stopped threads in order to see whether the previous one is still in a stopped state.