This is the mail archive of the
mailing list for the GDB project.
Re: implementing eval command
On Sat, 2008-02-16 at 09:36 +0200, Yakov Lerner wrote:
> On Fri, Feb 15, 2008 at 7:58 PM, Michael Snyder <firstname.lastname@example.org> wrote:
> > Moving this to "gdb" list, since it is not a patch.
> > On Thu, 2008-02-14 at 18:18 +0200, Yakov Lerner wrote:
> > > I'd like to make a patch that implements eval command, as follows.
> > > I have following idea to implement eval simply:
> > > Syntax of eval will be similar to the syntax of 'printf' command:
> > > eval "string with %..." comma-separated-expressions
> > > Implementation relies on existing printf_command() function,
> > > by rewriting printf_command into pair of functions, one that computes
> > > result of printf as allocated string; both printf_command and eval_command
> > > will use compute_printf() function.
> > > What do you think ?
> > Hmmm, that would be one way of getting around the
> > limitations of some commands that can't accept expressions
> > as arguments (mentioned in another thread).
> > What do you see as the context for this eval command?
> > How do you imagine it will be used?
> Apparently, the capability to insert variable into arbitrary part of
> gdb command is missing in gdb. I hit this several days ago when I needed
> to make a script that uses 'thread apply $num where' to a subset of threads
> in a program that had hundreds of threads and I was told on the list that this
> is impossible.
Oh yes, that was the thread I was thinking about.
> I also see other requests for eval command on the mailing list archive.
> So, instead of enriching just 'thread apply' command to accept variable
> (or maybe parenthesized expression) I thought it's much more generic
> to have eval command in the end.
> I thought about easy way to implement it, and then I got idea of using
> the print-like format and comma-separated arg list.
Cool, well, personally I think this is a very interesting idea.
With the printf format, it should be possible to construct
fairly complex commands.