Re: [google] support for building Linux kernel with FDO (issue4523061)
I found this thread through a Google search so I didn't have much context. Can you point me to the google/main source repo for gcc and the kernel? Are there plans to migrate this patch to the gcc and Linux mainline? Sorry, but I have never used the PGO option in icc. Steve Xinliang David Li wrote: This patch is for google/main which is 4.7 based, but the validated version is in google_46 branch (which is based on 4.6). By the way (given that you are from intel), do you know if linux kernel can be built with icc with PGO turned on? Our intern Xiaotian has tried to use icc (12.0) to built kernel, and had some problems. The bootable kernel built with icc + gcc (for those failed with icc) does not perform quite well. -- View this message in context: http://old.nabble.com/-google---support-for-building-Linux-kernel-with-FDO-%28issue4523061%29-tp31607746p32655618.html Sent from the gcc - patches mailing list archive at Nabble.com.
Re: [google] support for building Linux kernel with FDO (issue4523061)
Rong Xu wrote: That will be good. But you never know, we internally have fixed some bugs that filed to us because people use kernel's old gcov code (many versions guarded by ifdef) for their tests. -Rong Has there been any progress one this patch? What version of gcc is this patch for? I am interested in something that works with gcc 4.7. -Steve -- View this message in context: http://old.nabble.com/-google---support-for-building-Linux-kernel-with-FDO-%28issue4523061%29-tp31607746p32649731.html Sent from the gcc - patches mailing list archive at Nabble.com.
Re: [google] support for building Linux kernel with FDO (issue4523061)
This patch is for google/main which is 4.7 based, but the validated version is in google_46 branch (which is based on 4.6). By the way (given that you are from intel), do you know if linux kernel can be built with icc with PGO turned on? Our intern Xiaotian has tried to use icc (12.0) to built kernel, and had some problems. The bootable kernel built with icc + gcc (for those failed with icc) does not perform quite well. Thanks, David On Thu, Oct 13, 2011 at 7:02 PM, vulcansh steven.t.hamp...@intel.com wrote: Rong Xu wrote: That will be good. But you never know, we internally have fixed some bugs that filed to us because people use kernel's old gcov code (many versions guarded by ifdef) for their tests. -Rong Has there been any progress one this patch? What version of gcc is this patch for? I am interested in something that works with gcc 4.7. -Steve -- View this message in context: http://old.nabble.com/-google---support-for-building-Linux-kernel-with-FDO-%28issue4523061%29-tp31607746p32649731.html Sent from the gcc - patches mailing list archive at Nabble.com.
Re: [google] support for building Linux kernel with FDO (issue4523061)
On Mon, May 16, 2011 at 3:38 PM, Andi Kleen a...@firstfloor.org wrote: Jan Hubicka hubi...@ucw.cz writes: Yep, I think it does make sense to share the implementation, but we need to find resonable way to do so. I doubt this will be very popular with the kernel community, which prefers self contained code. Won't be surprised if there are objections .. Also the interface doesn't change that often or does it? As FDO gains popularity, the profile coverage code will change faster than people may think. To quote some potential ones -- lightweight ipo, path profiling, call trace profiling etc. The current kernel code is for gcc 3. That could be simply replaced with a modern gcc 4 interface. Rong's approach will let kernel get coverage + FDO support almost for free -- there is no need for kernel to maintain something is basically not maintainable. One other plus for embeddable gcov is that Linux kernel is not the only potential consumer of this infrastructure. So from sole gcov maintainer POV, I think adding such support for interface an dmaking libgcov building in its own directory is a positive thing. I doubt I will however have time to implement it myself this stage1 - the list of high priority things is just too long. Patches would be welcome, however. If kernel developers decides to maintain its own variant of libgcov, it is not big problem with me either and I am trying to keep the interface stable unless there are good reasons to break it. It is however clear that we will break libgcov interface this GCC release (we already did) and given new interest in it, probably in releases to come, too. Honza
Re: [google] support for building Linux kernel with FDO (issue4523061)
Rong Xu x...@google.com writes: The current kernel code is for gcc 3. That could be simply replaced with a modern gcc 4 interface. You cannot replace. You have to keep the code for every gcc versions that being used. I don't think it's a problem to not support gcc 3 gcov/profiling anymore. -Andi -- a...@linux.intel.com -- Speaking for myself only
Re: [google] support for building Linux kernel with FDO (issue4523061)
On Sun, May 15, 2011 at 3:27 AM, Jan Hubicka hubi...@ucw.cz wrote: On Fri, May 13, 2011 at 5:54 AM, Paolo Bonzini bonz...@gnu.org wrote: On 05/13/2011 03:03 AM, Rong Xu wrote: * gcc/coverage.c (revision 173717): set a flag if building for Linux kernel. * gcc/tree-profile.c (revision 173717): don't emit TLS declarations for Linux kernel builds. I think this should be done without touching at all the profiling machinery in GCC. 1) add a new TLS model -ftls-model=none and make the kernel uses it. The model would simply force targetm.have_tls to false. This is a good idea. 2) as Richi mentioned, gcov-io and libgcov changes then can move to the kernel, and GCC needs no change at all here. In fact -- reuse gcc code profiling machinery for FDO is the KEY objective in this effort --- the effort tries to minimize gcc changes by refactoring gcc code and isolating/abstracting away part of gcc implementation that is user space program specific without using runtime hooks. Aside from the kernel FDO change -- the refactoring itself actually makes the libgcov code more readable -- the existing implementation has many huge functions etc. Kernel source has their implementation of coverage testing -- but it makes lots of data structure assumptions and hard coded -- it can easily out of sync with gcc and is considered unmaintainable. Yep, I think it does make sense to share the implementation, but we need to find resonable way to do so. I guess we could separate out the i/o bits into interface generic enough to cover the needs, move libgcov into its own directory (just like libgcc is these days) and add an configury option Honza, Thanks for the comments. Can you elaborate what the options will be look like? -Rong that sets the interface. The kernel's interface can then be implemented in a single file instead of tons of ifdefs and I guess can sit either in kernel or gcc tree... Honza Rong will have more explanation on the design. Thanks, David BTW, these parts of LIPO: + if (!is_kernel_build) + DECL_TLS_MODEL (dc_gcov_type_ptr_var) = + decl_default_tls_model (dc_gcov_type_ptr_var); dc_void_ptr_var = build_decl (UNKNOWN_LOCATION, VAR_DECL, @@ -1488,8 +1493,9 @@ ptr_void); DECL_ARTIFICIAL (dc_void_ptr_var) = 1; DECL_EXTERNAL (dc_void_ptr_var) = 1; - DECL_TLS_MODEL (dc_void_ptr_var) = - decl_default_tls_model (dc_void_ptr_var); + if (!is_kernel_build) + DECL_TLS_MODEL (dc_void_ptr_var) = + decl_default_tls_model (dc_void_ptr_var); Probably are missing a !targetm.have_tls. Paolo
Re: [google] support for building Linux kernel with FDO (issue4523061)
On Fri, May 13, 2011 at 5:54 AM, Paolo Bonzini bonz...@gnu.org wrote: On 05/13/2011 03:03 AM, Rong Xu wrote: * gcc/coverage.c (revision 173717): set a flag if building for Linux kernel. * gcc/tree-profile.c (revision 173717): don't emit TLS declarations for Linux kernel builds. I think this should be done without touching at all the profiling machinery in GCC. 1) add a new TLS model -ftls-model=none and make the kernel uses it. The model would simply force targetm.have_tls to false. This is a good idea. 2) as Richi mentioned, gcov-io and libgcov changes then can move to the kernel, and GCC needs no change at all here. In fact -- reuse gcc code profiling machinery for FDO is the KEY objective in this effort --- the effort tries to minimize gcc changes by refactoring gcc code and isolating/abstracting away part of gcc implementation that is user space program specific without using runtime hooks. Aside from the kernel FDO change -- the refactoring itself actually makes the libgcov code more readable -- the existing implementation has many huge functions etc. Kernel source has their implementation of coverage testing -- but it makes lots of data structure assumptions and hard coded -- it can easily out of sync with gcc and is considered unmaintainable. Yep, I think it does make sense to share the implementation, but we need to find resonable way to do so. I guess we could separate out the i/o bits into interface generic enough to cover the needs, move libgcov into its own directory (just like libgcc is these days) and add an configury option that sets the interface. The kernel's interface can then be implemented in a single file instead of tons of ifdefs and I guess can sit either in kernel or gcc tree... Honza Rong will have more explanation on the design. Thanks, David BTW, these parts of LIPO: + if (!is_kernel_build) + DECL_TLS_MODEL (dc_gcov_type_ptr_var) = + decl_default_tls_model (dc_gcov_type_ptr_var); dc_void_ptr_var = build_decl (UNKNOWN_LOCATION, VAR_DECL, @@ -1488,8 +1493,9 @@ ptr_void); DECL_ARTIFICIAL (dc_void_ptr_var) = 1; DECL_EXTERNAL (dc_void_ptr_var) = 1; - DECL_TLS_MODEL (dc_void_ptr_var) = - decl_default_tls_model (dc_void_ptr_var); + if (!is_kernel_build) + DECL_TLS_MODEL (dc_void_ptr_var) = + decl_default_tls_model (dc_void_ptr_var); Probably are missing a !targetm.have_tls. Paolo
Re: [google] support for building Linux kernel with FDO (issue4523061)
On Fri, May 13, 2011 at 6:53 AM, Xinliang David Li davi...@google.com wrote: Ok for google/main. Seems to be very special and not appropriate for GCC trunk. Instead an adjusted copy providing the interface GCC needs should belong to the kernel tree. Richard.
Re: [google] support for building Linux kernel with FDO (issue4523061)
On Fri, May 13, 2011 at 6:53 AM, Xinliang David Li davi...@google.com wrote: Ok for google/main. Seems to be very special and not appropriate for GCC trunk. Instead an adjusted copy providing the interface GCC needs should belong to the kernel tree. Andi Kleen also did work in this direction. We probably should synchronize the efforts. It seems that there is quite a bit of FDO stuff that should get in some form to mainline for 4.7. Perhaps some overview would be helpful. Honza Richard.
Re: [google] support for building Linux kernel with FDO (issue4523061)
On 05/13/2011 03:03 AM, Rong Xu wrote: * gcc/coverage.c(revision 173717): set a flag if building for Linux kernel. * gcc/tree-profile.c(revision 173717): don't emit TLS declarations for Linux kernel builds. I think this should be done without touching at all the profiling machinery in GCC. 1) add a new TLS model -ftls-model=none and make the kernel uses it. The model would simply force targetm.have_tls to false. 2) as Richi mentioned, gcov-io and libgcov changes then can move to the kernel, and GCC needs no change at all here. BTW, these parts of LIPO: + if (!is_kernel_build) +DECL_TLS_MODEL (dc_gcov_type_ptr_var) = + decl_default_tls_model (dc_gcov_type_ptr_var); dc_void_ptr_var = build_decl (UNKNOWN_LOCATION, VAR_DECL, @@ -1488,8 +1493,9 @@ ptr_void); DECL_ARTIFICIAL (dc_void_ptr_var) = 1; DECL_EXTERNAL (dc_void_ptr_var) = 1; - DECL_TLS_MODEL (dc_void_ptr_var) = - decl_default_tls_model (dc_void_ptr_var); + if (!is_kernel_build) +DECL_TLS_MODEL (dc_void_ptr_var) = + decl_default_tls_model (dc_void_ptr_var); Probably are missing a !targetm.have_tls. Paolo
Re: [google] support for building Linux kernel with FDO (issue4523061)
On Fri, May 13, 2011 at 11:43:42AM +0200, Jan Hubicka wrote: On Fri, May 13, 2011 at 6:53 AM, Xinliang David Li davi...@google.com wrote: Ok for google/main. Seems to be very special and not appropriate for GCC trunk. Instead an adjusted copy providing the interface GCC needs should belong to the kernel tree. Andi Kleen also did work in this direction. We probably should synchronize the efforts. Yes, the in kernel gcov code -- which already has large parts of the gcov interface, but unfortunately for gcc 3 needs to be updated. This needs to be done inside the kernel tree though. I did some work on this to update, but my efforts fell a bit short. The resulting kernel was actually larger because I was missing some information. My variant didn't need the TLS changes because I just used atomic counters. I also ran into some problems with gcc when the information was not missing some TUs due to the way the information is collected. -Andi -- a...@linux.intel.com -- Speaking for myself only.
Re: [google] support for building Linux kernel with FDO (issue4523061)
On Fri, May 13, 2011 at 5:54 AM, Paolo Bonzini bonz...@gnu.org wrote: On 05/13/2011 03:03 AM, Rong Xu wrote: * gcc/coverage.c (revision 173717): set a flag if building for Linux kernel. * gcc/tree-profile.c (revision 173717): don't emit TLS declarations for Linux kernel builds. I think this should be done without touching at all the profiling machinery in GCC. 1) add a new TLS model -ftls-model=none and make the kernel uses it. The model would simply force targetm.have_tls to false. This is a good idea. 2) as Richi mentioned, gcov-io and libgcov changes then can move to the kernel, and GCC needs no change at all here. In fact -- reuse gcc code profiling machinery for FDO is the KEY objective in this effort --- the effort tries to minimize gcc changes by refactoring gcc code and isolating/abstracting away part of gcc implementation that is user space program specific without using runtime hooks. Aside from the kernel FDO change -- the refactoring itself actually makes the libgcov code more readable -- the existing implementation has many huge functions etc. Kernel source has their implementation of coverage testing -- but it makes lots of data structure assumptions and hard coded -- it can easily out of sync with gcc and is considered unmaintainable. Rong will have more explanation on the design. Thanks, David BTW, these parts of LIPO: + if (!is_kernel_build) + DECL_TLS_MODEL (dc_gcov_type_ptr_var) = + decl_default_tls_model (dc_gcov_type_ptr_var); dc_void_ptr_var = build_decl (UNKNOWN_LOCATION, VAR_DECL, @@ -1488,8 +1493,9 @@ ptr_void); DECL_ARTIFICIAL (dc_void_ptr_var) = 1; DECL_EXTERNAL (dc_void_ptr_var) = 1; - DECL_TLS_MODEL (dc_void_ptr_var) = - decl_default_tls_model (dc_void_ptr_var); + if (!is_kernel_build) + DECL_TLS_MODEL (dc_void_ptr_var) = + decl_default_tls_model (dc_void_ptr_var); Probably are missing a !targetm.have_tls. Paolo
Re: [google] support for building Linux kernel with FDO (issue4523061)
Thanks for the comments. This particular patch is not intended for trunk. But we do want to hear your feedback on our designs. On Fri, May 13, 2011 at 9:31 AM, Xinliang David Li davi...@google.com wrote: On Fri, May 13, 2011 at 5:54 AM, Paolo Bonzini bonz...@gnu.org wrote: On 05/13/2011 03:03 AM, Rong Xu wrote: * gcc/coverage.c (revision 173717): set a flag if building for Linux kernel. * gcc/tree-profile.c (revision 173717): don't emit TLS declarations for Linux kernel builds. I think this should be done without touching at all the profiling machinery in GCC. 1) add a new TLS model -ftls-model=none and make the kernel uses it. The model would simply force targetm.have_tls to false. This is a good idea. Agreed. We can use the option together with -fprofile-generate. 2) as Richi mentioned, gcov-io and libgcov changes then can move to the kernel, and GCC needs no change at all here. In fact -- reuse gcc code profiling machinery for FDO is the KEY objective in this effort --- the effort tries to minimize gcc changes by refactoring gcc code and isolating/abstracting away part of gcc implementation that is user space program specific without using runtime hooks. Aside from the kernel FDO change -- the refactoring itself actually makes the libgcov code more readable -- the existing implementation has many huge functions etc. Kernel source has their implementation of coverage testing -- but it makes lots of data structure assumptions and hard coded -- it can easily out of sync with gcc and is considered unmaintainable. Rong will have more explanation on the design. David has said most I want to say. I just add one more thing: kernel can be compiled with many versions of gcc where libgcov is not guaranteed to be compatible. It's will be messy if we put the all versions of libgcov code into kernel. It's much cleaner to reuse the libgcov code in gcc. For maintenance, it's better to have a central place for one functionality. The functionality in libgcov can be rough divided into the following part: (1) gcov_init support: kernel need to have it's own version. (2) runtime profile support: this part is mostly neutral to user-space mode or kernel mode. Only some LIPO support needs to use a few libc functions. (3) dumping the profile file (traverse gcov_list, compute summary, merging profile, wrtie gcda file etc). I would say most of the functionalities are neutral. Only the file I/O part is specific to user-mode. Kernel's merging function is not necessary as it can be done offline. We need to refactor gcov_exit() so it can dump one individual gcov_info. So I think it's reasonable to factor the libgcov code to provide kernel support. There are many place in this patch can be improved in this regard, but here are the key points of our design that we want to keep: (1) The functionality of dumping gcov_info (independent of use-space mode or kernel mode) should be in gcc. (2) libgcov source in gcc will be exported to kernel. We can re-factor current implementation to separate kernel code. I have another patch that puts all the kernel code into separated files (and they can easily be moved to kernel.) Thanks, David BTW, these parts of LIPO: + if (!is_kernel_build) + DECL_TLS_MODEL (dc_gcov_type_ptr_var) = + decl_default_tls_model (dc_gcov_type_ptr_var); dc_void_ptr_var = build_decl (UNKNOWN_LOCATION, VAR_DECL, @@ -1488,8 +1493,9 @@ ptr_void); DECL_ARTIFICIAL (dc_void_ptr_var) = 1; DECL_EXTERNAL (dc_void_ptr_var) = 1; - DECL_TLS_MODEL (dc_void_ptr_var) = - decl_default_tls_model (dc_void_ptr_var); + if (!is_kernel_build) + DECL_TLS_MODEL (dc_void_ptr_var) = + decl_default_tls_model (dc_void_ptr_var); Probably are missing a !targetm.have_tls. Paolo
Re: [google] support for building Linux kernel with FDO (issue4523061)
Thanks for the comments. This particular patch is not intended for trunk. But we do want to hear your feedback on our designs. On Fri, May 13, 2011 at 9:31 AM, Xinliang David Li davi...@google.com wrote: On Fri, May 13, 2011 at 5:54 AM, Paolo Bonzini bonz...@gnu.org wrote: On 05/13/2011 03:03 AM, Rong Xu wrote: * gcc/coverage.c (revision 173717): set a flag if building for Linux kernel. * gcc/tree-profile.c (revision 173717): don't emit TLS declarations for Linux kernel builds. I think this should be done without touching at all the profiling machinery in GCC. 1) add a new TLS model -ftls-model=none and make the kernel uses it. The model would simply force targetm.have_tls to false. This is a good idea. Agreed. We can use the option together with -fprofile-generate. 2) as Richi mentioned, gcov-io and libgcov changes then can move to the kernel, and GCC needs no change at all here. In fact -- reuse gcc code profiling machinery for FDO is the KEY objective in this effort --- the effort tries to minimize gcc changes by refactoring gcc code and isolating/abstracting away part of gcc implementation that is user space program specific without using runtime hooks. Aside from the kernel FDO change -- the refactoring itself actually makes the libgcov code more readable -- the existing implementation has many huge functions etc. Kernel source has their implementation of coverage testing -- but it makes lots of data structure assumptions and hard coded -- it can easily out of sync with gcc and is considered unmaintainable. Rong will have more explanation on the design. David has said most I want to say. I just add one more thing: kernel can be compiled with many versions of gcc where libgcov is not guaranteed to be compatible. It's will be messy if we put the all versions of libgcov code into kernel. It's much cleaner to reuse the libgcov code in gcc. For maintenance, it's better to have a central place for one functionality. The functionality in libgcov can be rough divided into the following part: (1) gcov_init support: kernel need to have it's own version. (2) runtime profile support: this part is mostly neutral to user-space mode or kernel mode. Only some LIPO support needs to use a few libc functions. (3) dumping the profile file (traverse gcov_list, compute summary, merging profile, wrtie gcda file etc). I would say most of the functionalities are neutral. Only the file I/O part is specific to user-mode. Kernel's merging function is not necessary as it can be done offline. We need to refactor gcov_exit() so it can dump one individual gcov_info. So I think it's reasonable to factor the libgcov code to provide kernel support. There are many place in this patch can be improved in this regard, but here are the key points of our design that we want to keep: (1) The functionality of dumping gcov_info (independent of use-space mode or kernel mode) should be in gcc. (2) libgcov source in gcc will be exported to kernel. We can re-factor current implementation to separate kernel code. I have another patch that puts all the kernel code into separated files (and they can easily be moved to kernel.) Thanks, David BTW, these parts of LIPO: + if (!is_kernel_build) + DECL_TLS_MODEL (dc_gcov_type_ptr_var) = + decl_default_tls_model (dc_gcov_type_ptr_var); dc_void_ptr_var = build_decl (UNKNOWN_LOCATION, VAR_DECL, @@ -1488,8 +1493,9 @@ ptr_void); DECL_ARTIFICIAL (dc_void_ptr_var) = 1; DECL_EXTERNAL (dc_void_ptr_var) = 1; - DECL_TLS_MODEL (dc_void_ptr_var) = - decl_default_tls_model (dc_void_ptr_var); + if (!is_kernel_build) + DECL_TLS_MODEL (dc_void_ptr_var) = + decl_default_tls_model (dc_void_ptr_var); Probably are missing a !targetm.have_tls. Paolo
[google] support for building Linux kernel with FDO (issue4523061)
This patch add support to build Linux kernel with FDO.
Building Linux kernel with FDO needs both compiler change and
kernel changes. This part only contains the gcc changes. I'll
attach kernel changes to the reveiew thread for reference.
Source files gcov-io.c gcov-io.h and libgcov.c will be copied to
kernel source and directly used in the kernel build. When building
for kernel, we assume option '-D__KERNEL__' is used.
To enable profile generation, we need to
a.1) set the following config:
CONFIG_GCOV_KERNEL=y
CONFIG_GCOV_PROFILE_ALL=y
a.2) set COMPILER_LIB_PATH to the absolute path to the
parent directory of gcov-src. gcov-src is a directory
containing the following 4 files:
gcov-iov.h gcov-io.h gcov-io.c and libgcov.c.
It usually sits at
${GCC_ROOT}/lib/gcc/x86_64-unknown-linux-gnu/${GCC_VERSION}/
a.3) set CFLAGS_GCOV as -fprofile-generate and build the
kernel (prof_gen).
To obtain the profile data
b.1) install profile_gen kernel, mount debugfs.
b.2) reset the profile count:
echo 1 /sys/kernel/debug/gcov/reset
b.3) run the benchmark
b.4) cp -r /sys/kernel/debug/gcov/your_kernel_build_dir/ dest_dir
To build FDO optimized kernel:
c.1 ) same as a.1).
c.2 ) same as a.2).
c.3) set set CFLAGS_GCOV as
-fprofile-use -fprofile-correction -Wcoverage-mismatch and build.
Performance results:
Tested with 2.6.34 and 2.6.36 kernel with stand-alone benchmarks:
tbench(~23%), dbench(~4%), unixbench(1%-2%), no noticable regressions.
This patch has been testd with bootstraps, regression test, standalong
kernel benchmarks (tbench, dbench, membench, unixbench, iozone, specjbb,
and kernbench), and google internal FDO tests.
2011-05-12 Rong Xu x...@google.com
* gcc/gcov-io.c (revision 173717): FDO support to build Linux kernel.
* gcc/gcov-io.h (revision 173717): FDO support to build Linux kernel.
* gcc/coverage.c(revision 173717): set a flag if building for
Linux kernel.
* gcc/tree-profile.c(revision 173717): don't emit TLS declarations
for Linux kernel builds.
* gcc/libgcov.c (revision 173717): FDO support to build Linux kernel.
Index: gcc/gcov-io.c
===
--- gcc/gcov-io.c (revision 173717)
+++ gcc/gcov-io.c (working copy)
@@ -32,6 +32,10 @@
static void gcov_allocate (unsigned);
#endif
+#ifdef __GCOV_KERNEL__
+struct gcov_var gcov_var ATTRIBUTE_HIDDEN;
+#endif
+
static inline gcov_unsigned_t from_file (gcov_unsigned_t value)
{
#if !IN_LIBGCOV
@@ -54,6 +58,7 @@
Return zero on failure, 0 on opening an existing file and 0 on
creating a new one. */
+#ifndef __GCOV_KERNEL__
GCOV_LINKAGE int
#if IN_LIBGCOV
gcov_open (const char *name)
@@ -148,7 +153,24 @@
return 1;
}
+#else /* __GCOV_KERNEL__ */
+extern _GCOV_FILE *gcov_current_file;
+
+GCOV_LINKAGE int
+gcov_open (const char *name)
+{
+ gcov_var.start = 0;
+ gcov_var.offset = gcov_var.length = 0;
+ gcov_var.overread = -1u;
+ gcov_var.error = 0;
+ gcov_var.file = gcov_current_file;
+ gcov_var.mode = 1;
+
+ return 1;
+}
+#endif /* __GCOV_KERNEL__ */
+
/* Close the current gcov file. Flushes data to disk. Returns nonzero
on failure or error flag set. */
@@ -161,7 +183,7 @@
if (gcov_var.offset gcov_var.mode 0)
gcov_write_block (gcov_var.offset);
#endif
- fclose (gcov_var.file);
+ _GCOV_fclose (gcov_var.file);
gcov_var.file = 0;
gcov_var.length = 0;
}
@@ -217,7 +239,7 @@
static void
gcov_write_block (unsigned size)
{
- if (fwrite (gcov_var.buffer, size 2, 1, gcov_var.file) != 1)
+ if (_GCOV_fwrite (gcov_var.buffer, size 2, 1, gcov_var.file) != 1)
gcov_var.error = 1;
gcov_var.start += size;
gcov_var.offset -= size;
@@ -413,7 +435,7 @@
gcov_allocate (gcov_var.length + words);
excess = gcov_var.alloc - gcov_var.length;
#endif
- excess = fread (gcov_var.buffer + gcov_var.length,
+ excess = _GCOV_fread (gcov_var.buffer + gcov_var.length,
1, excess 2, gcov_var.file) 2;
gcov_var.length += excess;
if (gcov_var.length words)
@@ -554,6 +576,10 @@
GCOV_LINKAGE void
gcov_sync (gcov_position_t base, gcov_unsigned_t length)
{
+#ifdef __GCOV_KERNEL__
+ /* should not reach this point */
+ gcc_assert (0);
+#else /* __GCOV_KERNEL__ */
gcc_assert (gcov_var.mode 0);
base += length;
if (base - gcov_var.start = gcov_var.length)
@@ -561,9 +587,10 @@
else
{
gcov_var.offset = gcov_var.length = 0;
- fseek (gcov_var.file, base 2, SEEK_SET);
- gcov_var.start = ftell (gcov_var.file) 2;
+ _GCOV_fseek (gcov_var.file, base 2, SEEK_SET);
+ gcov_var.start = _GCOV_ftell (gcov_var.file) 2;
}
+#endif /* __GCOV_KERNEL__ */
}
#endif
@@ -576,8 +603,8 @@
gcc_assert (gcov_var.mode 0);
if (gcov_var.offset)
gcov_write_block (gcov_var.offset);
- fseek (gcov_var.file, base 2, SEEK_SET);
-
