And add its own header to the rtos_xxx_stackings.c
Signed-off-by: Erhan Kurubas <erhan.kurubas@espressif.com>
Change-Id: I084130fde7ee8645129a7cf60bb7bf59448e2f39
Reviewed-on: https://review.openocd.org/c/openocd/+/7441
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Extended feature. This is a large patch, but is self-contained to the
eCos support and does not affect any other openocd functionality. It
does NOT affect existing eCos RTOS plugin users where their
applications do not provide the extended symbolic helper
information. If the helper symbols are not available the rtos support
code will behave as before. This "dynamic" functionality is *required*
because eCos does NOT have a fixed/hardwired, known, layout for the
thread descriptor structure. The per-application build eCos
configuration can affect the shape of the thread descriptor structure
(field presence, and hence offsets of subsequent fields) such that
constant values cannot be used to consistently interpret all possible
eCos application configurations. For historical reasons, there is not
yet a consistent namespace for the helper symbols across eCos HALs
hence the support is currently limited to specific architectures
(Cortex-M and ARM/Cortex-A). No new Clang analyser warnings are raised
by this changeset.
Change-Id: Ib3a36877326eeb56595cbca55e21b9e59a59c98a
Signed-off-by: James G. Smith <jsmith@rallysmith.co.uk>
Reviewed-on: https://review.openocd.org/c/openocd/+/6275
Reviewed-by: Alex Schuilenburg <alex.schuilenburg@gmail.com>
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Tested-by: jenkins
With the old checkpatch we cannot use the correct format for the
SPDX tags in the file .c, in fact the C99 comments are not allowed
and we had to use the block comment.
With the new checkpatch, let's switch to the correct SPDX format.
Change created automatically through the command:
sed -i \
's,^/\* *\(SPDX-License-Identifier: .*[^ ]\) *\*/$,// \1,' \
$(find src/ contrib/ -name \*.c)
Change-Id: I6da16506baa7af718947562505dd49606d124171
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/7153
Tested-by: jenkins
We have left the camelcase symbols *xPSR* for some time, to avoid
any conflict with possibly pending patches in gerrit.
With the approaching v0.12.0-rc1, it's time to revisit it.
The patches in gerrit that conflict with this rename are all not
merge-able due to conflicts or due to negative review.
Drop these CamelCase symbols.
Change-Id: Ifbac4c1df9cc55994e024971a2aaebeed2ea4ed3
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/7155
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Replace the FSF boilerplate with the SPDX tag.
The SPDX tag on files *.c is incorrect, as it should use the C99
single line comment using '//'. But current checkpatch doesn't
allow C99 comments, so keep using standard C comments, by now.
Change-Id: If0194089baded7f58dc5d87a35d6e0aff9f43785
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/7070
Tested-by: jenkins
This is more readable, and as a bonus the compiler will help out if the
definition of the struct changes.
Change-Id: Ibf660134d9900173f6592407d5cc2203654a4a1b
Signed-off-by: Tim Newsome <tim@sifive.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/6659
Tested-by: jenkins
Reviewed-by: Tarek BOCHKATI <tarek.bouchkati@gmail.com>
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Convert CamelCase enum in uppercase and the other symbols in
lowercase.
Change-Id: I141c55bdfe6ef2a2da28d1da15a283a644ae7cb2
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: http://openocd.zylin.com/6306
Tested-by: jenkins
This patch adds support for p packet responses by targets configured
with RTOS support. This change required moving to a rtos_reg struct,
which is similar to struct reg used by targets, which resulted in
needing to update each stacking with register numbers. This patch also
allows targets with non-linear register numbers to function with RTOSes
as well.
Change-Id: I5b189d74110d6b6f2fa851a67ab0762ae6b1832f
Signed-off-by: Steven Stallion <stallion@squareup.com>
Reviewed-on: http://openocd.zylin.com/4121
Tested-by: jenkins
Reviewed-by: Matthias Welwarsky <matthias@welwarsky.de>
Also make GPL notices consistent according to:
https://www.gnu.org/licenses/gpl-howto.html
Change-Id: I84c9df40a774958a7ed91460c5d931cfab9f45ba
Signed-off-by: Marc Schink <openocd-dev@marcschink.de>
Reviewed-on: http://openocd.zylin.com/3488
Tested-by: jenkins
Reviewed-by: Andreas Färber <afaerber@suse.de>
Reviewed-by: Freddie Chopin <freddie.chopin@gmail.com>
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Some targets (Cortex M) require more complicated calculations for
turning the stored stack pointer back into a process stack pointer.
For example, the Cortex M stores a bit in the auto-stacked xPSR
indicating that alignment had to be performed and an additional 4
byte padding is present before the exception stacking. This change
only sets up the framework for Cortex-M unstacking and does not
add Cortex-M support.
Note: this also fixes the alignment calculation nearly addressed by
change #2301 entitled rtos/rtos.c: fix stack alignment calculation.
Updated calculation is in rtos_generic_stack_align.
Change-Id: I0f662cad0df81cbe5866219ad0fef980dcb3e44f
Signed-off-by: Andrew Ruder <andrew.ruder@elecsyscorp.com>
Cc: Paul Fertser <fercerpav@gmail.com>
Cc: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Cc: Evan Hunter <evanhunter920@gmail.com>
Cc: Jon Burgess <jburgess777@gmail.com>
Reviewed-on: http://openocd.zylin.com/3002
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Tested-by: jenkins
Seems that when xml register support was added the rtos code was not
updated to match. This then caused gdb to return the following error when
rtos support was enabled - "Remote 'g' packet reply is too long".
Change-Id: I7429c4b1efed120e2e690678d55f3d6e87ee1ff1
Signed-off-by: Spencer Oliver <spen@spen-soft.co.uk>
Reviewed-on: http://openocd.zylin.com/2054
Tested-by: jenkins
Reviewed-by: Paul Fertser <fercerpav@gmail.com>