This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

More descriptive prompt [was Re: Process exit in multi-process, and gdb's selected thread.]


[- 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]