From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2233 invoked by alias); 24 Feb 2009 18:12:13 -0000 Received: (qmail 2004 invoked by uid 22791); 24 Feb 2009 18:12:11 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.45.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 24 Feb 2009 18:12:07 +0000 Received: from zps36.corp.google.com (zps36.corp.google.com [172.25.146.36]) by smtp-out.google.com with ESMTP id n1OIC4uN023766 for ; Tue, 24 Feb 2009 10:12:04 -0800 Received: from rv-out-0708.google.com (rvbf25.prod.google.com [10.140.82.25]) by zps36.corp.google.com with ESMTP id n1OIC3Ux027641 for ; Tue, 24 Feb 2009 10:12:03 -0800 Received: by rv-out-0708.google.com with SMTP id f25so2325450rvb.22 for ; Tue, 24 Feb 2009 10:12:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.19.16 with SMTP id w16mr2722772rvi.66.1235499123406; Tue, 24 Feb 2009 10:12:03 -0800 (PST) Date: Tue, 24 Feb 2009 18:12:00 -0000 Message-ID: Subject: More descriptive prompt [was Re: Process exit in multi-process, and gdb's selected thread.] From: Doug Evans To: Pedro Alves Cc: Marc Khouzam , gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-System-Of-Record: true X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-02/txt/msg00151.txt.bz2 [- gdb-patches] [+ gdb] On Tue, Feb 17, 2009 at 10:15 AM, Pedro Alves wrote: > On Tuesday 17 February 2009 17:08:04, Marc Khouzam wrote: > >> At first glance, things look very good. I was able to detach from >> all processes and re-attach. When detached from all processes, I ran >> the 'info threads' commands and the result was empty, so I know there >> was not thread selected. But I did not get any errors and was able >> to attach/detach, multiple times. >> > > That's very good to know, thanks! > >> The only thing that gave me trouble was that auto-attach was triggered >> from my Stub but I don't think HEAD deals with it perfectly, so I got >> "No registers" when running -list-thread-groups after an auto-attach. > > Yep, that's expected with HEAD. > >> Bottom line is that this patch is very promising. >> Good stuff! >> > > Great! Coming into this a bit late ... cut-n-pasted this back in for some more context: > (gdb) info threads > 2 Thread 31176.31176 0x00007f0706154796 in ?? () > > No selected thread. See `help thread'. > (gdb) info inferiors > 3 31176 > (gdb) c > Continuing. > Cannot execute this command without a live selected thread. > (gdb) detach > The program is not being run. > (gdb) kill > The program is not being run. > (gdb) This is sort of tangential to the thread, but it's been on my mind. I was wondering, can we make the prompt in command-line mode a bit more descriptive? Graphical frontends can solve these things their own way, but for command line mode if there were in fact no selected proc ess or thread, AND I could trivially recognize that from the prompt, it'd reduce the confusion substantially. It might be useful to include the currently selected thread in the prompt. In a system with named threads (a bit of python scripting would help), turning a "42" thread number into "watchdog-thread" or some such would be helpful for some developers I think. Without putting a lot of thought into it, maybe something like (thread 42) info threads [...] (thread 42) or (watchdog-thread) p *this [...] (watchdog-thread) or (no process) echo Hey dude, where's my process?\n Hey dude, where's my process? (no process) In a simulator target in a past life it was very useful to have the current instruction count in the prompt. [Actually it printed two counts, the transmeta vliw insn count, and the x86 insn count.] I realize MANY programs look for "(gdb)" (or "(gdb) "). I'm not suggesting breaking that. In a past life I think(!) we just put the extra text before the "(gdb)". E.g., maybe something like (thread 42)(gdb) or (no process)(gdb) or some such. That might work in some situations. For situations where it wouldn't work one would just use the old boring, static prompt :-). For interactive users we have a lot more freedom to provide something more useful than just "(gdb) ". Anyways, can we 1) Provide a way to change the default prompt to be more descriptive without needing any scripting hacks. Maybe something like "set prompt (thread %t)(gdb) " -> "(thread 42)(gdb) " or "(thread unselected)(gdb) ". 2) Provide a way to let a function dynamically compute the prompt. Maybe something like "set prompt %p(my_python_function_to_compute_prompt)". Comments? If there's general favorability of this I'll work on a patch.