[lldb-dev] lldb 5.0 debugging a threaded C program on FreeBSD 11.1-RELEASE (x86-64)
Hello, 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. Best regards Rolf ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] lldb 4.0 (not 5) debugging a threaded C program on FreeBSD 11.1-RELEASE (x86-64)
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. Best regards Rolf > Am 16.11.2017 um 18:18 schrieb Dr. Rolf Jansen via lldb-dev > : > > Hello, > > 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. > > Best regards > > Rolf > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Unifying ctor+Clear() inits into in-class initializers?
Hi,
https://reviews.llvm.org/D40212
At least DWARFCompileUnit and I see even for example MachVMRegion duplicate
intialization of fields in both their constructor and Clear(). Moreover the
initialization is in different place than declaration of the member variable.
Is it OK to just use in-class member variable initializers and:
void Clear() {
this->~ClassName();
new (this) ClassName();
}
?
Pavel Labath otherwise suggests to just call Clear() from the constructor.
Still then I find the code could be more readable with in-class members
initializers - moreover during further refactorizations+extensions.
Thanks,
Jan Kratochvil
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] lldb 5.0 debugging a threaded C program on FreeBSD 11.1-RELEASE (x86-64)
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) > On Nov 16, 2017, at 12:18 PM, Dr. Rolf Jansen via lldb-dev > wrote: > > Hello, > > 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. > > Best regards > > Rolf > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] solved: Unifying ctor+Clear() inits into in-class initializers?
On Sun, 19 Nov 2017 15:58:02 +0100, Jan Kratochvil via lldb-dev wrote:
> https://reviews.llvm.org/D40212
...
> Is it OK to just use in-class member variable initializers and:
> void Clear() {
> this->~ClassName();
> new (this) ClassName();
> }
> ?
FYI Greg Clayton in the review above decided this is not good and it will be
better to avoid Clear() completely.
Jan Kratochvil
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] lldb 5.0 debugging a threaded C program on FreeBSD 11.1-RELEASE (x86-64)
Greg, 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: if (stop_id_changed) 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. Best regards Rolf > Am 19.11.2017 um 16:38 schrieb Greg Clayton : > > 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) > > >> On Nov 16, 2017, at 12:18 PM, Dr. Rolf Jansen via lldb-dev >> wrote: >> >> Hello, >> >> 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. >> >> Best regards >> >> Rolf ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
