This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: hardware support for gdb?


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]