This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA] Give thread names in thread events, give Ada task names in more output.


On Mon, 2019-06-03 at 14:02 -0600, Tom Tromey wrote:
> > > > > > "Philippe" == Philippe Waroquiers <philippe.waroquiers@skynet.be> writes:
> 
> Philippe> With this patch, we e.g. get:
> Philippe>   [New Thread 0x7ffff701b700 (LWP 13891) "sleepers"]
> Philippe>   [Switching to thread 2 (Thread 0x7ffff781c700 (LWP 13890) "sleepers")]
> Philippe> instead of:
> Philippe>   [New Thread 0x7ffff701b700 (LWP 13918)]
> Philippe>   [Switching to thread 2 (Thread 0x7ffff781c700 (LWP 13917))]
> 
> Thanks.  I'm mildly surprised this works at thread-announce time, since
> I thought the thread had to be created before it could be given a name.
> Maybe it is racy?  (FWIW it is fine if it is.)  Or maybe I'm mistaken
> and there's a way to name a thread before pthread_create.
On linux, the thread gets a default name at creation time.
I think this default name is derived from the executable name for the main thread,
or is equal to the creator thread name (if the new thread is not the main thread).

> 
> Philippe> +/* Return the string to display e.g. in "info threads"'s "Target Id"
> Philippe> +   column, for TP.  */
> Philippe> +
> Philippe> +std::string
> Philippe> +thread_target_id_str (thread_info *tp);
> 
> This should be "extern std::string thread_target_id_str (...);".
> 
> However, could this just be a method on thread_info?  I think that would
> be preferable.  I think it's not much more work.
Yes, that was easy to do.

> 
> Philippe> -			   target_pid_to_str (lp->ptid).c_str ());
> Philippe> +			   thread_target_id_str (th).c_str ());
> 
> Are there spots calling target_pid_to_str that do not want to call the
> new function?
We have different "spot kinds" calling target_pid_to_str.
Some spots have a thread_info*, they get the ptid from this thread_info
to call target_pid_to_str.  These are trivial to convert.

Some spots have just a ptid.  Calling thread_target_id_str implies to
convert the ptid to a thread_info*.  This can return a null ptr, and so
could lead to a problem.
Maybe we could define a new function such as:
    target_pid_to_thr_id_str (ptid)
that tries to convert ptid to a thread_info*.
If it finds one, then it returns thread_target_id_str (th)
otherwise it returns target_pid_to_str (ptid).

This should be a relatively mechanical and not risky change, but we
have about 200 calls to target_pid_to_str in various user messages
and (mostly) debug info.

What do you think ?

Philippe

Note: gdbserver has its own struct thread_info (in gdb/gdbserver/gdbthread.h)
and its own target_pid_to_str (in gdb/gdbserver/target.c).
These target_pid_to_str calls are only for debug info, except one call
in an error message.
This patch does not touch the gdbserver side.




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]