From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1181 invoked by alias); 18 Feb 2004 16:51:06 -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 1042 invoked from network); 18 Feb 2004 16:51:02 -0000 Received: from unknown (HELO mms3.broadcom.com) (63.70.210.38) by sources.redhat.com with SMTP; 18 Feb 2004 16:51:02 -0000 Received: from 63.70.210.1 by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.6.0)); Wed, 18 Feb 2004 08:51:08 -0800 X-Server-Uuid: 8D569F9F-42CF-4602-970D-AACC4BD5D310 Received: from mail-sj1-5.sj.broadcom.com (mail-sj1-5.sj.broadcom.com [10.16.128.236]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id IAA06226 for ; Wed, 18 Feb 2004 08:50:10 -0800 (PST) Received: from PCSJCASOCONNOR (dhcpe2-sj1-109 [10.16.75.109]) by mail-sj1-5.sj.broadcom.com (8.12.9/8.12.9/SSF) with SMTP id i1IGohov026768 for ; Wed, 18 Feb 2004 08:50:43 -0800 (PST) From: "Vijay Kamarshi" To: gdb@sources.redhat.com Subject: RE: hardware support for gdb? Date: Wed, 18 Feb 2004 16:51:00 -0000 Message-ID: MIME-Version: 1.0 In-Reply-To: <403375BD.4010801@billgatliff.com> X-WSS-ID: 6C2D48762IW5896072-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2004-02/txt/msg00229.txt.bz2 Bill, Thanks for your reply. I will look at your gdbstubs code shortly. -Vijay -----Original Message----- From: gdb-owner@sources.redhat.com [mailto:gdb-owner@sources.redhat.com]On Behalf Of Bill Gatliff Sent: Wednesday, February 18, 2004 6:25 AM To: Vijay Kamarshi Cc: gdb@sources.redhat.com Subject: Re: hardware support for gdb? Vijay: >Do you see an advantage in *not* having GDB do the disassembly for single >stepping across a branch instruction? > I don't think the code is any different, no matter where it's located. It's better to do it on the target for bandwidth reasons, but that's the only advantage I can think of offhand. Well, that and the case where the stub is in ROM, and can't be bugfixed. :^) >I imagine, in the debug stub on remote target, you disassemble the branch >instruction and place break instructions at the two possible code paths. >When one of the code path hits, you copy back the original instructions to >the two locations and continue. Is this the way you implement it? Or the >other option would be to actually figure out which path would be taken and >place one break instruction there. > You can look at my code, it's in the gdbstubs project on Sourceforge. I'm disassembling on the remote target, determining where the branch will go (i.e. branch or not), and setting the break instruction at the destination. I have considered many times setting two breakpoints so that I don't have to compute the destination, but during implementation I learned that computing a conditional branch destination is the hard part; the check to see if you're going there is usually just looking at a bit or two in the processor's status register, and is quite easy. >If you are implementing instruction disassembly in your stubs, then you must >have a way of telling the GDB host not to do this in the host. Is this just >done via the regular serial communication protocol? > That's the interesting question. I've never seen gdb try to do the disassembly itself during instruction stepping, so I don't know how to turn it on or off! >We are using a processor core that implements speculative branching. I am >wondering how I am going to get it to work right. > I bet it's a lot like the prefetching behavior on ARM7/9, which is that you don't even know it's going on unless you are directly manipulating the PC. There are only a few places where I have to do that. In processors like the SH that have a delay slot, I have simply decided that you can't stepi the delay slot instruction. :^) b.g. -- Bill Gatliff Public embedded GNU and embedded Linux training dates announced! bgat@billgatliff.com