better "pr" with gdb-6.4

better "pr" with gdb-6.4

[Dan Nicolaescu]

Using "pr" when debugging is a bit inconvenient because one has to do:

p VARIABLE
pr 

Instead it would be nicer to just do:
pr VARIABLE

Well, with gdb-6.4 this is possible, thanks to a new variable ($argc)
that holds the number of arguments passed to a command. "pr" can now
be written like this to support both versions shown above:

define pr
  if ($argc == 0)
     set debug_print ($)
  elif ($argc == 1)
     set debug_print ($arg0)
  end
end

Processing even more arguments can be done by adding more "elif"
  elif ($argc == 2)
     set debug_print ($arg0)
     set debug_print ($arg1)

Unfortunately AFAIK it is not possible to do it in a simpler way
(there's no equivalent of Bourne shell's "shift" and the positional
arguments cannot be accessed through a variable that can be
incremented in a loop).

I don't know enough about autoconf to integrate the above in the build
system, but maybe some of you might be useful as a local hack until
properly integrated in emacs....

        --dan

Re: better "pr" with gdb-6.4

[Kim F. Storm]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> Using "pr" when debugging is a bit inconvenient because one has to do:
>
> p VARIABLE
> pr 

pp C-VARIABLE
pv LISP-VARIABLE

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: better "pr" with gdb-6.4

[Dan Nicolaescu]

storm@cua.dk (Kim F. Storm) writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > > Using "pr" when debugging is a bit inconvenient because one has to do:
  > >
  > > p VARIABLE
  > > pr 
  > 
  > pp C-VARIABLE
  > pv LISP-VARIABLE

Well the same logic applies to these too, you cannot do:

p C-VAR
pp

or 
pp C-VAR1 C-VAR2

Re: better "pr" with gdb-6.4

[Nick Roberts]

 > Well the same logic applies to these too, you cannot do:
 > 
 > p C-VAR
 > pp
 > 
 > or 
 > pp C-VAR1 C-VAR2

Most Emacs users/developers probably don't have GDB 6.4 so you would at
least need to give your function a different name.

I have a couple of other functions that just work when the selected frame is
Ffuncall, for printing all the argument names.  Are they generally useful?

Nick


(gdb) b Fload
Breakpoint 3 at 0x81a4513: file lread.c, line 682.
(gdb) r -q
Starting program: /home/nickrob/emacs/src/emacs -q

Breakpoint 3, Fload (file=140229699, noerror=137853993, nomessage=137853993, nosuffix=137853993, must_suffix=137853945) at lread.c:682
(gdb) up
#1  0x0818cd1b in Ffuncall (nargs=5, args=0xfee5fd10) at eval.c:2893
(gdb) pp1args
args[0] = load
args[1] = "/usr/local/share/emacs/22.0.50/site-lisp/subdirs.el"
args[2] = t
args[3] = t
args[4] = t
(gdb) ppargs
load
"/usr/local/share/emacs/22.0.50/site-lisp/subdirs.el"
t
t
t



define ppargs
set $i = nargs
while $i
  set $index = nargs - $i
  pp args[$index]
  set $i = $i - 1
  end
end

define pp1args
set $i = nargs
while $i
  set $index = nargs - $i
  printf "args["
  output $index
  printf "] = "
  pp args[$index]
  set $i = $i - 1
  end
end

Re: better "pr" with gdb-6.4

[Kim F. Storm]

Nick Roberts <nickrob@snap.net.nz> writes:

>  > Well the same logic applies to these too, you cannot do:
>  > 
>  > p C-VAR
>  > pp
>  > 
>  > or 
>  > pp C-VAR1 C-VAR2
>
> Most Emacs users/developers probably don't have GDB 6.4 so you would at
> least need to give your function a different name.

Perhaps, for portability, could .gdbinit do something like
globally:
 set $argc = -1
and then the pp functions could test if $argc >= 0 to 
recognize GDB 6.4 ?

> I have a couple of other functions that just work when the selected frame is
> Ffuncall, for printing all the argument names.  Are they generally useful?

Seems useful, but why have to functions which does the same thing?

Actually, it would alse be useful if you could enhance
xbacktrace to recognize when the current frame is Ffuncall and
print the args at that level  (maybe for other functions too).

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: better "pr" with gdb-6.4

[Miles Bader]

2006/2/7, Kim F. Storm <storm@cua.dk>:
> > I have a couple of other functions that just work when the selected frame is
> > Ffuncall, for printing all the argument names.  Are they generally useful?
>
> Seems useful, but why have to functions which does the same thing?

FWIW, I find the current emacs debug macros quite hard to remember in
all their subtle variation.  It would be nice to have the "main"
macros like pr and xbacktrace work intuitively in more cases (which I
think includes accepting an argument for pr -- everytime I debug emacs
after a long absence, I seem to try giving pr an argument a few times
before I remember how it works... :-), and deprecate the older less
flexible ones (they can be kept around for people with ancient
versions of gdb).

-Miles
--
Do not taunt Happy Fun Ball.

Re: better "pr" with gdb-6.4

[Nick Roberts]

 > FWIW, I find the current emacs debug macros quite hard to remember in
 > all their subtle variation.  It would be nice to have the "main"
 > macros like pr and xbacktrace work intuitively in more cases (which I
 > think includes accepting an argument for pr -- everytime I debug emacs
 > after a long absence, I seem to try giving pr an argument a few times
 > before I remember how it works... :-), and deprecate the older less
 > flexible ones (they can be kept around for people with ancient
 > versions of gdb).

Well GDB 6.3 isn't exactly ancient, but I think we can keep everybody
happy.  If we follow Kim's suggestion and modify Dan's function (GDB
doesn't understand elif):

set $argc = -1

define pr
  if ($argc == -1 || $argc == 0)
     set debug_print ($)
  else
    if ($argc == 1)
       set debug_print ($arg0)
    end
  end
end

then pr will work without an argument for pre 6.4 (as before) and with and
without an argument for 6.4.

We could also add more arguments as Dan suggests if people want, but note
that GDB's print command doesn't have this feature.

We need to keep pp for pre 6.4 (but those with 6.4 don't need to remember it!).

Nick

Re: better "pr" with gdb-6.4

[Nick Roberts]

 > > Most Emacs users/developers probably don't have GDB 6.4 so you would at
 > > least need to give your function a different name.
 > 
 > Perhaps, for portability, could .gdbinit do something like
 > globally:
 >  set $argc = -1
 > and then the pp functions could test if $argc >= 0 to 
 > recognize GDB 6.4 ?

Yes, that seems to work.

 > > I have a couple of other functions that just work when the selected frame
 > > is Ffuncall, for printing all the argument names.  Are they generally
 > > useful?
 > 
 > Seems useful, but why have to functions which does the same thing?

Sorry I wasn't clear.  They're meant as alternatives.

 > Actually, it would alse be useful if you could enhance
 > xbacktrace to recognize when the current frame is Ffuncall and
 > print the args at that level  (maybe for other functions too).

But only some of the lisp backtrace appears as calls to Ffuncall (the
primitives?).  In the example that I gave, the lisp backtrace has two
levels:

Lisp Backtrace:
"load"
"normal-top-level"

but the C backtrace has only one call to Ffuncall (for load):

(gdb) bt
#0  Fload (file=140229683, noerror=137853993, nomessage=137853993,
    nosuffix=137853993, must_suffix=137853945) at lread.c:682
#1  0x0818cd1b in Ffuncall (nargs=5, args=0xfef0da20) at eval.c:2893
#2  0x081c0dd6 in Fbyte_code (bytestr=137297859, vector=137298020, maxdepth=48)
    at bytecode.c:694
#3  0x0818d3e7 in funcall_lambda (fun=137297836, nargs=0,
    arg_vector=0xfef0db90) at eval.c:3066
#4  0x0818d057 in apply_lambda (fun=137297836, args=137853945, eval_flag=1)
    at eval.c:2988
#5  0x0818c0bc in Feval (form=139389765) at eval.c:2261
#6  0x08111668 in top_level_2 () at keyboard.c:1332
#7  0x0818ab24 in internal_condition_case (bfun=0x8111654 <top_level_2>,
    handlers=137897729, hfun=0x811130f <cmd_error>) at eval.c:1465
#8  0x08111698 in top_level_1 () at keyboard.c:1340
#9  0x0818a5b6 in internal_catch (tag=137893985, func=0x811166d <top_level_1>,
    arg=137853945) at eval.c:1211
#10 0x081115d3 in command_loop () at keyboard.c:1297
#11 0x0811108e in recursive_edit_1 () at keyboard.c:995
#12 0x081111cf in Frecursive_edit () at keyboard.c:1056
#13 0x0810faac in main (argc=2, argv=0xfef0e2a4) at emacs.c:1789

Nick

Re: better "pr" with gdb-6.4

[Kim F. Storm]

Nick Roberts <nickrob@snap.net.nz> writes:

> Sorry I wasn't clear.  They're meant as alternatives.

Ok, but I would like ppargs to print a short form like this:
(load "..." t t t)

>
>  > Actually, it would alse be useful if you could enhance
>  > xbacktrace to recognize when the current frame is Ffuncall and
>  > print the args at that level  (maybe for other functions too).
>
> But only some of the lisp backtrace appears as calls to Ffuncall (the
> primitives?).  In the example that I gave, the lisp backtrace has two
> levels:
>
> Lisp Backtrace:
> "load"
> "normal-top-level"
>
> but the C backtrace has only one call to Ffuncall (for load):

Is it possible to write a macro that would traverse up the C stack and do
something sensible for "known functions" like Ffuncall and Feval.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: better "pr" with gdb-6.4

[Nick Roberts]

 > Ok, but I would like ppargs to print a short form like this:
 > (load "..." t t t)

The problem is that GDB's output is line buffered so output isn't flushed
until a newline is sent.  This is the also true for the existing command
pp1.  However such commands do work with GDB within Emacs.  For that case
this should work:

define ppargs
  set $i = nargs
  printf "("
  while $i
    set $index = nargs - $i
    pp2 args[$index]
    set $i = $i - 1
    if $i
      printf " "
    end
  end
  printf ")\n"
end

 > Is it possible to write a macro that would traverse up the C stack and do
 > something sensible for "known functions" like Ffuncall and Feval.

I think it is possible.  I'll try to work something out.

Nick

Re: better "pr" with gdb-6.4

[Andreas Schwab]

Nick Roberts <nickrob@snap.net.nz> writes:

> But only some of the lisp backtrace appears as calls to Ffuncall (the
> primitives?).  In the example that I gave, the lisp backtrace has two
> levels:
>
> Lisp Backtrace:
> "load"
> "normal-top-level"
>
> but the C backtrace has only one call to Ffuncall (for load):

The other function is called via Feval.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."