Community
Participate
Working Groups
Starting with GDB 7.3: On GNU/Linux, "info threads" will display the thread name as set by prctl or pthread_setname_np. There is also a new command, "thread name", which can be used to assign a name internally for GDB to display. The new name field is also reported by -thread-info: "name The name of the thread. If the user specified a name using the thread name command, then this name is given. Otherwise, if gdb can extract the thread name from the target, then that name is given. If gdb cannot find the thread name, then this field is omitted."
Proposed fix by Simon Marchi: https://git.eclipse.org/r/#/c/36435/
While testing I noticed a couple of interesting things. 1- if the thread name is not set, GDB will provide a default that is not the same as what we used to show. This means that we will have an impact on programs that don't care about thread names. I will look further into this and probably bring it up to the community. 2- The information about a particular thread is only refreshed when that thread suspends. This means that if one thread sets the name of a running thread, we won't see that new name until the running thread stops. I'm not sure if this is a big deal or not. When stepping over the call to pthread_setname_np(), it feels weird not to see the new name shown, but maybe that is just because I'm debugging this particular issue.
(In reply to Marc Khouzam from comment #2) > While testing I noticed a couple of interesting things. > > 1- if the thread name is not set, GDB will provide a default that is not the > same as what we used to show. This means that we will have an impact on > programs that don't care about thread names. I will look further into this > and probably bring it up to the community. On Linux, when a thread is not given a specific name, the OS gives it the same name as its process. This is what we would now see in CDT. Although this is a change from before, I think that us showing "Thread" was kind of a random choice, and using the name as provided by the OS makes sense. I'll still go to the list as this is a noticeable change.
With or without the patch, on Windows with GDB 7.6.1 it looks like this: Thread [1] 0 (Suspended : Breakpoint) main() at test.cpp:13 0x4016c6 It looks like there's no general way of setting a thread name in win32 APIs. There's only a Visual Studio specific way, see http://msdn.microsoft.com/en-us/library/xcb2z8hs%28VS.90%29.aspx
(In reply to Marc Khouzam from comment #3) > I'll still go to the list as this is a noticeable change. We had a discussion on the list and we decided to slightly change the format of the Thread node in the Debug view to better deal with the thread name. The agreement was to show the following format: MyProcess [1530] [cores: 2,3] Thread #1 [MyProcess] 18787 [core: 3] (Suspended: Container) Thread #2 [MyProcess] 18788 [core: 2] (Running: Container) Thread #3 [Worker] 18789 [core: 3] (Suspended: Container) Thread #4 [Heartbeat] 18797 [core: 3] (Running: Container) The discussion can be seen on the mailing list: https://dev.eclipse.org/mhonarc/lists/cdt-dev/msg28458.html I have posted a patch that changes this format for DSF-GDB: https://git.eclipse.org/r/37276 This patch should be committed first to have the new format, and then we can commit Simon's patch to add the thread name.
(In reply to Marc-Andre Laperle from comment #4) > With or without the patch, on Windows with GDB 7.6.1 it looks like this: > > Thread [1] 0 (Suspended : Breakpoint) > main() at test.cpp:13 0x4016c6 > > It looks like there's no general way of setting a thread name in win32 APIs. > There's only a Visual Studio specific way, see > http://msdn.microsoft.com/en-us/library/xcb2z8hs%28VS.90%29.aspx When you have a moment, can you post the gdb traces for the -thread-info command? I wonder if the 'name' field is not used or if it is there with no name specified.
Created attachment 249075 [details] Windows gdb traces
(In reply to Marc Khouzam from comment #6) > When you have a moment, can you post the gdb traces for the -thread-info > command? I wonder if the 'name' field is not used or if it is there with no > name specified. There is no "name" field on either Windows and Mac as far as I can tell.
(In reply to Marc-Andre Laperle from comment #8) > (In reply to Marc Khouzam from comment #6) > > When you have a moment, can you post the gdb traces for the -thread-info > > command? I wonder if the 'name' field is not used or if it is there with no > > name specified. > > There is no "name" field on either Windows and Mac as far as I can tell. Good. So, what I suggest is that if there is no "name" field, we don't put anything in the Debug view. This will avoid having [unnamed] for every thread on Windows and Mac. On the other hand, threads on Linux seem to always be named, so I don't have a scenario to even use [unnamed]. I've left it out of the patch until we have an actual valid scenario.
I committed this fix through two commits. The first changes the formatting of the Thread node in the debug view: http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=d317c160800ca7eda3e539ec3ea202e5b1caf43a While the second, which is Simon's patch, enables the thread name from GDB: http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=c6865cfb7dfaad4317abc572c3fe73ed5ff8be3a
I updated the N&N: https://wiki.eclipse.org/CDT/User/NewIn86#Display_of_Thread_names
