On Wed, 2012-11-07 at 16:54 +0100, Matthias Schwarzott wrote: Printing thread names is not a bad idea (not too sure that a lot of applications are using pthread_setname or prctl but never mind).
In any case, I see several subtilities to look at. > Using plain gdb, info threads also lists these user-defined names. > But valgrind and gdb+vgdb only show the thread-ids. I tried with plain gdb 7.5 on fedora 12 (kernel 2.6.32.26-175.fc12.i686.PAE). The prctl get/set name syscalls are working, but I could not persuade (gdb) info threads or ps command to show these names. With which versions have you succeeded to have info threads showing the thread names ? > The only place in valgrind that already handles thread names is a > helgrind client request. Which is unimplemented in helgrind, but implemented by drd. There will be a need to decide which one(s) to show if both prctl and the DRD client request were used to give a name to a thread. > > > I think it would be a good idea if valgrind could also show the thread name. > My first attempt is to add more code to POST(sys_prctl) and in case of > VKI_PR_SET_NAME is called, store the set name into a new field of > ThreadState. > Then in every user visible place where a threadid is printed, also print > the name. > How could this look like? I think that in some cases, an error can reference a terminated thread (e.g. for helgrind or drd errors). For such a case, you cannot recuperate the thread name in the ThreadState as this ThreadState could have been emptied or re-used by another thread. I think that helgrind maintains a unique thread data structure (even for terminated thread). So, you will have to copy the thread name to this unique helgrind data structure. (in other words, it looks like printing the thread name cannot be done "centrally" in coregrind error mgr, at least e.g. for helgrind). Maybe/probably drd does a similar thing. > The other option would be to call prctl(PR_GET_NAME) at every place that > needs a thread name. This would not work when a thread prints an error which references another thread. Otherwise, if you can retrieve somewhere the name of a non terminated thread (i.e. the "ThreadState solution"), then it is straightforward to have Valgrind gdbsrv giving back this info to GDB. See handling of packet "qThreadExtraInfo," in file server.c. Philippe ------------------------------------------------------------------------------ LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
