From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8970 invoked by alias); 8 May 2002 19:44:56 -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 8962 invoked from network); 8 May 2002 19:44:55 -0000 Received: from unknown (HELO tetsuo.nj.caldera.com) (63.124.204.226) by sources.redhat.com with SMTP; 8 May 2002 19:44:55 -0000 Received: from caldera.com (localhost.localdomain [127.0.0.1]) by tetsuo.nj.caldera.com (8.11.6/8.11.6) with ESMTP id g48Jurc04381; Wed, 8 May 2002 15:56:53 -0400 Message-ID: <3CD98303.5B2F08C3@caldera.com> Date: Wed, 08 May 2002 12:44:00 -0000 From: Petr Sorfa Organization: Caldera X-Accept-Language: en MIME-Version: 1.0 To: "gdb-patches@sources.redhat.com" Subject: [RFC] IA64 handling of breakpoints on L in MLX instruction bundles Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-05/txt/msg00222.txt.bz2 Hi, 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? Petr