How do breakpoints work???
![Granum, Allen [CAR:CF81:EXCH]'s profile photo](https://lh3.googleusercontent.com/a/default-user=s40-c)
Granum, Allen [CAR:CF81:EXCH]
I have always thought that when a breakpoint was set, that some code was inserted at the location of the breakpoint which would halt the execution. However, there is skeptasism since further investigation of the
breakpoint location using the l and d commands does not show any modification to the code where the breakpoint was set.
Can anyone enlighten me?
--
Allen Granum
Nortel Networks
Wireless Internet
BSP Development Team
Email: agr...@nortelnetworks.com
Phone: (613)763-4324
Johan Borkhuis
> I have always thought that when a breakpoint was set, that some code
> was inserted at the location of the breakpoint which would halt the
> execution. However, there is skeptasism since further investigation of
> the breakpoint location using the l and d commands does not show any
> modification to the code where the breakpoint was set.
As far as I know these routines know that you inserted a breakpoint there,
and will show the original code. You can try your own code to read these
memory locations and see what is written there.
Groeten,
Johan
--
o o o o o o o . . . _____________________________
o _____ || Johan Borkhuis |
.][__n_n_|DD[ ====_____ | bork...@agere.com |
>(________|__|_[_________]_|__________________________|
_/oo OOOOO oo` ooo ooo 'o!o!o o!o!o`
=== VxWorks FAQ: http://www.xs4all.nl/~borkhuis/vxworks/vxworks.html ===
Harvey Taylor
<agr...@americasm01.nt.com> Allen Granum wrote:
>
> Wondering how the whole breakpoint mechanism works on a PPC/vxWorks system?
>
I don't know about the PPC, but AFAIK there are three possible mechanisms.
Insert an interrupt or illegal op code.
Run the processor in Trace mode and watch for the address.
Use external hardware to monitor the address bus & trigger an int.
> I have always thought that when a breakpoint was set, that some code was inserted
> at the location of the breakpoint which would halt the execution. However, the
> breakpoint location using the l and d commands does not show any modification
> to the code where the breakpoint was set.
>
> Can anyone enlighten me?
>
As someone else pointed out, does the tool know about your breakpoint?
WALP it. [Write A Little Program]
<xnorteler>
-het
--
Everyone has the right to recognition everywhere as a person
before the law.
UDHR:Article 6: http://www.autobahn.mb.ca/~het/udhr.html
H.E. Taylor http://www.autobahn.mb.ca/~het/
Mike Kordik
of trap it could list the original instruction when you do a listing. I have
seen this behaviour on several different chips/platforms. This makes more
sense in a listing thant a memory dump but I guess there is no reason why it
couldn't do it on a dump.
Just a thought.
-Mike
"Granum, Allen [CAR:CF81:EXCH]" <agr...@americasm01.nt.com> wrote in
message news:3B8CE9C7...@americasm01.nt.com...
Lori Fraleigh
The tgtsvr generally caches the text segments for VxWorks. If you
do an 'l' from WindShell, you won't see the changed instructions.
If the target shell is available, perform an 'l' from it - you should
see the instruction used to set the breakpoint. If your kernel
has the proper components built in, you can also do an '@l' from
WindShell. Specifying the '@' sign before the 'l' tells WindShell
and the tgtsvr to execute the command on the target and return the
response.
Regards,
Lori
--
Lori Fraleigh Director of Engineering
Real-Time Innovations, Inc. http://www.rti.com
Phone: 408-734-4200 x121 Fax: 408-734-5009
John
"Mike Kordik" <kord...@betalasermike.com> wrote in message news:<Ucdj7.28$6g3.1224@client>...
> If you set a breakpoint and the tool replaces the instruction with some sort
> of trap it could list the original instruction when you do a listing. I have
> seen this behaviour on several different chips/platforms. This makes more
> sense in a listing thant a memory dump but I guess there is no reason why it
> couldn't do it on a dump.
Actually there is a much less sinister (clever?) reason why the
commands do not see the breakpoint... the shell is an unbreakable
task, so all the time it is running the breakpoints are not installed.
When a context switch causes a breakable task to run, the breakpoints
will be resinstated.
So, to see the breakpoint in memory simply spawn the d() command or
l() command. That will then run in a breakable task, and you should
see the magic code inserted to cause an exception.
HTH,
John...
Macleod, Randy [CAR:CW31:EXCH]
Well, here is what I see using a telnet session to a VME PPC target.
Find some function to break:
-> lkup "ifShow"
ifShow 0x001e6884 text (cesnetvx.pserv.o.sym)
value = 0 = 0x0
-> b
No breakpoints
value = 0 = 0x0
-> pData=0x001e6884
pData = 0x1ffebd0: value = 1992836 = 0x1e6884 = ifShow
-> sp printf,"At address %x, value = %x.\n",pData,*pData
task spawned: id = 0x160fde8, name = t5
value = 23133672 = 0x160fde8
-> At address 1e6884, value = 9421ffc8.
# Add a breakpoint:
-> b 0x1e6884
value = 0 = 0x0
-> b
0x001e6884: ifShow Task: all Count: 0
value = 0 = 0x0
-> sp printf,"At address %x, value = %x.\n",pData,*pData
task spawned: id = 0x160fde8, name = t6
value = 23133672 = 0x160fde8
-> At address 1e6884, value = 9421ffc8.
# Someone suggested that the behavior could be different
# if there is more than one breakpoint...
-> b 0x1e6888
value = 0 = 0x0
-> b
0x001e6888: ifShow +0x4 Task: all Count: 0
0x001e6884: ifShow Task: all Count: 0
value = 0 = 0x0
-> sp printf,"At address %x, value = %x.\n",pData,*pData
task spawned: id = 0x160fde8, name = t7
value = 23133672 = 0x160fde8
-> At address 1e6884, value = 9421ffc8.
So it sure looks like the instruction at the breakpoint
address was not overwritten. Is VxWorks checking a breakpoint
list every time the PC is incremented?
// Randy "The Inquisitive Skeptic" MacLeod
--
- - - - - The axis of the universe is irony. - - - - -
John
An interesting approach, but flawed by one little detail. The command
you are using to display the data is:
> -> sp printf,"At address %x, value = %x.\n",pData,*pData
You have used sp to try to avoid the unbreakable nature of the shell,
but unfortunately printf does not evaluate '*pData' - the shell
evaluates it, and then passes the result to printf. That means that it
is still the shell that is reading the memory.
To make this work, try the following:
-> sp d, pData, 1, 4
That should spawn the 'd' function which I don't believe checks the bp
list before working (if you want to be sure, you have the source for
it in target/src/usr/usrLib.c).
Having a PPC604 target handy shows the following (this is AE, but
should be the same for 5.4 - except for the shell prompt):
[vxKernel] -> b 0x00178304
value = 0 = 0x0
[vxKernel] -> sp d, 0x00178304,1, 4
task spawned: tid = 0x301d38, name = pdt4
value = 3153208 = 0x301d38
[vxKernel] -> Dump memory for vxKernel (PD ID 0x203ef4)
0x00178300: 7fe00008 * ........*
bdall
value = 0 = 0x0
[vxKernel] -> sp d, 0x00178304,1, 4
task spawned: tid = 0x301d38, name = pdt5
value = 3153208 = 0x301d38
[vxKernel] -> Dump memory for vxKernel (PD ID 0x203ef4)
0x00178300: 9421fff0 * ! ........*
A disassembly (without the bp installed) shows this:
[vxKernel] -> l 0x00178304
Disassembly for vxKernel (PD ID 0x203ef4)
pdShow:
0x00178304 9421fff0 stwu r1,-16(r1)
0x00178308 7c0802a6 mfspr r0,LR
HTH,
John...
"Macleod, Randy [CAR:CW31:EXCH]" <macl...@americasm01.nt.com> wrote in message news:<3B8E5185...@americasm01.nt.com>...
Emmanuel Herbreteau
Hi,
On PPC (at least PPC 8xx), there are :
- hardware breakpoints : an internal comparator stop the execution
when the program counter reach a value (4 hardware breakpoints on
PPC823)
- software breakpoint : a special opcode is written in memory (it only
works in RAM, you can not set a software breakpoint in ROM !).
You probably use hardware breakpoints...
--
Regards
Emmanuel