Insight debugging remote targets

Insight debugging remote targets

[MWCruess]

Thanks for the help with the "silent exit" problem that I was having
a couple of weeks ago.   This is a back burner project for me, but
I have made some progress.  I have the evaluation boards for the
Motorola processor running connected to both Sparc and NT
systems.  The command line interface works, and I can download
and run programs.  The Insight GUI, however, seems to be confused.

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.

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.

I looked in the bug database and didn't see anything like this.

Thanks,
Michael

Re: Insight debugging remote targets

[Keith Seitz]

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

Re: Insight debugging remote targets

[Fernando Nasser]

MWCruess@cs.com wrote:
> 
> 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.
> 
The remote protocol creates a fake pid (MAGIC_NULL_PID) when you connect
to the target.  Look in remote.c.

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@cygnus.com
2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
Toronto, Ontario   M4P 2C9              Fax:  416-482-6299

Re: Insight debugging remote targets

[mwcruess]

Thanks for the information.  The code that I am
modifying uses monitor.c.  Around monitor.c line 2250
there is code:

  if (exec_bfd)
    write_pc (bfd_get_start_address (exec_bfd));

    inferior_pid = 0;       /* No process now */

I found that before a load, at monitor_wait(),
inferior_pid was 42000, after a load it was 0.
Clearly that's what the code above does, but nothing
was setting it back to 42000.  I commented out the
assignment to inferior_pid.  With this out, a "run" from the command
line produces a dialog box (on NT) that warns me that
a program is already being run.  If I tell it to go
ahead, everything seems to work.  The window controls
work also.  If I use the GUI alone, it seems to work
and I do not get a warning when I click on the run
button.

I looked at the file that you pointed me to and
I did not see you setting inferior_pid to 0 after
a load, and generic_load did not do it either, so
taking it out of monitor.c seemed OK (but the comment
that follows worries me).

Is this the right thing to do?

Thanks,
Michael 

Re: Insight debugging remote targets

[Keith Seitz]

mwcruess@cs.com wrote:
> 
> Thanks for the information.  The code that I am
> modifying uses monitor.c.  Around monitor.c line 2250
> there is code:
> 
>   if (exec_bfd)
>     write_pc (bfd_get_start_address (exec_bfd));
> 
>     inferior_pid = 0;       /* No process now */
> 

Hmmmm... I would guess that this is incorrect, but it looks like it has
been this way for some time. I am a little confused, though, since I
remember using Insight on several monitors: mon2000 (m32r) and picobug
(mcore).

How did it ever work? I see the same thing happen in dink32-rom.c,
m32r-rom.c, dve3900-rom.c, mon960-rom.c, and almost all remote targets
(remote-*.c).

Anyone remember how this is supposed to work?
Keith