[OpenOCD-devel] Python API for supplying thread information?

[Duane Ellis]

Hi - I’ve been following this thread

A while ago - I proposed a very different architecture that would solve a lot of this.

Fundamentally, there are two processes:   (A) The GDB process and (B) the GDBSERVER process.
When debugging an application that runs under a true OS (such as linux) this works great.

But - when debugging anything bare metal, and that includes things like the Linux Kernel, and just about any RTOS in any micro-controller things are very different.

The problem is these things are two processes that cannot share knowledge of each other, 

The current architecture is this:  At the “target remote” - level - GDB sends various packets like Register Read/Write,  Memory Read/Write packet. The problem is you need to write lots of GDB Protocol additions to add features - these extra things are not (and never) required when debugging an application under and Operating system. It is more then just “thread level information” - it extends to hardware registers, MMU state, Cache Information - things that an application debugger never sees and never uses.

In the current architecture it is the job of the GDB SERVER to translate these extra packets in to the actual operation. This makes sense when you are talking about a OS-APP-TARGET (i.e.: Windows, Linux, Mac, Cellphone apps)  The OS solution is written once and is reused over and over again. And there are not that many of of these things. It works great for apps because there are very few of these things to write, and you are talking to an OS… not bare metal..

In the bare metal case, there are countless GDB SERVERS - and every one has to duplicate the process, the features and the packets. It is even worse when we talk about the RTOS support, every GDBSERVER solution has to write its own version of the RTOS support.  Don’t forget about MMU level inspection, or Cache Debugging. These are things an APPLICATION level debugger never sees - a bare metal debugger sees these things all the time (of course depending on the chip, i.e.: ARMV8 kernel debug, vrs CortexM3 debug).

Bottom line: I believe the current gdb server solution is not well suited for some complex bare metal things - and that is what this thread is about.

What I proposed a while back was this:

What if we 

1) introduced a “JTAG/SWD” protocol instead.  For ARM (Cortex)- bare metal - all operations there are a series of DAP operations. i.e.: Dap Read/Dap Write.

2) For JTAG based chips (i.e.: earlier ARM 9 chips, Mips chips, etc) there are a number of JTAG level protocols (XILINX for example has a SOCKET based solution)

3) For SWD (cortex) based chips - all SWD operations can be ‘downgraded to JTAG’ - by a shim layer if needed.

4) Then - write a *NEW* target layer in GDB that uses this new protocol and effectively implement the memory read/write and register read/write operations in python, the bottom layer of that python implementation would send JTAG or SWD commands over the wire instead of “memory read” and “register read/write” packets.

The advantage I see is this:

    GDB can be come very aware of the target MMU, for example - GDB can walk through all of the ARMv8 Hypervisor and

    All of this is in one process - not spread across a protocol.

    You have a simple common (and rich) script language (i.e.: Python) that lets one write some major scripts once - for all bare metal targets.

    Flash programing operations (very common in micro-controllers) are written once - in Python - for all targets.

    All of this is “write once” and it works - in one common way at the Python layer in GDB.

-Duane.