* Insight debugging remote targets @ 2000-06-22 5:07 MWCruess 2000-06-22 6:04 ` Keith Seitz 2000-06-22 6:11 ` Fernando Nasser 0 siblings, 2 replies; 5+ messages in thread From: MWCruess @ 2000-06-22 5:07 UTC (permalink / raw) To: insight 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Insight debugging remote targets 2000-06-22 5:07 Insight debugging remote targets MWCruess @ 2000-06-22 6:04 ` Keith Seitz 2000-06-22 15:35 ` mwcruess 2000-06-22 6:11 ` Fernando Nasser 1 sibling, 1 reply; 5+ messages in thread From: Keith Seitz @ 2000-06-22 6:04 UTC (permalink / raw) To: MWCruess; +Cc: insight 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Insight debugging remote targets 2000-06-22 6:04 ` Keith Seitz @ 2000-06-22 15:35 ` mwcruess 2000-06-23 6:00 ` Keith Seitz 0 siblings, 1 reply; 5+ messages in thread From: mwcruess @ 2000-06-22 15:35 UTC (permalink / raw) To: Keith Seitz; +Cc: MWCruess, insight 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Insight debugging remote targets 2000-06-22 15:35 ` mwcruess @ 2000-06-23 6:00 ` Keith Seitz 0 siblings, 0 replies; 5+ messages in thread From: Keith Seitz @ 2000-06-23 6:00 UTC (permalink / raw) To: fnasser, jingham; +Cc: insight 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Insight debugging remote targets 2000-06-22 5:07 Insight debugging remote targets MWCruess 2000-06-22 6:04 ` Keith Seitz @ 2000-06-22 6:11 ` Fernando Nasser 1 sibling, 0 replies; 5+ messages in thread From: Fernando Nasser @ 2000-06-22 6:11 UTC (permalink / raw) To: MWCruess; +Cc: insight 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2000-06-23 6:00 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-06-22 5:07 Insight debugging remote targets MWCruess 2000-06-22 6:04 ` Keith Seitz 2000-06-22 15:35 ` mwcruess 2000-06-23 6:00 ` Keith Seitz 2000-06-22 6:11 ` Fernando Nasser
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).