From: Peter Oberparleiter <peter.oberparleiter@de.ibm.com>
Change all source and include paths to absolute form when

CONFIG_GCOV_PROFILE is enabled.
Example:
  gcc -Idir1 -c a.c -o a.o
will become
  gcc -I/path/to/dir1 -c /path/to/a.c -o a.o
Required by the gcov profiling infrastructure: when compiling with

option -fprofile-arcs, gcc stores file names inside object files.

Relative paths prevent the gcov tool from finding corresponding source

files.
Signed-off-by: Peter Oberparleiter <peter.oberparleiter@de.ibm.com>

---

 scripts/Kbuild.include |    7 +++++++

 scripts/Makefile.build |    3 ++-

 scripts/Makefile.lib   |    8 +++++++-

 3 files changed, 16 insertions(+), 2 deletions(-)
Index: linux-2.6.26-rc3/scripts/Makefile.lib

===================================================================

--- linux-2.6.26-rc3.orig/scripts/Makefile.lib

+++ linux-2.6.26-rc3/scripts/Makefile.lib

@@ -126,10 +126,16 @@ __a_flags	=                          $(c

 __cpp_flags     =                          $(call flags,_cpp_flags)

 endif
-c_flags        = -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(KBUILD_CPPFLAGS) \

+___c_flags        = -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(KBUILD_CPPFLAGS) \

 		 $(__c_flags) $(modkern_cflags) \

 		 -D"KBUILD_STR(s)=\#s" $(basename_flags) $(modname_flags)
+ifeq ($(CONFIG_GCOV_PROFILE),)

+c_flags = $(___c_flags)

+else

+c_flags = $(call flags_addpath,___c_flags,$(objtree))

+endif

+

 a_flags        = -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(KBUILD_CPPFLAGS) \

 		 $(__a_flags) $(modkern_aflags)
Index: linux-2.6.26-rc3/scripts/Makefile.build

===================================================================

--- linux-2.6.26-rc3.orig/scripts/Makefile.build

+++ linux-2.6.26-rc3/scripts/Makefile.build

@@ -165,7 +165,8 @@ $(obj)/%.symtypes : $(src)/%.c FORCE

 # (See cmd_cc_o_c + relevant part of rule_cc_o_c)
 quiet_cmd_cc_o_c = CC $(quiet_modtag)  $@

-cmd_cc_o_c = $(CC) $(c_flags) -c -o $@ $<

+cmd_cc_o_c = $(CC) $(c_flags) -c -o ...
[ message continues ]

I don't like this.  It converts the compiler error messages from

relative paths to absolute paths which is rather obnoxious when

all kernel developent is (or should be) base-directory-agnostic.
--

The compiler error messages are already absolute paths when using O=

(see e.g. all error messages sent by me in recent years).
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
--

On Fri, 23 May 2008 20:18:40 +0300
Well I guess that's understandable with O=.
But I find it rather nasty.  (I guess it'd be less nasty if I were to

get off my butt and work out how to teach rxvt that "/" is a word

separator).
What do others think?

--

That the gcov tool has a bug if it insist on using absolute paths.

And thus we should fix gcov and not workaround it in the kernel.
	Sam

--

I've given this some more thought and came up with a possible

alternative solution that doesn't require paths to be absolute:
For a given source file x.c, gcov requires x.c (main source),

x.gcno (static coverage meta data) and x.gcda (dynamically created

coverage data) to work. x.gcno may refer to further source files. To

find these files the corresponding paths need to be either absolute or

gcov must be called from gcc's current working directory during

compilation (which always should be $(objtree)).
Currently these files are placed like this:
  sysfs:

    x.gcda

    x.gcno -> symbolic link to $(objtree)/rel/path/x.gcno

    x.c -> symbolic link to $(srctree)/rel/path/x.c
  objtree:

    x.gcno
  srctree:

    x.c
Instead, kbuild could be modified to create links to x.gcda in

$(objtree) like this:
  sysfs:

    x.gcda
  objtree:

    x.gcno

    x.gcda -> symbolic link to /sys/kernel/debug/gcov/rel/path/x.gcda
  srctree:

    x.c
gcov could then be called like this:
  cd $(objtree)

  gcov -o rel/path/ $(srctree)/rel/path/x.c
Would this be an acceptable approach? Also, for automated collection of

coverage data, there must be some algorithm to find the source file for

a given .gcda file. Is the assumption correct that the "rel/path/" part

is the same for $(srctree) and $(objtree), i.e. can the source file

be derived like this?:
    $(objtree)/rel/path/x.o -> $(srctree)/rel/path/x.c
Alternatively, kbuild could also create a link to x.c in $(objtree),

though I'm not sure if that wouldn't have side effects like e.g. naming

conflicts with generated .c files in $(objtree).

--

IIRC, there was also the slight problem that all uses of __FILE__

(there are quite a few in the kernel) will also now be absolute and

increase the size of the vmlinux image by quite a bit.
Yeah... http://lkml.org/lkml/2006/4/25/40
Vegard
--

"The animistic metaphor of the bug that maliciously sneaked in while

the programmer was not looking is intellectually dishonest as it

disguises that the error is the programmer's own creation."

	-- E. W. Dijkstra, EWD1036

--

This is specific to O=.. build kernels.

I recall this is not an issue for the gcov patchset (if O=... is not used).

But I have not checked it.
	Sam

--