From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26581 invoked by alias); 17 Feb 2004 13:56:29 -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 26573 invoked from network); 17 Feb 2004 13:56:26 -0000 Received: from unknown (HELO saturn.billgatliff.com) (209.251.101.200) by sources.redhat.com with SMTP; 17 Feb 2004 13:56:26 -0000 Received: from billgatliff.com (meta-adsl-9.mtco.com [207.179.223.9]) by saturn.billgatliff.com (Postfix) with ESMTP id B0B924E00A8; Tue, 17 Feb 2004 07:56:25 -0600 (CST) Message-ID: <40321D89.4040703@billgatliff.com> Date: Tue, 17 Feb 2004 13:56:00 -0000 From: Bill Gatliff User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030 MIME-Version: 1.0 To: mohanlal jangir , gdb@sources.redhat.com Subject: Re: hardware support for gdb? References: <402CE55C.6070605@gnu.org> <4031535A.7080500@gnu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-02/txt/msg00191.txt.bz2 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