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

[Peter Oberparleiter]

Sam Ravnborg wrote:
> On Fri, May 23, 2008 at 11:17:07AM -0700, Andrew Morton wrote:
>> On Fri, 23 May 2008 20:18:40 +0300
>> Adrian Bunk <bunk@xxxxxxxxxx> wrote:
>> 
>> > On Thu, May 22, 2008 at 08:17:24PM -0700, Andrew Morton wrote:
>> > > On Mon, 19 May 2008 10:44:56 +0200 Peter Oberparleiter <peter.oberparleiter@xxxxxxxxxx> wrote:
>> > > 
>> > > > From: Peter Oberparleiter <peter.oberparleiter@xxxxxxxxxx>
>> > > > 
>> > > > 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.
>> > > 
>> > > 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?
> 
> 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).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/