[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20071201074044.GA13974@elte.hu>
Date: Sat, 1 Dec 2007 08:40:46 +0100
From: Ingo Molnar <mingo@...e.hu>
To: "Metzger, Markus T" <markus.t.metzger@...el.com>
Cc: Andi Kleen <ak@...e.de>, tglx@...utronix.de,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, hpa@...or.com,
"Siddha, Suresh B" <suresh.b.siddha@...el.com>,
Michael Kerrisk <mtk-manpages@....net>,
markus.t.metzger@...il.com, Roland McGrath <roland@...hat.com>
Subject: Re: [patch 0/2] x86, ptrace: support for branch trace store(BTS)
* Ingo Molnar <mingo@...e.hu> wrote:
> > Our debugger team has a prototype implementation for their debugger.
> > But that will not be available for some time.
> >
> > I hope that we get gdb support, soon, but that would take a while if
> > I had to do it.
>
> i'm wondering what the main use-case would be then, and what the gdb
> folks think about the current API. (Roland?)
here's a forwarded mail from Roland about the patch and APIs. (and i
hope that now i can stop playing the middleman, with everyone Cc:-ed :)
------------>
From: Roland McGrath <roland@...hat.com>
Subject: Re: [patch][v2] x86, ptrace: support for branch trace store(BTS)]
Cool. It's been on my list to look into exposing those features
somehow. I hadn't planned on doing it until after the utrace stuff
settles and there is a more coherent interface context in which to do
it.
If they are tackling the MSR hacking and context switch and so forth,
I'd like to see them start out by just adding block-step
(debugctlmsr.btf) with the PTRACE_SINGLEBLOCK interface as ia64 has.
That should lay some of the same groundwork needed here, but is much
simpler.
I am not really in favor of this new ptrace interface. I think they
should look around across arch's and think about sane general-purpose
interfaces for features of this kind that might be built with some
commonality across machines. Also do it in a layered way from
low-level, with something usable for kernel-mode too. The discussion
Alan Stern and I had on LKML that started as kwatch and became
hw_breakpoint is an example of how I would go at this set of features
too.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists