Very Computer

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

J?rn

--
Simplicity is prerequisite for reliability.
-- Edsger W. Dijkstra
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Thanks,
Paul Larson

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

   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

        .globl  ret_from_fork
 ret_from_fork:
        bl      schedule_tail
+#ifdef CONFIG_GCOV_ALL


+       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

  */
 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__

+__CTOR_LIST__:
+.section ".dtors","aw"
+.globl  __DTOR_LIST__

+__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

        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__

+__CTOR_LIST__:
+.section ".dtors","aw"
+.globl  __DTOR_LIST__

+__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

        .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__

+__CTOR_LIST__:
+.section ".dtors","aw"
+.globl  __DTOR_LIST__

+__DTOR_LIST__:
+#endif
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Quote:=?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?

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.

Paul.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Quote:> 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.

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.

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/