From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 39528 invoked by alias); 23 Mar 2017 14:33:41 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 38888 invoked by uid 89); 23 Mar 2017 14:33:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.0 required=5.0 tests=BAYES_20,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=*new*, *NEW*, chips, duane X-HELO: p3plsmtpa12-07.prod.phx3.secureserver.net Received: from p3plsmtpa12-07.prod.phx3.secureserver.net (HELO p3plsmtpa12-07.prod.phx3.secureserver.net) (68.178.252.236) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 23 Mar 2017 14:33:38 +0000 Received: from [10.0.0.101] ([172.14.36.47]) by :SMTPAUTH: with SMTP id r3nWcmvAYJndVr3nWcPp0P; Thu, 23 Mar 2017 07:33:07 -0700 X-Sender: duane@duaneellis.com Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: [OpenOCD-devel] Python API for supplying thread information? From: Duane Ellis In-Reply-To: <86mvccuszh.fsf@gmail.com> Date: Thu, 23 Mar 2017 14:33:00 -0000 Cc: Freddie Chopin , gdb@sourceware.org, Phil Muldoon , openocd-devel@lists.sourceforge.net Content-Transfer-Encoding: quoted-printable Message-Id: References: <1490175792.1242.7.camel@op.pl> <4b310e40-3f39-feed-6134-d2cfe68c4423@redhat.com> <1490199596.1410.3.camel@op.pl> <86mvccuszh.fsf@gmail.com> To: Yao Qi X-CMAE-Envelope: MS4wfLSJnuHJiEDStGkwt4cmeBmmhYqiNhBDDW3VB/8gdeM3GUaLK4bBKMaQRseUC5eH1sY24mWQMR4I3QyQsMo9dzx+rFZj5dHTMahigR412fi70nCJlBp+ Hjw6AG8XkA3AZnrZUo1PteWsx+V0M1C4OUJQtQcDhHanXJbGnavtXsgw3Jg7TjHxktLSqctCx8lSMffO4LLsplxD0491xACqY0VcSoOrPfTKlRBZo7EGKH8k TqHnvrQoRoSXTY2AQet7PkcTFXlWeAgz45yS/ZHgbKHfN2Y2UO5dn/Le/PRwwCYnAvSH95b5U2rTq01e1rXwaQ== X-SW-Source: 2017-03/txt/msg00048.txt.bz2 Hi - I=E2=80=99ve been following this thread A while ago - I proposed a very different architecture that would solve a l= ot of this. Fundamentally, there are two processes: (A) The GDB process and (B) the G= DBSERVER process. When debugging an application that runs under a true OS (such as linux) thi= s 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 v= ery different. The problem is these things are two processes that cannot share knowledge o= f each other,=20 The current architecture is this: At the =E2=80=9Ctarget remote=E2=80=9D -= level - GDB sends various packets like Register Read/Write, Memory Read/W= rite packet. The problem is you need to write lots of GDB Protocol addition= s to add features - these extra things are not (and never) required when de= bugging an application under and Operating system. It is more then just =E2= =80=9Cthread level information=E2=80=9D - it extends to hardware registers,= MMU state, Cache Information - things that an application debugger never s= ees and never uses. In the current architecture it is the job of the GDB SERVER to translate th= ese 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 the= re are not that many of of these things. It works great for apps because th= ere are very few of these things to write, and you are talking to an OS=E2= =80=A6 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 w= hen we talk about the RTOS support, every GDBSERVER solution has to write i= ts own version of the RTOS support. Don=E2=80=99t forget about MMU level i= nspection, or Cache Debugging. These are things an APPLICATION level debugg= er never sees - a bare metal debugger sees these things all the time (of co= urse 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 f= or some complex bare metal things - and that is what this thread is about. What I proposed a while back was this: What if we=20 1) introduced a =E2=80=9CJTAG/SWD=E2=80=9D protocol instead. For ARM (Cort= ex)- 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 =E2=80=98downgr= aded to JTAG=E2=80=99 - 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 operat= ions in python, the bottom layer of that python implementation would send J= TAG or SWD commands over the wire instead of =E2=80=9Cmemory read=E2=80=9D = and =E2=80=9Cregister read/write=E2=80=9D packets. The advantage I see is this: GDB can be come very aware of the target MMU, for example - GDB can wal= k 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 writ= ten once - in Python - for all targets. All of this is =E2=80=9Cwrite once=E2=80=9D and it works - in one commo= n way at the Python layer in GDB. -Duane.