* Redefining built-in commands. @ 2002-05-30 17:23 Don Howard 2002-05-30 17:37 ` Don Howard 2002-05-31 0:29 ` Eli Zaretskii 0 siblings, 2 replies; 5+ messages in thread From: Don Howard @ 2002-05-30 17:23 UTC (permalink / raw) To: gdb I've run across a bug involving redefinition of built-in commands: If the command has an alias, the alias is not redefined. Instead, the alias is left in an inconsistent state and causes a crash when invoked. Should gdb allow users to redefine built-in commands? If so, should the orignial alias continue to behave like the original built-in, or should it's behavior be modified also? -- dhoward@redhat.com gdb engineering ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Redefining built-in commands. 2002-05-30 17:23 Redefining built-in commands Don Howard @ 2002-05-30 17:37 ` Don Howard 2002-05-31 0:29 ` Eli Zaretskii 1 sibling, 0 replies; 5+ messages in thread From: Don Howard @ 2002-05-30 17:37 UTC (permalink / raw) To: gdb On Thu, 30 May 2002, Don Howard wrote: > > > I've run across a bug involving redefinition of built-in commands: > > If the command has an alias, the alias is not redefined. Instead, the > alias is left in an inconsistent state and causes a crash when invoked. > > Should gdb allow users to redefine built-in commands? If so, should the > orignial alias continue to behave like the original built-in, or should > it's behavior be modified also? > An example: (gdb) define next Really redefine built-in command "next"? (y or n) y Type commands for definition of "next". End with a line saying just "end". >echo A silly example - redefine next\n >end (gdb) next A silly example - redefine next (gdb) n Segmentation fault -- dhoward@redhat.com gdb engineering ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Redefining built-in commands. 2002-05-30 17:23 Redefining built-in commands Don Howard 2002-05-30 17:37 ` Don Howard @ 2002-05-31 0:29 ` Eli Zaretskii 2002-06-05 14:39 ` Don Howard 1 sibling, 1 reply; 5+ messages in thread From: Eli Zaretskii @ 2002-05-31 0:29 UTC (permalink / raw) To: dhoward; +Cc: gdb > Date: Thu, 30 May 2002 17:24:05 -0700 (PDT) > From: Don Howard <dhoward@redhat.com> > > Should gdb allow users to redefine built-in commands? I think it should, unless we cannot do it safely. > If so, should the > orignial alias continue to behave like the original built-in, or should > it's behavior be modified also? I'm not 100% sure, but I tend to think the aliases that are mere abbreviations, like `n' for `next', should be redefined to the new command, while aliases which aren't abbreviations should be left to point to the original command. But if the above cannot be done, we should either redefine the aliases to the new command, or disable the aliases entirely. Crashing is not an option, obviously. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Redefining built-in commands. 2002-05-31 0:29 ` Eli Zaretskii @ 2002-06-05 14:39 ` Don Howard 2002-06-10 9:23 ` Tom Tromey 0 siblings, 1 reply; 5+ messages in thread From: Don Howard @ 2002-06-05 14:39 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gdb On Fri, 31 May 2002, Eli Zaretskii wrote: > > Date: Thu, 30 May 2002 17:24:05 -0700 (PDT) > > From: Don Howard <dhoward@redhat.com> > > > > Should gdb allow users to redefine built-in commands? > > I think it should, unless we cannot do it safely. > > > If so, should the > > orignial alias continue to behave like the original built-in, or should > > it's behavior be modified also? > > I'm not 100% sure, but I tend to think the aliases that are mere > abbreviations, like `n' for `next', should be redefined to the new > command, while aliases which aren't abbreviations should be left to > point to the original command. > > But if the above cannot be done, we should either redefine the aliases > to the new command, or disable the aliases entirely. Crashing is not > an option, obviously. > Ignoring the alias issue, I don't see any benefit to being able to redefine built-in commands. When a built-in command is redefined, it's original functionality is lost for the remainder of that debugging session. For example, say the user redefines the 'step' command -- there is no longer a way to do source-level stepping. (gdb) define step > do something special > step > end (gdb) The above example ends up "doing something special" until gdb hits it's recursion limit, rather than doing something special and then stepping. The example *does* work just fine if the user picks anything other than a built-in name: (gdb) define special_step > do something special > step > end (gdb) I think the ability to redefine built-in commands is a misfeature. Users can always choose an alternate name for their custom commands. -- dhoward@redhat.com gdb engineering ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Redefining built-in commands. 2002-06-05 14:39 ` Don Howard @ 2002-06-10 9:23 ` Tom Tromey 0 siblings, 0 replies; 5+ messages in thread From: Tom Tromey @ 2002-06-10 9:23 UTC (permalink / raw) To: Don Howard; +Cc: Eli Zaretskii, gdb >>>>> "Don" == Don Howard <dhoward@redhat.com> writes: Don> (gdb) define step Don> do something special Don> step Don> end Don> (gdb) Don> The above example ends up "doing something special" until gdb hits it's Don> recursion limit, rather than doing something special and then stepping. Don> The example *does* work just fine if the user picks anything other than a Don> built-in name: Bash solves this problem by adding a `command' command, which invokes the original command. So in the above you could use `command step' to invoke the real step. Perhaps this would be useful in gdb. Tom ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2002-06-10 16:23 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-05-30 17:23 Redefining built-in commands Don Howard 2002-05-30 17:37 ` Don Howard 2002-05-31 0:29 ` Eli Zaretskii 2002-06-05 14:39 ` Don Howard 2002-06-10 9:23 ` Tom Tromey
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox