* 2.5.67-gcov and 2.4.20-gcov
@ 2003-04-16 14:20 Paul Larson
2003-04-16 16:44 ` [Ltp-coverage] " Jörn Engel
0 siblings, 1 reply; 6+ messages in thread
From: Paul Larson @ 2003-04-16 14:20 UTC (permalink / raw)
To: ltp-coverage, lse-tech, lkml
[-- Attachment #1: Type: text/plain, Size: 597 bytes --]
The Linux Kernel GCOV patch has a new home. It will now be available
from the Linux Test Project site at: http://ltp.sourceforge.net.
This release updates the gcov-kernel patches and utilities for 2.5.67
and 2.4.20 kernels, and includes some minor bugfixes.
The Linux Kernel GCOV patch allows utilization of the gcov tool
against a running kernel. This is different from most other profiling
methods because it can easily tell you things like: which lines of code
are executed, how many times they are executed, and how often different
branches are taken.
Thanks,
Paul Larson
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 240 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Ltp-coverage] 2.5.67-gcov and 2.4.20-gcov
2003-04-16 14:20 2.5.67-gcov and 2.4.20-gcov Paul Larson
@ 2003-04-16 16:44 ` Jörn Engel
2003-04-16 16:51 ` Paul Larson
0 siblings, 1 reply; 6+ messages in thread
From: Jörn Engel @ 2003-04-16 16:44 UTC (permalink / raw)
To: Paul Larson; +Cc: ltp-coverage, lse-tech, lkml
On Wed, 16 April 2003 09:20:02 -0500, Paul Larson wrote:
>
> The Linux Kernel GCOV patch has a new home. It will now be available
> from the Linux Test Project site at: http://ltp.sourceforge.net.
>
> This release updates the gcov-kernel patches and utilities for 2.5.67
> and 2.4.20 kernels, and includes some minor bugfixes.
>
> The Linux Kernel GCOV patch allows utilization of the gcov tool
> against a running kernel. This is different from most other profiling
> methods because it can easily tell you things like: which lines of code
> are executed, how many times they are executed, and how often different
> branches are taken.
Excuse me for being lazy. Does this already cover ppc? I submitted a
patch over some other channels some time ago.
Jörn
--
Simplicity is prerequisite for reliability.
-- Edsger W. Dijkstra
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Ltp-coverage] 2.5.67-gcov and 2.4.20-gcov
2003-04-16 16:44 ` [Ltp-coverage] " Jörn Engel
@ 2003-04-16 16:51 ` Paul Larson
2003-04-17 12:31 ` Jörn Engel
0 siblings, 1 reply; 6+ messages in thread
From: Paul Larson @ 2003-04-16 16:51 UTC (permalink / raw)
To: Jörn Engel; +Cc: ltp-coverage, lse-tech, lkml
[-- Attachment #1: Type: text/plain, Size: 301 bytes --]
On Wed, 2003-04-16 at 11:44, Jörn Engel wrote:
> Excuse me for being lazy. Does this already cover ppc? I submitted a
> patch over some other channels some time ago.
No, not yet. And I havn't seen that patch, could you send it to me, or
to the ltp-coverage mailing list?
Thanks,
Paul Larson
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 240 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Ltp-coverage] 2.5.67-gcov and 2.4.20-gcov
2003-04-16 16:51 ` Paul Larson
@ 2003-04-17 12:31 ` Jörn Engel
2003-04-17 23:07 ` Paul Mackerras
0 siblings, 1 reply; 6+ messages in thread
From: Jörn Engel @ 2003-04-17 12:31 UTC (permalink / raw)
To: Paul Larson
Cc: ltp-coverage, lse-tech, lkml, Paul Mackerras, Benjamin Herrenschmidt
On Wed, 16 April 2003 11:51:09 -0500, Paul Larson wrote:
> On Wed, 2003-04-16 at 11:44, Jörn Engel wrote:
> > Excuse me for being lazy. Does this already cover ppc? I submitted a
> > patch over some other channels some time ago.
> No, not yet. And I havn't seen that patch, could you send it to me, or
> to the ltp-coverage mailing list?
Attached.
Most of it is trivial - identical to arch/*.
The bit in arch/ppc/kernel/entry.S was necessary for me to compile
this for a ppc 405gp based system, gcov would grow the kernel beyond
the relative jump distance for "bnel syscall_trace".
Paulus, Ben, is the relative jump a wanted optimization or unclean
code that went unnoticed so far? IOW should this go into mainline or
remain part of the gcov patch?
Jörn
--
Optimizations always bust things, because all optimizations are, in
the long haul, a form of cheating, and cheaters eventually get caught.
-- Larry Wall
Index: arch/ppc/config.in
===================================================================
RCS file: /home/linux/arch/ppc/config.in,v
retrieving revision 1.11
diff -u -r1.11 config.in
--- arch/ppc/config.in 19 Feb 2003 21:41:13 -0000 1.11
+++ arch/ppc/config.in 28 Mar 2003 12:37:57 -0000
@@ -714,3 +714,13 @@
bool 'Support for early boot texts over serial port' CONFIG_SERIAL_TEXT_DEBUG
fi
endmenu
+
+mainmenu_option next_comment
+comment 'GCOV coverage profiling'
+
+bool 'GCOV kernel' CONFIG_GCOV_PROFILE
+if [ "$CONFIG_GCOV_PROFILE" != "n" ]; then
+ bool ' GCOV kernel profiler' CONFIG_GCOV_ALL
+fi
+
+endmenu
Index: arch/ppc/kernel/entry.S
===================================================================
RCS file: /home/linux/arch/ppc/kernel/entry.S,v
retrieving revision 1.2
diff -u -r1.2 entry.S
--- entry.S 14 Feb 2003 21:40:50 -0000 1.2
+++ entry.S 28 Mar 2003 12:59:06 -0000
@@ -314,9 +314,19 @@
.globl ret_from_fork
ret_from_fork:
bl schedule_tail
+#ifdef CONFIG_GCOV_ALL
+ lis r0,syscall_trace@ha
+ addi r0,r0,syscall_trace@l
+ mtlr r0
+#endif
lwz r0,TASK_PTRACE(r2)
andi. r0,r0,PT_TRACESYS
+#ifdef CONFIG_GCOV_ALL
+ beq ret_from_except
+ blrl
+#else
bnel- syscall_trace
+#endif
b ret_from_except
.globl ret_from_intercept
Index: arch/ppc/kernel/head.S
===================================================================
RCS file: /home/linux/arch/ppc/kernel/head.S,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 head.S
--- arch/ppc/kernel/head.S 5 Nov 2002 16:24:13 -0000 1.1.1.1
+++ arch/ppc/kernel/head.S 28 Mar 2003 12:37:57 -0000
@@ -1755,3 +1755,24 @@
*/
abatron_pteptrs:
.space 8
+
+#ifdef CONFIG_GCOV_PROFILE
+/*
+ * The .ctors-section contains a list of pointers to constructor
+ * functions which are used to initialize gcov structures.
+ *
+ * Because there is no NULL at the end of the constructor list
+ * in the kernel we need the addresses of both the constructor
+ * as well as the destructor list which are supposed to be
+ * adjacent.
+ */
+
+.section ".ctors","aw"
+.globl __CTOR_LIST__
+.type __CTOR_LIST__,@object
+__CTOR_LIST__:
+.section ".dtors","aw"
+.globl __DTOR_LIST__
+.type __DTOR_LIST__,@object
+__DTOR_LIST__:
+#endif
Index: arch/ppc/kernel/head_4xx.S
===================================================================
RCS file: /home/linux/arch/ppc/kernel/head_4xx.S,v
retrieving revision 1.8
diff -u -r1.8 head_4xx.S
--- arch/ppc/kernel/head_4xx.S 17 Feb 2003 20:06:16 -0000 1.8
+++ arch/ppc/kernel/head_4xx.S 28 Mar 2003 12:37:57 -0000
@@ -1271,3 +1271,24 @@
mtdcr 0x022, r3
blr
#endif
+
+#ifdef CONFIG_GCOV_PROFILE
+/*
+ * The .ctors-section contains a list of pointers to constructor
+ * functions which are used to initialize gcov structures.
+ *
+ * Because there is no NULL at the end of the constructor list
+ * in the kernel we need the addresses of both the constructor
+ * as well as the destructor list which are supposed to be
+ * adjacent.
+ */
+
+.section ".ctors","aw"
+.globl __CTOR_LIST__
+.type __CTOR_LIST__,@object
+__CTOR_LIST__:
+.section ".dtors","aw"
+.globl __DTOR_LIST__
+.type __DTOR_LIST__,@object
+__DTOR_LIST__:
+#endif
Index: arch/ppc/kernel/head_8xx.S
===================================================================
RCS file: /home/linux/arch/ppc/kernel/head_8xx.S,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 head_8xx.S
--- arch/ppc/kernel/head_8xx.S 5 Nov 2002 16:24:13 -0000 1.1.1.1
+++ arch/ppc/kernel/head_8xx.S 28 Mar 2003 12:37:58 -0000
@@ -997,3 +997,23 @@
.space 16
#endif
+#ifdef CONFIG_GCOV_PROFILE
+/*
+ * The .ctors-section contains a list of pointers to constructor
+ * functions which are used to initialize gcov structures.
+ *
+ * Because there is no NULL at the end of the constructor list
+ * in the kernel we need the addresses of both the constructor
+ * as well as the destructor list which are supposed to be
+ * adjacent.
+ */
+
+.section ".ctors","aw"
+.globl __CTOR_LIST__
+.type __CTOR_LIST__,@object
+__CTOR_LIST__:
+.section ".dtors","aw"
+.globl __DTOR_LIST__
+.type __DTOR_LIST__,@object
+__DTOR_LIST__:
+#endif
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Ltp-coverage] 2.5.67-gcov and 2.4.20-gcov
2003-04-17 12:31 ` Jörn Engel
@ 2003-04-17 23:07 ` Paul Mackerras
2003-04-19 21:24 ` Jörn Engel
0 siblings, 1 reply; 6+ messages in thread
From: Paul Mackerras @ 2003-04-17 23:07 UTC (permalink / raw)
To: Jörn Engel
Cc: Paul Larson, ltp-coverage, lse-tech, lkml, Benjamin Herrenschmidt
=?iso-8859-1?Q?J=81=F6rn?= Engel writes:
> The bit in arch/ppc/kernel/entry.S was necessary for me to compile
> this for a ppc 405gp based system, gcov would grow the kernel beyond
> the relative jump distance for "bnel syscall_trace".
>
> Paulus, Ben, is the relative jump a wanted optimization or unclean
> code that went unnoticed so far? IOW should this go into mainline or
> remain part of the gcov patch?
What's unclean about bnel?
I think ret_from_fork would be better like this:
.globl ret_from_fork
ret_from_fork:
bl schedule_tail
lwz r0,TASK_PTRACE(r2)
andi. r0,r0,PT_TRACESYS
beq+ ret_from_except
bl syscall_trace
b ret_from_except
Unless of course you have bloated the kernel beyond 32MB, but then we
would be in all sorts of difficulties.
> +.section ".ctors","aw"
> +.globl __CTOR_LIST__
> +.type __CTOR_LIST__,@object
> +__CTOR_LIST__:
> +.section ".dtors","aw"
> +.globl __DTOR_LIST__
> +.type __DTOR_LIST__,@object
> +__DTOR_LIST__:
Can't you do this in arch/ppc/vmlinux.lds using PROVIDE() instead of
making the same change to each of the head*.S files?
Paul.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Ltp-coverage] 2.5.67-gcov and 2.4.20-gcov
2003-04-17 23:07 ` Paul Mackerras
@ 2003-04-19 21:24 ` Jörn Engel
0 siblings, 0 replies; 6+ messages in thread
From: Jörn Engel @ 2003-04-19 21:24 UTC (permalink / raw)
To: Paul Mackerras
Cc: Paul Larson, ltp-coverage, lse-tech, lkml, Benjamin Herrenschmidt
On Fri, 18 April 2003 09:07:58 +1000, Paul Mackerras wrote:
> =?iso-8859-1?Q?J=81=F6rn?= Engel writes:
>
> > The bit in arch/ppc/kernel/entry.S was necessary for me to compile
> > this for a ppc 405gp based system, gcov would grow the kernel beyond
> > the relative jump distance for "bnel syscall_trace".
> >
> > Paulus, Ben, is the relative jump a wanted optimization or unclean
> > code that went unnoticed so far? IOW should this go into mainline or
> > remain part of the gcov patch?
>
> What's unclean about bnel?
Nothing, as long as it works. But the jump target may only be 1<<13
bytes away. With gcov, it is further. syscall_trace is in a different
source file, so the distance can grow quite large.
> I think ret_from_fork would be better like this:
>
> .globl ret_from_fork
> ret_from_fork:
> bl schedule_tail
> lwz r0,TASK_PTRACE(r2)
> andi. r0,r0,PT_TRACESYS
> beq+ ret_from_except
> bl syscall_trace
> b ret_from_except
>
> Unless of course you have bloated the kernel beyond 32MB, but then we
> would be in all sorts of difficulties.
Does bl leave 25 bits for the jump target? I don't have a ppc manual
or test hardware with me over the holidays. Will check next week.
32MB sounds quite sufficient. My current record is 28MB for vmlinux on
i386, after allyesconfig basically. This is for statical analysis
only, I would think about booting such a monster.
> > +.section ".ctors","aw"
> > +.globl __CTOR_LIST__
> > +.type __CTOR_LIST__,@object
> > +__CTOR_LIST__:
> > +.section ".dtors","aw"
> > +.globl __DTOR_LIST__
> > +.type __DTOR_LIST__,@object
> > +__DTOR_LIST__:
>
> Can't you do this in arch/ppc/vmlinux.lds using PROVIDE() instead of
> making the same change to each of the head*.S files?
Maybe, but why bother. As long as the patch doesn't go into mainline,
the change is identical for arch/*/kernel/head*.S, which is easy to
understand.
If you think it would still be nicer, I will do the change.
Jörn
--
Data dominates. If you've chosen the right data structures and organized
things well, the algorithms will almost always be self-evident. Data
structures, not algorithms, are central to programming.
-- Rob Pike
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2003-04-19 21:12 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-04-16 14:20 2.5.67-gcov and 2.4.20-gcov Paul Larson
2003-04-16 16:44 ` [Ltp-coverage] " Jörn Engel
2003-04-16 16:51 ` Paul Larson
2003-04-17 12:31 ` Jörn Engel
2003-04-17 23:07 ` Paul Mackerras
2003-04-19 21:24 ` Jörn Engel
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 NNTP newsgroup(s).