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

[Marco Barisione <mbarisione@undo.io>]

Second ping for https://sourceware.org/pipermail/gdb-patches/2020-September/171829.html <https://sourceware.org/pipermail/gdb-patches/2020-September/171829.html>.


> On 28 Sep 2020, at 08:54, Marco Barisione <mbarisione@undo.io> wrote:
> 
> Ping for the patch series at https://sourceware.org/pipermail/gdb-patches/2020-September/171829.html.
> 
> Thanks!
> 
> 
>> On 14 Sep 2020, at 10:39, Marco Barisione <mbarisione@undo.io> 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.
>> 
>> The first thing is adding a way of accessing the untokenised arguments to a
>> command via something like "$arg@" (Andrew Burgess suggested "$argv", but
>> Pedro Alves pointed out that would look like an argument vector).
>> 
>> Another thing which could be added is the ability to do "uplevel -1 ..." to
>> access the directly redefined command.
>> This is implemented in Python but I couldn't find an obvious way of doing that
>> for the "uplevel" command as there's no way of knowing which command you are
>> currently executing (at least from what I could see).
>> Maybe it could be implemented in a similar way to how command arguments are
>> kept around with scoped_user_args_level, so we could keep a stack of all (user
>> and non-user) commands which are being executed.  By checking the latest one
>> you can know what "uplevel -1" would apply to.
>> 
> 
> -- 
> Marco Barisione
> 

-- 
Marco Barisione