Hi Folks,
Any chance that this patch could get pulled?
http://openocd.zylin.com/#/c/4348/
I took a look into using GDB for disassembly, but ran into issues with it:
GDB is doing something in the background that is impacting the L2 cache
controller counters. This makes OpenOCD the best solution
Hi Folks,
This was a pretty small patch adding PLD support to the arm disasembler (
http://openocd.zylin.com/#/c/4348/), and it would be nice to either:
a) Get it pulled into the main repo so people using the dissasembler don't
get a "TODO" message
-or-
b) Have the disassembly feature cut so
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
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
Whoa, geez... ask about a feature and it gets cut?! Just kidding.
I'm working on a project to inject bit flips into caches. We're using
OpenOCD to run the target program one step at a time and build a database
of all memory accesses. For each line of code, we disassemble it, and if it
touches
Hi,
are there good reasons why we need (ARM) disassembly integrated in
OpenOCD? As Paul already said, there are awesome external
tools/libraries like Capstone.
If there are no good reasons, I would vote to remove the disassembly
features in near future rather than extending it because it
Hello James,
On Sat, Jan 13, 2018 at 06:20:05PM -0500, James Marshall wrote:
> I found the "...TODO..." in srt/target/arm_disassembler.c.
> Do you know when this may be implemented? If I attempt to implement it, are
> there any pitfalls I should know about (I'm assuming that there is something
>