Support for Intel's last branch recording to ptrace. This gives debuggers
access to this hardware feature and allows them to show an execution trace
of the debugged application.
Last branch recording (see section 18.5 in the Intel 64 and IA-32
Architectures Software Developer's Manual) allows
>-Original Message-
>From: Andi Kleen [mailto:[EMAIL PROTECTED]
>Sent: Montag, 3. Dezember 2007 17:22
>> What did you have in mind when you asked for kernel-mode support?
>
>I asked about that earlier too and I would like to see per CPU traces
>for ring 0 with some way to dump that on
-Original Message-
From: Andi Kleen [mailto:[EMAIL PROTECTED]
Sent: Montag, 3. Dezember 2007 17:22
What did you have in mind when you asked for kernel-mode support?
I asked about that earlier too and I would like to see per CPU traces
for ring 0 with some way to dump that on crashes
Support for Intel's last branch recording to ptrace. This gives debuggers
access to this hardware feature and allows them to show an execution trace
of the debugged application.
Last branch recording (see section 18.5 in the Intel 64 and IA-32
Architectures Software Developer's Manual) allows
> All ptrace cleanup patches from Roland were posted by him to lkml, and
> we picked them up from there. Review is ongoing, Roland replied to all
> feedback with more patches, and those were integrated as well. Final
> upstream merging of this depends on more review and test results (as
>
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> Ingo Molnar <[EMAIL PROTECTED]> writes:
>
> > * Andi Kleen <[EMAIL PROTECTED]> wrote:
> >
> >> Just don't wait for that. utrace doesn't seem to have any concrete
> >> plans to merge any time soon AFAIK[1] and it would be a shame to delay
> >> an
On Mon, 3 Dec 2007, Andi Kleen wrote:
> Ingo Molnar <[EMAIL PROTECTED]> writes:
>
> > * Andi Kleen <[EMAIL PROTECTED]> wrote:
> >
> >> Just don't wait for that. utrace doesn't seem to have any concrete
> >> plans to merge any time soon AFAIK[1] and it would be a shame to delay
> >> an useful
Ingo Molnar <[EMAIL PROTECTED]> writes:
> * Andi Kleen <[EMAIL PROTECTED]> wrote:
>
>> Just don't wait for that. utrace doesn't seem to have any concrete
>> plans to merge any time soon AFAIK[1] and it would be a shame to delay
>> an useful feature forever.
>>
>> [1] At least the patches have
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> Just don't wait for that. utrace doesn't seem to have any concrete
> plans to merge any time soon AFAIK[1] and it would be a shame to delay
> an useful feature forever.
>
> [1] At least the patches have not reached any mailing lists
FYI, as far as
On Monday 03 December 2007 14:53:27 Markus Metzger wrote:
> > 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.
>
> I'm looking
>There seems to be support for block stepping in arch/x86/kernel/step.c,
>which is used by kernel/ptrace.c.
>
>This is now another user for the DEBUGCTL MSR; the access needs to be
>synchronized. I'll look into it.
I looked into the new block/single stepping support in
arch/x86/kernel/step.c.
It
> 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.
I'm looking very much forward to utrace. From what I read so far, this is
a much
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.
I'm looking very much forward to utrace. From what I read so far, this is
a much nicer
There seems to be support for block stepping in arch/x86/kernel/step.c,
which is used by kernel/ptrace.c.
This is now another user for the DEBUGCTL MSR; the access needs to be
synchronized. I'll look into it.
I looked into the new block/single stepping support in
arch/x86/kernel/step.c.
It uses
On Monday 03 December 2007 14:53:27 Markus Metzger wrote:
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.
I'm looking very much
* Andi Kleen [EMAIL PROTECTED] wrote:
Just don't wait for that. utrace doesn't seem to have any concrete
plans to merge any time soon AFAIK[1] and it would be a shame to delay
an useful feature forever.
[1] At least the patches have not reached any mailing lists
FYI, as far as arch/x86
Ingo Molnar [EMAIL PROTECTED] writes:
* Andi Kleen [EMAIL PROTECTED] wrote:
Just don't wait for that. utrace doesn't seem to have any concrete
plans to merge any time soon AFAIK[1] and it would be a shame to delay
an useful feature forever.
[1] At least the patches have not reached any
On Mon, 3 Dec 2007, Andi Kleen wrote:
Ingo Molnar [EMAIL PROTECTED] writes:
* Andi Kleen [EMAIL PROTECTED] wrote:
Just don't wait for that. utrace doesn't seem to have any concrete
plans to merge any time soon AFAIK[1] and it would be a shame to delay
an useful feature forever.
* Andi Kleen [EMAIL PROTECTED] wrote:
Ingo Molnar [EMAIL PROTECTED] writes:
* Andi Kleen [EMAIL PROTECTED] wrote:
Just don't wait for that. utrace doesn't seem to have any concrete
plans to merge any time soon AFAIK[1] and it would be a shame to delay
an useful feature forever.
All ptrace cleanup patches from Roland were posted by him to lkml, and
we picked them up from there. Review is ongoing, Roland replied to all
feedback with more patches, and those were integrated as well. Final
upstream merging of this depends on more review and test results (as
usual),
* Ingo Molnar <[EMAIL PROTECTED]> 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
* Metzger, Markus T <[EMAIL PROTECTED]> wrote:
> >> Not yet. We are talking to internal teams regarding gdb support.
> >
> >But you already have reasonably realistic test code right?
>
> I wrote a small program to talk to ptrace and look at the trace of
> small sample programs to test the
On Nov 30, 2007 5:04 PM, Michael Kerrisk <[EMAIL PROTECTED]> wrote:
> [...]
>
> > Please cc Michael Kerrisk <[EMAIL PROTECTED]> on future versions of
> > these patches.
>
> Yes, please. Buit note that my official address nowadays is
>
> [EMAIL PROTECTED]
Ooops! I meant [EMAIL PROTECTED]
--
[...]
> Please cc Michael Kerrisk <[EMAIL PROTECTED]> on future versions of
> these patches.
Yes, please. Buit note that my official address nowadays is
[EMAIL PROTECTED]
Chers,
Michael
--
Michael Kerrisk
Maintainer of the Linux man-pages project
http://www.kernel.org/doc/man-pages/
-
To
Support for Intel's last branch recording to ptrace. This gives debuggers
access to this hardware feature and allows them to show an execution trace
of the debugged application.
Last branch recording (see section 18.5 in the Intel 64 and IA-32
Architectures Software Developer's Manual) allows
>> Not yet. We are talking to internal teams regarding gdb support.
>
>But you already have reasonably realistic test code right?
I wrote a small program to talk to ptrace and look at the trace of small
sample programs to test the patch. I do this on P4 32bit and Core2
64bit.
Our debugger team
>yep, i already tried to check how well it integrates to x86.git:
I ported it to scm/linux/kernel/git/x86/linux-2.6-x86.git mm.
I will send out the patch and then look at the below discussion.
>the code does not seem to be layered correctly: i'd suggest to
>read the
>discussion between Roland
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> The patches were horridly wordwrapped.
yep, i already tried to check how well it integrates to x86.git:
http://lkml.org/lkml/2007/11/29/93
the code does not seem to be layered correctly: i'd suggest to read the
discussion between Roland McGrath
On Friday 30 November 2007 10:57:22 Metzger, Markus T wrote:
>
> >Is there any userspace code avaialble which people can use to play with
> >this?
>
> Not yet. We are talking to internal teams regarding gdb support.
But you already have reasonably realistic test code right?
We were burned a
>Is there any userspace code avaialble which people can use to play with
>this?
Not yet. We are talking to internal teams regarding gdb support.
>How do you envisage it being used in the long term? Do you
>expect any of
>the standard performance tuning tools will be tweaked to
>understand
Is there any userspace code avaialble which people can use to play with
this?
Not yet. We are talking to internal teams regarding gdb support.
How do you envisage it being used in the long term? Do you
expect any of
the standard performance tuning tools will be tweaked to
understand this
On Friday 30 November 2007 10:57:22 Metzger, Markus T wrote:
Is there any userspace code avaialble which people can use to play with
this?
Not yet. We are talking to internal teams regarding gdb support.
But you already have reasonably realistic test code right?
We were burned a few times
* Metzger, Markus T [EMAIL PROTECTED] wrote:
Not yet. We are talking to internal teams regarding gdb support.
But you already have reasonably realistic test code right?
I wrote a small program to talk to ptrace and look at the trace of
small sample programs to test the patch. I do this
Support for Intel's last branch recording to ptrace. This gives debuggers
access to this hardware feature and allows them to show an execution trace
of the debugged application.
Last branch recording (see section 18.5 in the Intel 64 and IA-32
Architectures Software Developer's Manual) allows
Not yet. We are talking to internal teams regarding gdb support.
But you already have reasonably realistic test code right?
I wrote a small program to talk to ptrace and look at the trace of small
sample programs to test the patch. I do this on P4 32bit and Core2
64bit.
Our debugger team has a
yep, i already tried to check how well it integrates to x86.git:
I ported it to scm/linux/kernel/git/x86/linux-2.6-x86.git mm.
I will send out the patch and then look at the below discussion.
the code does not seem to be layered correctly: i'd suggest to
read the
discussion between Roland
* Andrew Morton [EMAIL PROTECTED] wrote:
The patches were horridly wordwrapped.
yep, i already tried to check how well it integrates to x86.git:
http://lkml.org/lkml/2007/11/29/93
the code does not seem to be layered correctly: i'd suggest to read the
discussion between Roland McGrath and
[...]
Please cc Michael Kerrisk [EMAIL PROTECTED] on future versions of
these patches.
Yes, please. Buit note that my official address nowadays is
[EMAIL PROTECTED]
Chers,
Michael
--
Michael Kerrisk
Maintainer of the Linux man-pages project
http://www.kernel.org/doc/man-pages/
-
To
On Nov 30, 2007 5:04 PM, Michael Kerrisk [EMAIL PROTECTED] wrote:
[...]
Please cc Michael Kerrisk [EMAIL PROTECTED] on future versions of
these patches.
Yes, please. Buit note that my official address nowadays is
[EMAIL PROTECTED]
Ooops! I meant [EMAIL PROTECTED]
--
Michael Kerrisk
* Ingo Molnar [EMAIL PROTECTED] 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
On Thu, 29 Nov 2007 08:14:10 -
"Metzger, Markus T" <[EMAIL PROTECTED]> wrote:
> Support for Intel's last branch recording to ptrace. This gives
> debuggers
> access to this hardware feature and allows them to show an execution
> trace
> of the debugged application.
>
> Last branch recording
Support for Intel's last branch recording to ptrace. This gives
debuggers
access to this hardware feature and allows them to show an execution
trace
of the debugged application.
Last branch recording (see section 18.5 in the Intel 64 and IA-32
Architectures Software Developer's Manual) allows
Support for Intel's last branch recording to ptrace. This gives
debuggers
access to this hardware feature and allows them to show an execution
trace
of the debugged application.
Last branch recording (see section 18.5 in the Intel 64 and IA-32
Architectures Software Developer's Manual) allows
On Thu, 29 Nov 2007 08:14:10 -
Metzger, Markus T [EMAIL PROTECTED] wrote:
Support for Intel's last branch recording to ptrace. This gives
debuggers
access to this hardware feature and allows them to show an execution
trace
of the debugged application.
Last branch recording (see
44 matches
Mail list logo
