Re: RFC GDB Linux Awareness analysis

[Doug Evans <dje at google dot com>]

On Wed, Sep 30, 2015 at 9:41 AM, Duane Ellis <duane@duaneellis.com> wrote:
> I would offer the following for GDB Kernel Dump analysis - there is *a*lot* more that is needed.
> ...
> 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

The extent to which gdb is not a bare metal debugger is IMO mostly
driven by patches.
Application level debugging gets more attention.
But if reasonable patches came our way I would certainly approve them.
[The devil is, again, in the details of course.
One of the harder parts of hacking on gdb is that you can't break, or
make harder,
any of the other of the myriad of supported use cases, some of which are so
old it's a crime that we're still having to put time into them (IMO).]

> 4) In the bare metal world - GDB has a really big (fundamental) problem - GDB thinks an address is a integer

This has been an off and on discussion in gdb since at least as far
back as Cygnus days. :-)
No disagreement here that we have the wrong kind of abstraction for an address.

> 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)

I'd like to see a world where we actually open up gdb innards more,
instead of providing
an API on top of a closed system. The scripting possibilities would
increase by at least
an order of magnitude.

> 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â

Depends on what the helper function does of course.
E.g., it's possible to resurrect a corefile (assuming it hasn't been
truncated, etc.)
enough to run a pretty-printer contained in the app (as opposed to in python).

> 4) GDB does not currently expose enough via the scripting interface
>         As I stated above - attitudes need to change about GDB

No disagreement here.