From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12403 invoked by alias); 17 Feb 2004 20:04:02 -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 12391 invoked from network); 17 Feb 2004 20:04:02 -0000 Received: from unknown (HELO mms2.broadcom.com) (63.70.210.59) by sources.redhat.com with SMTP; 17 Feb 2004 20:04:02 -0000 Received: from 63.70.210.1 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.6.0)); Tue, 17 Feb 2004 12:03:40 -0800 X-Server-Uuid: 011F2A72-58F1-4BCE-832F-B0D661E896E8 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 MAA12155 for ; Tue, 17 Feb 2004 12:03:14 -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 i1HK3gov012281 for ; Tue, 17 Feb 2004 12:03:47 -0800 (PST) From: "Vijay Kamarshi" To: gdb@sources.redhat.com Subject: RE: hardware support for gdb? Date: Tue, 17 Feb 2004 20:04:00 -0000 Message-ID: MIME-Version: 1.0 In-Reply-To: <40321D89.4040703@billgatliff.com> X-WSS-ID: 6C2CAC160QC5572145-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2004-02/txt/msg00206.txt.bz2 Hi Bill, Do you see an advantage in *not* having GDB do the disassembly for single stepping across a branch instruction? 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. 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? We are using a processor core that implements speculative branching. I am wondering how I am going to get it to work right. Thanks in advance for your answers. -Vijay -----Original Message----- From: gdb-owner@sources.redhat.com [mailto:gdb-owner@sources.redhat.com]On Behalf Of Bill Gatliff Sent: Tuesday, February 17, 2004 5:56 AM To: mohanlal jangir; gdb@sources.redhat.com Subject: Re: hardware support for gdb? Mohanlal: >Thanks Andrew for your prompt replies. I was reading an article on "how gdb >works". This is a paragraph from that: > >The Remote Serial Protocol's step command is a bit more challenging, >especially when the target processor doesn't provide a "trace bit" or >similar functionality (For example, Motorola 683xx processors contain the >ability to trap on instruction execution and/or changes in program flow; >this feature is controlled by the "trace enable" bits, T1 and T0, in the >processor's status register). In these cases, the only alternative is for >the stub to disassemble the instruction about to be executed so that it can >determine where the program is going to go next. > >What I understood from this paragraph is that, if a target processor provide >"trace bit" kind of functionality, gdb developer's life is easier otherwise >he has to do some more work(disassembling of instruction). Am I right? Could >you please explain a little about "trace bit" or similar functionality? Is >it the breakpoint instruction, you mentioned about? > The full text of the article you refer to (I think) is at: http://billgatliff.com/articles/gnu/gdb-agent.html/index.html If the target processor provides a "trace bit" like the 68K does, then the debugging agent/stub author's job is quite easy. It only has to activate the bit when gdb sends the "s" command (which happens when you type 'stepi' at the gdb prompt), then the processor will run precisely one machine instruction then give control back to the debugging agent. For other processors that don't have a trace bit or a similar piece of breakpoint-generating hardware (UBC on the SH, and some PPC and ARM machines have breakpoint registers), the debugging agent has to manually cause an exception when gdb sends the "s" command. My stubs do this by brute-force disassembling the instruction, figuring out where it will go, and setting a breakpoint instruction at that address. It isn't nearly as hard as it sounds! And finally, gdb can do the instruction disassembly itself, as Andrew Cagney mentions. I've never tried that approach, though, and have never even investigated how to tell gdb to do that... :^) I have a library of gdb debugging agent stubs on Sourceforge. The 68K stub uses trace bits, the SH stub tries to use the UBC (and mostly fails, due to bugs/shortcomings in the peripheral), and the ARM stub uses instruction disassembly (of the most popular instructions, a few are still missing). Go to sf.net and search for "gdbstubs". The code posted there hasn't changed in a bit, because, well, once you have something that works... I use derivatives from gdbstubs almost daily for my own projects and training materials. As customer demand or time permits, I add targets. PPC and MIPS are on the list, as are additional refinements to the ARM target to support instructions that the recent gcc-3.x code is using in function epilogues that it didn't use before (performance enhancement). And, as someone already mentioned, there are a few example stubs included with the gdb source tree. OT, I have been trying to get Red Hat to release their Heisenberg implementation for inclusion into gdbstubs, which would allow better debugging of realtime embedded systems. They haven't said no, but they haven't managed to push through the paperwork, either. Of course Heisenberg is well documented (thanks!), but I haven't had the chance to convert the documentation into code myself. Regards, b.g. > >Regards >Mohanlal > > -- Bill Gatliff Embedded GNU, Linux, and other board support packages. bgat@billgatliff.com