From: Andreas Arnez <arnez@linux.vnet.ibm.com>
To: Peter Griffin <peter.griffin@linaro.org>
Cc: gdb@sourceware.org, lee.jones@linaro.org
Subject: Re: RFC GDB Linux Awareness analysis
Date: Fri, 02 Oct 2015 10:56:00 -0000 [thread overview]
Message-ID: <m38u7llet5.fsf@oc1027705133.ibm.com> (raw)
In-Reply-To: <20150930132729.GB26183@griffinp-ThinkPad-X1-Carbon-2nd> (Peter Griffin's message of "Wed, 30 Sep 2015 14:27:29 +0100")
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
next prev parent reply other threads:[~2015-10-02 10:56 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20150603142858.GA19370@griffinp-ThinkPad-X1-Carbon-2nd>
2015-08-20 18:22 ` Andreas Arnez
2015-09-30 13:27 ` Peter Griffin
2015-09-30 16:41 ` Duane Ellis
2015-10-05 18:32 ` Doug Evans
2015-10-01 9:25 ` Yao Qi
2015-10-02 10:56 ` Andreas Arnez [this message]
2015-10-05 18:54 duane
2015-10-05 19:41 ` Doug Evans
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m38u7llet5.fsf@oc1027705133.ibm.com \
--to=arnez@linux.vnet.ibm.com \
--cc=gdb@sourceware.org \
--cc=lee.jones@linaro.org \
--cc=peter.griffin@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).