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.
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel
