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

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Sun, Feb 12, 2023 at 16:04:15 +0200, Eli Zaretskii wrote:
> > 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.

I've looked at the pp command, and I think it is only capable of
displaying objects from within the Lisp environment; it won't display
Lisp_Object's in the C environment.  If that's the case, it wouldn't
cover all my needs.

> 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, .....

I have an Emacs running gdb, and a seperate "target" Emacs, the one being
debugged.  I'm not sure which one you mean 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).

No, I'm running on Linux consoles, without the -nw.  It might be possible
to start GDB in a third console, but it would be awkward.

> > 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.

Thanks, that's a good point I wasn't aware of.  One way out of that would
be to test gdb's $argc is exactly 1, and throw an error message if not.
Presumably, there will be some way to quote arguments to gdb functions,
I'll have to read the fine manual a bit more closely.

> 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.

As I said, I could test $argc == 1.  Most of the time, users are not
going to be giving "multi" arguments to the gdb commands, are they?

-- 
Alan Mackenzie (Nuremberg, Germany).