From mboxrd@z Thu Jan  1 00:00:00 1970
From: Keith Seitz <kseitz@firetalk.com>
To: MWCruess@cs.com
Cc: insight@sourceware.cygnus.com
Subject: Re: Insight debugging remote targets
Date: Thu, 22 Jun 2000 06:04:00 -0000
Message-id: <39520ECE.79E7DADF@firetalk.com>
References: <6c.6d4c22.26835b76@cs.com>
X-SW-Source: 2000-q2/msg00309.html

MWCruess@cs.com wrote:
> 
> I can select a target, download a program, and set a breakpoint (e.g.
> at main).  When I click the 'run' button the program runs.  At this point
> the GUI says that the program has terminated  and the buttons for stepping
> are dimmed.   I can still type "step" in the command window, however.
> The program happily steps and the source window even displays the correct
> line in the program.  This happens both on 4.95 on Sparc and 5.0 on NT.

BTW, the run button will do all of these things for you, if you want it
to. Pop down the "More Options" frame in the Target Selection dialog to
see what it will do. If you're running a remote-like, monitor, or
simulator target, the default actions will be to attach to the target,
download, and continue execution (remote targets _never_ use "run").

> I poked around in the code for the source window in gdbtk, and I saw
> comment regarding the process ID of the inferior process having to be correct
> for the code to work.  Since operating in remote mode does not have an
> inferior process, I was wondering if this is related.

Tee hee. Gdb-ism. Take a look at one of the existing remote targets.
Here's a little excerpt from v850ice.c, which I wrote some time ago:

/* Code for opening a connection to the ICE.  */

static void
v850ice_open (name, from_tty)
     char *name;
     int from_tty;
{
  /* ... */
  /* Without this, some commands which require an active target (such as
kill)
     won't work.  This variable serves (at least) double duty as both
the pid
     of the target process (if it has such), and as a flag indicating
that a
     target is active.  These functions should be split out into
seperate
     variables, especially since GDB will someday have a notion of
debugging
     several processes.  */
  inferior_pid = 42000;
  /* ... */
}

This is hacky, but it's necessary. If you scan the sources, this is set
in several places, like monitor.c and remote.c, so it's not always
explicitly necessary to set it. If you're doing a new target/protocol,
you'll probably need to make sure that while there's a connection to an
inferior, inferior_pid is set. The "usual" pid for something that
doesn't really have a pid is 42000.

I would double-check that this is being set. You can do this easily
enough by entering "tk gdb_target_has_execution" into the console window
after you've attached to the target. If it returns zero, you know that
gdbtk doesn't think that the target is in an executable state. This proc
just checks gdb's internal variables, returning (target_has_execution &&
inferior_pid != 0).

If gdb_target_has_execution does return one, type "tk set
::gdb_running". If this is zero, that's a tougher one to figure out, and
I'd have to go digging through the sources a little before commenting.

Let us know what happens.
Keith