[RFC] Let "gcore" command accept a suffix argument

[RFC] Let "gcore" command accept a suffix argument

[Michael Snyder]

I can't find the reference message, but I have a recollection
about somebody asking why some gdb command (may have been 'gcore')
couldn't accept a gdb internal variable so that the filename could
in effect be "computed", or disambiguated, to avoid overwriting.

Having just done this for "record save", I thought I'd float the
idea of generalizing it.

1) So -- what if 'gcore' were to accept an optional second argument
which, if present, would be treated as an integer and suffixed to
the gcore filename?  So for instance:

(gdb) set $a = 0
(gdb) gcore foo $a++
(gdb) step
(gdb) gcore foo $a++
(gdb) step
(gdb) gcore foo $a++

would result in three files: foo.0, foo.1, and foo.2.

2) Similarly, what if we were to do the same thing with
add_setshow_filename_cmd, which is used for commands such
as "set logging filename".  Then a series of logging files
could be created, each with a unique filename.

Yes, I know, we could do the same thing with Python, but
I'm not convinced that that is an argument against doing it
stand alone (maybe for users who don't want to learn python).

I'm prepared to submit a patch for 1 and 2, separately or together.

Re: [RFC] Let "gcore" command accept a suffix argument

[Hui Zhu]

I think if each command can support $v directly is better.

For example:
set $a=0
gcore $a
Saved corefile 0

Thanks,
Hui

On Sun, Nov 29, 2009 at 10:19, Michael Snyder <msnyder@vmware.com> wrote:
> I can't find the reference message, but I have a recollection
> about somebody asking why some gdb command (may have been 'gcore')
> couldn't accept a gdb internal variable so that the filename could
> in effect be "computed", or disambiguated, to avoid overwriting.
>
> Having just done this for "record save", I thought I'd float the
> idea of generalizing it.
>
> 1) So -- what if 'gcore' were to accept an optional second argument
> which, if present, would be treated as an integer and suffixed to
> the gcore filename?  So for instance:
>
> (gdb) set $a = 0
> (gdb) gcore foo $a++
> (gdb) step
> (gdb) gcore foo $a++
> (gdb) step
> (gdb) gcore foo $a++
>
> would result in three files: foo.0, foo.1, and foo.2.
>
> 2) Similarly, what if we were to do the same thing with
> add_setshow_filename_cmd, which is used for commands such
> as "set logging filename".  Then a series of logging files
> could be created, each with a unique filename.
>
> Yes, I know, we could do the same thing with Python, but
> I'm not convinced that that is an argument against doing it
> stand alone (maybe for users who don't want to learn python).
>
> I'm prepared to submit a patch for 1 and 2, separately or together.
>
>
>
>

Re: [RFC] Let "gcore" command accept a suffix argument

[Joel Brobecker]

> I think if each command can support $v directly is better.
> 
> For example:
> set $a=0
> gcore $a
> Saved corefile 0

Am I the only one who really doesn't like this idea? The more I think
about it, the less I like it. It feels like putting a plug instead of
getting a new pair of tires. I'm surprised at my own reaction, since
it is not going to affect me all that much, and so I will let it go
if others like it (but it feels like a bandaid to me, and once it's in,
we won't be able to remove it).

-- 
Joel

Re: [RFC] Let "gcore" command accept a suffix argument

[Tom Tromey]

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

>> For example:
>> set $a=0
>> gcore $a
>> Saved corefile 0

Joel> Am I the only one who really doesn't like this idea?

Nope.

Joel> I'm surprised at my own reaction, since
Joel> it is not going to affect me all that much, and so I will let it go
Joel> if others like it (but it feels like a bandaid to me, and once it's in,
Joel> we won't be able to remove it).

GDB's command language is already weird and inconsistent.  And it does
affect you -- it affects all maintainers, because it is hard to justify
incompatible changes.  So, I think it is better for both maintainers and
users if we come up with generic facilities rather than ad hoc ones like
this.

Tom

Re: [RFC] Let "gcore" command accept a suffix argument

[Michael Snyder]

Joel Brobecker wrote:
>> I think if each command can support $v directly is better.
>>
>> For example:
>> set $a=0
>> gcore $a
>> Saved corefile 0
> 
> Am I the only one who really doesn't like this idea? The more I think
> about it, the less I like it. It feels like putting a plug instead of
> getting a new pair of tires. I'm surprised at my own reaction, since
> it is not going to affect me all that much, and so I will let it go
> if others like it (but it feels like a bandaid to me, and once it's in,
> we won't be able to remove it).

I don't like the above suggestion, but I assume you are
talking about the original idea.

So, knowing what problem we are trying to solve, do you
have a picture of what "new tires" would look like?

Re: [RFC] Let "gcore" command accept a suffix argument

[Joel Brobecker]

> I don't like the above suggestion, but I assume you are
> talking about the original idea.

Personally, I think that we should look at python. As far as I could
tell, I was already able to do everything with the current python
support, even if a little convoluted. We can also start working on
a python layer for process record too.  That would be my prefered
approach.

Otherwise, what do you think of Tom's suggestion (new "eval" command)?

-- 
Joel

Re: [RFC] Let "gcore" command accept a suffix argument

[Michael Snyder]

Joel Brobecker wrote:
>> I don't like the above suggestion, but I assume you are
>> talking about the original idea.
> 
> Personally, I think that we should look at python. As far as I could
> tell, I was already able to do everything with the current python
> support, even if a little convoluted. We can also start working on
> a python layer for process record too.  That would be my prefered
> approach.
> 
> Otherwise, what do you think of Tom's suggestion (new "eval" command)?

Well I wouldn't want to be stuck implementing it...
I don't know python!   ;-)

Would it be able to include the incr? "eval gcore foo.$a++"?

Re: [RFC] Let "gcore" command accept a suffix argument

[Joel Brobecker]

> Would it be able to include the incr? "eval gcore foo.$a++"?

I do not think so, not as suggested by Tom, I believe.  The suggestion
is to expand convenience variables, not evaluate full-fledged
expressions.  The issue with full-fledged expressions is that you have
to recognize them and find where they start and end. But I think that
this would not be a serious limitation in practice, since the above
can be rewritten as:

  eval gcore foo.$a
  set $a = $a + 1

-- 
Joel

Re: [RFC] Let "gcore" command accept a suffix argument

[Michael Snyder]

Joel Brobecker wrote:
>> Would it be able to include the incr? "eval gcore foo.$a++"?
> 
> I do not think so, not as suggested by Tom, I believe.  The suggestion
> is to expand convenience variables, not evaluate full-fledged
> expressions.  The issue with full-fledged expressions is that you have
> to recognize them and find where they start and end. But I think that
> this would not be a serious limitation in practice, since the above
> can be rewritten as:
> 
>   eval gcore foo.$a
>   set $a = $a + 1

Well, that would suit me OK, so long as somebody else
implements it.

Re: [RFC] Let "gcore" command accept a suffix argument

[Hui Zhu]

[-- Attachment #1: Type: text/plain, Size: 3440 bytes --]

Hi guys,

I make a patch to make gdb support "eval gcore foo.$a" command.

(gdb) set $cmd="pwd"
(gdb) eval $cmd
Working directory /home/teawater/gdb/bgdbno/gdb.
(gdb) set $cmd="file ~/gdb/a.out"
(gdb) eval $cmd
Reading symbols from /home/teawater/gdb/a.out...done.
(gdb) start
Temporary breakpoint 1 at 0x80483be
Starting program: /home/teawater/gdb/a.out

Temporary breakpoint 1, 0x080483be in main ()
(gdb) set $name="eval"
(gdb) set $num=3
(gdb) eval gcore $name.$num
Saved corefile eval.3

Please post your comments about it.

And the help and file that include this command is not very well.
Please help me with them.  :)

Thanks,
Hui


2009-12-10  Hui Zhu  <teawater@gmail.com>
	* printcmd.c (ctype.h): New include.
	(eval_command): New function.
	(_initialize_printcmd): New command "eval".


---
 printcmd.c |   83 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 83 insertions(+)

--- a/printcmd.c
+++ b/printcmd.c
@@ -50,6 +50,8 @@
 #include "parser-defs.h"
 #include "charset.h"

+#include <ctype.h>
+
 #ifdef TUI
 #include "tui/tui.h"		/* For tui_active et.al.   */
 #endif
@@ -2625,6 +2627,84 @@ printf_command (char *arg, int from_tty)
   do_cleanups (old_cleanups);
 }

+static void
+eval_command (char *exp, int from_tty)
+{
+#define CMDSIZE 1024
+  char cmd[CMDSIZE + 1];
+  char *cmdp = cmd;
+  int is_eval = 0;
+  char *eval_begin;
+
+  if (!exp)
+    return;
+
+  while (cmdp - cmd < CMDSIZE)
+    {
+      if (is_eval)
+        {
+          if (!isalnum (exp[0]) && exp[0] != '_')
+            {
+              struct value *value;
+              gdb_byte *buffer;
+              int length = -1;
+              struct type *char_type = NULL;
+              const char *la_encoding = NULL;
+              char tmp = exp[0];
+
+              exp[0] = '\0';
+              value = parse_and_eval (eval_begin);
+
+              switch (TYPE_CODE (value_type (value)))
+                {
+                  case TYPE_CODE_ARRAY:
+                    LA_GET_STRING (value, &buffer, &length,
+                                   &char_type, &la_encoding);
+                   break;
+                  case TYPE_CODE_INT:
+                    buffer = plongest (value_as_long (value));
+                    length = strlen (buffer);
+                    break;
+                  default:
+                    buffer = eval_begin;
+                    length = exp - eval_begin;
+                    break;
+                }
+
+              if (length > CMDSIZE - (cmdp - cmd))
+                length = CMDSIZE - (cmdp - cmd);
+              memcpy (cmdp, buffer, length);
+              cmdp += length;
+
+              exp[0] = tmp;
+              is_eval = 0;
+            }
+          else
+            exp ++;
+        }
+      else
+        {
+          if (!exp[0])
+            break;
+
+          if (exp[0] == '$')
+            {
+              is_eval = 1;
+              eval_begin = exp;
+            }
+          else
+            {
+              cmdp[0] = exp[0];
+              cmdp ++;
+            }
+          exp ++;
+        }
+    }
+  cmdp[0] = '\0';
+
+  execute_command (cmd, from_tty);
+}
+
 void
 _initialize_printcmd (void)
 {
@@ -2788,4 +2868,7 @@ Show printing of source filename and lin
 			   NULL,
 			   show_print_symbol_filename,
 			   &setprintlist, &showprintlist);
+
+  add_com ("eval", no_class, eval_command, _("\
+Call command with variable."));
 }

[-- Attachment #2: eval.txt --]
[-- Type: text/plain, Size: 2642 bytes --]

---
 printcmd.c |   83 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 83 insertions(+)

--- a/printcmd.c
+++ b/printcmd.c
@@ -50,6 +50,8 @@
 #include "parser-defs.h"
 #include "charset.h"
 
+#include <ctype.h>
+
 #ifdef TUI
 #include "tui/tui.h"		/* For tui_active et.al.   */
 #endif
@@ -2625,6 +2627,84 @@ printf_command (char *arg, int from_tty)
   do_cleanups (old_cleanups);
 }
 
+static void
+eval_command (char *exp, int from_tty)
+{
+#define CMDSIZE 1024
+  char cmd[CMDSIZE + 1];
+  char *cmdp = cmd;
+  int is_eval = 0;
+  char *eval_begin;
+
+  if (!exp)
+    return;
+
+  while (cmdp - cmd < CMDSIZE)
+    {
+      if (is_eval)
+        {
+          if (!isalnum (exp[0]) && exp[0] != '_')
+            {
+              struct value *value;
+              gdb_byte *buffer;
+              int length = -1;
+              struct type *char_type = NULL;
+              const char *la_encoding = NULL;
+              char tmp = exp[0];
+
+              exp[0] = '\0';
+              value = parse_and_eval (eval_begin);
+
+              switch (TYPE_CODE (value_type (value)))
+                {
+                  case TYPE_CODE_ARRAY:
+                    LA_GET_STRING (value, &buffer, &length,
+                                   &char_type, &la_encoding);
+                   break;
+                  case TYPE_CODE_INT:
+                    buffer = plongest (value_as_long (value));
+                    length = strlen (buffer);
+                    break;
+                  default:
+                    buffer = eval_begin;
+                    length = exp - eval_begin;
+                    break;
+                }
+
+              if (length > CMDSIZE - (cmdp - cmd))
+                length = CMDSIZE - (cmdp - cmd);
+              memcpy (cmdp, buffer, length);
+              cmdp += length;
+
+              exp[0] = tmp;
+              is_eval = 0;
+            }
+          else
+            exp ++;
+        }
+      else
+        {
+          if (!exp[0])
+            break;
+
+          if (exp[0] == '$')
+            {
+              is_eval = 1;
+              eval_begin = exp;
+            }
+          else
+            {
+              cmdp[0] = exp[0];
+              cmdp ++;
+            }
+          exp ++;
+        }
+    }
+  cmdp[0] = '\0';
+
+  execute_command (cmd, from_tty);
+}
+
 void
 _initialize_printcmd (void)
 {
@@ -2788,4 +2868,7 @@ Show printing of source filename and lin
 			   NULL,
 			   show_print_symbol_filename,
 			   &setprintlist, &showprintlist);
+
+  add_com ("eval", no_class, eval_command, _("\
+Call command with variable."));
 }

Re: [RFC] Let "gcore" command accept a suffix argument

[Tom Tromey]

>>>>> "Michael" == Michael Snyder <msnyder@vmware.com> writes:

Michael> I can't find the reference message, but I have a recollection
Michael> about somebody asking why some gdb command (may have been 'gcore')
Michael> couldn't accept a gdb internal variable so that the filename could
Michael> in effect be "computed", or disambiguated, to avoid overwriting.

It isn't just gcore.  This lack of reflectivity comes up every week, for
different commands, on the gdb irc channel.  Our standard answers are
(1) use Python, and (2) you can do it more horribly using set logging
and shell.

Michael> 1) So -- what if 'gcore' were to accept an optional second
Michael> argument which, if present, would be treated as an integer and
Michael> suffixed to the gcore filename?

I don't like it very much, I think because it is a specific solution to
a general problem.

Michael> Yes, I know, we could do the same thing with Python, but
Michael> I'm not convinced that that is an argument against doing it
Michael> stand alone (maybe for users who don't want to learn python).

I'm not that sympathetic to users who don't want to learn about the
facilities that gdb provides.  That said, presumably some versions of
gdb won't enable python, and it would make sense to provide some
solution to those users as well.

As a counter-proposal, consider an "eval" command.  It would substitute
any $foo in its argument before invoking the real command.  Your example
would be:

set $a = 0
eval gcore foo.$a
set $a = $a + 1

A "$$" in the argument would be converted to a single "$", so users
could also defer convenience variable evaluation when needed.

"eval" itself isn't more than a few lines of Python ;)

Tom