Changing the subject line to reflect a very different chain of thought On May 3, 2014, at 11:43 PM, Paul Fertser <[email protected]> wrote:
>> Are you familiar with Rube Goldberg Designs … A very american >> cartoon. (British may recognize: W. Heath Robinson) > > Hehe, fascinating. I hope my proposal to have an openocd instance per > jtag chain is actually not that bizarre, and it's way easier to > implement compared to possible alternatives. > > Let's see what the others have to say though, it's quite likely I'm > just stuck now on my "simple" solution and can't see anything past it. This is *NOT* a bad idea - but I think OpenOCD is not ready for it yet. There are structural problems on all ends of the gdb/openocd world , and this is just one of them. If you think about the entire end-to-end solution you can see all kinds of issues, I like to focus on “scripting” as the way to tie things together end to end Part 1) Start at the GUI for the debugger, what script language can I use to create dialog boxes? I mean something simple that helps me automate my task. Maybe I want to be able to examine the hardware registers in a GUI window of some type. What “language” do I use to do this? OpenOCD: No GUI ability, GDB: no Physical Memory access ability, GDB/GUI: Cross language issues Part 2) Generally, the user(victim)’s interface to the target is the debugger command line access, typing commands - etc. That is yet another scripting language OpenOCD: JimTCL, GDB: custom(newer: A python interface), LLDB: Python based, Eclipse: JAVA, Part 3) Sadly, there are factions within the GDB-GUI that refuse any and all access to the GDB command line (http://www.kdbg.org/todo.php, see: NOT todo) this rules out automation - and helpful scripts. Reminds me of the USA TV show Seinfeld character http://en.wikipedia.org/wiki/The_Soup_Nazi Part 4) Generally, GDB is designed to debug a single APP running under an Operating system and cannot think in of other terms, there is no such thing as bare-metal. GDB is getting better, but it has a very long way to go. Part 5) GDB has no concept of different memory spaces, and memory access methods. Examples include: Physical Memory Window verses a Virtual Window. With the newer ARM cpus, you also have “secure access” vrs “non-secure” access - GDB has no concept … and how do I create a GUI window for this? Part 6) How can I specify a “variable view” window that displays physical memory? Can i click on a pointer in a structure and traverse a pointer chain via physical, or secure memory accesses. OpenOCD: Does not understand variables, GDB: Does not understand GUI or Physical Memory, Existing GUIs: Agh… forget about it Part 7) It would be great to have the ability to “dump cache” (in a memory dump window, highlighting the dirty/clean/valid rows) - and having a second window that lets me see physical memory. Have you ever debugged cache problems? Very non-trivial work. === I could go on, but I think you get the idea - in some ways, the current architecture is a dead end or has some very insurmountable obstacles. === Now, go back up the food chain a little bit, I want to paint a picture of a completely different architecture that solves the above problems What if Debugger/GUI had the same scripting language? (i.e.: Python, GDB has this, LLDB is based on Python?) What if debugger understood memory attributes? (i.e.: Address = HASH or DICT address & attributes) Load PyTK - or PyGTK - we have a gui - with debugger and target control with a unified scripting language! What if we split OpenOCD into two parts - exactly like you describe. Today, OpenOCD is a monolithic beast. We split at the interface level - and create an RPC level access to the interface. Two important RPC requests would be: LOCK the interface and UNLOCK the interface. That is *EXACTLY* what you are describing - by having a separate instance of OPENOCD… exposing an RPC-INTERFACE Next: convert OpenOCD into a PYTHON plugin in some form (Oyvind talked about libopenocd a while ago) It would not be simple, it would mean jettisoning JIM-TCL - and going with a completely different language. Now we have the same scripting language as the debugger, in fact - the debugger could load OpenOCD as a PY-MODULE and we could now create a unified scripting language that is first class, the same language constructs that work *end*to*end* across the debug landscape. Now, OpenOCD has a Python based GUI - that is a huge win. When the debugger starts, and loads the PY_MODULE(openocd) - it could option(a) connect to an existing interface RPC, or (b) launch/create a new interface RPC For the non-DEBUGGER case (i.e.: FPGA programing, SPI flash programing, etc) - the same PY_MODULE can be reused - very cleanly. Yea, far fetched and a blue sky dream and not simple to change. The key is exactly splitting OPENOCD into two components, creating the “INTERFACE-RPC” and the DEBUG component - exactly where you say to split it. -Duane ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
