Skip to contentSkip to conversation

kbuild: make source and include paths absolute

PATCH In review Peter Oberparleiter 6 participants 9 messages May 19, 2008 – May 27, 2008 Kbuild

lore
Share & tools
lore
#0 lore raw

PATCH 6/7 kbuild: make source and include paths absolute

From: Peter Oberparleiter <[email protected]>

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.

---
 scripts/Kbuild.include |    7 +++++++
 scripts/Makefile.build |    3 ++-
 scripts/Makefile.lib   |    8 +++++++-
 3 files changed, 16 insertions(+), 2 deletions(-)
scripts/Makefile.lib +7 -1
Index: 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)
 
scripts/Makefile.build +2 -1
Index: 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 $@ \
+		$(if $(CONFIG_GCOV_PROFILE),$(call addpath,$<,$(objtree)),$<)
 
 ifdef CONFIG_MODVERSIONS
 # When module versioning is enabled the following steps are executed
scripts/Kbuild.include +7 -0
Index: linux-2.6.26-rc3/scripts/Kbuild.include
===================================================================
@@ -149,6 +149,13 @@ addtree = $(if $(filter-out -I/%,$(1)),$
 # Find all -I options and call addtree
 flags = $(foreach o,$($(1)),$(if $(filter -I%,$(o)),$(call addtree,$(o)),$(o)))
 
+# Prefix $(1) with $(2)/ if $(1) does not start with /
+addpath = $(if $(filter-out /%,$(1)),$(2)/$(1),$(1))
+
+# Find all -I options and call addpath
+flags_addpath = $(foreach o,$($(1)),\
+		$(if $(filter -I%,$(o)),-I$(call addpath,$(o:-I%=%),$(2)),$(o)))
+
 # echo command.
 # Short version is used, if $(quiet) equals `quiet_', otherwise full one.
 echo-cmd = $(if $($(quiet)cmd_$(1)),\
#1 lore raw
Quoted 9 lines · Peter Oberparleiter

From: Peter Oberparleiter <[email protected]>

Change all source and include paths to absolute form when CONFIG_GCOV_PROFILE is enabled.

Example:

gcc -Idir1 -c a.c -o a.o

Quoted 8 lines

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.

I think it would be good to fix this in the gcov tool. When I think of distribution kernels the source usually ends up in a different place in the packages than the kernel was originally compiled. So it would be good to extend gcov here or let it search in well known locations first (/usr/src/linux, /usr/src/debug/...).

Cheers,
Jan

#2 lore raw
In reply to Peter Oberparleiter
Quoted 9 lines · On Mon, 19 May 2008 10:44:56 +0200 Peter Oberparleiter…

From: Peter Oberparleiter <[email protected]>

Change all source and include paths to absolute form when CONFIG_GCOV_PROFILE is enabled.

Example:

gcc -Idir1 -c a.c -o a.o

Quoted 8 lines

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.

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.

#3 lore raw
Quoted 15 lines · Andrew Morton
Quoted 13 lines · On Mon, 19 May 2008 10:44:56 +0200 Peter Oberparleiter…

From: Peter Oberparleiter <[email protected]>

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

Quoted 8 lines
Quoted 4 lines

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.

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

Signature · 4 lines
       "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
#4 lore raw
Quoted 21 lines · On Fri, 23 May 2008 20:18:40 +0300 Adrian Bunk <[email protected]> wrote:
Quoted 20 lines · Andrew Morton
Quoted 17 lines · On Mon, 19 May 2008 10:44:56 +0200 Peter Oberparleiter…

From: Peter Oberparleiter <[email protected]>

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.

Quoted 7 lines
Quoted 3 lines

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

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?

#5 lore raw
Quoted 32 lines · Andrew Morton
Quoted 21 lines · On Fri, 23 May 2008 20:18:40 +0300 Adrian Bunk <[email protected]> wrote:
Quoted 20 lines · Andrew Morton
Quoted 17 lines · On Mon, 19 May 2008 10:44:56 +0200 Peter Oberparleiter…

From: Peter Oberparleiter <[email protected]>

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.

Quoted 7 lines
Quoted 3 lines

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

Quoted 7 lines

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

#6 lore raw
Quoted 35 lines · Sam Ravnborg
Quoted 34 lines · Andrew Morton
Quoted 21 lines · On Fri, 23 May 2008 20:18:40 +0300 Adrian Bunk <[email protected]> wrote:
Quoted 20 lines · Andrew Morton
Quoted 17 lines · On Mon, 19 May 2008 10:44:56 +0200 Peter Oberparleiter…

From: Peter Oberparleiter <[email protected]>

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.

Quoted 7 lines
Quoted 3 lines

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

Well I guess that's understandable with O=.

Quoted 8 lines
Quoted 5 lines

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.

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

Signature · 4 lines
"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
#7 lore raw
Quoted 9 lines
Quoted 9 lines
Quoted 8 lines

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?

Quoted 8 lines
Quoted 2 lines

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.

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

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

#8 lore raw
In reply to Sam Ravnborg
Quoted 35 lines · Sam Ravnborg
Quoted 34 lines · Andrew Morton
Quoted 21 lines · On Fri, 23 May 2008 20:18:40 +0300 Adrian Bunk <[email protected]> wrote:
Quoted 20 lines · Andrew Morton
Quoted 17 lines · On Mon, 19 May 2008 10:44:56 +0200 Peter Oberparleiter…

From: Peter Oberparleiter <[email protected]>

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.

Quoted 7 lines
Quoted 3 lines

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

Well I guess that's understandable with O=.

Quoted 8 lines
Quoted 5 lines

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.

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