hardware support for gdb?

hardware support for gdb?

[mohanlal jangir]

I have an ARM board which comes with its own boot monitor, which just brings
up the board. I download RedBoot to bring the target up as well as to
connect with gdb. My question is, what is minimal support required from a
target hardware so that an application like RedBoot can work on it to
connect with gdb and provide debugging.

Regards
Mohanlal

Re: hardware support for gdb?

[Andrew Cagney]

> I have an ARM board which comes with its own boot monitor, which just brings
> up the board. I download RedBoot to bring the target up as well as to
> connect with gdb. My question is, what is minimal support required from a
> target hardware so that an application like RedBoot can work on it to
> connect with gdb and provide debugging.

Some sort of "serial" communications channel (from a simple serial 
device through to mini-tcp on an ethernet device).

Andrew

Re: hardware support for gdb?

[mohanlal jangir]

> > I have an ARM board which comes with its own boot monitor, which just
brings
> > up the board. I download RedBoot to bring the target up as well as to
> > connect with gdb. My question is, what is minimal support required from
a
> > target hardware so that an application like RedBoot can work on it to
> > connect with gdb and provide debugging.
>
> Some sort of "serial" communications channel (from a simple serial
> device through to mini-tcp on an ethernet device).
>
> Andrew
>

Really!! Does even single stepping also not require any hardware support?

Regards
Mohanlal

Re: hardware support for gdb?

[Andrew Cagney]

> I have an ARM board which comes with its own boot monitor, which just
> 
> brings
> 
>> > up the board. I download RedBoot to bring the target up as well as to
>> > connect with gdb. My question is, what is minimal support required from
> 
> a
> 
>> > target hardware so that an application like RedBoot can work on it to
>> > connect with gdb and provide debugging.
> 
>>
>> Some sort of "serial" communications channel (from a simple serial
>> device through to mini-tcp on an ethernet device).
>>
>> Andrew
>>
> 
> 
> Really!! Does even single stepping also not require any hardware support?

I'm not sure what you mean by hardware support.  The instruction set 
architecture needs to provide a breakpoint instruction.  A single-step 
mechanism is useful but not an absolute requirement - GDB can use 
software singlestep (although I suspect that code has bitrotten).

Andrew

Re: hardware support for gdb?

[mohanlal jangir]

> >
> > Really!! Does even single stepping also not require any hardware
support?
>
> I'm not sure what you mean by hardware support.  The instruction set
> architecture needs to provide a breakpoint instruction.  A single-step
> mechanism is useful but not an absolute requirement - GDB can use
> software singlestep (although I suspect that code has bitrotten).
>
> Andrew
>

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?

Regards
Mohanlal

Re: hardware support for gdb?

[Bill Gatliff]

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

Re: hardware support for gdb?

[Peter Barada]

>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?

For more info on a 'trace' bit type architecture, look up any 68000 or
ColdFire processor manual.  In a nutshell, in an exception, if you patch the
status register value to or in the trace bit, then when the return
from exception is taken, the processor will execute *one* instruction
and then take an exception.  This allows you to step the processor one
instruction at a time without affecting its execution.

If the processor does not have this capability, then gdb inserts an
illegal instruction following the instruction it wants to step.  The
instruction needs to be decoded so if there is a possible branch(or
return or jump-to-subroutine), GDB can place another illegal
instruction at the target of the branch.   This can take quite a while
if GDB is comminication with the target via a slow serial line...

-- 
Peter Barada
peter@the-baradas.com

RE: hardware support for gdb?

[Vijay Kamarshi]

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

Re: hardware support for gdb?

[Bill Gatliff]

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

RE: hardware support for gdb?

[Vijay Kamarshi]

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

RE: hardware support for gdb?

[Atul Talesara]

Please see inline ...

> -----Original Message-----
> From: gdb-owner@sources.redhat.com
[mailto:gdb-owner@sources.redhat.com]
> On Behalf Of mohanlal jangir
> Sent: Tuesday, February 17, 2004 10:16 AM
> To: Andrew Cagney
> Cc: gdb@sources.redhat.com
> Subject: Re: hardware support for gdb?
> 
> > >
> > > Really!! Does even single stepping also not require any hardware
> support?
> >
> > I'm not sure what you mean by hardware support.  The instruction set
> > architecture needs to provide a breakpoint instruction.  A
single-step
> > mechanism is useful but not an absolute requirement - GDB can use
> > software singlestep (although I suspect that code has bitrotten).
> >
> > Andrew
> >
> 
> 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?
You are right :-)

> Could
> you please explain a little about "trace bit" or similar
functionality? 

[Atul Talesara] Trace bit is a special bit in one of the control
registers
of the processor which instructs processor to generate a "debug
exception"
after executing every instruction, thus transferring control to the
debug
exception handler (debugger/stub, in our case); essentially allowing to
single step through the code.  Now, when this functionality is not
available
in the processor, debugger has to put a BREAK instruction AFTER the
current
instruction, so that after execution of that instruction processor
generates
an exception, transferring control to debugger/stub, thus emulating a
single
step. Debugger now replaces this BREAK with the original instruction and
puts a BREAK again AFTER this instruction.  And keeps doing this until
user
wants to "single-step".  Now, because of the branch instructions,
guessing
the next instruction becomes a non-trivial issue (requiring you to
disassemble instructions to get the destination addresses), and also
complicates the process of restoring original instructions.  This is
what is
called as single step in software.  If you are curious to look at the
code
that does this, then skim through:
/linux-2.4/arch/mips/kernel/gdb-stub.c
Hope this answers your question.

>  Is
> it the breakpoint instruction, you mentioned about?
> 
> Regards
> Mohanlal


Thanks and Regards,
Atul P Talesara
------------------------------------------------------------------
     The Self as a different entity, an object, is what
       people are trying to see.  That is an illusion.
                                                         -Sri Sri
------------------------------------------------------------------