bug#61453: It is annoying to have to type 'print foo' before each .gdbinit command.

[Eli Zaretskii]

> Date: Sun, 12 Feb 2023 13:34:36 +0000
> Cc: 61453@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > What's wrong with the existing "pp" command?  I think it covers all
> > your needs, and doesn't need any changes to existing xFOO commands.
> 
> The pp comand does nothing on my setup except for scrolling the gdb
> window up one line.  Its help text says "Works only when an inferior
> emacs is executing.".  I normally start the target Emacs on a separate
> Linux console, then attach it to my gdb session with the attach command.
> I don't really know what "an inferior emacs" means, though I'm sure I
> could find out if I read etc/DEBUG more carefully.

You do need to have a running Emacs for "pp", but if you attach to a
running Emacs, you already have that.  I guess the problem is that the
output of "pp" goes to the same display as the one Emacs uses, since
you are running a -nw session, right?  Maybe you should try "set
new-console 1", or start GDB on a separate console (if that is
possible with the console you are using).

> So, I still think my patch would be a good idea.

But does it really work?  You use $arg0, but that means you cannot
have an arbitrary expression as an argument, and have to be very
cautious with blanks and other delimiters, because GDB could decide
that $arg0 is just part of the argument.  Observe:

  (gdb) define foo
  > print $arg0
  > end
  (gdb) foo 1 + 2 + 3
  $1 = 1

But

  (gdb) print 1 + 2 + 3
  $2 = 6

and

  (gdb) p Vmost_positive_fixnum - 1
  $1 = 6917529027641081854
  (gdb) xint
  $2 = 2305843009213693950

So the existing commands accept/interpret arbitrary expressions,
whereas your changed commands will not necessarily do so.  Which means
they can silently produce incorrect results, and the user will be none
the wiser.