Re: Add a way to invoke redefined (overridden) GDB commands

[Marco Barisione <mbarisione@undo.io>]

On 12 Oct 2020, at 12:50, Pedro Alves <pedro@palves.net> wrote:
> On 9/14/20 10:39 AM, Marco Barisione wrote:
>> Currently, when a GDB command is redefined, the original implementation is not
>> available any more.  This makes it difficult to build features on top of
>> existing commands.
>> 
>> Last year I submitted a patch to fix this but I ran out of time to address the
>> review comments (the original patch was sent on the 28th of October 2019).
>> These patches restart that work and should address all the comments I got last
>> time.  As the patchea are very different and a long time passed, I'm
>> submitting as a new series.
>> 
>> My patches add a new "uplevel" command and a new gdb.Command.invoke_uplevel
>> method inspired by TCL (as initially suggested by Andrew Burgess) so you can
>> do this:
>> 
>>    (gdb) define run
>>    echo Will run!\n
>>    uplevel 0 run
>>    end
>>    (gdb) run
>>    Will run!
>>    [... normal output of run ...]
>> 
>> 
>> There are a couple of other things which could be added to make the "uplevel"
>> command more helpful, but I think they are out of scope and my patches are
>> already useful as they are.
> 
> So I'm looking at this afresh, and really questioning this "uplevel N"
> design.  This it not really like TCL's "uplevel".  With TCL's uplevel,
> you are accessing a different scope or frame, not a previous implementation
> of the function that was overwritten.  To me, the naming choice is
> confusing, from that angle.  If someone extends GDB's CLI to gain support
> for local variables, then a really-TCL-like uplevel is likely handy, and
> then calling that feature "uplevel" would be good.
> 
> I also question whether "uplevel N" with "N>0" is really usable, since
> in general you don't know what other scripts may have overridden.  E.g.,
> you never know what "uplevel 3 cmd" will run, since you don't know how
> many scripts redefined/overridden cmd.
> 
> If we stick with the TCL inspiration, I think a better approach would
> be to add support for renaming commands, like TCL's rename command:
> 
>  https://www.tcl.tk/man/tcl8.4/TclCmd/rename.htm
> 
> So a user would do:
> 
> (gdb) rename run org_run
> (gdb) define run
>> echo Will run!\n
>> org_run
>> end
> (gdb) run
>  Will run!
>  [... normal output of run ...]
> (gdb) org_run
>  [... normal output of run ...]
> 
> (You can find many examples of TCL's rename in use in GDB's testsuite.)

I will try implementing this then, including the semantics for deleting
a command (copied from the TCL command).

A problem with GDB is that commands can have spaces so:
    (gdb) rename foo bar
Is ambiguous. Do you want to delete the "foo bar" command or rename the
"foo" command to "bar"?
Even without deleting command, this would be ambiguous:
    (gdb) rename foo bar baz

Unless somebody proposes something different I will use "--" to split
the two command names.

For instance:
    (gdb) # Rename "foo" to “bar":
    (gdb) rename foo -- bar
    (gdb) # Rename "foo bar" to "baz":
    (gdb) rename foo bar -- baz
    (gdb) # Delete "foo bar":
    (gdb) rename foo bar --
    (gdb) # Invalid:
    (gdb) rename --
    (gdb) rename -- hello


-- 
Marco Barisione