This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: RFC GDB Linux Awareness analysis
- From: Duane Ellis <duane at duaneellis dot com>
- To: Peter Griffin <peter dot griffin at linaro dot org>
- Cc: Andreas Arnez <arnez at linux dot vnet dot ibm dot com>, gdb at sourceware dot org, lee dot jones at linaro dot org
- Date: Wed, 30 Sep 2015 09:41:29 -0700
- Subject: Re: RFC GDB Linux Awareness analysis
- Authentication-results: sourceware.org; auth=none
- References: <20150603142858 dot GA19370 at griffinp-ThinkPad-X1-Carbon-2nd> <m3d1yhhlav dot fsf at oc1027705133 dot ibm dot com> <20150930132729 dot GB26183 at griffinp-ThinkPad-X1-Carbon-2nd>
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