[OpenOCD-devel] [PATCH]: ca0ff02 HACKING: document practices to improve code quality
This is an automated email from Gerrit. Paul Fertser (fercer...@gmail.com) just uploaded a new patch set to Gerrit, which you can find at http://openocd.zylin.com/4343 -- gerrit commit ca0ff025acb577edc9d5f5fa5f4000480d203a31 Author: Paul Fertser Date: Tue Jan 16 15:11:18 2018 +0300 HACKING: document practices to improve code quality Change-Id: I58a7d978b7d5bca3037c4535f06746b9f4411950 Signed-off-by: Paul Fertser diff --git a/HACKING b/HACKING index 162da86..cb22bc2 100644 --- a/HACKING +++ b/HACKING @@ -27,7 +27,42 @@ it so large that it's hard to review; split large patches into smaller ones. (That can also help track down bugs later on.) All patches should be "clean", which includes preserving the existing -coding style and updating documentation as needed. +coding style and updating documentation as needed (when adding a new +command, the corresponding documentation should be added to +@c doc/openocd.texi in the same commit). OpenOCD runs on both Little +Endian and Big Endian hosts so the code can't count on specific byte +ordering. + +There are several additional methods of improving the quality of your +patch: + +- Runtime testing with Valgrind Memcheck + + This helps to spot memory leaks, undefined behaviour due to + uninitialized data or wrong indexing, memory corruption, etc. + +- Clang Static Analyzer + + Using this tool uncovers many different kinds of bugs in C code, + with problematic execution paths fully explained. It is a part of + standard Clang installation. + + To generate a report, run this in the OpenOCD source directory: + @code + mkdir build-scanbuild; cd build-scanbuild + scan-build ../configure + scan-build make CFLAGS="-std=gnu99 -I. -I../../jimtcl" + @endcode + +- Runtime testing with sanitizers + + Both GCC and LLVM/Clang include advanced instrumentation options to + detect undefined behaviour and many kinds of memory + errors. Available with @c -fsanitize=* command arguments. + +Please consider performing these additonal checks where appropriate +(especially Clang Static Analyzer for big portions of new code) and +mention the results in the commit message. Say in the commit message if it's a bugfix (describe the bug) or a new feature. Don't expect patches to merge immediately -- -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
[OpenOCD-devel] [PATCH]: 2877f92 doxygen: fix issues with recent Doxygen versions
This is an automated email from Gerrit. Paul Fertser (fercer...@gmail.com) just uploaded a new patch set to Gerrit, which you can find at http://openocd.zylin.com/4342 -- gerrit commit 2877f92e29e030f5aae91c104c8324981d22a1c8 Author: Paul Fertser Date: Tue Jan 16 15:08:34 2018 +0300 doxygen: fix issues with recent Doxygen versions This fixes parsing of several documentation files which do not have dot in the filename. style.txt change fixes doxygen warnings and ensures proper display of comment begin/end instructions in HTML. Tested with Doxygen 1.8.13. Change-Id: I9fd9ac3b51b47076b8fdbd3e93b90c3eba9b9631 Signed-off-by: Paul Fertser diff --git a/Doxyfile.in b/Doxyfile.in index 13b0c24..6e68b4e 100644 --- a/Doxyfile.in +++ b/Doxyfile.in @@ -216,7 +216,7 @@ OPTIMIZE_OUTPUT_VHDL = NO # .inc files as Fortran files (default is PHP), and .f files as C (default is Fortran), # use: inc=Fortran f=C -EXTENSION_MAPPING = +EXTENSION_MAPPING = no_extension=C # If you use STL classes (i.e. std::string, std::vector, etc.) but do not want # to include (a tag file for) the STL sources as input, then you should diff --git a/doc/manual/style.txt b/doc/manual/style.txt index 2ff2a29..0bfae35 100644 --- a/doc/manual/style.txt +++ b/doc/manual/style.txt @@ -176,10 +176,10 @@ comments. * @returns The value(s) returned, or possible error conditions. */ @endverbatim - -# The block should start on the line following the opening @c /**. - -# The end of the block, \f$*/\f$, should also be on its own line. + -# The block should start on the line following the opening @c /\**. + -# The end of the block, @c */, should also be on its own line. -# Every line in the block should have a @c '*' in-line with its start: -- A leading space is required to align the @c '*' with the @c /** line. +- A leading space is required to align the @c '*' with the @c /\** line. - A single "empty" line should separate the function documentation from the block of parameter and return value descriptions. - Except to separate paragraphs of documentation, other extra -- -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
[OpenOCD-devel] [PATCH]: cc3c2a9 aarch64: fix reset handling
This is an automated email from Gerrit.
Matthias Welwarsky (matth...@welwarsky.de) just uploaded a new patch set to
Gerrit, which you can find at http://openocd.zylin.com/4345
-- gerrit
commit cc3c2a99e00b6cfb82aa96f5f08c3b18d0c22fd7
Author: Matthias Welwarsky
Date: Tue Jan 9 12:18:19 2018 +0100
aarch64: fix reset handling
make sure to only "reset halt" targets that were previously examined,
make sure to only assert the reset line when SRST doesn't gate JTAG
(or if transport is SWD)
Change-Id: Ibeb2c488fa06a49c78e66b6d7a5c963e6301bc4c
Signed-off-by: Matthias Welwarsky
diff --git a/src/target/aarch64.c b/src/target/aarch64.c
index 5da4db3..7665928 100644
--- a/src/target/aarch64.c
+++ b/src/target/aarch64.c
@@ -28,6 +28,7 @@
#include "target_type.h"
#include "armv8_opcodes.h"
#include "armv8_cache.h"
+#include
#include
enum restart_mode {
@@ -1637,7 +1638,14 @@ static int aarch64_assert_reset(struct target *target)
/* REVISIT handle "pulls" cases, if there's
* hardware that needs them to work.
*/
- jtag_add_reset(0, 1);
+
+ /*
+* FIXME: fix reset when transport is SWD. This is a temporary
+* work-around for release v0.10 that is not intended to stay!
+*/
+ if (transport_is_swd() ||
+ (target->reset_halt && (jtag_get_reset_config()
& RESET_SRST_NO_GATING)))
+ jtag_add_reset(0, 1);
} else {
LOG_ERROR("%s: how to reset?", target_name(target));
return ERROR_FAIL;
@@ -1674,9 +1682,12 @@ static int aarch64_deassert_reset(struct target *target)
if (target->state != TARGET_HALTED) {
LOG_WARNING("%s: ran after reset and before halt ...",
target_name(target));
- retval = target_halt(target);
- if (retval != ERROR_OK)
- return retval;
+ if (target_was_examined(target)) {
+ retval = target_halt(target);
+ if (retval != ERROR_OK)
+ return retval;
+ } else
+ target->state = TARGET_UNKNOWN;
}
}
@@ -2304,11 +2315,9 @@ static int aarch64_examine_first(struct target *target)
static int aarch64_examine(struct target *target)
{
- int retval = ERROR_OK;
+ int retval;
- /* don't re-probe hardware after each reset */
- if (!target_was_examined(target))
- retval = aarch64_examine_first(target);
+ retval = aarch64_examine_first(target);
/* Configure core debug access */
if (retval == ERROR_OK)
--
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
[OpenOCD-devel] [PATCH]: cc4e2c8 aarch64: fix setting breakpoint on unexamined targets
This is an automated email from Gerrit.
Matthias Welwarsky (matth...@welwarsky.de) just uploaded a new patch set to
Gerrit, which you can find at http://openocd.zylin.com/4344
-- gerrit
commit cc4e2c8c3c618e3175bbd67a69e3cd9a18e9f9c4
Author: Matthias Welwarsky
Date: Tue Jan 9 10:31:41 2018 +0100
aarch64: fix setting breakpoint on unexamined targets
When setting breakpoints, don't fail on targets that have not been
examined yet.
Change-Id: Iadfcfe27eaf2ec342aa9eb22caf266d948785623
Signed-off-by: Matthias Welwarsky
diff --git a/src/target/aarch64.c b/src/target/aarch64.c
index 784274a..5da4db3 100644
--- a/src/target/aarch64.c
+++ b/src/target/aarch64.c
@@ -1550,6 +1550,9 @@ static int aarch64_add_breakpoint(struct target *target,
{
struct aarch64_common *aarch64 = target_to_aarch64(target);
+ if (!target_was_examined(target))
+ return ERROR_OK;
+
if ((breakpoint->type == BKPT_HARD) && (aarch64->brp_num_available <
1)) {
LOG_INFO("no hardware breakpoint available");
return ERROR_TARGET_RESOURCE_NOT_AVAILABLE;
--
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
[OpenOCD-devel] [PATCH]: 592bbbb aarch64: clean up scan-build errors
This is an automated email from Gerrit.
Matthias Welwarsky (matth...@welwarsky.de) just uploaded a new patch set to
Gerrit, which you can find at http://openocd.zylin.com/4346
-- gerrit
commit 5920e2dfeb8f5db19d62b176b916a1717078
Author: Matthias Welwarsky
Date: Tue Jan 16 13:05:04 2018 +0100
aarch64: clean up scan-build errors
scan-build reported a couple of problems with code in aarch64.c,
this patch cleans them up. No functional changes.
Change-Id: Ie210237ddc840a8bbcd535f86a3a5faf473132f2
Signed-off-by: Matthias Welwarsky
diff --git a/src/target/aarch64.c b/src/target/aarch64.c
index 7665928..f39e2d1 100644
--- a/src/target/aarch64.c
+++ b/src/target/aarch64.c
@@ -635,9 +635,11 @@ static int aarch64_prepare_restart_one(struct target
*target)
armv8->debug_base + CPUV8_DBG_DSCR, dscr);
}
- /* clear sticky bits in PRSR, SDR is now 0 */
- retval = mem_ap_read_atomic_u32(armv8->debug_ap,
- armv8->debug_base + CPUV8_DBG_PRSR, &tmp);
+ if (retval == ERROR_OK) {
+ /* clear sticky bits in PRSR, SDR is now 0 */
+ retval = mem_ap_read_atomic_u32(armv8->debug_ap,
+ armv8->debug_base + CPUV8_DBG_PRSR, &tmp);
+ }
return retval;
}
@@ -1821,6 +1823,8 @@ static int aarch64_write_cpu_memory(struct target *target,
dscr = (dscr & ~DSCR_MA);
retval = mem_ap_write_atomic_u32(armv8->debug_ap,
armv8->debug_base + CPUV8_DBG_DSCR, dscr);
+ if (retval != ERROR_OK)
+ return retval;
if (arm->core_state == ARM_STATE_AARCH64) {
/* Write X0 with value 'address' using write procedure */
@@ -1832,10 +1836,13 @@ static int aarch64_write_cpu_memory(struct target
*target,
/* Write R0 with value 'address' using write procedure */
/* Step 1.a+b - Write the address for read access into DBGDTRRX
*/
/* Step 1.c - Copy value from DTR to R0 using instruction mrc
DBGDTRTXint, r0 */
- dpm->instr_write_data_dcc(dpm,
+ retval = dpm->instr_write_data_dcc(dpm,
ARMV4_5_MRC(14, 0, 0, 0, 5, 0), address);
}
+ if (retval != ERROR_OK)
+ return retval;
+
if (size == 4 && (address % 4) == 0)
retval = aarch64_write_cpu_memory_fast(target, count, buffer,
&dscr);
else
@@ -1947,13 +1954,21 @@ static int aarch64_read_cpu_memory_fast(struct target
*target,
retval = dpm->instr_execute(dpm, ARMV4_5_MCR(14, 0, 0, 0, 5,
0));
}
+ if (retval != ERROR_OK)
+ return retval;
+
/* Step 1.e - Change DCC to memory mode */
*dscr |= DSCR_MA;
retval = mem_ap_write_atomic_u32(armv8->debug_ap,
armv8->debug_base + CPUV8_DBG_DSCR, *dscr);
+ if (retval != ERROR_OK)
+ return retval;
+
/* Step 1.f - read DBGDTRTX and discard the value */
retval = mem_ap_read_atomic_u32(armv8->debug_ap,
armv8->debug_base + CPUV8_DBG_DTRTX, &value);
+ if (retval != ERROR_OK)
+ return retval;
count--;
/* Read the data - Each read of the DTRTX register causes the
instruction to be reissued
@@ -2017,28 +2032,35 @@ static int aarch64_read_cpu_memory(struct target
*target,
/* Read DSCR */
retval = mem_ap_read_atomic_u32(armv8->debug_ap,
armv8->debug_base + CPUV8_DBG_DSCR, &dscr);
+ if (retval != ERROR_OK)
+ return retval;
/* This algorithm comes from DDI0487A.g, chapter J9.1 */
/* Set Normal access mode */
dscr &= ~DSCR_MA;
- retval += mem_ap_write_atomic_u32(armv8->debug_ap,
+ retval = mem_ap_write_atomic_u32(armv8->debug_ap,
armv8->debug_base + CPUV8_DBG_DSCR, dscr);
+ if (retval != ERROR_OK)
+ return retval;
if (arm->core_state == ARM_STATE_AARCH64) {
/* Write X0 with value 'address' using write procedure */
/* Step 1.a+b - Write the address for read access into
DBGDTR_EL0 */
/* Step 1.c - Copy value from DTR to R0 using instruction mrs
DBGDTR_EL0, x0 */
- retval += dpm->instr_write_data_dcc_64(dpm,
+ retval = dpm->instr_write_data_dcc_64(dpm,
ARMV8_MRS(SYSTEM_DBG_DBGDTR_EL0, 0), address);
} else {
/* Write R0 with value 'address' using write procedure */
/* Step 1.a+b - Write the address for read access into
DBGDTRRXint */
/* Step 1.c - Copy value from DTR to R0 using instruction mrc
DBGDTRTXint, r0 */
- retval += dpm->instr_write_data_dcc(dpm,
+ retval = dpm->instr_write_data_dcc(dpm,
[OpenOCD-devel] [PATCH]: b6764ce rtos: fix thread ID handling
This is an automated email from Gerrit.
Richard Braun (rbr...@sceen.net) just uploaded a new patch set to Gerrit, which
you can find at http://openocd.zylin.com/4347
-- gerrit
commit b6764ceb0bafe31d24e0232c7f6c7fa826fc8643
Author: Richard Braun
Date: Mon Jan 8 16:43:15 2018 +0100
rtos: fix thread ID handling
When the RTOS uses addresses as thread identifiers, these values are
usually high, above 2G. For some reason, GDB encodes them using a dash
followed by the two's complement of the actual value, so that e.g.
0xc1f1a204 is encoded as -3e0e5dfc. Because of the negative symbol,
sign extension occurs on the 64-bits output thread ID variable,
preventing any chance to match the thread ID in the future.
This change introduces a small wrapper that first scans the thread ID
into an unsigned 32-bits integer, before assigning this value to a
64-bits signed thread ID.
Change-Id: Ibecc4549a382c6fba97fe41ebfd5f8e12bf1b83e
Signed-off-by: Richard Braun
diff --git a/src/rtos/rtos.c b/src/rtos/rtos.c
index 84ee498..9935997 100644
--- a/src/rtos/rtos.c
+++ b/src/rtos/rtos.c
@@ -101,6 +101,19 @@ static int os_alloc_create(struct target *target, struct
rtos_type *ostype)
return ret;
}
+static int read_threadid(const char *packet, const char *format_prefix,
threadid_t *threadid)
+{
+ char format[64];
+ uint32_t tmp;
+ int ret;
+
+ snprintf(format, sizeof(format), "%s" SCNx32, format_prefix);
+ ret = sscanf(packet, format, &tmp);
+ *threadid = tmp;
+
+ return ret;
+}
+
int rtos_create(Jim_GetOptInfo *goi, struct target *target)
{
int x;
@@ -284,7 +297,7 @@ int rtos_thread_packet(struct connection *connection, char
const *packet, int pa
(target->rtos->thread_count != 0)) {
threadid_t threadid = 0;
int found = -1;
- sscanf(packet, "qThreadExtraInfo,%" SCNx64, &threadid);
+ read_threadid(packet, "qThreadExtraInfo,%", &threadid);
if ((target->rtos != NULL) &&
(target->rtos->thread_details != NULL)) {
int thread_num;
@@ -387,7 +400,7 @@ int rtos_thread_packet(struct connection *connection, char
const *packet, int pa
} else if (packet[0] == 'T') { /* Is thread alive? */
threadid_t threadid;
int found = -1;
- sscanf(packet, "T%" SCNx64, &threadid);
+ read_threadid(packet, "T%", &threadid);
if ((target->rtos != NULL) && (target->rtos->thread_details !=
NULL)) {
int thread_num;
for (thread_num = 0; thread_num <
target->rtos->thread_count; thread_num++) {
@@ -406,7 +419,7 @@ int rtos_thread_packet(struct connection *connection, char
const *packet, int pa
* all other operations ) */
if ((packet[1] == 'g') && (target->rtos != NULL)) {
threadid_t threadid;
- sscanf(packet, "Hg%16" SCNx64, &threadid);
+ read_threadid(packet, "Hg%16", &threadid);
LOG_DEBUG("RTOS: GDB requested to set current thread to
0x%" PRIx64, threadid);
/* threadid of 0 indicates target should choose */
if (threadid == 0)
--
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] ARM Disassembly for PLD commands
So it's a pretty odd use-case, and maybe not worth maintaining (I would obviously vote for keeping it... if I have a vote that is). And maybe there is a smarter / better way to do it. We did investigate using the RPC interface and decided against it (I don't recall the specifics). And maybe there is a way to use Capstone... What about GDB - have you tried it? It has an integrated disassembler. Marc -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Telnet interface is not protected against cross protocol scripting
On 15.01.2018 03:26, Christopher Head wrote: > On January 14, 2018 12:37:53 PM PST, Michael Schwingen > wrote: >> How about a safe mode that disallows "dangerous" commands (eg. those >> that call external programs)? This would be a bit like "-dSAFER" on >> ghostscript, which disallows certain commands when processing untrusted >> input. > That sounds awfully difficult to get right. After all, if I want to steal > your top secret document, all I need available to me is PROGRAM (to put a > copy of said document into the microcontroller) followed by MDW (to read it > back). Limiting file access to a list of configured directories should be enough. However, if you really need this, you can get that now by running OpenOCD in firejail. cu Michael -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Telnet interface is not protected against cross protocol scripting
On January 16, 2018 6:24:31 AM PST, Michael Schwingen wrote: >Limiting file access to a list of configured directories should be >enough. >However, if you really need this, you can get that now by running >OpenOCD in firejail. Firejail looks like it might help. I’m not sure file access or local command execution is the only issue here, though. OpenOCD is a tool for embedded system development. Depending on the nature of said system, granting an attacker access to the target probably allows them to at best create a 3.3-to-ground short on a GPIO and perhaps damage the I/O driver, up to at worst set your desk on fire. I’m not totally convinced that allowing an attacker to do *anything* with OpenOCD is safe. -- Christopher Head -- Christopher Head signature.asc Description: PGP signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] ARM Disassembly for PLD commands
We looked at GDB, but didn't end up having a need for it... because we were already using OpenOCD which has an integrated disassembler. :) On Tue, Jan 16, 2018 at 8:20 AM, Marc Schink wrote: > So it's a pretty odd use-case, and maybe not worth maintaining (I would >> obviously vote for keeping it... if I have a vote that is). And maybe there >> is a smarter / better way to do it. We did investigate using the RPC >> interface and decided against it (I don't recall the specifics). And maybe >> there is a way to use Capstone... >> > > What about GDB - have you tried it? It has an integrated disassembler. > > Marc > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > OpenOCD-devel mailing list > OpenOCD-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openocd-devel > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
[OpenOCD-devel] [PATCH]: 8414054 topic: Add PLD command to ARM disassembler.
This is an automated email from Gerrit.
James (jcma...@gwmail.gwu.edu) just uploaded a new patch set to Gerrit, which
you can find at http://openocd.zylin.com/4348
-- gerrit
commit 8414054381f15cd16e9f4bb222e2e902815fc1cb
Author: James Marshall
Date: Tue Jan 16 21:08:16 2018 -0500
topic: Add PLD command to ARM disassembler.
Updates the ARM disassembler to handle PLD (PreLoad Data) commands.
Previously handled by printing a TODO message. There are three forms of the
command: literal, register, and immediate. Simply decode based off of the A1
encoding for the instructions in the ARM ARM.
Change-Id: I63bf97f16af254e838462c7cfac80f6c4681c556
Signed-off-by: James Marshall
diff --git a/src/target/arm_disassembler.c b/src/target/arm_disassembler.c
index ef69a20..0dc6792 100644
--- a/src/target/arm_disassembler.c
+++ b/src/target/arm_disassembler.c
@@ -118,15 +118,78 @@ static int evaluate_pld(uint32_t opcode,
uint32_t address, struct arm_instruction *instruction)
{
/* PLD */
- if ((opcode & 0x0d70f000) == 0x0550f000) {
+ if ((opcode & 0x0d50f000) == 0x0550f000) {
+ uint8_t Rn;
+ uint8_t U;
+ unsigned offset;
+
instruction->type = ARM_PLD;
+ Rn = (opcode & 0xf) >> 16;
+ U = (opcode & 0x0080) >> 23;
+ if (Rn == 0xf) {
+ /* literal */
+ offset = opcode & 0x0fff;
+ snprintf(instruction->text, 128,
+"0x%8.8" PRIx32 "\t0x%8.8" PRIx32 "\tPLD %s%d",
+address, opcode, U ? "" : "-", offset);
+ } else {
+ uint8_t I, R;
- snprintf(instruction->text,
- 128,
- "0x%8.8" PRIx32 "\t0x%8.8" PRIx32 "\tPLD
...TODO...",
- address,
- opcode);
+ I = (opcode & 0x0200) >> 25;
+ R = (opcode & 0x0040) >> 22;
+
+ if (I) {
+ /* register PLD{W} [,+/-{, }] */
+ offset = (opcode & 0x0F80) >> 7;
+ uint8_t Rm;
+ Rm = opcode & 0xf;
+
+ if (offset == 0) {
+ /* No shift */
+ snprintf(instruction->text, 128,
+"0x%8.8" PRIx32 "\t0x%8.8"
PRIx32 "\tPLD%s [r%d, %sr%d]",
+address, opcode, R ? "" : "W",
Rn, U ? "" : "-", Rm);
+
+ } else {
+ uint8_t shift;
+ shift = (opcode & 0x60) >> 5;
+ if (shift == 0x0) {
+ /* LSL */
+ snprintf(instruction->text, 128,
+"0x%8.8" PRIx32
"\t0x%8.8" PRIx32 "\tPLD%s [r%d, %sr%d, LSL #0x%x)",
+address, opcode, R ?
"" : "W", Rn, U ? "" : "-", Rm, offset);
+ } else if (shift == 0x1) {
+ /* LSR */
+ snprintf(instruction->text, 128,
+"0x%8.8" PRIx32
"\t0x%8.8" PRIx32 "\tPLD%s [r%d, %sr%d, LSR #0x%x)",
+address, opcode, R ?
"" : "W", Rn, U ? "" : "-", Rm, offset);
+ } else if (shift == 0x2) {
+ /* ASR */
+ snprintf(instruction->text, 128,
+"0x%8.8" PRIx32
"\t0x%8.8" PRIx32 "\tPLD%s [r%d, %sr%d, ASR #0x%x)",
+address, opcode, R ?
"" : "W", Rn, U ? "" : "-", Rm, offset);
+ } else if (shift == 0x3) {
+ /* ROR */
+ snprintf(instruction->text, 128,
+"0x%8.8" PRIx32
"\t0x%8.8" PRIx32 "\tPLD%s [r%d, %sr%d, ROR #0x%x)",
+address, opcode, R ?
"" : "W", Rn, U ? "" : "-", Rm, offset);
+ }
+ }
+ } else {
+ /* immediate PLD{W} [, #+/-] */
+ offset = opcode &
[OpenOCD-devel] [openocd:tickets] #172 OpenOCD does not work on Windows 10 for ti-icdi & tm4c1294
--- ** [tickets:#172] OpenOCD does not work on Windows 10 for ti-icdi & tm4c1294** **Status:** new **Milestone:** 0.9.0 **Labels:** Windows 10 **Created:** Wed Jan 17, 2018 06:37 AM UTC by Kishore Luthra **Last Updated:** Wed Jan 17, 2018 06:37 AM UTC **Owner:** nobody OpenOCD does not work for TI ICDI interface and board configuration ek-tm4c1294xl.cfg on Windows 10, although the same configuration and interface works well on Windows 7. It gives error in opening and with error in init and ocd_bouncer --- Sent from sourceforge.net because openocd-devel@lists.sourceforge.net is subscribed to https://sourceforge.net/p/openocd/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/openocd/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.-- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
