kbuild: make source and include paths absolute
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
@@ -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
@@ -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
@@ -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)),\
Quoted 9 lines · Peter Oberparleiter
From: Peter Oberparleiter <[email protected]>
Change all source and include paths to absolute form when
CONFIG_GCOV_PROFILEis 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
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_PROFILEis 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.
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_PROFILEis enabled.Example:
gcc -Idir1 -c
a.c-o a.owill 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 SeedQuoted 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_PROFILEis enabled.Example:
gcc -Idir1 -c
a.c-o a.owill 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?
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_PROFILEis enabled.Example:
gcc -Idir1 -c
a.c-o a.owill 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
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_PROFILEis enabled.Example:
gcc -Idir1 -c
a.c-o a.owill 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
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.
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
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_PROFILEis enabled.Example:
gcc -Idir1 -c
a.c-o a.owill 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.gcdasrctree:
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).