From: Doug Evans <dje@google.com>
To: Pedro Alves <pedro@codesourcery.com>
Cc: Marc Khouzam <marc.khouzam@ericsson.com>, gdb@sourceware.org
Subject: More descriptive prompt [was Re: Process exit in multi-process, and gdb's selected thread.]
Date: Tue, 24 Feb 2009 18:12:00 -0000 [thread overview]
Message-ID: <e394668d0902241012n458775c5s9e7ba9187209764@mail.gmail.com> (raw)
[- gdb-patches]
[+ gdb]
On Tue, Feb 17, 2009 at 10:15 AM, Pedro Alves <pedro@codesourcery.com> 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.
next reply other threads:[~2009-02-24 18:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-24 18:12 Doug Evans [this message]
2009-02-24 18:26 ` Daniel Jacobowitz
2009-02-24 18:41 ` Pedro Alves
2009-02-24 19:09 ` Pedro Alves
2009-02-25 17:41 ` Joel Brobecker
2009-02-25 17:49 ` Doug Evans
2009-02-25 17:59 ` Paul Pluzhnikov
2009-02-25 18:52 ` More descriptive prompt Tom Tromey
2009-02-25 19:00 ` Doug Evans
2009-02-25 19:42 ` Tom Tromey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e394668d0902241012n458775c5s9e7ba9187209764@mail.gmail.com \
--to=dje@google.com \
--cc=gdb@sourceware.org \
--cc=marc.khouzam@ericsson.com \
--cc=pedro@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox