User defined software traces using Virtual Platform scripting APIs

6 views

Skip to first unread message

AchimNohl

unread,

Feb 4, 2010, 7:55:44 AM2/4/10

to Virtual Platform-Users

Virtual Platforms typically provide some sort of API that allow the
user to interact with the platform and automate the control for e.g.
testing purposes. E.g. in the VP that we provide in the cloud, every
action that you can perform in the Virtual Platform Analyzer GUI, can
be scripted. E.g. setting a breakpoint, running unitl a breakpoint and
printing the value of a register can be described in a three line TCL
file.

Essentially, you can create very interesting tracing solutions that do
not require any code changes. Thus, even though you do not want or
maybe even can compile certain SW modules, you can add tracing easily.
The concept is simple: You create watchpoint or breakpoint. But,
instead of suspending the simulation you print values coming from the
software (e.g. numbers, strings) or values of hardware signals/
registers (e.g. interrupt signal/mask). On the desktop of our VP you
find a reference to the "Scripting Solutions Quick Reference". This
pdf shows the most commonly used commands, but I want to give you some
TCL examples here:

1. Example: You want to issue a debug message whenver a Linux kernel
page fault occurs:

# Set a breakpoint at the Linux page fault handler
set bp [create_breakpoint do_page_fault]
# A message should be printed whenever a page fault is handled
$bp set_callback { puts “Page fault!” }

You typically put this code into a file such as "example.tcl" and read
it via the VPA TCL shell using:

source example.tcl

2. Example: Trace the interrupt value argument stored in R0 at the
function irq_enter

# Create a breakpoint at irq_enter and store the handle in bp
set bp [i_ARM926EJS_0 create_breakpoint irq_enter]
# Register a trace callback that prints
$bp set_callback { puts "Handling interrupt: [i_ARM926EJS_0/R
get_value 0] "}

3. Example: Trace the device files that are opened by the OS using the
sys_open system call

# Print a string from address <vaddr>
proc print_string { vaddr} {
# Iterate over all characters:
while {1} {
# Read character from memory through core MMU
set c [i_ARM926EJS_0 get_values $vaddr ]
if { $c == 0 } {
# Zero terminated string
break
}
# Print the character
puts -nonewline "[format "%c" $c]"
# Increment virtual address
incr vaddr
}
puts ""
return ""
}

# Set a breakpoint at sys_open
set bp [i_ARM926EJS_0 create_breakpoint sys_open]
# Attach a callback that prints the file that is going to be opened
$bp set_callback { print_string [i_ARM926EJS_0/R get_value 0] }

AchimNohl

unread,

Feb 4, 2010, 8:00:40 AM2/4/10

to Virtual Platform-Users

Here is an example on what the sys_open trace will produce on the
Android Linux:

/dev/ashmem
/proc/self/cmdline
/system/fonts/DroidSans.ttf
/system/fonts/DroidSans-Bold.ttf
/system/fonts/DroidSerif-Regular.ttf
/system/fonts/DroidSerif-Bold.ttf
/system/fonts/DroidSerif-Italic.ttf
/system/fonts/DroidSerif-BoldItalic.ttf

These are just some simple examples, but they are of tremedous help
when doing debugging during porting or development. Imagine you want
to see the kernel debug messages issued by printk but you have no
console or UART working yet. Using this mechanism you can make them
visible. If you want to try it out yourself just use an example script
that is contained in the VP. In the VPA enter:

source example_printk.tcl

and see what happens. The fileis located in /home/demo/ARM926EJS-
CoWareVP-VersatilePB-...\skins\Android\sim