Thanks, now it can work for ntfs.
but it still not work for my really purpose.
I intend to get coverage for ocfs, It is filesystem module,=20
when I make it, all the .bb, .bbg file are still generated at SRCROOT, =
and the .o file is in the same dir as the .c file.
but on 2.4, it's ok.=20
I'm still investing this problem, maybe you can give me some suggestion?
From .cmd file, the command line of gcc is ok.
type this on command line, the .bb an .bbg is generated on the same =
directory as the .c file.
cmd_/home/xling/ocfs/ocfs2-6/src/inode.o :=3D gcc =
-Wp,-MD,/home/xling/ocfs/ocfs2-6/src/.inode.o.d -nostdinc -iwithprefix =
include -D__KERNEL__ -I/usr/src/linux-2.6.3/include =
-I/usr/src/linux-2.6.3 -I/usr/src/linux-2.6.3 =
-I/home/xling/ocfs/ocfs2-6/src -I/home/xling/ocfs/ocfs2-6/src =
-D__KERNEL__ -I/usr/src/linux-2.6.3/include -I/usr/src/linux-2.6.3 =
-I/usr/src/linux-2.6.3 -Wall -Wstrict-prototypes -Wno-trigraphs =
-fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=3D2 =
-march=3Dpentium4 -I/usr/src/linux-2.6.3/include/asm-i386/mach-default =
-O2 -fomit-frame-pointer -I/home/xling/ocfs/ocfs2-6/src/inc -DDEBUG =
-DTRACE -DHAVE_NPTL -DDEBUG_LOCK_BUFFER -DVERBOSE_BH_JBD_TRACE =
-DVERBOSE_LOCKING_TRACE -DVERBOSE_BH_SEQNUM_TRACE -DVERBOSE_PROCESS_VOTE =
-D__ILP32__ -Wall -Wstrict-prototypes -Wno-format =
-DOCFS_BUILD_DATE=3D\"y\" -DOCFS_BUILD_MD5=3D\"z\" =
-DOCFS_BUILD_VERSION=3D\"x\" -fprofile-arcs -ftest-coverage -DMODULE =
-DKBUILD_BASENAME=3Dinode -DKBUILD_MODNAME=3Docfs2 -c -o =
> -----Original Message-----
> From: Peter Oberparleiter [mailto:oberpapr@...]=20
> Sent: 2004=C4=EA4=D4=C220=C8=D5 20:47
> To: Ling, Xiaofeng
> Cc: ltp-coverage@...
> Subject: Re: [Ltp-coverage] kernel gcov problem
> On Tue, 2004-04-20 at 08:45, Ling, Xiaofeng wrote:
> > I tried to add in fs/ntfs/Makefile:
> > EXTRA_CFLAGS +=3D $(GCOV_FLAGS)
> > it does not work.
> > if add as:
> > EXTRA_CFLAGS +=3D -fprofile-arcs -ftest-coverage
> > the .bb and .bbg files are generated in the SRCROOT, not=20
> > SRCROOT/fs/ntfs.
> you've discovered two bugs in the gcov-kernel patch:
> 1. the GCOV_FLAGS variable isn't exported to sub-directory=20
> Makefiles 2. building a kernel in a separate object directory=20
> doesn't work if CONFIG_GCOV_ALL isn't set.
> I fixed those bugs - the LTP CVS repository now contains the=20
> corrected patch versions for linux-2.6.4 and linux-2.6.5.
> The correct way to instrument a subdirectory is, as you stated, to add
> EXTRA_CFLAGS +=3D $(GCOV_FLAGS)
> to the respective Makefile.
> Peter Oberparleiter
From: Peter Oberparleiter <oberpapr@so...> - 2004-04-23 11:36:46
On Friday 23 April 2004 05:46, Ling, Xiaofeng wrote:
> I intend to get coverage for ocfs, It is filesystem module,
> when I make it, all the .bb, .bbg file are still generated at SRCROOT, and
> the .o file is in the same dir as the .c file. but on 2.4, it's ok.
The place where the extra gcov files are created depends on the current
working directory when calling gcc, i.e. it depends on the build process you
are using to compile the external module. I don't know what process you are
using so I'm not sure what may have gone wrong.