From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15854 invoked by alias); 27 Sep 2002 21:05:50 -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 15847 invoked from network); 27 Sep 2002 21:05:49 -0000 Received: from unknown (HELO sj-msg-core-3.cisco.com) (171.70.157.152) by sources.redhat.com with SMTP; 27 Sep 2002 21:05:49 -0000 Received: from mira-sjcm-3.cisco.com (IDENT:mirapoint@mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8RL5caW000516; Fri, 27 Sep 2002 14:05:38 -0700 (PDT) Received: from cisco.com (tkonkle-ultra.cisco.com [128.107.164.74]) by mira-sjcm-3.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAG25427; Fri, 27 Sep 2002 14:04:22 -0700 (PDT) Message-ID: <3D94C824.62A5113B@cisco.com> Date: Fri, 27 Sep 2002 14:05:00 -0000 From: Wendy Peikes Organization: Software Tools X-Accept-Language: en MIME-Version: 1.0 To: wendy p , gdb Subject: Anyone using efficient algorithm or HW support for NEXT/STEP? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-09/txt/msg00492.txt.bz2 Here at Cisco, we've gotten both the host (started with gnu gdb 5.0) and target gdb working for arm-elf. (Note: I'd be glad to answer any questions about the arm gdb host side and help with target-side questions) We're (my target-side colleague and myself) are wondering if someone is using a better algorithm for the NEXT and STEP commands: Our gdb's single stepping is very slow. Current implementation (A) (Note: applies, in general, to all platforms, not just to arm): 1- restore user installed breakpoints 2- command to single step. 3- ack and set temp breakpoint(s). For arm, sets two temp breakpoints on branches and function calls; one at the destination and one at next instruction. These cover conditional execution either way it may go. 4- exception signal 5- remove breakpoints 6- collect regs to see where we are. 7- if still between start addr and stop addr, repeat, if == stop addr: stop 8 - if in another function, determine return addr and set breakpoint there 9 - continue 10 - go to 4 When it could be more efficient, simpler, and more robust to do B: 1- restore user installed breakpoints 2- set a temp breakpoint at stop addr 3 - continue 4- exception signal 5- collect regs and display where we are Is anyone out there using a more efficient algorithm similar to B? Also, is anyone using hardware single-stepping or hardware-assisted stepping? For which platforms? Thank you much for your help, Wendy Peikes Cisco Systems Software Tools Group GDB Support