Reply by David Kirkland●November 3, 20042004-11-03
"Raymond Toy" <raymond.toy@ericsson.com> wrote in message
news:sxdmzyhv6jq.fsf@edgedsp4.rtp.ericsson.se...
>>>>>> "Andrew" == Andrew Reilly <andrew-newspost@areilly.bpc-users.org> writes:
>
> Andrew> On Tue, 19 Oct 2004 20:42:43 -0700, Sandeep Chikkerur wrote:
> >> I am not sure if this is the right place to ask this question.
> >> When we are debugging some application , say in simulation, we often put
> >> the breakpoints, to see what is happening at that place.
> >>
> >> (Example : in Code Composer Studio, we put breakpoints )
> >>
> >> I want to know how the breakpoints are implemented ?
>
> Andrew> In the days before "debug assist" hardware was ubiquitous in
> processors,
> Andrew> debuggers would insert breakpoints by replacing the piece of code
> at the
> Andrew> desired site with a call to the breakpoint entry routine.
> Continuing
> Andrew> execution would then involve emulating the replaced instruction(s)
> and
> Andrew> executing a "return from subroutine" instruction.
>
> Andrew> Nowadays most processors include special registers that are
> compared
> Andrew> against the processor's instruction pointer (or even data memory
> Andrew> accesses), and either trap (interrupt) or enter
> in-circuit-emulation mode
> Andrew> when a match occurs. The details tend to be slightly different
> from
> Andrew> processor to processor.
>
> But surely, there can't be enough special registers to handle all the
> breakpoints that someone might want to use? I might have 20 or more
> breakpoints (not necessarily all active) in complicated code. I would
> think breakpoints are still implemented by inserting a special
> instruction. The special registers would be used for things like
> watch-points so you can tell if something is being read or written and
> from where.
>
> But I'm guessing here.
>
> Ray
Yes, you are correct. If you look at Microsoft's Kernel Level Debugger or
NuMega's SoftIce you will find both HW and SW breakpoints. There are usually a
few CPU registers that allow you to set a HW breakpoints - these are extremely
fast but relatively dumb and you can only set a few of them. On the other hand
you can have SW breakpoints which are essentially implemented as people have
shown in this thread. In this case you can wrap a great deal of logic around
this breakpoint - you can set as many as the software(debugger) and memory
allow, but they slow down the execution.
Depending on the type of App you're writing you would use different types of
breakpoints.
Best,
Dave
Reply by Jerry Avins●October 21, 20042004-10-21
Sandeep Chikkerur wrote:
> James Stevenson <james@stev.org> wrote in message news:<Pine.LNX.4.44.0410201416260.1639-100000@beast.stev.org>...
>
>>Hi,
>>
>>that can actually be quiet easy if the processor you are using supports
>>this method.
>>
>>you inset a software except opcode like a trap.
>>When the exception goes off you just hit a breakpoint then
>>you re-write the original code back in there and return to execute.
>>
>>if you need to fire multiple break points when you re-write the code
>>the next intrustion should do the opposite. Remove the code and insert
>>the original trap back in place and remove the other trap next time the
>>code runs it should hit the break point again.
>>
>>Thats the software method for it.
>>
>>The hardware method is done using memory protection by disableing
>>execution on a memory region which should also trigger an exception.
>>
>> James
>>
>>On 19 Oct 2004, Sandeep Chikkerur wrote:
>>
>>
>>>Hi,
>>>
>>>I am not sure if this is the right place to ask this question.
>>>When we are debugging some application , say in simulation, we often put
>>>the breakpoints, to see what is happening at that place.
>>>
>>>(Example : in Code Composer Studio, we put breakpoints )
>>>
>>>I want to know how the breakpoints are implemented ?
>>>
>>>
>>>Thanks
>>>Sandeep
>>>
>
>
> Hi,
>
> Here I am wanting to know how the software breakpoints are designed &
> implemented ?
>
> Ex: A small 'C' example written in TI's Code Composer Studio
That's a good question. Its answer illustrates the power that software
can wield in the hands of clever programmers. It's almost magic.
The language of the program is immaterial. Software breakpoints are
implemented in the native (assembly) language of the processor. Here is
one possible scheme when the code is in RAM:
At each breakpoint, enough instructions are replaced as are needed to
make room for a jsr instruction. An entry is made into a table, indexed
by original address, that contains the programmer's original code and a
jump to immediately after its original location.
The code at the breakpoint is changed to jsr <address of BP routine>.
(Of course, 'jsr' is the opcode for jump-to-subroutine.) When the
breakpoint routine is entered, the address (or one more than the
address, depending on the processor) of the breakpoint is on the stack.
The breakpoint routine, most of which is similar to a ROM monitor, uses
that information to restore the programmer's code during the break
session. Restoring the programmer's code is usually the BP routine's
first task, so that a dump of RAM shows it. To see BP code, dump memory
at another breakpoint. To end the break session, the jsr is restored and
the code in the table, including the jump, is executed.
Jerry
--
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������
Reply by Brad Griffis●October 21, 20042004-10-21
Sandeep,
Other people's descriptions here are very close to what happens on the TI
DSPs though I think I can add a little more.
There is an actual instruction in the DSP's instruction set (ESTOP) which
when executed with an emulator attached halts the DSP. So when you insert a
breakpoint in your code the emulation replaces the original instruction from
your code with ESTOP. When the ESTOP is executed the processor halts.
Perhaps you're wondering what happens if your code is executing out of
flash. In this case you cannot simply replace an instruction at run-time so
you need to use other methods. In this case you need a hardware breakpoint.
On most of the TI processors you can use two hardware breakpoints at any
given time. The hardware breakpoint works by monitoring the program address
bus to see when you reach the desired instruction.
Brad
"Sandeep Chikkerur" <sandeep_mc81@yahoo.com> wrote in message
news:d5d88eb5.0410191942.523c1bea@posting.google.com...
> Hi,
>
> I am not sure if this is the right place to ask this question.
> When we are debugging some application , say in simulation, we often put
> the breakpoints, to see what is happening at that place.
>
> (Example : in Code Composer Studio, we put breakpoints )
>
> I want to know how the breakpoints are implemented ?
>
>
> Thanks
> Sandeep
Reply by James Stevenson●October 21, 20042004-10-21
> Hi,
>
> Here I am wanting to know how the software breakpoints are designed &
> implemented ?
>
> Ex: A small 'C' example written in TI's Code Composer Studio
>
> The numbers after // represent the line numbers
>
> void main(void) //1
> { //2
> int a, b, c; //3
> a = 10; //4
> b = 20; //5
> c = a + b; //6
> printf(" SUM = %d\n " , c); //7
> } //8
>
>
> Now, I want to set a breakpoint on line 6 & 7.
> So, what mechanism goes internally?
>
> And, it is also possible to go to a mixed mode & set a break point on
> the assembly generated instructions corresponding to the C statements.
>
> For example, the equivalent assembly for line number 6 would be
>
> (c = a + b ) = { ld reg1 , mem1
> ld reg2 , mem2
> move reg3, reg1
> add reg3, reg2
> st reg3, mem3
> }
>
> mem1 has value of a
> mem2 has value of b
> mem3 will have sum of a + b
>
> Now, if I want to set a breakpoint on "add reg3, reg2", in a mixed
> mode,
> how does this happen.
>
> So, to summarise the above points,
> 1 . When a 'C' like statement has a break point, how does it happen ?
> 2. When the same 'C' like statement is viewed in a mixed mode, and
> set a break point in one of the assembly instructions, how the does
> the break points work ?
First of all you need to understand that the only language you work
in with break point in assembler wether thats been originally written
in assembeler or been compiled from C thats up to you. You will need a
line number converter for the c compiler debug information that it
produces. If you are using compilers like TI Code Composer / ADI you may
need to write this from scratch.
I dont know the TI's assebmler syntax but here it is in pseudo form.
0x0 reg1 = LOAD a
0x1 reg2 = LOAD b
0x2 reg3 = reg1 + reg2
0x3 SAVE reg3
Before running the code you would change the opcode at 0x0
to be TRAP 0x1 (or another number)
eg
0x0 TRAP 0x1
0x1 reg2 = LOAD b
0x2 reg3 = reg1 + reg2
0x3 SAVE reg3
this will mean you can never get past the instruction
line 0x0 no matter how hard you try because while the trap is there the
exception should keep on getting executed. To get around this small
problem you do something like this in the exception handler.
0x0 reg1 = LOAD a
0x1 reg2 = TRAP 0x2
0x2 reg3 = reg1 + reg2
0x3 SAVE reg3
so after returning from the exceptiont he line 0x0 is executed and another
excection is run from 0x1 you can then replace this code with
0x0 TRAP 0x1
0x1 reg2 = LOAD b
0x2 reg3 = reg1 + reg2
0x3 SAVE reg3
again and continue on your way leaving the breakpoint as it first was.
ready to pause execution the next time you execute the function.
This is in fact the easy part of software break point but where jumps
are located on the code your code has to folow both options int he jump so
that it works properly this is when it becomes awakward.
James
--
--------------------------
Mobile: +44 07779080838
http://www.stev.org
10:50am up 21:16, 3 users, load average: 0.00, 0.00, 0.00
Reply by Sandeep Chikkerur●October 21, 20042004-10-21
James Stevenson <james@stev.org> wrote in message news:<Pine.LNX.4.44.0410201416260.1639-100000@beast.stev.org>...
> Hi,
>
> that can actually be quiet easy if the processor you are using supports
> this method.
>
> you inset a software except opcode like a trap.
> When the exception goes off you just hit a breakpoint then
> you re-write the original code back in there and return to execute.
>
> if you need to fire multiple break points when you re-write the code
> the next intrustion should do the opposite. Remove the code and insert
> the original trap back in place and remove the other trap next time the
> code runs it should hit the break point again.
>
> Thats the software method for it.
>
> The hardware method is done using memory protection by disableing
> execution on a memory region which should also trigger an exception.
>
> James
>
> On 19 Oct 2004, Sandeep Chikkerur wrote:
>
> > Hi,
> >
> > I am not sure if this is the right place to ask this question.
> > When we are debugging some application , say in simulation, we often put
> > the breakpoints, to see what is happening at that place.
> >
> > (Example : in Code Composer Studio, we put breakpoints )
> >
> > I want to know how the breakpoints are implemented ?
> >
> >
> > Thanks
> > Sandeep
> >
Hi,
Here I am wanting to know how the software breakpoints are designed &
implemented ?
Ex: A small 'C' example written in TI's Code Composer Studio
The numbers after // represent the line numbers
void main(void) //1
{ //2
int a, b, c; //3
a = 10; //4
b = 20; //5
c = a + b; //6
printf(" SUM = %d\n " , c); //7
} //8
Now, I want to set a breakpoint on line 6 & 7.
So, what mechanism goes internally?
And, it is also possible to go to a mixed mode & set a break point on
the assembly generated instructions corresponding to the C statements.
For example, the equivalent assembly for line number 6 would be
(c = a + b ) = { ld reg1 , mem1
ld reg2 , mem2
move reg3, reg1
add reg3, reg2
st reg3, mem3
}
mem1 has value of a
mem2 has value of b
mem3 will have sum of a + b
Now, if I want to set a breakpoint on "add reg3, reg2", in a mixed
mode,
how does this happen.
So, to summarise the above points,
1 . When a 'C' like statement has a break point, how does it happen ?
2. When the same 'C' like statement is viewed in a mixed mode, and
set a break point in one of the assembly instructions, how the does
the break points work ?
Thanks
Sandeep
Reply by ●October 20, 20042004-10-20
Raymond Toy <raymond.toy@ericsson.com> writes:
> >>>>> "Andrew" == Andrew Reilly <andrew-newspost@areilly.bpc-users.org> writes:
>
> Andrew> On Tue, 19 Oct 2004 20:42:43 -0700, Sandeep Chikkerur wrote:
> >> I am not sure if this is the right place to ask this question.
> >> When we are debugging some application , say in simulation, we often put
> >> the breakpoints, to see what is happening at that place.
> >>
> >> (Example : in Code Composer Studio, we put breakpoints )
> >>
> >> I want to know how the breakpoints are implemented ?
>
> Andrew> In the days before "debug assist" hardware was ubiquitous in processors,
> Andrew> debuggers would insert breakpoints by replacing the piece of code at the
> Andrew> desired site with a call to the breakpoint entry routine. Continuing
> Andrew> execution would then involve emulating the replaced instruction(s) and
> Andrew> executing a "return from subroutine" instruction.
>
> Andrew> Nowadays most processors include special registers that are compared
> Andrew> against the processor's instruction pointer (or even data memory
> Andrew> accesses), and either trap (interrupt) or enter in-circuit-emulation mode
> Andrew> when a match occurs. The details tend to be slightly different from
> Andrew> processor to processor.
>
> But surely, there can't be enough special registers to handle all the
> breakpoints that someone might want to use? I might have 20 or more
> breakpoints (not necessarily all active) in complicated code. I would
> think breakpoints are still implemented by inserting a special
> instruction. The special registers would be used for things like
> watch-points so you can tell if something is being read or written and
> from where.
Perhaps this is the difference between a "hardware breakpoint" and a "software
breakpoint"?
> But I'm guessing here.
Me too.
--
Randy Yates
Sony Ericsson Mobile Communications
Research Triangle Park, NC, USA
randy.yates@sonyericsson.com, 919-472-1124
Reply by Raymond Toy●October 20, 20042004-10-20
>>>>> "Andrew" == Andrew Reilly <andrew-newspost@areilly.bpc-users.org> writes:
Andrew> On Tue, 19 Oct 2004 20:42:43 -0700, Sandeep Chikkerur wrote:
>> I am not sure if this is the right place to ask this question.
>> When we are debugging some application , say in simulation, we often put
>> the breakpoints, to see what is happening at that place.
>>
>> (Example : in Code Composer Studio, we put breakpoints )
>>
>> I want to know how the breakpoints are implemented ?
Andrew> In the days before "debug assist" hardware was ubiquitous in processors,
Andrew> debuggers would insert breakpoints by replacing the piece of code at the
Andrew> desired site with a call to the breakpoint entry routine. Continuing
Andrew> execution would then involve emulating the replaced instruction(s) and
Andrew> executing a "return from subroutine" instruction.
Andrew> Nowadays most processors include special registers that are compared
Andrew> against the processor's instruction pointer (or even data memory
Andrew> accesses), and either trap (interrupt) or enter in-circuit-emulation mode
Andrew> when a match occurs. The details tend to be slightly different from
Andrew> processor to processor.
But surely, there can't be enough special registers to handle all the
breakpoints that someone might want to use? I might have 20 or more
breakpoints (not necessarily all active) in complicated code. I would
think breakpoints are still implemented by inserting a special
instruction. The special registers would be used for things like
watch-points so you can tell if something is being read or written and
from where.
But I'm guessing here.
Ray
Reply by James Stevenson●October 20, 20042004-10-20
Hi,
that can actually be quiet easy if the processor you are using supports
this method.
you inset a software except opcode like a trap.
When the exception goes off you just hit a breakpoint then
you re-write the original code back in there and return to execute.
if you need to fire multiple break points when you re-write the code
the next intrustion should do the opposite. Remove the code and insert
the original trap back in place and remove the other trap next time the
code runs it should hit the break point again.
Thats the software method for it.
The hardware method is done using memory protection by disableing
execution on a memory region which should also trigger an exception.
James
On 19 Oct 2004, Sandeep Chikkerur wrote:
> Hi,
>
> I am not sure if this is the right place to ask this question.
> When we are debugging some application , say in simulation, we often put
> the breakpoints, to see what is happening at that place.
>
> (Example : in Code Composer Studio, we put breakpoints )
>
> I want to know how the breakpoints are implemented ?
>
>
> Thanks
> Sandeep
>
> Hi,
>
> I am not sure if this is the right place to ask this question.
> When we are debugging some application , say in simulation, we often put
> the breakpoints, to see what is happening at that place.
>
> (Example : in Code Composer Studio, we put breakpoints )
>
> I want to know how the breakpoints are implemented ?
Where's Dr. Mike when you need him???
--
% Randy Yates % "Midnight, on the water...
%% Fuquay-Varina, NC % I saw... the ocean's daughter."
%%% 919-577-9882 % 'Can't Get It Out Of My Head'
%%%% <yates@ieee.org> % *El Dorado*, Electric Light Orchestra
http://home.earthlink.net/~yatescr
Reply by Andrew Reilly●October 20, 20042004-10-20
On Tue, 19 Oct 2004 20:42:43 -0700, Sandeep Chikkerur wrote:
> I am not sure if this is the right place to ask this question.
> When we are debugging some application , say in simulation, we often put
> the breakpoints, to see what is happening at that place.
>
> (Example : in Code Composer Studio, we put breakpoints )
>
> I want to know how the breakpoints are implemented ?
In the days before "debug assist" hardware was ubiquitous in processors,
debuggers would insert breakpoints by replacing the piece of code at the
desired site with a call to the breakpoint entry routine. Continuing
execution would then involve emulating the replaced instruction(s) and
executing a "return from subroutine" instruction.
Nowadays most processors include special registers that are compared
against the processor's instruction pointer (or even data memory
accesses), and either trap (interrupt) or enter in-circuit-emulation mode
when a match occurs. The details tend to be slightly different from
processor to processor.
Cheers,
--
Andrew