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

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

[Doug Evans]

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

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

[Daniel Jacobowitz]

On Tue, Feb 24, 2009 at 10:12:03AM -0800, Doug Evans wrote:
> 2) Provide a way to let a function dynamically compute the prompt.
>    Maybe something like "set prompt %p(my_python_function_to_compute_prompt)".

Maybe define a new fake command for hooking, similar to hook-stop?
define hook-prompt
  set prompt "(gdb $promptcount++) "
end

Except of course the CLI can't manipulate strings usefully.  So you'd
have to do it in Python.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Pedro Alves]

On Tuesday 24 February 2009 18:12:03, Doug Evans wrote:
> If there's general favorability of this I'll work on a patch.

This was something that had occured to be before as well when
I got tired of doing "info threads" while working on non-stop. 

This is what I was using at one point.  It added a PS1 style
formatting to the gdb command, so I could do

(gdb) set prompt (\\p \\T: \\S)

And have the prompt show up as:

 (1 Thread 0x7ffff7fd36e0 (LWP 12690): stopped) 

or, ...

 (1 Thread 0x7ffff7fd36e0 (LWP 12690): running) 

etc.

-- 
Pedro Alves

---
 gdb/event-top.c |   89 ++++++++++++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 86 insertions(+), 3 deletions(-)

Index: src/gdb/event-top.c
===================================================================
--- src.orig/gdb/event-top.c	2009-01-14 13:37:57.000000000 +0000
+++ src/gdb/event-top.c	2009-02-24 18:33:39.000000000 +0000
@@ -33,6 +33,7 @@
 #include "cli/cli-script.h"     /* for reset_command_nest_depth */
 #include "main.h"
 #include "gdbthread.h"
+#include "gdb_obstack.h"
 
 /* For dont_repeat() */
 #include "gdbcmd.h"
@@ -244,6 +245,83 @@ change_line_handler (void)
     }
 }
 
+static char *
+expand_gdb_prompt (char *prompt)
+{
+  char *p;
+  int escape = 0;
+  struct obstack obstack;
+  obstack_init (&obstack);
+
+  for (p = prompt; *p ; p++)
+    {
+      if (escape)
+	{
+	  escape = 0;
+	  switch (*p)
+	    {
+	    case 'p':
+	      {
+		char *t = xstrprintf ("%d",
+				      pid_to_thread_id (inferior_ptid));
+		obstack_grow_str (&obstack, t);
+		xfree (t);
+		break;
+	      }
+	    case 'T':
+	      {
+		if (!ptid_equal (inferior_ptid, null_ptid))
+		  {
+		    char *t = target_pid_to_str (inferior_ptid);
+		    if (t)
+		      obstack_grow_str (&obstack, t);
+		  }
+		break;
+	      }
+	    case 'x':
+	      {
+		if (!ptid_equal (inferior_ptid, null_ptid))
+		  {
+		    char *t = target_extra_thread_info (inferior_thread ());
+		    if (t)
+		      obstack_grow_str (&obstack, t);
+		  }
+		break;
+	      }
+	    case 'S':
+	      {
+		if (!ptid_equal (inferior_ptid, null_ptid))
+		  {
+		    if (is_running (inferior_ptid))
+		      obstack_grow_str (&obstack, "running");
+		    else if (is_stopped (inferior_ptid))
+		      obstack_grow_str (&obstack, "stopped");
+		    else if (is_exited (inferior_ptid))
+		      obstack_grow_str (&obstack, "exited");
+		  }
+		break;
+	      }
+	    }
+	}
+      else
+	{
+	  switch (*p)
+	    {
+	    case '\\':
+	      escape = 1;
+	      break;
+	    default:
+	      obstack_1grow (&obstack, *p);
+	      break;
+	    }
+	}
+    }
+
+  obstack_1grow (&obstack, '\0');
+
+  return xstrdup (obstack_finish (&obstack));
+}
+
 /* Displays the prompt. The prompt that is displayed is the current
    top of the prompt stack, if the argument NEW_PROMPT is
    0. Otherwise, it displays whatever NEW_PROMPT is. This is used
@@ -260,6 +338,7 @@ display_gdb_prompt (char *new_prompt)
 {
   int prompt_length = 0;
   char *gdb_prompt = get_prompt ();
+  char *expanded_prompt;
 
   /* Reset the nesting depth used when trace-commands is set.  */
   reset_command_nest_depth ();
@@ -307,20 +386,24 @@ display_gdb_prompt (char *new_prompt)
       strcat (new_prompt, SUFFIX (0));
     }
 
+  expanded_prompt = expand_gdb_prompt (new_prompt);
+
   if (async_command_editing_p)
     {
       rl_callback_handler_remove ();
-      rl_callback_handler_install (new_prompt, input_handler);
+      rl_callback_handler_install (expanded_prompt, input_handler);
     }
   /* new_prompt at this point can be the top of the stack or the one passed in */
-  else if (new_prompt)
+  else
     {
       /* Don't use a _filtered function here.  It causes the assumed
          character position to be off, since the newline we read from
          the user is not accounted for.  */
-      fputs_unfiltered (new_prompt, gdb_stdout);
+      fputs_unfiltered (expanded_prompt, gdb_stdout);
       gdb_flush (gdb_stdout);
     }
+
+  xfree (expanded_prompt);
 }
 
 /* Used when the user requests a different annotation level, with

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

[Pedro Alves]

On Tuesday 24 February 2009 18:41:11, Pedro Alves wrote:
> On Tuesday 24 February 2009 18:12:03, Doug Evans wrote:
> > If there's general favorability of this I'll work on a patch.

To be clear, I meant to say that I do favor a way to have a
more descriptive prompt, however it ends up implemented.  I'd be
fine with python, or whatever.

> This was something that had occured to be before as well when
> I got tired of doing "info threads" while working on non-stop. 
> 
> This is what I was using at one point.  It added a PS1 style
> formatting to the gdb command, so I could do
> 
> (gdb) set prompt (\\p \\T: \\S)
> 
> And have the prompt show up as:
> 
>  (1 Thread 0x7ffff7fd36e0 (LWP 12690): stopped) 
> 
> or, ...
> 
>  (1 Thread 0x7ffff7fd36e0 (LWP 12690): running) 
> 
> etc.
> 

-- 
Pedro Alves

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

[Joel Brobecker]

> This is what I was using at one point.  It added a PS1 style
> formatting to the gdb command, so I could do
> 
> (gdb) set prompt (\\p \\T: \\S)

Sounds like a useful idea to me. I'm torn between a python approach
and Pedro's approach. Pedro's approach might be seen as less powerful,
since one cannot extend the list of available escape sequences without
rebuilding GDB.  But I think it has the advantage of being simple
to implement and simple to use.

-- 
Joel

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

[Doug Evans]

On Wed, Feb 25, 2009 at 9:41 AM, Joel Brobecker <brobecker@adacore.com> wrote:
>> This is what I was using at one point.  It added a PS1 style
>> formatting to the gdb command, so I could do
>>
>> (gdb) set prompt (\\p \\T: \\S)
>
> Sounds like a useful idea to me. I'm torn between a python approach
> and Pedro's approach. Pedro's approach might be seen as less powerful,
> since one cannot extend the list of available escape sequences without
> rebuilding GDB.  But I think it has the advantage of being simple
> to implement and simple to use.
>

fwiw, I was actually proposing both.
Provide simple things (a la PS1 in bash parlance or whatever),
but also provide a way to run a (python) function to compute the prompt.

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

[Paul Pluzhnikov]

On Wed, Feb 25, 2009 at 9:49 AM, Doug Evans <dje@google.com> wrote:

> fwiw, I was actually proposing both.
> Provide simple things (a la PS1 in bash parlance or whatever),
> but also provide a way to run a (python) function to compute the prompt.

bash actually has a more powerful mechanism as well:
  PROMPT_COMMAND
    If set, the value is executed as a command prior to issuing
    each primary prompt.

Sounds like a python or user-definable prompt_command + PS1-like
token expansion will address most needs.

-- 
Paul Pluzhnikov

Re: More descriptive prompt

[Tom Tromey]

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

>> This is what I was using at one point.  It added a PS1 style
>> formatting to the gdb command, so I could do
>> 
>> (gdb) set prompt (\\p \\T: \\S)

Joel> Sounds like a useful idea to me. I'm torn between a python approach
Joel> and Pedro's approach. Pedro's approach might be seen as less powerful,
Joel> since one cannot extend the list of available escape sequences without
Joel> rebuilding GDB.  But I think it has the advantage of being simple
Joel> to implement and simple to use.

One could also write a Python hook, and then implement the PS1-style
substitution idea in Python :-)

Tom

Re: More descriptive prompt

[Doug Evans]

On Wed, Feb 25, 2009 at 10:49 AM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:
>
>>> This is what I was using at one point.  It added a PS1 style
>>> formatting to the gdb command, so I could do
>>>
>>> (gdb) set prompt (\\p \\T: \\S)
>
> Joel> Sounds like a useful idea to me. I'm torn between a python approach
> Joel> and Pedro's approach. Pedro's approach might be seen as less powerful,
> Joel> since one cannot extend the list of available escape sequences without
> Joel> rebuilding GDB.  But I think it has the advantage of being simple
> Joel> to implement and simple to use.
>
> One could also write a Python hook, and then implement the PS1-style
> substitution idea in Python :-)

Ya, ya, that occurred to me. :-)

fwiw, I'd prefer to support a more intelligent prompt without requiring python.
But I'm happy to implement whatever y'all agree on.

Re: More descriptive prompt

[Tom Tromey]

>>>>> "Doug" == Doug Evans <dje@google.com> writes:

Doug> fwiw, I'd prefer to support a more intelligent prompt without
Doug> requiring python.  But I'm happy to implement whatever y'all
Doug> agree on.

IMO -- don't let us bikeshed.  Design and implement something you like
that is reasonable.

Tom