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

[Philippe Waroquiers <philippe dot waroquiers at skynet dot be>]

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