Hello,
I am debugging a program with a large number of threads. I would like to give them human-readable names from within the running program. This is possible when using the visual studio debugger (here or search "how to set a thread name in native code") I was wondering if there is a better and/or Remedy-supported way to do this.
Alternatively, is there a way to access the FS segment register? This would be sufficient, though less convenient, since it would allow access to thread-locals in the watch window.
Thanks
I am debugging a program with a large number of threads. I would like to give them human-readable names from within the running program. This is possible when using the visual studio debugger (here or search "how to set a thread name in native code") I was wondering if there is a better and/or Remedy-supported way to do this.
Alternatively, is there a way to access the FS segment register? This would be sufficient, though less convenient, since it would allow access to thread-locals in the watch window.
Thanks
Edited by cphinton
on
Reason: Initial post
Cannot tell you anything about what Remedy supports.
But if you are on Windows 10, you can set thread name much easier - with SetThreadDescription function: https://docs.microsoft.com/en-us/...ssthreadsapi-setthreaddescription
It is also better in one aspect - thread name "sticks" around. In old "raise exception" way the name is set only if debugger is already running when RaiseException is called (so debugger can catch it and remember name), but SetThreadDescription function will provide name for debugger even if debugger attaches way later after call to SetThreadDescription.
But if you are on Windows 10, you can set thread name much easier - with SetThreadDescription function: https://docs.microsoft.com/en-us/...ssthreadsapi-setthreaddescription
It is also better in one aspect - thread name "sticks" around. In old "raise exception" way the name is set only if debugger is already running when RaiseException is called (so debugger can catch it and remember name), but SetThreadDescription function will provide name for debugger even if debugger attaches way later after call to SetThreadDescription.
Edited by Mārtiņš Možeiko
on
Thanks, that looks much nicer. Though having tested it, it is supported by a modern version of VS, but not older versions or Remedy.
I suppose that turns this thread into a feature request:
1. Support SetThreadDescription
2. Provide access to the TIB in the watch window (having looked it up again, it looks like it is the FS in 32-bit Windows, GS in 64-bit)
I suppose that turns this thread into a feature request:
1. Support SetThreadDescription
2. Provide access to the TIB in the watch window (having looked it up again, it looks like it is the FS in 32-bit Windows, GS in 64-bit)
Seems that improving getting thread names is a known issue:
https://github.com/x13pixels/remedybg-issues/issues/114
https://github.com/x13pixels/remedybg-issues/issues/114
Edited by Mārtiņš Možeiko
on
+1 on the thread name request.
I'm also doing a lot of multi-threaded code, and not seing the thread names is a problem.
Our code base uses the old RaiseException/THREADNAME_INFO method for compatibility reasons, would be nice if that was supported by RemedyBG.
In addition, it could be useful to be able to rename (F2?) the threads in the list, like when for example debugging a program that does not have any such information, to help finding the needles in the haystack :)
