Re: hardware support for gdb?

[Bill Gatliff <bgat at billgatliff dot com>]

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