From: Marco Barisione <mbarisione@undo.io>
To: Andrew Burgess <andrew.burgess@embecosm.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH 2/2] Add a way to preserve redefined GDB commands for later invocation
Date: Tue, 6 Oct 2020 08:18:42 +0100 [thread overview]
Message-ID: <69A8A132-78BB-490F-B8A6-C357BD08A1DF@undo.io> (raw)
In-Reply-To: <20201005181100.GI605036@embecosm.com>
On 5 Oct 2020, at 19:11, Andrew Burgess <andrew.burgess@embecosm.com> wrote:
>>> I also wonder how we might handle _really_ redefining a command now
>>> that past commands hang around.
>>>
>>> When writing the above cmd_1 example the first thing I did was open
>>> GDB and try to write the commands at the CLI. I made a typo when
>>> writing the second version of cmd_1. So now I'm stuck with a chain:
>>>
>>> working level 0 cmd_1 --> broken level 1 cmd_1
>>>
>>> Sure I can write a level 2 version that knows to skip over the broken
>>> level 1, but it might be nice if there was a flag somewhere that I
>>> could pass to say, no, really replace the last version of this command
>>> please.
>>
>> Is this really what a user would want? Or would they want the ability
>> to delete commands?
>
> Deleting too might be useful, but I think the case I gave is not
> unique to me, I tried writing a command, I got it slightly wrong.
> Sure I can delete and start again, but being able to just do:
>
> (gdb) define --redefine cmd_1
> ...
>
> would be nice.
I think I’m onboard with all your suggestions, but I’m not 100% sure about
the details. What happens if you "set confirm off"? That is, what should
be the default answer?
Do we need "define --override" and "define --replace"? What happens if the
command is not already previously defined?
--
Marco Barisione
next prev parent reply other threads:[~2020-10-06 7:18 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-14 9:39 Add a way to invoke redefined (overridden) GDB commands Marco Barisione
2020-09-14 9:39 ` [PATCH 1/2] Move the code to execute a cmd_list_element out from execute_command Marco Barisione
2020-10-05 9:08 ` Andrew Burgess
2020-10-05 9:40 ` Marco Barisione
2020-10-05 17:49 ` Andrew Burgess
2020-09-14 9:39 ` [PATCH 2/2] Add a way to preserve redefined GDB commands for later invocation Marco Barisione
2020-09-14 16:18 ` Eli Zaretskii
2020-09-14 16:51 ` Marco Barisione
2020-10-05 10:24 ` Andrew Burgess
2020-10-05 11:44 ` Marco Barisione
2020-10-05 18:11 ` Andrew Burgess
2020-10-06 7:18 ` Marco Barisione [this message]
2020-09-28 7:54 ` [PING] Add a way to invoke redefined (overridden) GDB commands Marco Barisione
2020-10-05 7:42 ` Marco Barisione
2020-10-12 11:50 ` Pedro Alves
2020-10-19 17:41 ` Marco Barisione
2020-10-19 18:05 ` Pedro Alves
2020-10-19 18:47 ` Philippe Waroquiers
2020-10-19 19:28 ` Marco Barisione
2020-10-20 15:06 ` Pedro Alves
2020-10-20 18:19 ` Marco Barisione
2020-10-20 18:32 ` Pedro Alves
2020-10-20 15:15 ` Pedro Alves
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=69A8A132-78BB-490F-B8A6-C357BD08A1DF@undo.io \
--to=mbarisione@undo.io \
--cc=andrew.burgess@embecosm.com \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).