From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18227 invoked by alias); 23 Sep 2013 16:33:00 -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 18204 invoked by uid 89); 23 Sep 2013 16:32:59 -0000 Received: from mail-ve0-f170.google.com (HELO mail-ve0-f170.google.com) (209.85.128.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 23 Sep 2013 16:32:59 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,NO_RELAYS autolearn=no version=3.3.2 X-HELO: mail-ve0-f170.google.com Received: by mail-ve0-f170.google.com with SMTP id c14so2578635vea.29 for ; Mon, 23 Sep 2013 09:32:56 -0700 (PDT) X-Received: by 10.58.75.18 with SMTP id y18mr507038vev.33.1379953976607; Mon, 23 Sep 2013 09:32:56 -0700 (PDT) MIME-Version: 1.0 Reply-To: pat.pannuto@gmail.com Received: by 10.58.144.101 with HTTP; Mon, 23 Sep 2013 09:32:36 -0700 (PDT) In-Reply-To: <0377C58828D86C4588AEEC42FC3B85A717680F5D@IRSMSX105.ger.corp.intel.com> References: <0377C58828D86C4588AEEC42FC3B85A717680F5D@IRSMSX105.ger.corp.intel.com> From: Pat Pannuto Date: Mon, 23 Sep 2013 16:33:00 -0000 Message-ID: Subject: Re: [PATCH] Print thread name when executing thread commands To: "Agovic, Sanimir" Cc: "gdb-patches@sourceware.org" Content-Type: text/plain; charset=ISO-8859-1 X-SW-Source: 2013-09/txt/msg00824.txt.bz2 On Mon, Sep 23, 2013 at 8:18 AM, Agovic, Sanimir wrote: > Hello Pat, > > please have a look at https://sourceware.org/ml/gdb-patches/2013-09/msg00485.html Your patch looks superior to mine. Covers more cases I'd missed and has test cases. I'll happily drop this if the other patch is merged. It looks like it's been sitting for a while (Mohsan's original patch went to bugzilla on 2012-09-25..), is there something standing in the way of the other patch going through? I can try to champion that one if it's necessary. > > A question below. > > -Sanimir > >> -----Original Message----- >> From: gdb-patches-owner@sourceware.org [mailto:gdb-patches-owner@sourceware.org] On Behalf >> Of Pat Pannuto >> Sent: Wednesday, September 18, 2013 08:37 PM >> To: Ricard Wanderlof >> Cc: gdb-patches@sourceware.org >> Subject: Re: [PATCH] Print thread name when executing thread commands >> >> $ cat print_thread_names.diff >> Index: gdb/thread.c >> =================================================================== >> RCS file: /cvs/src/src/gdb/thread.c,v >> retrieving revision 1.157 >> diff -u -p -r1.157 thread.c >> --- gdb/thread.c 17 Sep 2013 18:26:39 -0000 1.157 >> +++ gdb/thread.c 18 Sep 2013 18:31:15 -0000 >> @@ -1255,10 +1255,14 @@ thread_apply_all_command (char *cmd, int >> for (k = 0; k != i; k++) >> if (thread_alive (tp_array[k])) >> { >> + char *name; >> switch_to_thread (tp_array[k]->ptid); >> - printf_filtered (_("\nThread %d (%s):\n"), >> + name = tp_array[k]->name ? tp_array[k]->name >> + : target_thread_name (tp_array[k]); >> > What happens if a thread changes its name during execution, do we get the > cached or the actual thread name? It looks to me as we should never directly > access the thread_info::name member, or? I honestly don't know. I would expect it would mirror the behavior of `info threads` as the code is essentially duplicated. > > Btw, a testcase would be great. > > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen, Deutschland > Sitz der Gesellschaft: Feldkirchen bei Muenchen > Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk > Registergericht: Muenchen HRB 47456 > Ust.-IdNr./VAT Registration No.: DE129385895 > Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 > -- Pat Pannuto NSF/NDSEG/Qualcomm Fellow Computer Engineering University of Michigan 248.990.4548