From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 91014 invoked by alias); 4 Jun 2019 21:40:32 -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 90863 invoked by uid 89); 4 Jun 2019 21:40:31 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-10.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.1 spammy=13891, threadannounce, 13890, threadss X-HELO: mailsec119.isp.belgacom.be Received: from mailsec119.isp.belgacom.be (HELO mailsec119.isp.belgacom.be) (195.238.20.115) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 04 Jun 2019 21:40:29 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skynet.be; i=@skynet.be; q=dns/txt; s=securemail; t=1559684429; x=1591220429; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=g3e7ETKq2WY/0U9zlk2Wd56eiE0iaWvE/B4FkDpz1Ok=; b=wDiyJ1k2Sf+bdAVa+AmFIMu9nYMzBeJE/iItbkIytPQbX4gYD/WI7aNw sR2Ki+iT+ld1UMXDmzqR/UweOdWO4Q==; 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; 04 Jun 2019 23:40:25 +0200 Message-ID: <1559684425.1454.52.camel@skynet.be> Subject: Re: [RFA] Give thread names in thread events, give Ada task names in more output. From: Philippe Waroquiers To: Tom Tromey Cc: gdb-patches@sourceware.org Date: Tue, 04 Jun 2019 21:40:00 -0000 In-Reply-To: <87imtml9o6.fsf@tromey.com> References: <20190518182306.22937-1-philippe.waroquiers@skynet.be> <87imtml9o6.fsf@tromey.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-06/txt/msg00073.txt.bz2 On Mon, 2019-06-03 at 14:02 -0600, Tom Tromey wrote: > > > > > > "Philippe" == Philippe Waroquiers 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.