[RFA] Give thread names in thread events, give Ada task names in more output.
Commit Message
With this patch, we e.g. get:
[New Thread 0x7ffff701b700 (LWP 13891) "sleepers"]
[Switching to thread 2 (Thread 0x7ffff781c700 (LWP 13890) "sleepers")]
instead of:
[New Thread 0x7ffff701b700 (LWP 13918)]
[Switching to thread 2 (Thread 0x7ffff781c700 (LWP 13917))]
For Ada tasks, we e.g. get:
[Switching to task 2 task_list(1)]
[Current task is 2 task_list(1)]
instead of
[Switching to task 2]
[Current task is 2]
---
gdb/ChangeLog | 15 +++++++++++++++
gdb/NEWS | 4 ++++
gdb/ada-tasks.c | 18 ++++++++++++++++--
gdb/doc/ChangeLog | 5 +++++
gdb/doc/gdb.texinfo | 10 +++++-----
gdb/fbsd-nat.c | 2 +-
gdb/gdbthread.h | 6 ++++++
gdb/infrun.c | 2 +-
gdb/linux-nat.c | 2 +-
gdb/procfs.c | 16 ++++++++++++----
gdb/testsuite/ChangeLog | 8 ++++++++
gdb/testsuite/gdb.ada/rdv_wait.exp | 2 +-
gdb/testsuite/gdb.ada/task_switch_in_core.exp | 2 +-
.../multiple-successive-infcall.exp | 2 +-
gdb/thread.c | 13 ++++++-------
15 files changed, 83 insertions(+), 24 deletions(-)
Comments
> From: Philippe Waroquiers <philippe.waroquiers@skynet.be>
> Cc: Philippe Waroquiers <philippe.waroquiers@skynet.be>
> Date: Sat, 18 May 2019 20:23:06 +0200
>
> With this patch, we e.g. get:
> [New Thread 0x7ffff701b700 (LWP 13891) "sleepers"]
> [Switching to thread 2 (Thread 0x7ffff781c700 (LWP 13890) "sleepers")]
> instead of:
> [New Thread 0x7ffff701b700 (LWP 13918)]
> [Switching to thread 2 (Thread 0x7ffff781c700 (LWP 13917))]
>
> For Ada tasks, we e.g. get:
> [Switching to task 2 task_list(1)]
> [Current task is 2 task_list(1)]
> instead of
> [Switching to task 2]
> [Current task is 2]
Except for Ada, the names are only available on some platforms, right?
Should we mention that in the manual?
The documentation parts are OK, apart of that nit.
Thanks.
>>>>> "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.
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.
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?
thanks,
Tom
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.
On 5/18/19 7:23 PM, Philippe Waroquiers wrote:
> With this patch, we e.g. get:
> [New Thread 0x7ffff701b700 (LWP 13891) "sleepers"]
> [Switching to thread 2 (Thread 0x7ffff781c700 (LWP 13890) "sleepers")]
> instead of:
> [New Thread 0x7ffff701b700 (LWP 13918)]
> [Switching to thread 2 (Thread 0x7ffff781c700 (LWP 13917))]
>
> For Ada tasks, we e.g. get:
> [Switching to task 2 task_list(1)]
> [Current task is 2 task_list(1)]
> instead of
> [Switching to task 2]
> [Current task is 2]
BTW, if you're looking at improving this, take a look what I was
proposing here:
https://sourceware.org/ml/gdb-patches/2019-04/msg00448.html
(gdb) r
Starting program: build/gdb/testsuite/outputs/gdb.threads/schedlock/schedlock
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[Thread 1.2 (0x7ffff74b8700 (LWP 13984) "sleepers") appeared]
[Thread 1.2 (0x7ffff74b8700 (LWP 13984) "sleepers") exited]
[Inferior 1 (process 13980) exited normally]
(gdb)
Specifically, I think it'd be quite useful to show the thread's
gdb number. I'd say that is more useful than the thread name, even,
because you can use "info threads" to find the name from the unique
gdb id, but converse isn't so easy.
> @@ -986,10 +986,9 @@ should_print_thread (const char *requested_threads, int default_inf_num,
> return 1;
> }
>
> -/* Return the string to display in "info threads"'s "Target Id"
> - column, for TP. */
> +/* See gdbthread.h. */
>
> -static std::string
> +std::string
> thread_target_id_str (thread_info *tp)
> {
The commit's description talks about thread names, but
note that thread_target_id_str prints more than the name -- it also
prints the thread's extra info.
Thanks,
Pedro Alves
>>>>> "Philippe" == Philippe Waroquiers <philippe.waroquiers@skynet.be> writes:
>> Are there spots calling target_pid_to_str that do not want to call the
>> new function?
Philippe> We have different "spot kinds" calling target_pid_to_str.
Philippe> Some spots have a thread_info*, they get the ptid from this thread_info
Philippe> to call target_pid_to_str. These are trivial to convert.
Philippe> Some spots have just a ptid. Calling thread_target_id_str implies to
Philippe> convert the ptid to a thread_info*. This can return a null ptr, and so
Philippe> could lead to a problem.
Philippe> Maybe we could define a new function such as:
Philippe> target_pid_to_thr_id_str (ptid)
Philippe> that tries to convert ptid to a thread_info*.
Philippe> If it finds one, then it returns thread_target_id_str (th)
Philippe> otherwise it returns target_pid_to_str (ptid).
Philippe> This should be a relatively mechanical and not risky change, but we
Philippe> have about 200 calls to target_pid_to_str in various user messages
Philippe> and (mostly) debug info.
Philippe> What do you think ?
I think when I wrote that line, I hadn't yet appreciated that the patch
was just exposing a previously private function. So, while it may still
make sense to switch other calls to use it, I don't think it is a
requirement for this patch.
Tom
On Wed, 2019-06-05 at 10:02 +0100, Pedro Alves wrote:
> On 5/18/19 7:23 PM, Philippe Waroquiers wrote:
> > With this patch, we e.g. get:
> > [New Thread 0x7ffff701b700 (LWP 13891) "sleepers"]
> > [Switching to thread 2 (Thread 0x7ffff781c700 (LWP 13890) "sleepers")]
> > instead of:
> > [New Thread 0x7ffff701b700 (LWP 13918)]
> > [Switching to thread 2 (Thread 0x7ffff781c700 (LWP 13917))]
> >
> > For Ada tasks, we e.g. get:
> > [Switching to task 2 task_list(1)]
> > [Current task is 2 task_list(1)]
> > instead of
> > [Switching to task 2]
> > [Current task is 2]
>
> BTW, if you're looking at improving this, take a look what I was
> proposing here:
>
> https://sourceware.org/ml/gdb-patches/2019-04/msg00448.html
>
> (gdb) r
> Starting program: build/gdb/testsuite/outputs/gdb.threads/schedlock/schedlock
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
> [Thread 1.2 (0x7ffff74b8700 (LWP 13984) "sleepers") appeared]
> [Thread 1.2 (0x7ffff74b8700 (LWP 13984) "sleepers") exited]
> [Inferior 1 (process 13980) exited normally]
> (gdb)
>
> Specifically, I think it'd be quite useful to show the thread's
> gdb number. I'd say that is more useful than the thread name, even,
> because you can use "info threads" to find the name from the unique
> gdb id, but converse isn't so easy.
>
> > @@ -986,10 +986,9 @@ should_print_thread (const char *requested_threads, int default_inf_num,
> > return 1;
> > }
> >
> > -/* Return the string to display in "info threads"'s "Target Id"
> > - column, for TP. */
> > +/* See gdbthread.h. */
> >
> > -static std::string
> > +std::string
> > thread_target_id_str (thread_info *tp)
> > {
>
> The commit's description talks about thread names, but
> note that thread_target_id_str prints more than the name -- it also
> prints the thread's extra info.
Pedro and Tom,
Thanks for the feedback and suggestions.
I will see how to go on with this.
Maybe the best is to do this in 3 different patches:
* a patch adding the Ada task name where relevant
* a patch adding in the thread events the thread name
and the other things suggested by Pedro
* a third patch that replaces (where relevant) target_pid_to_str
by something like target_pid_to_thr_id_str
Philippe
On Wed, 2019-06-05 at 10:02 +0100, Pedro Alves wrote:
> (gdb) r
> Starting program: build/gdb/testsuite/outputs/gdb.threads/schedlock/schedlock
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
> [Thread 1.2 (0x7ffff74b8700 (LWP 13984) "sleepers") appeared]
> [Thread 1.2 (0x7ffff74b8700 (LWP 13984) "sleepers") exited]
> [Inferior 1 (process 13980) exited normally]
> (gdb)
>
> Specifically, I think it'd be quite useful to show the thread's
> gdb number. I'd say that is more useful than the thread name, even,
> because you can use "info threads" to find the name from the unique
> gdb id, but converse isn't so easy.
I am wondering what is the best way to implement this.
Currently, thread_target_id_str calls the target pid_to_str
and some other target functions, and builds the result.
On linux, for a thread, pid_to_str returns
Thread 0x7ffff7fcf700 (LWP 31607)
It is not very clear what is the best way to add the GDB qualified
thread id in this message.
First, the target pid_to_str cannot unconditionally add the qualified
thread id, otherwise 'info threads' would show it in double, such as:
(gdb) info thread
Id Target Id Frame
1.1 Thread 1.1 0x7ffff7fcf700 (LWP 4725) "sleepers" 0x00007ffff78fe603 in select () at ../sysdeps/unix/syscall-template.S:84
...
Also, target pid_to_str does not always return a message starting
with "Thread ...". When there is only the main thread, it returns rather something like:
(gdb) info threads
Id Target Id Frame
* 1 process 4816 "trivialleak" main () at trivialleak.c:12
Also, it looks somewhat ugly to have target <something>_to_str returning a string
which contains GDB specific numbering.
I started by adding a 'bool show_id' in the target pid_to_str, where SHOW_ID indicates
to add the 'GDB id' after Thread. This means (of course) to change all targets.
And it is not very clear what to do with SHOW_ID when rather the Target Id is
a process : should we show the inferior NUM ? Even when there is only one inferior ?
That does not look very nice.
Another idea could be to add a 'bool Title' to target pid_to_str,
where TITLE indicates to put or not the 'title'. Title being either
'Thread ' or 'process '.
Then the caller of pid_to_str can itself add the relevant title followed by the
GDB id followed by the target pid_to_str result.
This however implies to have a way to decide which kind of title should be added.
Moreover, some target are creative in the way they implement pid_to_str.
For example, bsd-uthread.c uses "process %d, thread 0x%lx" for a thread pid_to_str,
darwin uses "Thread 0x%lx of process %u"
fbsd-nat.c uses "LWP %d of process %d"
linux-nat.c uses "LWP %ld" while linux-thread-db.c uses "Thread 0x%lx (LWP %ld)"
sol-thread.c differentiates a process, a thread and a LWP.
....
Also, different methods are used by the targets to see if a ptid is a 'process'
or a 'thread' ptid (or event an 'LWP' ptid, in the case of solaris).
Maybe we can have another function thread_info::thread_info_to_str
that insert some postfix identification, such as:
[Thread 0x7ffff7518700 (LWP 7194) "break-while-run" appeared. Id 2.1]
and call it in the various thread event messages, and keep thread_id_to_str unchanged ?
So, not clear what to do.
Philippe
While I was testing all the above, I encountered 2 bugs that can be reproduced
by doing
cd /path/to/a/gdb/build/directory
gdb
source x.gdb
where x.gdb is:
# set trace-command on
set height unlimited
# set debug libthread-db 1
file gdb/testsuite/outputs/gdb.threads/break-while-running/break-while-running
shell ps
# if you insert this break, then you will not be able to run
# the inferior 2, as it can never insert the breakpoint.
# It fails with :
# Cannot insert breakpoint 1.
# Cannot access memory at address 0xa96
# while the breakpoint in inferior 1 is at address 0x0000555555554a96
########## break break-while-running.c:95
echo **************** \n
echo As breakpoint insert fails, type C-c for inferior 1 in a second or so ...\n
echo **************** \n
run
# list threads (we only have inferior 1)
info threads
add-inferior
inferior 2
file gdb/testsuite/outputs/gdb.threads/break-while-running/break-while-running
# the below info thread is what causes the libthread db to not be seen by GDB.
# list threads (we have inferior 1, and a not running inferior 2)
info threads
echo **************** \n
echo As breakpoint insert fails, type C-c for inferior 2 in a second or so ...\n
echo **************** \n
# And so the below runs inferior 1 with linux-nat target, not with
# linux-thread-db target
run
# and so the below info threads shows one inferior with
# Thread 0x .... (LWP ...)
# and the other with
# LWP ... (once threads are present)
info threads
@@ -6965,3 +6965,18 @@ version-control: never
coding: utf-8
End:
+2019-05-18 Philippe Waroquiers <philippe.waroquiers@skynet.be>
+
+ * gdbthread.h (thread_target_id_str): Declare.
+ * thread.c (thread_target_id_str): Make non static.
+ (add_thread_with_info): Use thread_target_id_str instead of
+ target_pid_to_str.
+ (thr_try_catch_cmd): Likewise.
+ * procfs.c (procfs_target::wait): Likewise.
+ * linux-nat.c (exit_lwp): Likewise.
+ * infrun.c (normal_stop): Likewise.
+ * fbsd-nat.c (fbsd_nat_target::wait): Likewise.
+ * gdb/ada-tasks.c (display_current_task_id): Print task name.
+ (task_command_1): Likewise.
+ * NEWS: Announce that thread and task names are now shown at
+ more places.
@@ -19,6 +19,10 @@
* Two new convernience functions $_cimag and $_creal that extract the
imaginary and real parts respectively from complex numbers.
+* GDB now shows thread names at more places, e.g. in messages announcing
+ the new threads. GDB also shows the Ada task names at more places,
+ e.g. in task switching messages.
+
* Python API
** The gdb.Value type has a new method 'format_string' which returns a
@@ -1255,7 +1255,17 @@ display_current_task_id (void)
if (current_task == 0)
printf_filtered (_("[Current task is unknown]\n"));
else
- printf_filtered (_("[Current task is %d]\n"), current_task);
+ {
+ struct ada_tasks_inferior_data *data
+ = get_ada_tasks_inferior_data (current_inferior ());
+ struct ada_task_info *task_info = &data->task_list[current_task - 1];
+
+ if (task_info->name[0] == '\0')
+ printf_filtered (_("[Current task is %d]\n"), current_task);
+ else
+ printf_filtered (_("[Current task is %d %s]\n"),
+ current_task, task_info->name);
+ }
}
/* Parse and evaluate TIDSTR into a task id, and try to switch to
@@ -1301,7 +1311,11 @@ task_command_1 (const char *taskno_str, int from_tty, struct inferior *inf)
switch_to_thread (tp);
ada_find_printable_frame (get_selected_frame (NULL));
- printf_filtered (_("[Switching to task %d]\n"), taskno);
+ if (task_info->name[0] == '\0')
+ printf_filtered (_("[Switching to task %d]\n"), taskno);
+ else
+ printf_filtered (_("[Switching to task %d %s]\n"),
+ taskno, task_info->name);
print_stack_frame (get_selected_frame (NULL),
frame_relative_level (get_selected_frame (NULL)),
SRC_AND_LOC, 1);
@@ -12855,3 +12855,8 @@ fill-column: 74
version-control: never
coding: utf-8
End:
+
+2019-05-18 Philippe Waroquiers <philippe.waroquiers@skynet.be>
+
+ * gdb.texinfo (Ada Tasks): Tell the task name is printed, update
+ examples.
@@ -17250,7 +17250,7 @@ State: Runnable
@item task
@kindex task@r{ (Ada)}
@cindex current Ada task ID
-This command prints the ID of the current task.
+This command prints the ID and name of the current task.
@smallexample
@iftex
@@ -17259,9 +17259,9 @@ This command prints the ID of the current task.
(@value{GDBP}) info tasks
ID TID P-ID Pri State Name
1 8077870 0 15 Child Activation Wait main_task
-* 2 807c458 1 15 Runnable t
+* 2 807c458 1 15 Runnable some_task
(@value{GDBP}) task
-[Current task is 2]
+[Current task is 2 some_task]
@end smallexample
@item task @var{taskno}
@@ -17277,9 +17277,9 @@ from the current task to the given task.
(@value{GDBP}) info tasks
ID TID P-ID Pri State Name
1 8077870 0 15 Child Activation Wait main_task
-* 2 807c458 1 15 Runnable t
+* 2 807c458 1 15 Runnable some_task
(@value{GDBP}) task 1
-[Switching to task 1]
+[Switching to task 1 some_task]
#0 0x8067726 in pthread_cond_wait ()
(@value{GDBP}) bt
#0 0x8067726 in pthread_cond_wait ()
@@ -1348,7 +1348,7 @@ fbsd_nat_target::wait (ptid_t ptid, struct target_waitstatus *ourstatus,
pl.pl_lwpid);
if (print_thread_events)
printf_unfiltered (_("[%s exited]\n"),
- target_pid_to_str (wptid).c_str ());
+ thread_target_id_str (thr).c_str ());
delete_thread (thr);
}
if (ptrace (PT_CONTINUE, pid, (caddr_t) 1, 0) == -1)
@@ -763,4 +763,10 @@ extern void print_selected_thread_frame (struct ui_out *uiout,
alive anymore. */
extern void thread_select (const char *tidstr, class thread_info *thr);
+/* Return the string to display e.g. in "info threads"'s "Target Id"
+ column, for TP. */
+
+std::string
+thread_target_id_str (thread_info *tp);
+
#endif /* GDBTHREAD_H */
@@ -7989,7 +7989,7 @@ normal_stop (void)
{
target_terminal::ours_for_output ();
printf_filtered (_("[Switching to %s]\n"),
- target_pid_to_str (inferior_ptid).c_str ());
+ thread_target_id_str (inferior_thread ()).c_str ());
annotate_thread_changed ();
}
previous_inferior_ptid = inferior_ptid;
@@ -1014,7 +1014,7 @@ exit_lwp (struct lwp_info *lp)
{
if (print_thread_events)
printf_unfiltered (_("[%s exited]\n"),
- target_pid_to_str (lp->ptid).c_str ());
+ thread_target_id_str (th).c_str ());
delete_thread (th);
}
@@ -2284,8 +2284,12 @@ wait_again:
if (syscall_is_lwp_exit (pi, what))
{
if (print_thread_events)
- printf_unfiltered (_("[%s exited]\n"),
- target_pid_to_str (retval).c_str ());
+ {
+ thread_info *thr = find_thread_ptid (retval);
+
+ printf_unfiltered (_("[%s exited]\n"),
+ thread_target_id_str (thr).c_str ());
+ }
delete_thread (find_thread_ptid (retval));
status->kind = TARGET_WAITKIND_SPURIOUS;
return retval;
@@ -2405,8 +2409,12 @@ wait_again:
else if (syscall_is_lwp_exit (pi, what))
{
if (print_thread_events)
- printf_unfiltered (_("[%s exited]\n"),
- target_pid_to_str (retval).c_str ());
+ {
+ thread_info *thr = find_thread_ptid (retval);
+
+ printf_unfiltered (_("[%s exited]\n"),
+ thread_target_id_str (thr).c_str ());
+ }
delete_thread (find_thread_ptid (retval));
status->kind = TARGET_WAITKIND_SPURIOUS;
return retval;
@@ -16053,3 +16053,11 @@ For older changes see ChangeLog-1993-2013.
Copyright 2014-2019 Free Software Foundation, Inc.
Copying and distribution of this file, with or without modification,
are permitted provided the copyright notice and this notice are preserved.
+
+2019-05-18 Philippe Waroquiers <philippe.waroquiers@skynet.be>
+
+ * gdb./threads/multiple-successive-infcall.exp: Update to match
+ thread name.
+ * gdb.ada/rdv_wait.exp: Update to match task name.
+ gdb.ada/task_switch_in_core.exp: Likewise.
+
@@ -31,5 +31,5 @@ runto "break_me"
# Switch to task 2, and verify that GDB is able to unwind all the way
# to foo.T.
gdb_test "task 2" \
- [join {"\\\[Switching to task 2\\\].*" \
+ [join {"\\\[Switching to task 2 mit\\\].*" \
".*foo\\.t \\(.*\\).*foo\\.adb:.*"} ""]
@@ -71,7 +71,7 @@ gdb_test "info tasks" \
# we will verify right after with an additional test that the current
# task is now task 2.
gdb_test "task 2" \
- "\\\[Switching to task 2\\\].*"
+ "\\\[Switching to task 2 my_t\\\].*"
gdb_test "info tasks" \
[multi_line "\\s+ID\\s+TID\\s+P-ID\\s+Pri\\s+State\\s+Name" \
@@ -42,7 +42,7 @@ gdb_continue_to_breakpoint "prethreadcreationmarker"
set after_new_thread_message "created new thread"
foreach_with_prefix thread {5 4 3} {
gdb_test_multiple "continue" "${after_new_thread_message}" {
- -re "\\\[New Thread ${hex} \\\(LWP \[0-9\]+\\\)\\\].*${gdb_prompt}" {
+ -re "\\\[New Thread ${hex} \\\(LWP \[0-9\]+\\\).*\\\].*${gdb_prompt}" {
pass "${after_new_thread_message}"
}
}
@@ -319,7 +319,7 @@ add_thread_with_info (ptid_t ptid, private_thread_info *priv)
result->priv.reset (priv);
if (print_thread_events)
- printf_unfiltered (_("[New %s]\n"), target_pid_to_str (ptid).c_str ());
+ printf_unfiltered (_("[New %s]\n"), thread_target_id_str (result).c_str ());
annotate_new_thread ();
return result;
@@ -986,10 +986,9 @@ should_print_thread (const char *requested_threads, int default_inf_num,
return 1;
}
-/* Return the string to display in "info threads"'s "Target Id"
- column, for TP. */
+/* See gdbthread.h. */
-static std::string
+std::string
thread_target_id_str (thread_info *tp)
{
std::string target_id = target_pid_to_str (tp->ptid);
@@ -1469,7 +1468,7 @@ thr_try_catch_cmd (thread_info *thr, const char *cmd, int from_tty,
if (!flags.quiet)
printf_filtered (_("\nThread %s (%s):\n"),
print_thread_id (thr),
- target_pid_to_str (inferior_ptid).c_str ());
+ thread_target_id_str (thr).c_str ());
printf_filtered ("%s", cmd_result.c_str ());
}
}
@@ -1480,7 +1479,7 @@ thr_try_catch_cmd (thread_info *thr, const char *cmd, int from_tty,
if (!flags.quiet)
printf_filtered (_("\nThread %s (%s):\n"),
print_thread_id (thr),
- target_pid_to_str (inferior_ptid).c_str ());
+ thread_target_id_str (thr).c_str ());
if (flags.cont)
printf_filtered ("%s\n", ex.what ());
else
@@ -1826,7 +1825,7 @@ print_selected_thread_frame (struct ui_out *uiout,
uiout->text ("[Switching to thread ");
uiout->field_string ("new-thread-id", print_thread_id (tp));
uiout->text (" (");
- uiout->text (target_pid_to_str (inferior_ptid).c_str ());
+ uiout->text (thread_target_id_str (tp).c_str ());
uiout->text (")]");
}
}