Community
Participate
Working Groups
Created attachment 139418 [details] CLIInfoThreadsInfo.java.patch Build ID: v200905220803 Steps To Reproduce: 1. Use DSF GDB for non-LWP multi-threaded debugging 2. Observe detailed thread info provided by GDB is not presented in Debug view More information: The pattern matcher in CLIInfoThreadsInfo#parseThreadInfo() will only match "info threads" substrings of the form: <x> Thread <y> (LWP <z>) DSF GDB currently extracts <z> for use as the pid but this is not a general solution. When debugging non-LWP multi-threaded systems, valuable information provided by GDB inside the parentheses is lost. Given thread info of the form: <x> Thread <y> (<text>) the attached patch makes DSF GDB treat "<y> (<text>)" as the pid. A more elegant solution would extract <text> into a separate ThreadInfo member variable. Note that <y> is not always numeric and the "(<text>)" part is optional.
(In reply to comment #0) > 1. Use DSF GDB for non-LWP multi-threaded debugging Can you tell me how to do that? What I tried was to compile without -lpthread. What happened was that 'info thread' did not give any output (note that debugging worked properly). > Given thread info of the form: > > <x> Thread <y> (<text>) Can you post some example of this?
(In reply to comment #1) > > 1. Use DSF GDB for non-LWP multi-threaded debugging > > Can you tell me how to do that? Consider the scenario where DSF GDB is attaching to a remote target which is running a non-POSIX operating system. The GDB server on the remote target will determine the precise format of the "info threads" output. > > Given thread info of the form: > > > > <x> Thread <y> (<text>) > > Can you post some example of this? Here are two examples of "info threads" output containing useful information in the parentheses: http://groups.google.com/group/gnu.gdb.bug/browse_thread/thread/fe0cc7f7092ef090 http://mail.kde.org/pipermail/kdepim-bugs/2007-August/002774.html
I've also noticed this problem with GDB 6.8 using gdbserver on Linux. 926,397 18info threads 926,408 &"info threads\n" 926,408 ~"* 1 Thread 14994 main () at ../testapp.cc:504\n"
(In reply to comment #3) > I've also noticed this problem with GDB 6.8 using gdbserver on Linux. > > 926,397 18info threads > 926,408 &"info threads\n" > 926,408 ~"* 1 Thread 14994 main () at ../testapp.cc:504\n" Yes. The thread information in parentheses is optional. My patch accommodates the above case.
I'll sign up for this one. I looked at the patch and I think it needs to be a little more flexible. But it was a pretty fast look and I could have misread it. Anyway, I'll find out when I test it. Randy
Created attachment 160240 [details] better parsing of the command line information This is a melding of the patch supplied by the submitter and the original. Basically I changed it to try the first original algorithm, based on the assumption that the LWP number was originally important. If it fails to find that then it defaults to the parsing algorithm supplied by the submitter. It also is a little more forgiving with respect to the case of the informatio returned. Randy
Pawel I checked in the attached patch to HEAD. Please take a look at it. Randy
Looks fine to me. I only extracted the Patterns into static variables so they don't have to be created every time.
(In reply to comment #8) > Looks fine to me. I only extracted the Patterns into static variables so they > don't have to be created every time. Pawel, looks like your tweak rendered the fix a non-fix :-) A simple copy-n-paste bug. You never use 'RESULT_PATTERN' (instead you accidentally use the LWP variant twice). I'm in the code now, fixing the case for cygwin/mingw, which uses yet another format. Oh joy. So, I'll take care of this, too.
(In reply to comment #9) > Pawel, looks like your tweak rendered the fix a non-fix :-) A simple > copy-n-paste bug. You never use 'RESULT_PATTERN' (instead you accidentally use > the LWP variant twice). wow that's bad... thanks for catching it
Created attachment 160872 [details] Fix accidental regression in last commit. Also, enhanced documentation
Note also bug 280631. Without the patch in 280631, new non-LWP threads may never be seen in the Debug view.
