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
Implementation of break points
Started by ●October 20, 2004
Reply by ●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
Reply by ●October 20, 20042004-10-20
sandeep_mc81@yahoo.com (Sandeep Chikkerur) writes:> 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 ●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 >-- -------------------------- Mobile: +44 07779080838 http://www.stev.org 2:10pm up 36 min, 4 users, load average: 2.88, 3.15, 2.97
Reply by ●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 ●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 ●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 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 ●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 ●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 StudioThat'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. �����������������������������������������������������������������������
