I have a script with a breakpoint A and I want to know if is a function that shows the run time till the breakpoint is reached(manually you see it at Misc Runtime ). Let's say if it hits at 10ms is passed if is more is fail. The current code for reaching the breakpoint is:
GO A
TOOLBOX WaitValidateBreakpoint A
ENTRY &StoppedAtBreakpoint
IF &StoppedAtBreakpoint==FALSE()
(
TOOLBOX TestStepFail "Breakpoint A is not reached"
RETURN
)
ELSE
(
TOOLBOX TestStepPass "Breakpoint A is reached"
RETURN
)
You can get time the core was running until it hits a breakpoints with the PRACTICE function RunTime.LASTRUN()
So you can write something like that:
IF RunTime.LASTRUN()<=10.ms
PRINT "OK"
ELSE
PRINT "Execution took too long!"
You can read more about PRACTICE functions in <t32sys>/pdf/general_func.pdf located in you TRACE32 installation.
See also: Benchmarking Code Runtime with Trace32
Related
In gdb, when it hits a breakpoint, I need to manually investigate the variable values, one by one, with print or print/x functions.
Is there any easier way to list all selected variable's values whenever it hits a breakpoint, commonly known as a "watch window" of a GUI debugger?
Commands can be executed on breakpoints.
From docs:
break foo
commands
printf "x is %d\n",x
end
Or add commands to some existing breakpoint (breakpoint number 3 in this case):
commands 3
print x
print y
end
Or make a command that adds prints to a breakpoint:
define addwatch
commands $arg0
print x
print y
end
end
Then use:
addwatch 3
Or make a command that sets a breakpoint and adds prints to it.
Scripts can be stored in .gdbinit, so they'll load automatically. The language is either this GDB syntax or Python.
P.S. Some people do tracing with this by adding continue at the end of the command list: that way the variables are printed, but the application doesn't stop on the breakpoint.
Basically I have two breakpoints, let's say A and B. I wrote a .cmm script for automation test and I want to know how can you see i breakpoint A is reached before breakpoint B. Based on this presumption to have a condition to pass or fail the test. The code below just shows if the breakpoints are reached and they are.
GO A
TOOLBOX WaitValidateBreakpoint A
ENTRY &StoppedAtBreakpoint
IF &StoppedAtBreakpoint==FALSE()
(
TOOLBOX TestStepFail "Breakpoint A is not reached"
RETURN
)
ELSE
(
TOOLBOX TestStepPass "Breakpoint A is reached"
RETURN
)
GO B
TOOLBOX WaitValidateBreakpoint B
ENTRY &StoppedAtBreakpoint
IF &StoppedAtBreakpoint==FALSE()
(
TOOLBOX TestStepFail "Breakpoint B is not reached"
RETURN
)
ELSE
(
TOOLBOX TestStepPass "Breakpoint B is reached"
RETURN
)
Due to the problem description I am assuming that the existing automation script is able to detect whether breakpoint A or B is hit. This is reflected by two PRACTICE macros containing the addresses of the two breakpoints:
LOCAL &address_bp_a &address_bp_b
Two additional PRACTICE macros track which breakpoint is triggered first:
LOCAL &bp_a_first &bp_b_first
&bp_a_first=FALSE()
&bp_b_first=FALSE()
The scripts starts the program execution and monitors which breakpoint is triggered first. This happens in a loop in case other breakpoints are hit:
WHILE !(&bp_a_first||&bp_b_first)
(
Go
WAIT !STATE.RUN()
IF Register(PC)==&address_bp_a
(
&bp_a_first=TRUE()
)
ELSE IF Register(PC)==&address_bp_b
(
&bp_b_first=TRUE()
)
)
IF &bp_a_first
(
PRINT "Breakpoint A was hit first"
)
ELSE IF &bp_b_first
(
PRINT "Breakpoint B was hit first"
)
I have some code that calculates the price of a stock option using Monte Carlo and returns a discounted price. The final few lines of the relevant method look like this:
if(payoffType == pt.LongCall or payoffType == pt.LongPut):
discountedPrice=discountedValue
elif(payoffType == pt.ShortCall or payoffType == pt.ShortPut):
discountedPrice=(-1.0)*discountedValue
else:
raise Exception
#endif
print "dv:", discountedValue, " px:", discountedPrice
return discountedPrice
At a higher level of the program, I create four pricers, which are passed to instances of a portfolio class that calls the price() method on the pricer it has received.
When I set the breakpoint on the if statement or the print statement, the breakpoints work as expected. When I set the breakpoint on the return statement, the breakpoint is interpreted correctly on the first pass through the pricing code, but then skipped on subsequent passes.
On occasion, if I have set a breakpoint somewhere in the flow of execution between the first pass through the pricing code and the second pass, the breakpoint will be picked up.
I obviously have a workaround, but I'm curious if anyone else has observed this behavior in the PyDev debugger, and if so, does anyone know the root cause?
The issues I know of are:
If you have a StackOverflowError anywhere in the code, Python will disable the tracing that the debugger uses.
I know there are some issues with asynchronous code which could make the debugger break.
A workaround is using a programmatic breakpoint (i.e.: pydevd.settrace -- the remote debugger session: http://www.pydev.org/manual_adv_remote_debugger.html has more details on it) -- it resets the tracing even if Python broke it in a stack overflow error and will always be hit to (the issue on asynchronous code is that the debugger tries to run with untraced threads, but sometimes it's not able to restore it on some conditions when dealing with asynchronous code).
I am using Lauterbach to debug a PowerPC embedded C software. I want to execute the below ALGO from a .cmm(PRACTICE) script. Pleas let me know if it is possible:
Set Breakpoint
When Breakpoint is hit, execute a .cmm file. This .cmm file will rewrite the values of an array.
Continue execution of program
I don't want to stub the whole function. The code has to be untouched.
Set the breakpoint with
Break.Set <addr> /Program /CMD "DO myScript.cmm"
To continue the execution of the target program, add the command Go to the end of the called PRACTICE script.
If you can't add the command Go to the end of the called PRACTICE script, you'll need a veneer-script like this:
// Content of myScript.cmm
DO myAlgorithm.cmm
Go
ENDDO
The Break.Set command knows also an option /RESUME, but this is not suitable for your case, since it won't wait until the called PRACTICE script has finished.
As you have mentioned !
I don't want to stub the whole function. The code has to be untouched.
You can try this;
;set a breakpoint on function
BREAK.SET <function_name/addr>\<LINE NUMBER>
;store address of current program counter(PC)
&pc=r(pc)
&call=address.offset(<function_name/addr>\<LINE NUMBER>) ;This will give the address of a function where breakpoint is set.
;Compare the address if it hit on correct function
IF (&pc==&call)
Do call_meonceHIT.cmm ;your desired .cmm script.
Break.Delete /ALL ; to delete all the set breakpoint.
This will make sure that breakpoint is hitting correct function or runnable.
Assume the following .gdbinit:
break foobar
ignore 1 1
run
The program is started using gdb --args ./myprogram --argument1 --argument2 etc.
Now, when I start this the first time around all is fine and dandy. However, if I issue a run on the (gdb) prompt in order to restart the program with the last-known command line, the ignore line will simply not take effect.
The reason is of course clear. The first time around I end up with
(gdb) info break
Num Type Disp Enb Address What
1 breakpoint keep y 0x000000000061ea6a in foobar at ../foobar.c:1173
breakpoint already hit 1 time
And any subsequent run starts with whatever value is shown for X in breakpoint already hit X time. Naturally that value will already exceed the limit set by ignore.
How can I reset the stats on the breakpoints or better yet how can I cause run to do that automatically for me?
How can I reset the stats on the breakpoints or better yet how can I cause run to do that automatically for me?
One way to do that is:
# ~/.gdbinit
break foobar
break main
commands 2
silent
ignore 1 1
continue
end
Now, every time you run, you hit silent breakpoint on main, which resets the ignore count on foobar breakpoint and continues.