From: Peter Oberparleiter <peter.oberparleiter@de.ibm.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Oberparleiter <oberparleiter@googlemail.com>,
linux-kernel@vger.kernel.org, ltp-coverage@lists.sourceforge.net,
Sam Ravnborg <sam@ravnborg.org>
Subject: Re: [PATCH 0/6] gcov kernel support
Date: Wed, 11 Jun 2008 14:59:54 +0200 [thread overview]
Message-ID: <484FCC4A.1010605@de.ibm.com> (raw)
In-Reply-To: <20080609120954.7d41a5bf.akpm@linux-foundation.org>
Andrew Morton wrote:
> On Mon, 09 Jun 2008 15:49:16 +0200 Peter Oberparleiter <peter.oberparleiter@de.ibm.com> wrote:
>
>> Andrew Morton wrote:
>> > On Mon, 02 Jun 2008 15:33:51 +0200 Peter Oberparleiter <peter.oberparleiter@de.ibm.com> wrote:
>> >
>> >> This is version #3 of the gcov kernel support patch set
>> >
>> > My build tree is now filled with dead symlinks, like
>> >
>> > lrwxrwxrwx 1 akpm akpm 64 Jun 9 00:06 security/selinux/nlmsgtab.gcda -> /sys/kernel/debug/gcov/usr/src/25/security/selinux/nlmsgtab.gcda
>>
>> Unfortunately a necessary evil of this approach: symlinks are created
>> for all compiled source files while link targets are only available when
>> the corresponding code is executed. In other words: those links will be
>> dead for source files which don't compile to actual code and for modules
>> as long as they are not loaded.
>
> It doesn't seem awfully useful. I don't run kernels on my build
> machines and I'm sure many are in the same situation. So gcov is going
> to need a way of locating these files on the *target* machine. And
> once that is available, there is no need to add all these symlinks into
> the build directory.
I don't see any other feasibly way to do it if we want the kernel to
work out-of-the-box with gcov. If the kernel was a user-space
application, gcc/libgcov would create the .gcda files in exactly the
same place where the symbolic links are now.
If we removed those symlinks, users would have to manually copy files
from /sys on the test machine to the correct position in /objtree on the
build machine before being able to get any kind of result. This would
IMO reduce the usefulness of the gcov kernel infrastructure noticeably
(though gcov-wrappers such as lcov could be modified to hide the
additional effort).
How about a CONFIG_GCOV_PROFILE_SYMLINKS configuration option?
>> > Which causes (at least)
>> >
>> > ctags: Warning: cannot open source file "security/selinux/ss/conditional.gcda" : No such file or directory
>> > ctags: Warning: cannot open source file "security/selinux/netlink.gcda" : No such file or directory
>> > ctags: Warning: cannot open source file "security/selinux/netlabel.gcda" : No such file or directory
>>
>> > and probably other thing which I haven't discovered yet.
I would argue that any mechanism that tries to access all files in
/objtree regardless of filename extension is brave at best, if not
broken.
>> I'm sure there's some kind of 'find' magic that can be used to work
>> around dead links. I'll see how this can be applied to the ctags case -
>> though neither 'make tags' nor 'make TAGS' seem to produce any warnings
>> on my system..
>
> I use
>
> ctags -R --excmd=pattern --format=1
ctags -R --excmd=pattern --format=1 --exclude=\*.gcda
:)
Regards,
Peter
next prev parent reply other threads:[~2008-06-11 13:00 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-02 13:33 [PATCH 0/6] gcov kernel support Peter Oberparleiter
2008-06-09 7:25 ` Andrew Morton
2008-06-09 13:49 ` Peter Oberparleiter
2008-06-09 19:09 ` Andrew Morton
2008-06-11 12:59 ` Peter Oberparleiter [this message]
2008-06-11 20:22 ` Andrew Morton
2008-06-13 14:29 ` Peter Oberparleiter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=484FCC4A.1010605@de.ibm.com \
--to=peter.oberparleiter@de.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ltp-coverage@lists.sourceforge.net \
--cc=oberparleiter@googlemail.com \
--cc=sam@ravnborg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.