[RFA] Give thread names in thread events, give Ada task names in more output.
Philippe Waroquiers
philippe.waroquiers@skynet.be
Sat Jun 8 15:45:00 GMT 2019
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
More information about the Gdb-patches
mailing list