This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: RFC GDB Linux Awareness analysis
- From: Andreas Arnez <arnez at linux dot vnet dot ibm dot com>
- To: Peter Griffin <peter dot griffin at linaro dot org>
- Cc: gdb at sourceware dot org, lee dot jones at linaro dot org
- Date: Fri, 02 Oct 2015 12:56:06 +0200
- 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>
On Wed, Sep 30 2015, Peter Griffin wrote:
> Hi Andreas,
>
> On Thu, 20 Aug 2015, Andreas Arnez wrote:
>
> [...]
>> So I believe posting the patches to get more feedback would be
>> worth-while.
>
> Ok, so the existing LKD code is on quite an old GDB version
> (7.6). Also the whole LKD patchset is currently quite large (15k
> LoC). So my plan was to try and reduce this as much as possible by
> removing parts of LKD that can (or already have) python
> implementations e.g. dmesg.
>
> Essentially the aim would be to try and reduce the LKD patchset as
> much as possible to the "core features" which I consider to be task
> awareness and loadable module support. At this point we could look at
> what might need adding to the GDB python API to migrate even more
> parts into python.
>
> Posting the whole patchset currently would involve porting to the
> latest GDB version and before doing that I'd like to get a better idea
> of what parts are likely to need re-writing or at least only ports the
> necessary parts.
I suggest to start with a small patch set that can be reviewed easily --
and changed, if necessary. Such as loadable modules support, or
whatever else you deem best suited for laying the foundations for this
project. And then see how it goes.
>[...]
>
> Does anyone have experience / thoughts on how often the existing threading
> implementations that are already inside GDB break? Presumably these are also
> tightly coupled to parsing out of tree data structures (or the libraries which
> GDB relies on to do this).
>
> I'm trying to get a feel for what the current maintenance burden is like having
> these implementations in C.
A user-space runtime usually has some sort of "debug interface" which
gives certain guarantees about reliable breakpoint targets and data
structure layouts. Such a convention allows the GDB support to stay
pretty stable.
Ideally the Linux kernel runtime provides a similar interface. For
instance, see the description of do_init_module() in module.c:
/*
* This is where the real work happens.
*
* Keep it uninlined to provide a reliable breakpoint target, e.g. for the gdb
* helper command 'lx-symbols'.
*/
One thing we haven't addressed so far is testing. Usually a new GDB
feature should come with a regression test case, such that it's less
likely to break after unrelated changes.
Maybe we can put various vmlinux- and associated crash dump binaries
into the test suite, along with a test case that loads/analyzes those.
However, such binaries can grow fairly large (many Giga- or even
Terabytes), so I'm not sure whether this is a viable option. Maybe
remove everything from the binaries that is irrelevant to the test case?
Other ideas for testing?
--
Andreas