From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8477 invoked by alias); 5 Dec 2008 18:43:41 -0000 Received: (qmail 8462 invoked by uid 22791); 5 Dec 2008 18:43:39 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate2.de.ibm.com (HELO mtagate2.de.ibm.com) (195.212.17.162) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 05 Dec 2008 18:42:49 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.13.1/8.13.1) with ESMTP id mB5Igk4R013426 for ; Fri, 5 Dec 2008 18:42:46 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mB5IgkIg3752056 for ; Fri, 5 Dec 2008 19:42:46 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id mB5Igj26021689 for ; Fri, 5 Dec 2008 19:42:46 +0100 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id mB5IgjF3021686; Fri, 5 Dec 2008 19:42:45 +0100 Message-Id: <200812051842.mB5IgjF3021686@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Fri, 5 Dec 2008 19:42:45 +0100 Subject: Re: Get rid of stop_pc (was: [RFA] dummy frame handling cleanup, plus inferior fun call signal handling improvement) To: pedro@codesourcery.com (Pedro Alves) Date: Fri, 05 Dec 2008 18:43:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org, dje@google.com (Doug Evans) In-Reply-To: <200812050115.30692.pedro@codesourcery.com> from "Pedro Alves" at Dec 05, 2008 01:15:30 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-12/txt/msg00099.txt.bz2 Pedro Alves wrote: > > > > > > > > (gdb) set $pc = 0xf00 > > > > (gdb) call func() > > > > > > Huh. But that case is in fact *broken*, because GDB will use stop_pc > > > incorrectly: for example, the check whether we are about to continue > > > at a breakpoint will look at stop_pc, but then continue at $pc. > > > > This one I believe was the original intention. The rationale being > > that you'd not want to hit a breakpoint again at stop_pc (0x1234), > > because there's where you stopped; but, you'd want to hit a a breakpoint > > at 0xf00, sort of like jump *$pc hits a breakpoint at $pc. > > > > Note, I'm not saying I agree with this. I did say that probably nobody > > would notice if we got rid of stop_pc. OK, I see. This is a valid use case, and it may make sense to keep it. However, as you point out, to make this really work as intended, we'd have make stop_pc a per-thread variable. And even in that case, the uses of stop_pc in step_1 and step_once seem invalid to me. > > > It seems to me just about every current user of stop_pc *really* wants > > > to look at regcache_read_pc (get_current_regcache ()) ... > > Is using read_pc instead OK with you? It's what I had written already. I guess so; longer term read_pc should probably die, but for now it's not really worse than the alternative. > @@ -3705,6 +3706,7 @@ handle_step_into_function (struct execut > { > struct symtab *s; > struct symtab_and_line stop_func_sal, sr_sal; > + CORE_ADDR stop_pc = read_pc (); > > s = find_pc_symtab (stop_pc); > if (s && s->language != language_asm) > @@ -3781,6 +3783,7 @@ handle_step_into_function_backward (stru > { > struct symtab *s; > struct symtab_and_line stop_func_sal, sr_sal; > + CORE_ADDR stop_pc = read_pc (); > > s = find_pc_symtab (stop_pc); > if (s && s->language != language_asm) These could probably receive the stop_pc from handle_inferior_event instead of recomputing it. > @@ -4283,7 +4286,7 @@ Further execution is probably impossible > if (tp->stop_step > && frame_id_eq (tp->step_frame_id, > get_frame_id (get_current_frame ())) > - && step_start_function == find_pc_function (stop_pc)) > + && step_start_function == find_pc_function (read_pc ())) > source_flag = SRC_LINE; /* finished step, just print source line */ > else > source_flag = SRC_AND_LOC; /* print location and source line */ As Andrew's comment notes, the function comparison should be redundant these days as it is already implied in the frame-ID comparison. > @@ -1149,7 +1149,7 @@ signal_command (char *signum_exp, int fr > FIXME: Neither should "signal foo" but when I tried passing > (CORE_ADDR)-1 unconditionally I got a testsuite failure which I haven't > tried to track down yet. */ > - proceed (oursig == TARGET_SIGNAL_0 ? (CORE_ADDR) -1 : stop_pc, oursig, 0); > + proceed (oursig == TARGET_SIGNAL_0 ? (CORE_ADDR) -1 : read_pc (), oursig, 0); > } > > /* Proceed until we reach a different source line with pc greater than Dan wanted to get rid of this use of stop_pc anyway, see: http://sourceware.org/ml/gdb-patches/2008-08/msg00651.html > @@ -1585,8 +1585,7 @@ program_info (char *args, int from_tty) > stat = bpstat_num (&bs, &num); > > target_files_info (); > - printf_filtered (_("Program stopped at %s.\n"), > - hex_string ((unsigned long) stop_pc)); > + printf_filtered (_("Program stopped at %s.\n"), paddr_nz (read_pc ())); > if (tp->stop_step) > printf_filtered (_("It stopped after being stepped.\n")); > else if (stat != 0) If we keep a tp->stop_pc, this place should also make use of it; otherwise the message isn't really valid (and not very useful: if it always just prints $pc, it would be redundant with the other commands to do so ...). Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com