Re: [patch 0/2] x86, ptrace: support for branch trace store(BTS)

From: Ingo Molnar <mingo@elte.hu>
To: "Metzger, Markus T" <markus.t.metzger@intel.com>
Cc: Andi Kleen <ak@suse.de>,
	tglx@linutronix.de, Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, hpa@zytor.com, "Siddha,
	Suresh B" <suresh.b.siddha@intel.com>,
	Michael Kerrisk <mtk-manpages@gmx.net>,
	markus.t.metzger@gmail.com, Roland McGrath <roland@redhat.com>
Subject: Re: [patch 0/2] x86, ptrace:  support for branch trace store(BTS)
Date: Sat, 1 Dec 2007 08:40:46 +0100	[thread overview]
Message-ID: <20071201074044.GA13974@elte.hu> (raw)
In-Reply-To: <20071130170655.GA10868@elte.hu>

* Ingo Molnar <mingo@elte.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@redhat.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.