From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1964 invoked by alias); 16 Apr 2003 01:35:43 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 1955 invoked from network); 16 Apr 2003 01:35:43 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 16 Apr 2003 01:35:43 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h3G1ZgD28182 for ; Tue, 15 Apr 2003 21:35:43 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h3G1Zgq17790; Tue, 15 Apr 2003 21:35:42 -0400 Received: from localhost.redhat.com (romulus-int.sfbay.redhat.com [172.16.27.46]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h3G1Zfg16594; Tue, 15 Apr 2003 21:35:41 -0400 Received: by localhost.redhat.com (Postfix, from userid 469) id D5EC72C441; Tue, 15 Apr 2003 21:40:08 -0400 (EDT) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16028.46200.713351.766037@localhost.redhat.com> Date: Wed, 16 Apr 2003 01:35:00 -0000 To: "J. Johnston" Cc: Andrew Cagney , Elena Zannoni , gdb@sources.redhat.com Subject: Re: prev_pc problem on ia64 In-Reply-To: <3E9C9E1B.4040400@redhat.com> References: <3E973FEB.1090500@redhat.com> <16027.6227.694651.833559@localhost.redhat.com> <3E9C8262.8070401@redhat.com> <3E9C9E1B.4040400@redhat.com> X-SW-Source: 2003-04/txt/msg00146.txt.bz2 J. Johnston writes: > Andrew Cagney wrote: > > (I'll ignore the debug info :-) > > > >> > Same function compiled for i686: > >> > > Special opcode 76: advance Address by 5 to 0x804839e and Line > >> by 1 to 31 > >> > Special opcode 230: advance Address by 16 to 0x80483ae and Line > >> by 1 to 32 > >> > Special opcode 146: advance Address by 10 to 0x80483b8 and Line > >> by 1 to 33 > >> > Special opcode 160: advance Address by 11 to 0x80483c3 and Line > >> by 1 to 34 > >> > > I have a patch whereby I reset prev_pc in > >> infrun.c:init_execution_control_state(): > >> > > if (prev_pc != 0) > >> > prev_pc = read_pc (); > >> > > prior to setting the ecs->sal. This works for me in both > >> scenarios. The check for > >> > 0 was needed because I get a failure on the ia64 trying to read the > >> pc too early when > >> > the psr register was invalid. > >> > > >> maybe read_pc should return an error code? Ah wait, it errors out, so > >> you should encapsulate that in a catch_errors(). > > > > > > The `prev_pc != 0' test is definitly wrong - that will only work when > > GDB first starts. Provided the target_has_execution (?), there > > shouldn't be an error (if there is, GDB's in bad shape :-), so the > > change should always assign a value to prev_pc and, conditional on > > target_has_execution, use the value of read_pc(). > > > > I tried to use target_has_execution but that did not work. The error > I get is that the process does not exist. The read_pc() routine for the ia64 is doing > a read_register_pid() and it appears that the inferior_ptid is not set up > at a time when target_has_execution is set to true. target_has_execution doesn't mean that the target is executing. It is a total misnomer to indicate that the gdb target stratum is capable of execution. I think what you want is target_has_registers. elena > > Does this observation seem reasonable? > > > I'm also left wondering if the prev_func_name assignment in: > > > >> static void > >> stop_stepping (struct execution_control_state *ecs) > >> { > >> if (target_has_execution) > >> { > >> /* Assuming the inferior still exists, set these up for next > >> time, just like we did above if we didn't break out of the > >> loop. */ > >> prev_pc = read_pc (); > >> prev_func_name = ecs->stop_func_name; > >> } > >> > >> /* Let callers know we don't want to wait for the inferior anymore. */ > >> ecs->wait_some_more = 0; > >> } > > > > > > should also be moved to init_execution_control_state, and both of those > > assignments should be deleted. > > > > Is it possible to move both of these into the ECS state? > > > >> please post the patch to gdb-patches. It's hard to judge, like this. > > > > > > Yes. > > > > Andrew > > > > >