From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4942 invoked by alias); 19 Nov 2001 20:55:31 -0000 Mailing-List: contact insight-help@sourceware.cygnus.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: insight-owner@sources.redhat.com Received: (qmail 4921 invoked from network); 19 Nov 2001 20:55:29 -0000 X-Authentication-Warning: makita.cygnus.com: keiths owned process doing -bs Date: Wed, 03 Oct 2001 11:09:00 -0000 From: Keith Seitz To: Grant Edwards cc: Subject: Re: No step button using insight w/ remote target. In-Reply-To: <20011119145348.A26837@visi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2001-q4/txt/msg00035.txt.bz2 On Mon, 19 Nov 2001, Grant Edwards wrote: > 829 if (target_has_execution && ! ptid_equal (inferior_ptid, null_ptid)) > Value returned is $3 = 1 > (gdb) print inferior_ptid > $4 = {pid = 0, lwp = 0, tid = 0} > (gdb) print null_ptid > $5 = {pid = 0, lwp = 0, tid = 0} > (gdb) print target_has_execution > No symbol "target_has_execution" in current context. > (gdb) > > "target_has_execution" is presumably a macro? Yes: #define target_has_execution \ (current_target.to_has_execution) > Anyway, inferior_ptid _is_ null_ptid, so that's probably the > issue. The "value returned" bit is from which I did a "finish" > to get back from ptid_equal(), IOW, ptid_equal() returned 1. I'm not so certain that there is something wrong with your stub. Let's back up a little and see if the ptid is ever created... If you step through remote_open_1, does the following line ever get executed? /* 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_ptid = pid_to_ptid (MAGIC_NULL_PID); Keith From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keith Seitz To: Grant Edwards Cc: Subject: Re: No step button using insight w/ remote target. Date: Mon, 19 Nov 2001 12:55:00 -0000 Message-ID: References: <20011119145348.A26837@visi.com> X-SW-Source: 2001-q4/msg00336.html Message-ID: <20011119125500.91mljf9-S93FMppAkDUqgnIfJ1FneQ-7R-HNhlZFLRs@z> On Mon, 19 Nov 2001, Grant Edwards wrote: > 829 if (target_has_execution && ! ptid_equal (inferior_ptid, null_ptid)) > Value returned is $3 = 1 > (gdb) print inferior_ptid > $4 = {pid = 0, lwp = 0, tid = 0} > (gdb) print null_ptid > $5 = {pid = 0, lwp = 0, tid = 0} > (gdb) print target_has_execution > No symbol "target_has_execution" in current context. > (gdb) > > "target_has_execution" is presumably a macro? Yes: #define target_has_execution \ (current_target.to_has_execution) > Anyway, inferior_ptid _is_ null_ptid, so that's probably the > issue. The "value returned" bit is from which I did a "finish" > to get back from ptid_equal(), IOW, ptid_equal() returned 1. I'm not so certain that there is something wrong with your stub. Let's back up a little and see if the ptid is ever created... If you step through remote_open_1, does the following line ever get executed? /* 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_ptid = pid_to_ptid (MAGIC_NULL_PID); Keith