[RFC,0/2] Command expression evaulation substitution

  This RFC proposes a new syntax to allow arbitrary expressions to be substituted
into command arguments.

For example, the first patch in this series adds a new `_env' Python convenience
function which gives users access to the shell's environment variables. If a user
wanted to access the value of an environment variable within a GDB command,
though, they cannot currently do that:

(gdb) set logging file $_env("HOME")/$_env("MYLOG")
(gdb) show logging file
The current logfile is "$_env("HOME")/$_env("MYLOG")".
(gdb) eval "set logging file %s/%s", $_env("HOME"), $_env("MYLOG")
evaluation of this expression requires the target program to be active

That `eval' doesn't work is likely a bug, but I nonetheless find the syntax quite
cumbersome for this purpose.

Therefore, I've chosen to introduce a new marker for expression substitution, $().
The second patch implements a proof-of-concept implementation following this
concept:

(gdb) set logging file $($_env("HOME"))/$($_env("MYLOG"))
(gdb) show logging file
The current logfile is "/home/keiths/my.log".

There is a lot more to do to refine this new feature. For example, the value
almost certainly needs to have a lot of format tweaking, since, for example,
using chars does not work:

(gdb) p 'a'
$1 = 97 'a'
(gdb) echo $($1)\n
97 'a'

There are probably a multitude of other similar issues to be sorted out,
such as arrays, repeating elements, symbol/object printing and so on.
If anyone has any suggestions on how to improve this value printing code, I'd
love to hear 'em.

I've also chosen to hook this in at quite a low level so that all commands can
immediately benefit from this. [That is, we don't have to add handling code into
every command function in which we want to support this new syntax.] This may
not be the best approach.

@Wendy.Peikes@netapp.com: Would this proposal satisfy NetApp's needs?

Keith Seitz (2):
  Add $_env convenience function
  Allow and evaluate expressions in command arguments

 gdb/data-directory/Makefile.in     |  1 +
 gdb/python/lib/gdb/function/env.py | 21 ++++++++++
 gdb/top.c                          | 65 ++++++++++++++++++++++++++++++
 3 files changed, 87 insertions(+)
 create mode 100644 gdb/python/lib/gdb/function/env.py
  

Thank you so much for writing back.

So is this patch you incorporated based on the idea I sent you? If so THANK YOU!

wendy

-----Original Message-----
From: Keith Seitz <keiths@redhat.com> 
Sent: Wednesday, January 25, 2023 11:38 AM
To: gdb-patches@sourceware.org
Cc: Peikes, Wendy <Wendy.Peikes@netapp.com>
Subject: [RFC PATCH 0/2] Command expression evaulation substitution

NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.




This RFC proposes a new syntax to allow arbitrary expressions to be substituted into command arguments.

For example, the first patch in this series adds a new `_env' Python convenience function which gives users access to the shell's environment variables. If a user wanted to access the value of an environment variable within a GDB command, though, they cannot currently do that:

(gdb) set logging file $_env("HOME")/$_env("MYLOG")
(gdb) show logging file
The current logfile is "$_env("HOME")/$_env("MYLOG")".
(gdb) eval "set logging file %s/%s", $_env("HOME"), $_env("MYLOG") evaluation of this expression requires the target program to be active

That `eval' doesn't work is likely a bug, but I nonetheless find the syntax quite cumbersome for this purpose.

Therefore, I've chosen to introduce a new marker for expression substitution, $().
The second patch implements a proof-of-concept implementation following this
concept:

(gdb) set logging file $($_env("HOME"))/$($_env("MYLOG"))
(gdb) show logging file
The current logfile is "/home/keiths/my.log".

There is a lot more to do to refine this new feature. For example, the value almost certainly needs to have a lot of format tweaking, since, for example, using chars does not work:

(gdb) p 'a'
$1 = 97 'a'
(gdb) echo $($1)\n
97 'a'

There are probably a multitude of other similar issues to be sorted out, such as arrays, repeating elements, symbol/object printing and so on.
If anyone has any suggestions on how to improve this value printing code, I'd love to hear 'em.

I've also chosen to hook this in at quite a low level so that all commands can immediately benefit from this. [That is, we don't have to add handling code into every command function in which we want to support this new syntax.] This may not be the best approach.

@Wendy.Peikes@netapp.com: Would this proposal satisfy NetApp's needs?

Keith Seitz (2):
  Add $_env convenience function
  Allow and evaluate expressions in command arguments

 gdb/data-directory/Makefile.in     |  1 +
 gdb/python/lib/gdb/function/env.py | 21 ++++++++++
 gdb/top.c                          | 65 ++++++++++++++++++++++++++++++
 3 files changed, 87 insertions(+)
 create mode 100644 gdb/python/lib/gdb/function/env.py

--
2.38.1