RE: hardware support for gdb?

["Vijay Kamarshi" <kamarshi at broadcom dot com>]

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