1. high_pc should be (maximum sample + 1) (Refer to gprof source code)
2. bucket index should be
sample offset
--------------- x (number of bucket)
sample range
For example, if minimum sample is 0 and maximum sample is 5
and the number of bucket is 3.
a = sampled_address - 0
b = 3
c = 6
(a, b, c refer to source code variables)
sampled_address = 0, => a = 0, => bucket_index = 0
sampled_address = 1, => a = 1, => bucket_index = 0
sampled_address = 2, => a = 2, => bucket_index = 1
sampled_address = 3, => a = 3, => bucket_index = 1
sampled_address = 4, => a = 4, => bucket_index = 2
sampled_address = 5, => a = 5, => bucket_index = 2
Change-Id: Ia9fa0e4d9c7183e3e9d7ceaf73e63729f07aa2ce
Signed-off-by: Hsiangkai Wang <hsiangkai@gmail.com>
Reviewed-on: http://openocd.zylin.com/1607
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Change variable name 'length' to 'numBuckets'. It is more readable.
Change-Id: I913cba0746f887adf6da401a46cd5e9ea88d2c6d
Signed-off-by: Hsiangkai Wang <hsiangkai@gmail.com>
Reviewed-on: http://openocd.zylin.com/1606
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
In GDB connected to OpenOCD there is a command "monitor gdb_sync" which makes
next stepi command to be ignored while GDB still will get an updated target
state. This command sets gdb_connection->sync field to true to notify that stepi
should be ignored. This field is set to true for all new connection and is set
to false after first "continue" command. However if first resume command is
stepi/nexti then it will be ignored and result will confuse GDB client, it will
report that target received signal SIGINT. This patch sets this field to false
for new connections, thus stepi/nexti will work properly when it is a first
resume command.
Change-Id: I7c9ebd69c3dc35f3e316041aa99f4e9d3425c0b6
Signed-off-by: Anton Kolesov <akolesov@synopsys.com>
Reviewed-on: http://openocd.zylin.com/1587
Tested-by: jenkins
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Keep the promise and ensure there're at least 3 bytes available after
the current position.
This eliminates the errors reported by Valgrind.
Change-Id: I1d0640e904c750eed808b2b4caf419b4d7619845
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Reviewed-on: http://openocd.zylin.com/1615
Tested-by: jenkins
Reviewed-by: Peter Stuge <peter@stuge.se>
Rewrite the target_*_buffer_default to generate as large accesses as
possible while maintaining natural alignment.
These versions are easy to extend to generate 8-byte accesses to support
64-bit targets, although it requires some conformity from all target
implementations (i.e. they need to refuse unsupported access sizes with
some defined error code, so we can try again with a smaller one).
Change-Id: I00ddcbb1d2fd33f9f8b99cb448cc93505a2421fc
Signed-off-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Reviewed-on: http://openocd.zylin.com/1221
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
The only remaining user is arm7_9 so remove it from the target API and add
it to struct arm7_9_common to support all its variants with minimal
changes. Many of the variants are likely not correct in the cache/mmu
handling when the bulk write is triggered. This patch does nothing to
change that, except for arm946e, where it was easier to do what might be
the right thing.
Change-Id: Ie73ac07507ff0936fefdb90760046cc8810ed182
Signed-off-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Reviewed-on: http://openocd.zylin.com/1220
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
remove clang warning - "Argument to free() is the address of a global
variable, which is not memory allocated by malloc()".
Change-Id: I015273eafc9644207684b363434c6ae8149bfcde
Signed-off-by: Spencer Oliver <spen@spen-soft.co.uk>
Reviewed-on: http://openocd.zylin.com/1613
Tested-by: jenkins
We already set cpsr in armv7m_build_reg_cache, so lets use it for all other
accesses to this field.
Change-Id: I19b3b21ecf1571bbea12e1be664845e6544f6fa1
Signed-off-by: Spencer Oliver <spen@spen-soft.co.uk>
Reviewed-on: http://openocd.zylin.com/1539
Tested-by: jenkins
Let the default handler issue an unsupported warning rather than using
empty handler routines that may/may not issue a unsupported warning.
Change-Id: Iafe3e45146981a4cfae39771c3ab7370ac86da48
Signed-off-by: Spencer Oliver <spen@spen-soft.co.uk>
Reviewed-on: http://openocd.zylin.com/1535
Tested-by: jenkins
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Reviewed-by: Hsiangkai Wang <hsiangkai@gmail.com>
Adds a flash driver for Nuvoton MINI51, MINI52 and MINI54 microcontrollers.
At the moment, it only supports the erase and write operations.
These microcontrollers have a 4 / 8 / 16 KB APROM for application code and a
2 KB LDROM for bootloaders. When the MCU has booted off the APROM, the LDROM
isn't mapped in memory but can be programmed, and the other way around.
This means that the ARM core is typically rebooted for programming. After a
successful write or erase operation, it is rebooted again, using the initial
boot source.
This driver only supports programming the APROM.
This driver is a pure JTAG implementation, it doesn't use any SRAM.
I've tested it on a MINI54ZAN microcontroller using an ST-LINK/V2. With the
microcontroller running at the default clock frequency of 22.1184 MHz, speed
seems to be around 1.1 KB/s.
Change-Id: I180889c55af9fb5614cd99a953b755baba14288a
Signed-off-by: Cosmin Gorgovan <cosmin@linux-geek.org>
Reviewed-on: http://openocd.zylin.com/1546
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
This patch adds a driver for the jtag_vpi server [1]. This server is
now part of the ORPSoC version 3 (OpenRISC Reference Platform SoC).
The jtag_vpi server provides an interface between OpenOCD and a simulated
core.
[1] http://github.com/fjullien/jtag_vpi
Change-Id: I717b72cace4845f66c878581345074f99002e21a
Signed-off-by: Franck Jullien <franck.jullien@gmail.com>
Reviewed-on: http://openocd.zylin.com/1609
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Currently we have very little info about the RTOS support. This should
improve that.
We also add info about what symbols are required for each supported RTOS.
This can be a trap, certainly when trying to use FreeRTOS support.
Change-Id: Ie57858571daca97515292ff5738a5a5ef55655b7
Signed-off-by: Spencer Oliver <spen@spen-soft.co.uk>
Reviewed-on: http://openocd.zylin.com/1538
Tested-by: jenkins
