From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11308 invoked by alias); 8 May 2002 21:22:50 -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 11293 invoked from network); 8 May 2002 21:22:47 -0000 Received: from unknown (HELO cygnus.com) (205.180.83.203) by sources.redhat.com with SMTP; 8 May 2002 21:22:47 -0000 Received: from romulus.sfbay.redhat.com (romulus.sfbay.redhat.com [172.16.27.251]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id OAA26859; Wed, 8 May 2002 14:22:44 -0700 (PDT) Received: (from kev@localhost) by romulus.sfbay.redhat.com (8.11.6/8.11.6) id g48LMcc19200; Wed, 8 May 2002 14:22:38 -0700 Date: Wed, 08 May 2002 14:22:00 -0000 From: Kevin Buettner Message-Id: <1020508212238.ZM19199@localhost.localdomain> In-Reply-To: Petr Sorfa "[RFC] IA64 handling of breakpoints on L in MLX instruction bundles" (May 8, 3:56pm) References: <3CD98303.5B2F08C3@caldera.com> To: Petr Sorfa , "gdb-patches@sources.redhat.com " Subject: Re: [RFC] IA64 handling of breakpoints on L in MLX instruction bundles MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-05/txt/msg00234.txt.bz2 On May 8, 3:56pm, Petr Sorfa wrote: > GDB cannot handle breakpoints on the L instruction type in MLX > instruction bundles. > > Current GDB inserts the breakpoint in L (second slot of the bundle). Not > only is this code never executed (it is specifically designed to hold > long integers) it actually changes the value for the associated > instruction (MOVL) in the third slot. So (a) the breakpoint doesn't work > and (b) the actual program has now changed functionally as the > breakpoint will never be hit to revert the instruction bundle to its > correct state. > > I have a patch for this. For both the ia64_memory_insert_breakpoint and > ia64_memory_remove_breakpoint routines in ia64-tdep.c a check is made on > the instruction bundle. If it is the second slot and an L type, then the > slot number is bumped up to the 3rd slot. This effectively achieves the > required behaviour. > > Is this solution acceptable? Yeah, sounds good. Send a patch to the list for approval. Thanks, Kevin