> From: Andy Lutomirski
>
> On Tue, Jan 12, 2021 at 9:02 AM Metzger, Markus T
> wrote:
> >
> > > [ 26.990644] getreg: gs_base = 0xf7f8e000
> > > [ 26.991694] getreg: GS=0x63, GSBASE=0xf7f8e000
> > > [ 26.993117] PTRACE_SETREGS
> > >
> [ 26.990644] getreg: gs_base = 0xf7f8e000
> [ 26.991694] getreg: GS=0x63, GSBASE=0xf7f8e000
> [ 26.993117] PTRACE_SETREGS
> [ 26.993813] putreg: change gsbase from 0xf7f8e000 to 0x0
> [ 26.995134] putreg: write GS=0x63; old GSBASE=0x0
> [ 26.996235] PTRACE_SETREGS done
>
> That's
> The GDB behavior looks to be different between the two cases -- with vs
> without gdb server, when I checked the GS/GSBASE values on the ptrace front.
64-bit GDB doesn't support FSGSBASE for 32-bit inferiors and it looks like
gdbserver
might not support FSGSBASE, at all.
I had added support
Hello Hugh,
> A little "optimization" crept into alloc_bts_buffer() along the way, which now
> places bts_interrupt_threshold not on a record boundary.
> And Stephane has shown me the sentence in Vol 3B, 17.4.9, which says "This
> address must point to an offset from the BTS buffer base that is a
Hello Hugh,
> A little "optimization" crept into alloc_bts_buffer() along the way, which now
> places bts_interrupt_threshold not on a record boundary.
> And Stephane has shown me the sentence in Vol 3B, 17.4.9, which says "This
> address must point to an offset from the BTS buffer base that is a
Hello,
Starting with 4.15 I noticed that BTS is sporadically missing the tail
of the trace in the perf_event data buffer. It shows as
[decode error (1): instruction overflow]
in GDB. Chances to see this are higher the longer the debuggee is
running. With this [1] tiny patch to one of
Hello,
Starting with 4.15 I noticed that BTS is sporadically missing the tail
of the trace in the perf_event data buffer. It shows as
[decode error (1): instruction overflow]
in GDB. Chances to see this are higher the longer the debuggee is
running. With this [1] tiny patch to one of
> -Original Message-
> From: Andy Lutomirski [mailto:l...@kernel.org]
> Sent: 21 March 2018 01:47
Hello Andy,
> I retract this particular comment. But I still think that all this
> complexity needs to
> be more clearly justified. My objection to the old approach wasn't that I
>
> -Original Message-
> From: Andy Lutomirski [mailto:l...@kernel.org]
> Sent: 21 March 2018 01:47
Hello Andy,
> I retract this particular comment. But I still think that all this
> complexity needs to
> be more clearly justified. My objection to the old approach wasn't that I
>
ackerras; Stephane Eranian; Andi Kleen;
> Liang, Kan; Hunter, Adrian; Metzger, Markus T; mathieu.poir...@linaro.org;
> a...@infradead.org; Peter Zijlstra; Alexander Shishkin
> Subject: [PATCH v8 02/14] perf: Add AUX area to ring buffer for raw data
> streams
>
> From: Peter Zijlstra
&
; Andi Kleen;
Liang, Kan; Hunter, Adrian; Metzger, Markus T; mathieu.poir...@linaro.org;
a...@infradead.org; Peter Zijlstra; Alexander Shishkin
Subject: [PATCH v8 02/14] perf: Add AUX area to ring buffer for raw data
streams
From: Peter Zijlstra pet...@infradead.org
This patch introduces AUX
> -Original Message-
> From: gdb-patches-ow...@sourceware.org
> [mailto:gdb-patches-ow...@sourceware.org] On Behalf Of Ingo Molnar
> Sent: Thursday, January 24, 2013 4:47 PM
> > Starting with Nehalem, the BTS "from" information may in some cases be
> > incorrect (AAJ122).
> >
> > This
-Original Message-
From: gdb-patches-ow...@sourceware.org
[mailto:gdb-patches-ow...@sourceware.org] On Behalf Of Ingo Molnar
Sent: Thursday, January 24, 2013 4:47 PM
Starting with Nehalem, the BTS from information may in some cases be
incorrect (AAJ122).
This has been
>-Original Message-
>From: Ingo Molnar [mailto:[EMAIL PROTECTED]
>Sent: Freitag, 22. Februar 2008 10:53
>To: Metzger, Markus T
>> The ptrace API is the user interface for the debugging/BTS aspect of
>> it. As such, it will remain stable.
>
>your last patc
>-Original Message-
>From: Roland McGrath [mailto:[EMAIL PROTECTED]
>Sent: Donnerstag, 21. Februar 2008 22:00
>Sorry I haven't replied in this thread sooner.
Thanks for your comments. I hope we get this resolved quickly.
>For the user-level interface, we should not be hasty with
-Original Message-
From: Roland McGrath [mailto:[EMAIL PROTECTED]
Sent: Donnerstag, 21. Februar 2008 22:00
Sorry I haven't replied in this thread sooner.
Thanks for your comments. I hope we get this resolved quickly.
For the user-level interface, we should not be hasty with cooking up
-Original Message-
From: Ingo Molnar [mailto:[EMAIL PROTECTED]
Sent: Freitag, 22. Februar 2008 10:53
To: Metzger, Markus T
The ptrace API is the user interface for the debugging/BTS aspect of
it. As such, it will remain stable.
your last patch does this to arch/x86/kernel/ptrace.c
>-Original Message-
>From: stephane eranian [mailto:[EMAIL PROTECTED]
>Sent: Donnerstag, 31. Januar 2008 12:16
>I looked at your code. My understanding is that it abstracts the BTS
>so that higher
>level code does not have to know the intricacies of the implementation
>especially
>given
-Original Message-
From: stephane eranian [mailto:[EMAIL PROTECTED]
Sent: Donnerstag, 31. Januar 2008 12:16
I looked at your code. My understanding is that it abstracts the BTS
so that higher
level code does not have to know the intricacies of the implementation
especially
given that the
>From: stephane eranian [mailto:[EMAIL PROTECTED]
>Sent: Mittwoch, 30. Januar 2008 12:01
>You can get information about the perfmon2 project at:
>http://perfmon2.sf.net
I downloaded your patch for 2.6.23 and cloned your git repository.
>From a first glance, it looks like there is indeed a lot
>From: Roland McGrath [mailto:[EMAIL PROTECTED]
>Sent: Mittwoch, 30. Januar 2008 08:26
>To: Metzger, Markus T
>I think this work has a great deal of overlap with the
>perfmon2 project.
>There are two facets that overlap, which together are the
>whole BTS feature.
>
&g
From: Roland McGrath [mailto:[EMAIL PROTECTED]
Sent: Mittwoch, 30. Januar 2008 08:26
To: Metzger, Markus T
I think this work has a great deal of overlap with the
perfmon2 project.
There are two facets that overlap, which together are the
whole BTS feature.
The same x86 debug store hardware
From: stephane eranian [mailto:[EMAIL PROTECTED]
Sent: Mittwoch, 30. Januar 2008 12:01
You can get information about the perfmon2 project at:
http://perfmon2.sf.net
I downloaded your patch for 2.6.23 and cloned your git repository.
From a first glance, it looks like there is indeed a lot of
>-Original Message-
>From: Ingo Molnar [mailto:[EMAIL PROTECTED]
>Sent: Dienstag, 8. Januar 2008 10:50
>please dont use shorts. Lets just us bts_size and no version
>at all, ok?
OK.
We need to be careful to add the positive and negative flag for new
features. Otherwise, we cannot
-Original Message-
From: Ingo Molnar [mailto:[EMAIL PROTECTED]
Sent: Dienstag, 8. Januar 2008 10:50
please dont use shorts. Lets just us bts_size and no version
at all, ok?
OK.
We need to be careful to add the positive and negative flag for new
features. Otherwise, we cannot
>-Original Message-
>From: Ingo Molnar [mailto:[EMAIL PROTECTED]
>Sent: Samstag, 15. Dezember 2007 08:30
>another detail: shouldnt this be structured so that the APIs are
>introduced in kernel/ptrace.c, and that the architecture offers the
>mechanism. (which would thus be
-Original Message-
From: Ingo Molnar [mailto:[EMAIL PROTECTED]
Sent: Samstag, 15. Dezember 2007 08:30
another detail: shouldnt this be structured so that the APIs are
introduced in kernel/ptrace.c, and that the architecture offers the
mechanism. (which would thus be ptrace-independent)
>-Original Message-
>From: Ingo Molnar [mailto:[EMAIL PROTECTED]
>Sent: Donnerstag, 13. Dezember 2007 14:08
>> Are you OK with this?
>
>this sounds a lot more flexible to me. Please, once it looks
>good to all
I will implement the ptrace ABI and the man pages and send them out for
>-Original Message-
>From: Ingo Molnar [mailto:[EMAIL PROTECTED]
>Sent: Donnerstag, 13. Dezember 2007 11:30
>> Users who want to process that huge amount of data would be
>better off
>> using a file-based approach (well, if it cannot be held in physical
>> memory, they will spend most
-Original Message-
From: Ingo Molnar [mailto:[EMAIL PROTECTED]
Sent: Donnerstag, 13. Dezember 2007 11:30
Users who want to process that huge amount of data would be
better off
using a file-based approach (well, if it cannot be held in physical
memory, they will spend most of their
-Original Message-
From: Ingo Molnar [mailto:[EMAIL PROTECTED]
Sent: Donnerstag, 13. Dezember 2007 14:08
Are you OK with this?
this sounds a lot more flexible to me. Please, once it looks
good to all
I will implement the ptrace ABI and the man pages and send them out for
review
>-Original Message-
>From: Ingo Molnar [mailto:[EMAIL PROTECTED]
>Sent: Mittwoch, 12. Dezember 2007 12:04
>> Would it be safe to drop the artificial limit and let the
>limit be the
>> available memory?
>
>no, that would be a DoS :-/
How about:
for (;;) {
int pid = fork();
>-Original Message-
>From: Ingo Molnar [mailto:[EMAIL PROTECTED]
>Sent: Dienstag, 11. Dezember 2007 15:53
>In the second use-case (tracing, profiling, call coverage metrics), we
>could live without zero-copy, as long as the buffer could be
>made "large
>enough". The current 4000
-Original Message-
From: Ingo Molnar [mailto:[EMAIL PROTECTED]
Sent: Dienstag, 11. Dezember 2007 15:53
In the second use-case (tracing, profiling, call coverage metrics), we
could live without zero-copy, as long as the buffer could be
made large
enough. The current 4000 records limit
-Original Message-
From: Ingo Molnar [mailto:[EMAIL PROTECTED]
Sent: Mittwoch, 12. Dezember 2007 12:04
Would it be safe to drop the artificial limit and let the
limit be the
available memory?
no, that would be a DoS :-/
How about:
for (;;) {
int pid = fork();
if
>-Original Message-
>From: Ingo Molnar [mailto:[EMAIL PROTECTED]
>Sent: Montag, 10. Dezember 2007 21:21
>here's the current proposed API:
>
>+ case PTRACE_BTS_MAX_BUFFER_SIZE:
>+ case PTRACE_BTS_ALLOCATE_BUFFER:
>+ case PTRACE_BTS_GET_BUFFER_SIZE:
>+ case
-Original Message-
From: Ingo Molnar [mailto:[EMAIL PROTECTED]
Sent: Montag, 10. Dezember 2007 21:21
here's the current proposed API:
+ case PTRACE_BTS_MAX_BUFFER_SIZE:
+ case PTRACE_BTS_ALLOCATE_BUFFER:
+ case PTRACE_BTS_GET_BUFFER_SIZE:
+ case
>From: Andi Kleen [mailto:[EMAIL PROTECTED]
>Sent: Freitag, 7. Dezember 2007 14:04
>With Out-of-order CPUs exact global metrics are pretty difficult.
>At which point of the instruction execution would you measure?
All I want to do is order the execution chunks of different
threads. Taking two
>From: Andi Kleen [mailto:[EMAIL PROTECTED]
>Sent: Freitag, 7. Dezember 2007 12:18
>> I would like to settle the discussion and find an interface that
>> everybody can agree to, so I can implement that interface and we can
>> move forward with the patch.
>
>The most efficient interface would be
Roland, Andi,
I would like to discuss the ptrace user interface for the BTS extension.
In previous emails,
Andi suggested a stream-like interface, but is also OK with an
array-like interface (as far as I understood).
Roland is dubious about the ptrace API additions.
I would like to settle the
From: Andi Kleen [mailto:[EMAIL PROTECTED]
Sent: Freitag, 7. Dezember 2007 12:18
I would like to settle the discussion and find an interface that
everybody can agree to, so I can implement that interface and we can
move forward with the patch.
The most efficient interface would be zero copy
From: Andi Kleen [mailto:[EMAIL PROTECTED]
Sent: Freitag, 7. Dezember 2007 14:04
With Out-of-order CPUs exact global metrics are pretty difficult.
At which point of the instruction execution would you measure?
All I want to do is order the execution chunks of different
threads. Taking two
Roland, Andi,
I would like to discuss the ptrace user interface for the BTS extension.
In previous emails,
Andi suggested a stream-like interface, but is also OK with an
array-like interface (as far as I understood).
Roland is dubious about the ptrace API additions.
I would like to settle the
>-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
>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
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
>> 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
>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
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
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
Changes to previous version(s):
- moved task arrives/departs notifications to __switch_to_xtra()
- added _TIF_BTS_TRACE and _TIF_BTS_TRACE_TS to _TIF_WORK_CTXSW_*
- split _TIF_WORK_CTXSW into ~_PREV and ~_NEXT for x86_64
- ptrace_bts_init_intel() function called from init_intel()
- removed
Describe extensions to ptrace interface for branch trace store
Signed-off-by: Markus Metzger <[EMAIL PROTECTED]>
Signed-off-by: Suresh Siddha <[EMAIL PROTECTED]>
---
Index: man/man2/ptrace.2
===
--- man.orig/man2/ptrace.2
Describe extensions to ptrace interface for branch trace store
Signed-off-by: Markus Metzger [EMAIL PROTECTED]
Signed-off-by: Suresh Siddha [EMAIL PROTECTED]
---
Index: man/man2/ptrace.2
===
--- man.orig/man2/ptrace.2
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
Changes to previous version(s):
- moved task arrives/departs notifications to __switch_to_xtra()
- added _TIF_BTS_TRACE and _TIF_BTS_TRACE_TS to _TIF_WORK_CTXSW_*
- split _TIF_WORK_CTXSW into ~_PREV and ~_NEXT for x86_64
- ptrace_bts_init_intel() function called from init_intel()
- removed
Changes to previous version(s):
- moved task arrives/departs notifications to __switch_to_xtra()
- added _TIF_BTS_TRACE and _TIF_BTS_TRACE_TS to _TIF_WORK_CTXSW_*
- split _TIF_WORK_CTXSW into ~_PREV and ~_NEXT for x86_64
- ptrace_bts_init_intel() function called from init_intel()
- removed
>Your patch seems to be still word wrapped.
I hope this is better with the next version I'm going to
send out in a few minutes. Sorry about that.
>The noflags variant should be probably data driven too.
I rewrote the entire code to use an offset/size configuration
instead of declaring structs
Your patch seems to be still word wrapped.
I hope this is better with the next version I'm going to
send out in a few minutes. Sorry about that.
The noflags variant should be probably data driven too.
I rewrote the entire code to use an offset/size configuration
instead of declaring structs
Changes to previous version(s):
- moved task arrives/departs notifications to __switch_to_xtra()
- added _TIF_BTS_TRACE and _TIF_BTS_TRACE_TS to _TIF_WORK_CTXSW_*
- split _TIF_WORK_CTXSW into ~_PREV and ~_NEXT for x86_64
- ptrace_bts_init_intel() function called from init_intel()
- removed
>> - the internal buffer interpretation as well as the corresponding
>> operations are selected at run-time by hardware detection
>> - different processors use different branch record formats
>
>I still think it would be far better if you would switch this
>over to be table
>driven. e.g.
- the internal buffer interpretation as well as the corresponding
operations are selected at run-time by hardware detection
- different processors use different branch record formats
I still think it would be far better if you would switch this
over to be table
driven. e.g. define a
>-Original Message-
>From: dean gaudet [mailto:[EMAIL PROTECTED]
>Sent: Dienstag, 20. November 2007 16:37
>To: Metzger, Markus T
>Cc: linux-kernel@vger.kernel.org; [EMAIL PROTECTED];
>[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Siddha, Suresh
&g
>-Original Message-
>From: dean gaudet [mailto:[EMAIL PROTECTED]
>Sent: Dienstag, 20. November 2007 16:27
>To: Metzger, Markus T
>Cc: linux-kernel@vger.kernel.org; [EMAIL PROTECTED];
>[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Siddha, Suresh
&g
Changes to previous version:
- moved task arrives/departs notifications to __switch_to_xtra()
- added _TIF_BTS_TRACE and _TIF_BTS_TRACE_TS to _TIF_WORK_CTXSW_*
- split _TIF_WORK_CTXSW into ~_PREV and ~_NEXT for x86_64
- ptrace_bts_init_intel() function called from init_intel()
- removed
Changes to previous version:
- moved task arrives/departs notifications to __switch_to_xtra()
- added _TIF_BTS_TRACE and _TIF_BTS_TRACE_TS to _TIF_WORK_CTXSW_*
- split _TIF_WORK_CTXSW into ~_PREV and ~_NEXT for x86_64
- ptrace_bts_init_intel() function called from init_intel()
- removed
-Original Message-
From: dean gaudet [mailto:[EMAIL PROTECTED]
Sent: Dienstag, 20. November 2007 16:37
To: Metzger, Markus T
Cc: linux-kernel@vger.kernel.org; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Siddha, Suresh
B; [EMAIL PROTECTED]
Subject: Re
-Original Message-
From: dean gaudet [mailto:[EMAIL PROTECTED]
Sent: Dienstag, 20. November 2007 16:27
To: Metzger, Markus T
Cc: linux-kernel@vger.kernel.org; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Siddha, Suresh
B; [EMAIL PROTECTED]
Subject: Re
Thanks for your comments.
>-Original Message-
>From: Andi Kleen [mailto:[EMAIL PROTECTED]
>Sent: Dienstag, 13. November 2007 21:21
>To: Siddha, Suresh B
>Cc: linux-kernel@vger.kernel.org; [EMAIL PROTECTED];
>[EMAIL PROTECTED]; [EMAIL PROTECTED]; Metzger, Markus T;
Thanks for your comments.
-Original Message-
From: Andi Kleen [mailto:[EMAIL PROTECTED]
Sent: Dienstag, 13. November 2007 21:21
To: Siddha, Suresh B
Cc: linux-kernel@vger.kernel.org; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]; Metzger, Markus T;
[EMAIL PROTECTED]
Subject
73 matches
Mail list logo
