From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 61387 invoked by alias); 30 Sep 2015 16:41:36 -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 61373 invoked by uid 89); 30 Sep 2015 16:41:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.8 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 X-HELO: p3plsmtpa12-02.prod.phx3.secureserver.net Received: from p3plsmtpa12-02.prod.phx3.secureserver.net (HELO p3plsmtpa12-02.prod.phx3.secureserver.net) (68.178.252.231) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 30 Sep 2015 16:41:33 +0000 Received: from [10.0.0.101] ([99.26.121.120]) by p3plsmtpa12-02.prod.phx3.secureserver.net with id PUhW1r0042bxR8r01UhX9u; Wed, 30 Sep 2015 09:41:32 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: RFC GDB Linux Awareness analysis From: Duane Ellis In-Reply-To: <20150930132729.GB26183@griffinp-ThinkPad-X1-Carbon-2nd> Date: Wed, 30 Sep 2015 16:41:00 -0000 Cc: Andreas Arnez , gdb@sourceware.org, lee.jones@linaro.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150603142858.GA19370@griffinp-ThinkPad-X1-Carbon-2nd> <20150930132729.GB26183@griffinp-ThinkPad-X1-Carbon-2nd> To: Peter Griffin X-IsSubscribed: yes X-SW-Source: 2015-09/txt/msg00036.txt.bz2 I would offer the following for GDB Kernel Dump analysis - there is *a*lot*= more that is needed. 1) It is not uncommon to have a raw ram dump of the running system captured= by some other means This RAMDUMP can be loaded into some type of CPU or MEMORY simulator=20 By raw RAMDUMP - assume the target has a 1GIG memory, the raw ram dump fil= e is exactly 1 gig And - may contain the contexts of other non-linux memory sections Other non-linux components examples include: GPU state, power management processor state, DSP state Or perhaps a video processing subsystem (ie: AMP core 0 =3D linux, core = 1=3D dedicated video) 2) These other things need to be examined =E2=80=9Cin context=E2=80=9D=20 That context might be a different endian order A different instruction set Or different structure packing rules Or perhaps they are encoded logs that need to be converted to readable asc= ii text 3) GDB - generally as stated in the caldron slide deck is a =E2=80=9Capplic= ation debugger=E2=80=9D it is not a bare metal debugger I cannot agree with this more - and it is a fundamental limitation for GDB And it is the source of much of the attitude about what gets done with GDB Crashdump is exactly a bare metal debug situation But you can also think about live target debug. Example: Step through user space into the kernel, and perhaps into a hype= rvisor call And debug each of these situations within their separate (and different) c= ontexts. 4) In the bare metal world - GDB has a really big (fundamental) problem - G= DB thinks an address is a integer These problems exist during *LIVE* debug of a target, and during postmo= rtem debug analysis of a crash dump LLDB has the same issue. It is not - an address in bare metal consists of 3 components, I would cal= l these =E2=80=9Cmemory access attributes": Component (A) the integer like index into the memory region Component (B) The route or memory region identifier Component (C) Attributes specific to the memory region Some examples include: ARM Trust Zone - secure vrs non-secure access (dump logs in trust zone) Dump context of non-active thread in that threads virtual memory configura= tion Some SOCs include alternate access means to memory For example an ARM SoC has the CPU memory aperture (view) of system memory And the ARM SoC may have the DAP=E2=80=99s view of memory access. Access to system registers of some type (i.e.: ARM mrc/mcr/mrs/msr, other= cpus have other forms) 5) In the crash dump case, the memory emulation system needs to be told *wh= ere* is the active MMU table The memory simulation needs a means to set the mum translation table base = register(s) In the crash dump case, GDB will issue a =E2=80=9Cread memory request=E2= =80=9D to examine a data structure. The memory simulation needs to perform MMU page table walks 6) Lots of the above needs to be scripted (i.e.: Python is a great solutio= n here, but is not always present) And - these scripts could be provided by the Linux Kernel build process Specifically: The kernel build process should produce an architecture/buil= d-specific data file with structure definition These scripts that I talk about, could read the =E2=80=98build-specific=E2= =80=99 data file=20 (more about this later) 7) A good example of scripting is during postmortem debug=20 GDB cannot call (execute) a helper function within the target because the = target is not =E2=80=9Clive=E2=80=9D Thus, many of these things have to be written on the host side Writing this in C is painful=E2=80=A6 Python offers some better solution = and increased flexibility 7) We are talking here about a command line, ascii text interface for GDB There is another slew of implications when you add a GUI window=20 For example - how do you specify a memory access for a memory (variable) d= ump (or watch) window? =09 There are other interesting windows - things that display CPU configuratio= n registers (ie: MMU enable/disable, cache control, the list goes on) =09 I=E2=80=99m debugging a kernel - so these things are relevant to the debug= session And thus the debugger should provide a means to access these items 8) The GDB expression parser (ie: address parser) needs to support casting= to a memory address with attributes For example: I have a =E2=80=9Cphys_pointer=E2=80=9D I want to cast this= to a C data structure But - some variables are accessed via =E2=80=9Cthe current [default] memor= y configuration=E2=80=9D But other variables {the one I just cast) needs to use a different memory = access configuration So what is the way out of this: 1) GDB needs to become more =E2=80=9Cbare metal friendly=E2=80=9D or at le= ast =E2=80=9Cbare metal aware" 2) GDB fundamentally needs the ability to specify the 3 missing elements t= o an address. This needs to become pervasive throughout GDB This is not a simple change - but a means needs to be created Example: The commercial debugger from lauterbach use what they call a =E2=80=9Cmemo= ry class=E2=80=9D In that debugger the feature is pervasive - every target SYMBOL can have = an access attribute Memory display windows have attributes Items in a dialog box (i.e.: CPU register view window) can have attributes 3) Some attitudes need to change about where things belong Some argue that feature (X) belongs in the gdb server And others say (Y) belongs in the GUI side of things I agree - architecturally some of these things belong in those other places But these do not address the scripting problem. Here=E2=80=99s an example: My target performs image or video processing With GDB - we are talking about 3 separate processes. The GUI, GDB it self, and the =E2=80=98gdb-remote=E2=80=99 or simulation = process I want to point at a physical memory location( the image buffer ) That memory buffer could be video bit planes, or RGBA data Or maybe it is some software defined radio data stream Accessing this might require starting with a data structure, an element wi= thin that structure (data pointer)=20 I can now access that memory - I have the data in Python array of some type Can I use the graphics library in Python to display my image or wave form? Can I use Python graphics to create a task switch timeline graph? Here=E2=80=99s an example (finger print) http://www.analog.com/library/analogdialogue/archives/42-07/fingerprint.ht= ml This is not limited to BARE METAL - what about applications that manipulat= e images? How can I write *ONE* script that controls all three execution processes: The GUI - eclipse or DDD or something else GDB - the core, what we talk about here GDB-REMOTE - which might be a JTAG thing, or a SIMULATION thing Attitudes that keep these separate make scripting these solutions impossib= ly hard 4) GDB does not currently expose enough via the scripting interface As I stated above - attitudes need to change about GDB LLDB suffers from this also - i.e.: It needs to work when Python is not pr= esent=E2=80=A6. Grrr... =09 In order to solve these bare-metal problems somebody needs to write code t= o make it happen. In effect, these would be =E2=80=9Cbare metal plugin=E2=80=9D features You could think of =E2=80=9Cimage processing=E2=80=9D or =E2=80=9CDSP awar= e=E2=80=9D features as another plugin. Python offers that plugin solution :-) 5) The GDB server thing (for jtag/bare metal) needs to change But that is a discussion for a different day and a different email chain -Duane