This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [4.1 patch] relocate profile data file


H. J. Lu wrote:

This is for gcc 4.1.

--- gcc/doc/gcov.texi.prefex	2005-03-28 11:56:34.000000000 -0800
+++ gcc/doc/gcov.texi	2005-05-04 14:56:17.000000000 -0700
this needs some rewording, for better readability ...

+* Cross-profiling:: Data files relocation.
/files/file

+@section Data files relocation to support cross-profiling
/files/file

+file will be placed in the object file directory. That implicitly requires +running the program at the same system as it was build or having same
/at/on/ /build/built/ /same/the same/
+absolute directory structure on the target system (program will try +to create needed directory structure).
absolute directory structure on the target system. The program will try
to create the needed directory structure, if it is not already present.

+To support cross-profiling, program compiled with @option{-fprofile-arcs}
+performs data file relocation basing on two environment variables:
To support cross-profiling, a program compiled with @option{-fprofile-arcs}
can relocate the data files based on two environment variables:

+
+@itemize @bullet
+@item
+GCOV_PREFIX contains the prefix to add to the absolute paths +in the object file.
... The default is no prefix.

+@item
+GCOV_PREFIX_STRIP indicates the how many initial directory names to strip off +the hardwired absolute paths. Default value is 0.
+@end itemize
+
+For example, if object file @file{/user/build/foo.o} was build with +@option{-fprofile-arcs}, the final executable will try to create data file +@file{/user/build/foo.gcda} when running at the target system and will +fail if corresponding directory does not exists and is not allowed to create.
> +
> +In this case, manipulating environment variables you can relocate data file
> +to the suitable local directory. For our example, setting @samp{GCOV_PREFIX=/target/run}
> +and @samp{GCOV_PREFIX_STRIP=1} values will force use of @file{/target/run/build/foo.gcda}
> +file name.For example, if the object file @file{/user/build/foo.o} was built with
@option{-fprofile-arcs}, the final executable will try to create the data file
@file{/user/build/foo.gcda} when running on the target system.  This will
fail if the corresponding directory does not exist and it is unable to create
it.  This can be overcome by, for example, setting the environment as
@samp{GCOV_PREFIX=/target/run} and @samp{GCOV_PREFIX_STRIP=1}.  Such a
setting will name the data file @file{/target/run/build/foo.gcda}.

You must move the data files to the expected directory tree in order to
use them for profile directed optimizations (@option{--use-profile}), or to
use the the @command{gcov} tool.


--- gcc/gcov-io.c.prefex	2005-04-28 16:11:30.000000000 -0700
+++ gcc/gcov-io.c	2005-05-04 14:56:17.000000000 -0700

You have a separate create_directory function. Why is that? I would have though it would be simpler to do that directly in gcov_open. Then you'd only have to alloca once. Something like

 create full path
 if (open (name))
    return;
 for (ptr = end_of_name; ptr != start;)
    ptr = strrchr (ptr, '/') // get to the previous /
    *ptr = 0;
    if (exists (name))
	break;
 do
   *ptr = '/';
   if (!mkdir (name)) error
   ptr += strlen(ptr);
 while (ptr != end_of_name)
 if (open (name))
   return;
 error;

+/* Directory prefix to relocate coverage data file names */
+static char *gcov_prefix = 0;
this should be const char.

+  /* Initialize directory prefix if requred */
+  if (gcov_prefix == 0)
+    {
+      if ((gcov_prefix = getenv("GCOV_PREFIX")))
please no. move the assignment out of the if.

+        {
+          char *tmp;
+	
+          /* Normalize prefix: take off trailing separator. */
+	  tmp = gcov_prefix + strlen(gcov_prefix) - 1;
this will fail it the variable is present but empty.

It's not safe to save getenv return values like this.  If the
program calls putenv, the storage can get reallocated or blown
away.  You'll need to refetch it for each call to gcov_exit.
If we do that, it means the program could change the prefix AND
the strip count. Which means we need to do the stripping at that
point to.  Perhaps it would be best to move the getenvs into
gcov_exit and deal with the prefix and dir stripping there. Then
those two static variables would not be needed.  Also, you'd
have the full pathname available in gcov_exit and you won't
have to alter those error message calls.

Have you thought about specifying the prefix and strip to
the compiler and gcov itself, so you don't need to move the
data files after they've been created?

nathan

--
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]