Re: RFC GDB Linux Awareness analysis

[Duane Ellis <duane@duaneellis.com>]

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 
	By raw RAMDUMP - assume the target has a 1GIG memory, the raw ram dump file 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 = linux, core 1= dedicated video)

2) These other things need to be examined “in context” 
	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 ascii text

3) GDB - generally as stated in the caldron slide deck is a “application debugger” 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 hypervisor call
	And debug each of these situations within their separate (and different) contexts.

4) In the bare metal world - GDB has a really big (fundamental) problem - GDB thinks an address is a integer
    These problems exist during *LIVE* debug of a target, and during postmortem 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 call these “memory 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 configuration
	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’s 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 *where* 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 “read memory request” 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 solution 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/build-specific data file with structure definition
	These scripts that I talk about, could read the ‘build-specific’ data file 
	(more about this later)

7) A good example of scripting is during postmortem debug 
	GDB cannot call (execute) a helper function within the target because the target is not “live”
	Thus, many of these things have to be written on the host side

	Writing this in C is painful…  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 
	For example - how do you specify a memory access for a memory (variable) dump (or watch) window?
	
	There are other interesting windows - things that display CPU configuration registers
	(ie: MMU enable/disable, cache control,  the list goes on)
	
	I’m 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 “phys_pointer”  I want to cast this to a C data structure
	But - some variables are accessed via “the current [default] memory configuration”
	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 “bare metal friendly”  or at least “bare metal aware"

2) 	GDB fundamentally needs the ability to specify the 3 missing elements to 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 “memory class”
	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’s 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 ‘gdb-remote’ 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 within that structure (data pointer) 
	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’s an example (finger print)
	http://www.analog.com/library/analogdialogue/archives/42-07/fingerprint.html

	This is not limited to BARE METAL - what about applications that manipulate 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 impossibly 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 present…. Grrr...
	
	In order to solve these bare-metal problems somebody needs to write code to make it happen.
	In effect, these would be “bare metal plugin” features

	You could think of “image processing” or “DSP aware” 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