path: root/gdb/gdb.ideas

BABYL OPTIONS:
Version: 5
Labels:
Note:   This is the header of an rmail file.
Note:   If you are seeing it in rmail,
Note:    it means the file has no messages in it.

From: mly@MICHAEL.AI.MIT.EDU (Richard Mlynarik)
To: rms@prep.ai.mit.edu
Subject: gdb suggestions (from hpux cdb)
Reply-To: mly-prep@prep.ai.mit.edu

"find-bug" command says "I can see the problem, but it will do you
good to find it yourself"

The gdb manual should explicitly state that gdb has no control over
forked (or execed or whatever) subprocesses.

I'd still like it if "delete" said what it had done.


Date: Tuesday, 13 May 1986, 00:40-EDT
From: <rms@LMI-ANGEL>
Sender: JC@LMI-ANGEL
Subject: interesting sdb features
To: rms@angel

output format p = pointer to procedure.

foo/x or foo/4x uses size of foo as size to print.

foo[1;4] to get elements 1 thru 4.

Continue to specified line number.

Interactively delete all breakpoints (asking about each one).



Command to write backtrace into a file, or even better to duplicate all
output to a file.  This could work by playing with descriptor 1,
making it a pipe to `tee'.  The original descriptor 1 is saved and
this mode can be turned off by putting it back.
  Date: Wed, 18 Feb 87 15:37:14 EST
  From: rms (Richard M. Stallman)
  Message-Id: <8702182037.AA16492@prep.ai.mit.edu>
  To: mly-prep@prep.ai.mit.edu
  In-Reply-To: <8702181913.AA16118@prep.ai.mit.edu>
  Subject: gdb "photo" command

  I don't think all this is worth the trouble to do now,
  because the right way to do it on TRIX is totally different
  and much easier.


Commands to enable and disable the autodisplays.  Associate
autodisplays with breakpoints perhaps, so they only display
at those breakpoints; this is easier than using breakpoint commands.

Remember how each breakpoint's position was specified.
Have command to reread symbol table and respecify each
breakpoint using same args (line number or function name) as before.

Have way to proceed process in background so that can then suspend
gdb but have subprocess continue


Date: Fri, 24 Jul 87 21:30:25 EDT
From: phr@PREP.AI.MIT.EDU (Paul Rubin)
To: bug-gdb@PREP.AI.MIT.EDU

After rereading the symbol table when user runs the "symbol-file"
command, when GDB notices that some of the source files are newer
it should reload them rather than just printing a message saying
they are newer.



Message-Id: <8704171941.AA05045@orville.arpa>
To: mly@prep.ai.mit.edu
Cc: raible@orville.arpa, fouts@orville.arpa, creon@orville.arpa
Subject: gdb hack/questions, etc
Date: 17 Apr 87 11:41:42 PST (Fri)
From: raible@orville.arpa


A couple of things:

1) Will gdb ever get dbx-sytly tracing?  Wouldn't it be fairly easy to add?

2) How about an xemacs gdb mode which has various windows, perhaps using
   terminal.el for generality?

3) Any word about that stupid IRIS SIGIOT problem?  Do you know of anyone
   else who has gotten IRIS subprocesses to work more reliably?

4) Below is a hack adapted from ramsdell@linus.uucp which can be pretty
   useful in gdb.  Instead of using gdb to patch extensive changes to a
   particular function, you can do the following (assuming the 50 lines
   of code below is part of your executable):
	1) create a new file (foo.c) containing the new function
	2) run cc -c foo.c
	3) in gdb, and patch in the new function as follows:

(gdb) info breakpoints
/* Load in the new object code... */
#1   y  0x00000125  in main (dyn.c line 46)
	break only if $function = funload ("foo"), 1
	silent
	echo new code for func ($function) initialized\n
	cont

/* ...and use it instead of the old code. */
#2   y  0x000001c2  in func (dyn.c line 59)
	break only if $ret = $function (a), 1
	silent
	set a = $ret
	j 60		/* func has a return on line 60 */

	This is more complicated than it has to be because of 2 bugs in v2.1:
	1) function calls in a breakpoint command list seem to abort
	   the execution of the rest of the command list.  This is
	   why all function calls are in the conditional part.
	   (gdb reference manual section 5.5).

	2) A 'return' in a command list also aborts the execution, and
	   in addition, prompts you for a y/n.
	   (gdb reference manual section 11.1).

	On the other hand, after doing 'cc -c foo.c' (which is pretty fast),
	you can simply rerun your program to check out the changes.
	This can be a big win!

The code for this is included below (compile with cc -g):
========================================================

#include <stdio.h>
#include <a.out.h>

typedef int (*intfun)();
char *myname;

intfun funload (filename)	/* Dynamically load 1st function from a .o */
     char *filename;
{
  int fd, size;
  struct exec hdr;
  char buf[100];
  intfun fun;

  /* -A => incremental loading - use dyn as the base symbol table
     -T => set the text segment origin to the following hex address
     -N => magic number 407 (text not read-only)
  */
  sprintf (buf, "ld -A %s -T %x -N %s.o -o %s -lc",
	   myname, sbrk (0), filename, filename);

  /* NOTE: if anything mallocs space between here and below, this will fail */
  system (buf);

  fd = open (filename, 0);
  read (fd, &hdr, sizeof(hdr));
  size = hdr.a_text + hdr.a_data + hdr.a_bss;

  if ((fun = (intfun) sbrk (size)) < 0)
    printf ("Couldn't find the space"), exit();

  read (fd, fun, size);		/* Load code. */
  /* NOTE: if anything mallocs space between here and above, this will fail */

  close (fd);
  return ((intfun) fun);
}
  
main (argc, argv)
     char **argv;
{
  intfun fun1, fun2;

  myname = *argv;

  fun1 = funload("fun1");
  printf ("The answer is %d.\n", (*fun1)(11) );

  fun2 = funload("fun2");
  printf ("The answer is %d.\n", (*fun2)() );
}
1,edited,,
Received: by PREP.AI.MIT.EDU; Tue, 16 Jun 87 03:12:54 EDT
Date: Tue, 16 Jun 87 03:12:54 EDT
From: rms (Richard M. Stallman)
Message-Id: <8706160712.AA07910@prep.ai.mit.edu>
To: rms
Subject: GDB ideas

*** EOOH ***
Date: Tue, 16 Jun 87 03:12:54 EDT
From: rms (Richard M. Stallman)
To: rms
Subject: GDB ideas

* Within a user-defined command, have local convenience variables,
local functions, local defined commands.

** Optionally echo commands within a user-defined command.

** Optionally record all user-typed commands in a log file.
Optionally record GDB output there too, marked as output so it
will not be executed if replayed.

* Execution commands

** Step until next branch, or next call.
(finish is step until next return).

step branch
or should it be
continue branch

** Stop on any branch, call or return
affecting ordinary step and continue commands.

stop branch

** Trace all branches, calls, returns.
This could be done by stopping on those events
and having a continue command to be executed after.

stop branch
commands branch
continue
end

** Commands to continue or step without any display after stop.
These may be useful in user-defined commands.

Have one prefix command that does this, modifying whatever other
command you might use.  For example,

silent step 5
silent cont

** Clear all breakpoint ignore-counts when inferior exits or is killed.

** Trace changes to a location (watchpoint).
Enable and disable them.

** Info command to show command-line for running the program.

* Auto-display

** Enable and disable display expressions.
Allow syntax 1d, 2d, etc. in enable, disable and delete commands.
Then there is no more need for an undisplay command.

** Displaying an auto variable should not do it in the wrong stack frame.
Either it should search for the proper stack frame to apply to
or it should deactivate itself when in the wrong frame.

* Printing

** Print an address as <file:line>+offset.

** Abbreviate initial whitespace modulo 16.

** p/x of an array should print each element with /x.

** Change the stack scan so that it has a more general idea
of what info is needed to describe a frame fully.

* Expressions

** Array slices.  Can replace @.

** %name for use of symbol names containing funny characters.

** User-defined convenience functions that can appear in expressions.

** Expression syntax to convert line number to address.

** Expression syntax to specify a name scope with an address, line number
or frame number.

Use the line number by itself, or an address with *, just as in b or l cmd:
38:foo or *0x40a:foo.  No good; the latter would be parsed as
*(0x40a:foo).

** Expression syntax to convert a frame number to its pc.
Perhaps unary %.

* Possible bugs

** Does set $pc= cause the current scope to be recalculated?
It should.

1,,
Received: by PREP.AI.MIT.EDU; Wed, 17 Jun 87 09:59:37 EDT
From: phr@ATHENA.MIT.EDU
Received: by ATHENA (5.45/4.7)
	id AA09084; Wed, 17 Jun 87 08:54:36 EDT
Received: by ORPHEUS.MIT.EDU (5.45/4.7) id AA02565; Wed, 17 Jun 87 08:54:29 EDT
Date: Wed, 17 Jun 87 08:54:29 EDT
Message-Id: <8706171254.AA02565@ORPHEUS.MIT.EDU>
To: rms@prep.ai.mit.edu
Subject: gdb suggestion
Status: RO

*** EOOH ***
From: phr@ATHENA.MIT.EDU
Date: Wed, 17 Jun 87 08:54:29 EDT
To: rms@prep.ai.mit.edu
Subject: gdb suggestion

Completion of file and function names; e.g. typing
	break XWriteBi
prints
	No such symbol: XWriteBi.
	Setting default command to "break XWriteBitmapFile"
so you can set a break at XWriteBitmapFile by hitting return a second
time.  Other interfaces ("complete to XWriteBitmapFile? (y/n)")
are also possible.


1,edited,,
Received: by PREP.AI.MIT.EDU; Wed, 24 Sep 86 16:33:11 EDT
Date: Wed, 24 Sep 86 16:33:11 EDT
From: mly (Richard Mlynarik)
Message-Id: <8609242033.AA11520@prep.ai.mit.edu>
To: rms
Cc: mly-prep
Subject: gdb gripes/suggestions/requests

*** EOOH ***
Date: Wed, 24 Sep 86 16:33:11 EDT
From: mly (Richard Mlynarik)
To: rms
Cc: mly-prep
Subject: gdb gripes/suggestions/requests

If would be really nice to have some way to do conditionals in user
  commands -- though this is really stretching the functionality of
  gdb a little too much, perhaps.  (see ~mly/e/.gdbint for some of
  the contortions I go through with || to get conditional
  evaluation...)

A -real- win wuold be some way to execute until he next function-call
  (like c-d in the cadr debugger)  This would even be useful if it
  were rather slow -- it would probably be faster than setting
  temporary breakpoints in all the functions which might be called,
  and would certainly be faster than "step"ping one's way until a
  funcall happened.

"info source" should mention what the directory search-path is (ie
  what "info dir" says) and in which directory it found each of the
  source files (and which source files it cannot locate in the
  search-path)


1,,
Received: by xcssun.Berkeley.EDU (5.57/1.25)
	id AA22869; Thu, 22 Oct 87 09:50:30 PDT
Received: from prep.ai.mit.edu by wheaties.ai.mit.edu; Thu, 22 Oct 87 12:17:59 EDT
Received: by PREP.AI.MIT.EDU; Thu, 22 Oct 87 12:21:00 EDT
Received: from pp.mcc.com by MCC.COM with TCP; Thu 22 Oct 87 10:54:41-CDT
Posted-Date: Thu, 22 Oct 87 10:55:13 CDT
Received: from big-d.aca.mcc.com by pp.mcc.com (4.12/KA70822) 
	id AA16571; Thu, 22 Oct 87 10:55:19 cdt
Return-Path: <tiemann@big-d.aca.mcc.com>
Received: by big-d.aca.mcc.com (3.2/KA70106)
	id AA04247; Thu, 22 Oct 87 10:55:13 CDT
Date: Thu, 22 Oct 87 10:55:13 CDT
From: tiemann%pp.mcc.com@mcc.com (Michael Tiemann)
Message-Id: <8710221555.AA04247@big-d.aca.mcc.com>
To: bug-gdb@prep.ai.mit.edu
Subject: expanding file names

*** EOOH ***
Posted-Date: Thu, 22 Oct 87 10:55:13 CDT
Return-Path: <tiemann@big-d.aca.mcc.com>
Date: Thu, 22 Oct 87 10:55:13 CDT
From: tiemann%pp.mcc.com@mcc.com (Michael Tiemann)
To: bug-gdb@prep.ai.mit.edu
Subject: expanding file names

When running a program, gdb thoughtfully passes the argument list
through the shell, expanding files and environment variables as
needed.  It would be nice if the same facility were added to the
command which adds directories to search paths.  For example, it would
be nice to say "dir ~/foo" .

Michael


1,,
Received: by xcssun.Berkeley.EDU (5.57/1.25)
	id AA25075; Fri, 23 Oct 87 10:42:52 PDT
Received: from prep.ai.mit.edu by wheaties.ai.mit.edu; Fri, 23 Oct 87 13:39:37 EDT
Received: by PREP.AI.MIT.EDU; Fri, 23 Oct 87 13:42:53 EDT
Received: from relay2.cs.net by RELAY.CS.NET id ac11193; 23 Oct 87 13:03 EDT
Received: from umb.edu by RELAY.CS.NET id ac05949; 23 Oct 87 13:01 EDT
Received: by umb.umb.edu; Fri, 23 Oct 87 10:18:40 EDT
Received: by ileaf.uucp (1.1/SMI-3.0DEV3)
	id AA00599; Wed, 21 Oct 87 10:56:52 EDT
Received: from marvin.io.uucp by io.uucp (1.1/SMI-3.0DEV3)
	id AA01359; Wed, 21 Oct 87 10:58:45 EDT
Received: by marvin.io.uucp (3.2/SMI-3.2)
	id AA00334; Wed, 21 Oct 87 11:02:20 EDT
Date: Wed, 21 Oct 87 11:02:20 EDT
From: Mark Dionne <io!marvin!md%ileaf.uucp%umb.umb.edu@relay.cs.net>
Message-Id: <8710211502.AA00334@marvin.io.uucp>
To: ileaf!umb!bug-gdb@prep.ai.mit.edu
Subject: gdb bug

*** EOOH ***
Date: Wed, 21 Oct 87 11:02:20 EDT
From: Mark Dionne <io!marvin!md%ileaf.uucp%umb.umb.edu@relay.cs.net>
To: ileaf!umb!bug-gdb@prep.ai.mit.edu
Subject: gdb bug

The /FMT and @ options of the "print" command seem to interact
in GDB 2.1. For example:

(gdb) p ($cmpn.buf[-1])@($cmpn.gapb - $cmpn.buf + 1)
$17 = {-16383, -24285, 55, 27944, -24285, -24285, 55, 28010, -24285,
-24285, 55, 28076, -24285, -24285, 55, 28142, -24285}
(gdb) p/x ($cmpn.buf[-1])@($cmpn.gapb - $cmpn.buf + 1)
$18 = 0xc001

I guess I see what's happening: the /x is applying to the whole
array rather than to the individual elements. Feature or bug?

	...!harvard!umb!ileaf!md	Mark Dionne, Interleaf
	  ...!sun!sunne!ileaf!md	Ten Canal Park, Cambridge, MA 02141
					(617) 577-9813 x5551



1,,
Received: by PREP.AI.MIT.EDU; Sun, 6 Sep 87 14:27:19 EDT
Message-Id: <8709061827.AA18170@prep.ai.mit.edu>
Received: from relay2.cs.net by RELAY.CS.NET id af03990; 6 Sep 87 14:22 EDT
Received: from umb.edu by RELAY.CS.NET id ab03029; 6 Sep 87 14:16 EDT
Received: by umb.umb.edu; Sun, 6 Sep 87 12:10:34 EDT
Date: Sun, 6 Sep 87 12:10:34 EDT
Received: by typo.umb.edu; Sun, 6 Sep 87 12:04:21 EDT
From: Robert Morris <ram%typo.umb.edu@RELAY.CS.NET>
To: bug-gdb@PREP.AI.MIT.EDU
Subject: convenient script

*** EOOH ***
Date: Sun, 6 Sep 87 12:10:34 EDT
From: Robert Morris <ram%typo.umb.edu@RELAY.CS.NET>
To: bug-gdb@PREP.AI.MIT.EDU
Subject: convenient script

I find it easier to maintain binaries on our heterogenous
network if I keep this trivial script in gdb source directory. Use it
if you want.


------------

#! /bin/csh -f
#	SETUP
#	setup gdb files for presently known machines
#	ram@umb.edu 
#		(ram%umb.edu@relay.cs.net if you have an incomplete mailer)
#	or ...!harvard!umb!ram
#
#	e.g.     SETUP sun3
#	note that sunX means major release X of sun software, generally
#	sun3 at this writing (gnu 18.41)
#
#	note GDB with gnuemacs 18.41 is already configured for vaxen

#		Bob Morris, UMASS-Boston 9/6/87
switch ($1)
	case "sun2":
		;
	case "sun3" : 
		set cputype="m68k";
		set inittype="suninit";
		breaksw;
	default : 
		set cputype=$1;
		set inittype=$1init;
		breaksw;
endsw
echo \#include \"m-$1.h\" > param.h
echo \#include \"$cputype-pinsn.c\" > pinsn.c
ed initialize.h <<! >& /dev/null
/init.h/
c
#include "m-$inittype.h"
.
w
q
!




1,answered,,
Received: from prep.ai.mit.edu by wheaties.ai.mit.edu; Sat, 19 Dec 87 18:18:50 EST
Received: by PREP.AI.MIT.EDU; Sat, 19 Dec 87 18:24:38 EST
Received: from big-d.aca.mcc.com by MCC.COM with TCP; Sat 19 Dec 87 17:19:48-CST
Date: Sat, 19 Dec 87 17:19:41 CST
From: tiemann@mcc.com (Michael Tiemann)
Posted-Date: Sat, 19 Dec 87 17:19:41 CST
Message-Id: <8712192319.AA26775@big-d.aca.mcc.com>
Received: by big-d.aca.mcc.com (3.2/ACA-V2.1) 
	id AA26775; Sat, 19 Dec 87 17:19:41 CST
To: rms@prep.ai.mit.edu
Subject: gdb

*** EOOH ***
Date: Sat, 19 Dec 87 17:19:41 CST
From: tiemann@mcc.com (Michael Tiemann)
Posted-Date: Sat, 19 Dec 87 17:19:41 CST
To: rms@prep.ai.mit.edu
Subject: gdb

file values.c, function unpack_field_as_long:

  val &= (1 << bitsize) - 1;

This is not as machine independent as it could be.  If you feel like
fixing this potential problem, there are many other instances to worry
about.

Michael


1,,
Received: by xcssun.Berkeley.EDU (5.57/1.25)
	id AA04771; Thu, 20 Aug 87 22:33:25 PDT
Received: from [128.52.22.14] by ucbvax.Berkeley.EDU (5.58/1.27)
	id AA07119; Thu, 20 Aug 87 00:37:04 PDT
Received: by PREP.AI.MIT.EDU; Thu, 20 Aug 87 03:37:35 EDT
Date: Thu, 20 Aug 87 03:37:35 EDT
From: rms@prep.ai.mit.edu (Richard M. Stallman)
Message-Id: <8708200737.AA15589@prep.ai.mit.edu>
To: rms@prep.ai.mit.edu
Subject: GDB changes for next version

*** EOOH ***
Date: Thu, 20 Aug 87 03:37:35 EDT
From: rms@prep.ai.mit.edu (Richard M. Stallman)
To: rms@prep.ai.mit.edu
Subject: GDB changes for next version

1. Use links, rather than editing some files, to configure it.

2. Can misc functions eval as their addresses rather than as
 a char in that address?  Is this reasonable in all cases
 given that non-functions cannot be distinguished
 and that you might use the result in various ways (arithmetic, etc.).


1,,
Received: by xcssun.Berkeley.EDU (5.57/1.25)
	id AA09136; Sat, 29 Aug 87 02:20:15 PDT
Received: from PREP.AI.MIT.EDU by ucbvax.Berkeley.EDU (5.58/1.27)
	id AA26072; Sat, 29 Aug 87 02:21:51 PDT
Received: by PREP.AI.MIT.EDU; Sat, 29 Aug 87 05:22:30 EDT
Received: by RUTGERS.EDU (5.54/1.14) with UUCP 
	id AA22247; Sat, 29 Aug 87 05:21:13 EDT
Received: from sequent.UUCP by spool.wisc.edu; Sat, 29 Aug 87 04:18:41 CDT
Received: from reed.UUCP by ogcvax.OGC.EDU (5.51/OGC_4.8)
		id AA08044; Fri, 28 Aug 87 20:06:41 PDT
Received: by reed.UUCP (5.51/5.17)
	id AA05059; Fri, 28 Aug 87 19:19:15 PDT
From: uwvax!sequent!ogcvax!reed!keith@rutgers.edu (Keith Packard)
Message-Id: <8708290219.AA05059@reed.UUCP>
To: rms@prep.ai.mit.edu
Subject: Re: GDB 
In-Reply-To: Your message of Thu, 20 Aug 87 03:39:37 EDT.
             <8708200735.AA26546@EDDIE.MIT.EDU> 
Date: Fri, 28 Aug 87 19:19:13 PDT

*** EOOH ***
From: uwvax!sequent!ogcvax!reed!keith@rutgers.edu (Keith Packard)
To: rms@prep.ai.mit.edu
Subject: Re: GDB 
In-Reply-To: Your message of Thu, 20 Aug 87 03:39:37 EDT.
             <8708200735.AA26546@EDDIE.MIT.EDU> 
Date: Fri, 28 Aug 87 19:19:13 PDT


Here is a simple test program for exibiting the trouble with signals:

-----
# include	<signal.h>

main ()
{
	int	handle ();
	int	i;
	signal (SIGALRM, handle);
	alarm (5);
	for (i = 0; i < 100000; i++)
		printf ("%d\n", i);
}

handle ()
{
	printf ("signal!\n");
	alarm (5);
}
-----

To demonstrate the problem, simply place a breakpoint before the call to
alarm and then start stepping through the program:

(gdb) break 7
(gdb) step
...
...

Eventually, the alarm call occurs and the program ends up in some
signal handling code -- unfortuantely a machine dependent location.  At this
point, because the fp has moved out of the current function (in fact on
many machines the frame is not in a consistent state at this point) gdb
assumes that a new function has started and suspends execution with another
prompt.

A reasonable solution would be to have gdb insert a breakpoint at the
expected signal return address and continue to that breakpoint -- I've
implemented this and found that it works.  There is, however, one nasty
problem -- longjmp around the suspended frame and the breakpoint is not hit
at the expected time.

Have fun...

keith packard

tektronix!reed!keith


1,,
Received: by xcssun.Berkeley.EDU (5.57/1.25)
	id AA09143; Sat, 29 Aug 87 02:24:58 PDT
Received: by neptune.Berkeley.EDU (5.57/1.25)
	id AA03738; Sat, 29 Aug 87 02:24:50 PDT
Date: Sat, 29 Aug 87 02:24:50 PDT
From: rms@neptune.berkeley.edu (Richard Stallman)
Message-Id: <8708290924.AA03738@neptune.Berkeley.EDU>
To: rms@neptune.Berkeley.EDU
Subject: GDB bug
Reply-To: rms@prep.ai.mit.edu

*** EOOH ***
Date: Sat, 29 Aug 87 02:24:50 PDT
From: rms@neptune.berkeley.edu (Richard Stallman)
To: rms@neptune.Berkeley.EDU
Subject: GDB bug
Reply-To: rms@prep.ai.mit.edu

Is there any way to make GDB, when stepping across a function call,
notice any attempt to longjump out of that call?
Perhaps an implicit breakpoint at longjump.
If longjump is called, find the pc in the jmp_buf and put
a self-deleting breakpoint there.


1,,
Received: by xcssun.Berkeley.EDU (5.57/1.25)
	id AA07976; Fri, 28 Aug 87 09:26:12 PDT
Received: from PREP.AI.MIT.EDU by ucbvax.Berkeley.EDU (5.58/1.27)
	id AA03230; Fri, 28 Aug 87 09:28:04 PDT
Received: by PREP.AI.MIT.EDU; Fri, 28 Aug 87 12:28:43 EDT
Date: Fri, 28 Aug 87 12:28:43 EDT
From: phr@prep.ai.mit.edu (Paul Rubin)
Message-Id: <8708281628.AA09926@prep.ai.mit.edu>
To: rms@prep.ai.mit.edu
Subject: gdb suggestions

*** EOOH ***
Date: Fri, 28 Aug 87 12:28:43 EDT
From: phr@prep.ai.mit.edu (Paul Rubin)
To: rms@prep.ai.mit.edu
Subject: gdb suggestions

1. I wish gdb had a command to re-read the sources so that I can edit
the program and recompile it without having to kill and restart gdb.

2. Would be nice if gdb could somehow connect the subprocess's tty channels
to a pty, so I can run gdb in an X window and the subprocess in a different
(xterm) window.

This might need hair to detect if the subprocess is running when you try
to examine variables, etc. and stop the subproc or report an error if it is.