From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 67984 invoked by alias); 8 Jun 2019 15:45:37 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 65490 invoked by uid 89); 8 Jun 2019 15:45:34 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-9.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.1 spammy=H*F:D*be, Specifically, UD:be, ptid X-HELO: mailsec116.isp.belgacom.be Received: from mailsec116.isp.belgacom.be (HELO mailsec116.isp.belgacom.be) (195.238.20.112) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 08 Jun 2019 15:45:31 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skynet.be; i=@skynet.be; q=dns/txt; s=securemail; t=1560008731; x=1591544731; h=message-id:subject:from:to:date:in-reply-to:references: mime-version:content-transfer-encoding; bh=cg4f/C6E5uQHEyatQeh4729J+YTix42QvSk6re4sDoI=; b=eSl0NADb6ELndu5jQHeRYhmDfYUZVnBDc2Bp2BZzpHOCBVDFY5o5T+FJ iMTQd3Uc/WNja/G2iHohwhzey5pmnw==; Received: from 161.32-242-81.adsl-dyn.isp.belgacom.be (HELO md) ([81.242.32.161]) by relay.skynet.be with ESMTP/TLS/AES256-GCM-SHA384; 08 Jun 2019 17:45:29 +0200 Message-ID: <1560008728.22517.2.camel@skynet.be> Subject: Re: [RFA] Give thread names in thread events, give Ada task names in more output. From: Philippe Waroquiers To: Pedro Alves , gdb-patches@sourceware.org Date: Sat, 08 Jun 2019 15:45:00 -0000 In-Reply-To: <592e4423-0204-607f-3165-60aa0a3b4652@redhat.com> References: <20190518182306.22937-1-philippe.waroquiers@skynet.be> <592e4423-0204-607f-3165-60aa0a3b4652@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-06/txt/msg00168.txt.bz2 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 _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