From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3967 invoked by alias); 19 Jan 2004 17:35:14 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 3941 invoked from network); 19 Jan 2004 17:35:13 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 19 Jan 2004 17:35:13 -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 i0JHZCl24789 for ; Mon, 19 Jan 2004 12:35:12 -0500 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 i0JHZCa30766 for ; Mon, 19 Jan 2004 12:35:12 -0500 Received: from localhost.localdomain (vpn50-57.rdu.redhat.com [172.16.50.57]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id i0JHZBR0020585 for ; Mon, 19 Jan 2004 12:35:12 -0500 Received: from saguaro (saguaro.lan [192.168.64.2]) by localhost.localdomain (8.12.10/8.12.10) with SMTP id i0JHZ6cG031927 for ; Mon, 19 Jan 2004 10:35:06 -0700 Date: Mon, 19 Jan 2004 17:35:00 -0000 From: Kevin Buettner To: gdb-patches@sources.redhat.com Subject: Re: [RFC] infrun.c: Fix infinite loop caused by breakpoint adjustment Message-Id: <20040119103506.70cd15fa@saguaro> In-Reply-To: <4001BA24.6090005@gnu.org> References: <1031218195400.ZM17244@localhost.localdomain> <4001BA24.6090005@gnu.org> Organization: Red Hat Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SW-Source: 2004-01/txt/msg00507.txt.bz2 On Sun, 11 Jan 2004 16:03:32 -0500 Andrew Cagney wrote: > > Any comments on the patch below? > > Can this paragraph (or something like it) should be included in the code > change? That way the reader will better understand exactly what goes > wrong and for which architecture. > > > It fixes an infinite loop caused by attempting to run to a location > > to which it's architecturally impossible to set a breakpoint at. (It's > > quite easy to reproduce this problem on FR-V. Just step into some > > library code which has been compiled with optimization.) Okay, here's what I committed: * infrun.c (step_into_function): Account for possible breakpoint adjustment when computing ``stop_func_start''. Index: infrun.c =================================================================== RCS file: /cvs/src/src/gdb/infrun.c,v retrieving revision 1.129 diff -u -p -r1.129 infrun.c --- infrun.c 19 Jan 2004 01:20:11 -0000 1.129 +++ infrun.c 19 Jan 2004 17:25:48 -0000 @@ -2757,6 +2757,29 @@ step_into_function (struct execution_con && ecs->sal.end < ecs->stop_func_end) ecs->stop_func_start = ecs->sal.end; + /* Architectures which require breakpoint adjustment might not be able + to place a breakpoint at the computed address. If so, the test + ``ecs->stop_func_start == stop_pc'' will never succeed. Adjust + ecs->stop_func_start to an address at which a breakpoint may be + legitimately placed. + + Note: kevinb/2004-01-19: On FR-V, if this adjustment is not + made, GDB will enter an infinite loop when stepping through + optimized code consisting of VLIW instructions which contain + subinstructions corresponding to different source lines. On + FR-V, it's not permitted to place a breakpoint on any but the + first subinstruction of a VLIW instruction. When a breakpoint is + set, GDB will adjust the breakpoint address to the beginning of + the VLIW instruction. Thus, we need to make the corresponding + adjustment here when computing the stop address. */ + + if (gdbarch_adjust_breakpoint_address_p (current_gdbarch)) + { + ecs->stop_func_start + = gdbarch_adjust_breakpoint_address (current_gdbarch, + ecs->stop_func_start); + } + if (ecs->stop_func_start == stop_pc) { /* We are already there: stop now. */