[PATCH] enabling gprof for cross builds

[PATCH] enabling gprof for cross builds

[Mark Shinwell]

[-- Attachment #1: Type: text/plain, Size: 843 bytes --]

Hi,

The attached patchette enables building of gprof for cross builds.
I believe gprof builds and executes correctly in this scenario with the 
single caveat that if you wish to examine gmon.out files produced on a 
target whose pointer size is 64 bits then you must compile gprof with a 
compiler that supports a 64-bit integer type.  As far as I can tell, 
endianness issues are handled automatically by virtue of the I/O 
routines going via bfd.

Does that caveat mean that a configure test (involving the build 
compiler's capability and the pointer size of the target) should be used 
to determine whether to build gprof?  I hear that this might be overkill.

Tested with cross builds from i686 to SPARC and ARM architectures.

Comments appreciated: I've recently started at CodeSourcery and so am 
somewhat new to all of this :-)

Mark

[-- Attachment #2: binutils-gprof.patch --]
[-- Type: text/plain, Size: 938 bytes --]

Index: configure.in
===================================================================
RCS file: /cvs/src/src/configure.in,v
retrieving revision 1.305
diff -U3 -p -r1.305 configure.in
--- configure.in	2 May 2006 00:16:50 -0000	1.305
+++ configure.in	8 May 2006 18:48:54 -0000
@@ -227,7 +227,7 @@ esac
 
 # Some tools are only suitable for building in a "native" situation.
 # Remove these if host!=target.  
-native_only="autoconf automake libtool fileutils find gawk gettext gzip hello indent m4 rcs recode sed shellutils tar textutils uudecode wdiff gprof target-groff guile perl time ash bash bzip2 prms gnuserv target-gperf"
+native_only="autoconf automake libtool fileutils find gawk gettext gzip hello indent m4 rcs recode sed shellutils tar textutils uudecode wdiff target-groff guile perl time ash bash bzip2 prms gnuserv target-gperf"
 
 # Similarly, some are only suitable for cross toolchains.
 # Remove these if host=target.

Re: [PATCH] enabling gprof for cross builds

[Daniel Jacobowitz]

Please include a ChangeLog entry next time :-)

Otherwise, I think this is fine; as I told you earlier, I've been
meaning to do it for years.

Do you have write access to gcc yet?  Changes to the top level files
need to be committed in sync to both trees.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [PATCH] enabling gprof for cross builds

[Ben Elliston]

> Does that caveat mean that a configure test (involving the build
> compiler's capability and the pointer size of the target) should be
> used to determine whether to build gprof?  I hear that this might be
> overkill.

You should certainly make sure that users aren't tripped up by any
caveats (either at build time, or runtime, if you prefer).  Don't
allow the cross-gprof to produce erroneous results.

Thanks for doing this!

Ben

Re: [PATCH] enabling gprof for cross builds

[Mark Shinwell]

Ben Elliston wrote:
>> Does that caveat mean that a configure test (involving the build
>> compiler's capability and the pointer size of the target) should be
>> used to determine whether to build gprof?  I hear that this might be
>> overkill.
> 
> You should certainly make sure that users aren't tripped up by any
> caveats (either at build time, or runtime, if you prefer).  Don't
> allow the cross-gprof to produce erroneous results.

After some more investigations today, I'm lead to believe that this is 
in fact a non-caveat.  Suppose we have the situation where binutils is 
built with a host compiler that does not possess a 64-bit integer type 
and the user then attempts to invoke gprof on a 64-bit executable.  In 
this scenario I believe that gprof is going to report an error anyway, 
since bfd will not have been built with 64-bit support and so will 
refuse to open the executable.

I therefore think that my original patch is in fact sufficient.

I've tried to test this hypothesis by adjusting the configure variables 
to simulate a host compiler lacking in a 64-bit data type, but I have so 
far failed to get this to work.  Perhaps someone here might be able to 
confirm the above behaviour of bfd from their prior knowledge...

Mark

Re: [PATCH] enabling gprof for cross builds

[Mark Shinwell]

Mark Shinwell wrote:
> Ben Elliston wrote:
>>> Does that caveat mean that a configure test (involving the build
>>> compiler's capability and the pointer size of the target) should be
>>> used to determine whether to build gprof?  I hear that this might be
>>> overkill.
>>
>> You should certainly make sure that users aren't tripped up by any
>> caveats (either at build time, or runtime, if you prefer).  Don't
>> allow the cross-gprof to produce erroneous results.
> 
> After some more investigations today, I'm lead to believe that this is 
> in fact a non-caveat.  Suppose we have the situation where binutils is 
> built with a host compiler that does not possess a 64-bit integer type 
> and the user then attempts to invoke gprof on a 64-bit executable.  In 
> this scenario I believe that gprof is going to report an error anyway, 
> since bfd will not have been built with 64-bit support and so will 
> refuse to open the executable.
> 
> I therefore think that my original patch is in fact sufficient.
> 
> I've tried to test this hypothesis by adjusting the configure variables 
> to simulate a host compiler lacking in a 64-bit data type, but I have so 
> far failed to get this to work.  Perhaps someone here might be able to 
> confirm the above behaviour of bfd from their prior knowledge...

Could I ping on this one please.

Mark

Re: [PATCH] enabling gprof for cross builds

[Daniel Jacobowitz]

On Wed, May 24, 2006 at 08:24:13AM +0100, Mark Shinwell wrote:
> Could I ping on this one please.

I'm sufficiently convinced.  With a changelog entry, this is OK.  Be
sure to (A) commit it to both gcc and src, and (B) regenerate the top
level configure script with the correct version of autoconf.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [PATCH] enabling gprof for cross builds

[Mark Shinwell]

[-- Attachment #1: Type: text/plain, Size: 412 bytes --]

Daniel Jacobowitz wrote:
> On Wed, May 24, 2006 at 08:24:13AM +0100, Mark Shinwell wrote:
>> Could I ping on this one please.
> 
> I'm sufficiently convinced.  With a changelog entry, this is OK.  Be
> sure to (A) commit it to both gcc and src, and (B) regenerate the top
> level configure script with the correct version of autoconf.

Committed to both gcc and src.  (Patches attached for completeness.)

Mark


[-- Attachment #2: gcc-gprof.patch --]
[-- Type: text/plain, Size: 3480 bytes --]

Index: ChangeLog
===================================================================
--- ChangeLog	(revision 114021)
+++ ChangeLog	(working copy)
@@ -1,3 +1,8 @@
+2006-05-24  Mark Shinwell  <shinwell@codesourcery.com>
+
+	* configure.in: Enable gprof for cross builds.
+	* configure: Regenerate.
+
 2006-05-22  Richard Guenther  <rguenther@suse.de>
 
 	Revert
Index: configure
===================================================================
--- configure	(revision 114021)
+++ configure	(working copy)
@@ -1013,7 +1013,7 @@ esac
 
 # Some tools are only suitable for building in a "native" situation.
 # Remove these if host!=target.  
-native_only="autoconf automake libtool fileutils find gawk gettext gzip hello indent m4 rcs recode sed shellutils tar textutils uudecode wdiff gprof target-groff guile perl time ash bash bzip2 prms gnuserv target-gperf"
+native_only="autoconf automake libtool fileutils find gawk gettext gzip hello indent m4 rcs recode sed shellutils tar textutils uudecode wdiff target-groff guile perl time ash bash bzip2 prms gnuserv target-gperf"
 
 # Similarly, some are only suitable for cross toolchains.
 # Remove these if host=target.
@@ -7290,15 +7290,34 @@ trap 'rm -f $CONFIG_STATUS conftest*; ex
 # Transform confdefs.h into DEFS.
 # Protect against shell expansion while executing Makefile rules.
 # Protect against Makefile macro expansion.
-cat > conftest.defs <<\EOF
-s%#define \([A-Za-z_][A-Za-z0-9_]*\) *\(.*\)%-D\1=\2%g
-s%[ 	`~#$^&*(){}\\|;'"<>?]%\\&%g
-s%\[%\\&%g
-s%\]%\\&%g
-s%\$%$$%g
-EOF
-DEFS=`sed -f conftest.defs confdefs.h | tr '\012' ' '`
-rm -f conftest.defs
+#
+# If the first sed substitution is executed (which looks for macros that
+# take arguments), then we branch to the quote section.  Otherwise,
+# look for a macro that doesn't take arguments.
+cat >confdef2opt.sed <<\_ACEOF
+t clear
+: clear
+s,^[ 	]*#[ 	]*define[ 	][ 	]*\([^ 	(][^ 	(]*([^)]*)\)[ 	]*\(.*\),-D\1=\2,g
+t quote
+s,^[ 	]*#[ 	]*define[ 	][ 	]*\([^ 	][^ 	]*\)[ 	]*\(.*\),-D\1=\2,g
+t quote
+d
+: quote
+s,[ 	`~#$^&*(){}\\|;'"<>?],\\&,g
+s,\[,\\&,g
+s,\],\\&,g
+s,\$,$$,g
+p
+_ACEOF
+# We use echo to avoid assuming a particular line-breaking character.
+# The extra dot is to prevent the shell from consuming trailing
+# line-breaks from the sub-command output.  A line-break within
+# single-quotes doesn't work because, if this script is created in a
+# platform that uses two characters for line-breaks (e.g., DOS), tr
+# would break.
+ac_LF_and_DOT=`echo; echo .`
+DEFS=`sed -n -f confdef2opt.sed confdefs.h | tr "$ac_LF_and_DOT" ' .'`
+rm -f confdef2opt.sed
 
 
 # Without the "./", some shells look in PATH for config.status.
Index: configure.in
===================================================================
--- configure.in	(revision 114021)
+++ configure.in	(working copy)
@@ -226,7 +226,7 @@ esac
 
 # Some tools are only suitable for building in a "native" situation.
 # Remove these if host!=target.  
-native_only="autoconf automake libtool fileutils find gawk gettext gzip hello indent m4 rcs recode sed shellutils tar textutils uudecode wdiff gprof target-groff guile perl time ash bash bzip2 prms gnuserv target-gperf"
+native_only="autoconf automake libtool fileutils find gawk gettext gzip hello indent m4 rcs recode sed shellutils tar textutils uudecode wdiff target-groff guile perl time ash bash bzip2 prms gnuserv target-gperf"
 
 # Similarly, some are only suitable for cross toolchains.
 # Remove these if host=target.

[-- Attachment #3: src-gprof.patch --]
[-- Type: text/plain, Size: 1575 bytes --]

Index: configure
===================================================================
RCS file: /cvs/src/src/configure,v
retrieving revision 1.218
diff -r1.218 configure
1025c1025
< native_only="autoconf automake libtool fileutils find gawk gettext gzip hello indent m4 rcs recode sed shellutils tar textutils uudecode wdiff gprof target-groff guile perl time ash bash bzip2 prms gnuserv target-gperf"
---
> native_only="autoconf automake libtool fileutils find gawk gettext gzip hello indent m4 rcs recode sed shellutils tar textutils uudecode wdiff target-groff guile perl time ash bash bzip2 prms gnuserv target-gperf"
Index: ChangeLog
===================================================================
RCS file: /cvs/src/src/ChangeLog,v
retrieving revision 1.650
diff -r1.650 ChangeLog
0a1,5
> 2006-05-24  Mark Shinwell  <shinwell@codesourcery.com>
> 
>       * configure.in: Enable gprof for cross builds.
>       * configure: Regenerate.
> 
Index: configure.in
===================================================================
RCS file: /cvs/src/src/configure.in,v
retrieving revision 1.305
diff -r1.305 configure.in
230c230
< native_only="autoconf automake libtool fileutils find gawk gettext gzip hello indent m4 rcs recode sed shellutils tar textutils uudecode wdiff gprof target-groff guile perl time ash bash bzip2 prms gnuserv target-gperf"
---
> native_only="autoconf automake libtool fileutils find gawk gettext gzip hello indent m4 rcs recode sed shellutils tar textutils uudecode wdiff target-groff guile perl time ash bash bzip2 prms gnuserv target-gperf"

Re: [PATCH] enabling gprof for cross builds

[Nick Clifton]

Hi Danny,

> I have a patch that allows you to specify a different directory than the
> host source directory.
> 
> That means :
> - you compile on a PC, sources in e.g. /home/danny/src/prog.c
> - by default, gcc compiles in a path /home/danny/src in which the
>   executable will try to store its profile information
> - that is not always present on the mobile device
> - there is a way to change this directory at run time, but that
>   isn't always easy (it isn't on CE)
> - so I've added a way to specify a different directory at compile
>   time, meaning I can override the directory that gcc puts in the
>   object file
> 
> I've been wanting to submit the code but didn't get around to it yet.
> 
> Should I clean it up and submit ?

This does sound interesting, but isn't this a patch to gcc rather than 
to gprof ?  If so then it should be submitted to the gcc-patches list 
rather than the binutils list.  Either way though, cleaning it up and 
submitting it would be a good thing to do.

Cheers
   Nick

Re: [PATCH] enabling gprof for cross builds

[Danny Backx]

[-- Attachment #1: Type: text/plain, Size: 1480 bytes --]

I need to apologise, I probably anwered the wrong question.

I've done stuff for gprof and gcov on the cegcc project.

For gprof, the tweaks are now in a directory src/profile/profile in our
svn; for gcov, they are in (roughly) src/gcc/gcc/*gcov* .

The gcov stuff allows you to specify a different directory on the gcc
command line, I didn't do this for gprof.

Does any of this sound interesting ?

I've been wanting to submit the gcov tweaks but I need to find the time.
Also part of the process is that I need to ask the maintainers how to
preferably get the information into the tool : should this via a gcc
command line option, an environment variable, or both.

	Danny


On Thu, 2007-04-12 at 21:39 +0100, John Tytgat wrote:
> In message <1176390019.14038.54.camel@dannypc>
>           Danny Backx <danny.backx@scarlet.be> wrote:
> 
> > [ cross-compiled gprof ]
> > I played with this a while ago for cegcc, and got it to work. (Host
> > environment is either linux or cygwin, target is Windows CE on ARM.)
> > 
> > I have a patch that allows you to specify a different directory than the
> > host source directory.
> > 
> > That means :
> > [...]
> > 
> > I've been wanting to submit the code but didn't get around to it yet.
> > 
> > Should I clean it up and submit ?
> 
> I would be interested to see this commited.
> 
> Thanks for the effort,
> John.
-- 
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] enabling gprof for cross builds

[John Tytgat]

In message <1176390019.14038.54.camel@dannypc>
          Danny Backx <danny.backx@scarlet.be> wrote:

> [ cross-compiled gprof ]
> I played with this a while ago for cegcc, and got it to work. (Host
> environment is either linux or cygwin, target is Windows CE on ARM.)
> 
> I have a patch that allows you to specify a different directory than the
> host source directory.
> 
> That means :
> [...]
> 
> I've been wanting to submit the code but didn't get around to it yet.
> 
> Should I clean it up and submit ?

I would be interested to see this commited.

Thanks for the effort,
John.
-- 
John Tytgat, in his comfy chair at home               GCCSDK: GCC on RISC OS
John.Tytgat@aaug.net                              http://gccsdk.riscos.info/

Re: [PATCH] enabling gprof for cross builds

[Danny Backx]

[-- Attachment #1: Type: text/plain, Size: 1621 bytes --]

I played with this a while ago for cegcc, and got it to work. (Host
environment is either linux or cygwin, target is Windows CE on ARM.)

I have a patch that allows you to specify a different directory than the
host source directory.

That means :
- you compile on a PC, sources in e.g. /home/danny/src/prog.c
- by default, gcc compiles in a path /home/danny/src in which the
  executable will try to store its profile information
- that is not always present on the mobile device
- there is a way to change this directory at run time, but that
  isn't always easy (it isn't on CE)
- so I've added a way to specify a different directory at compile
  time, meaning I can override the directory that gcc puts in the
  object file

I've been wanting to submit the code but didn't get around to it yet.

Should I clean it up and submit ?

	Danny

On Thu, 2007-04-12 at 10:45 +1000, Ben Elliston wrote:
> On Mon, 2007-04-09 at 13:45 -0400, Sanjay Chadha wrote:
> 
> > [schadha@devjava1-fc4 binutils-2.15.91.0.2]$ ./configure
> > --target=mipsel-linux --host==mipsel-linux
> > [schadha@devjava1-fc4 binutils-2.15.91.0.2]$ make
> > 
> > However the compiled gprof was compiled for the host (i386) machine. Any
> > ideas of what other changes may be required to cross compile gprof for
> > the mips machine.
> 
> gprof runs on the host, not on the target (but it reads target object
> code, of course).  In your configure command line above, I see you used
> ==, not =.  Perhaps that is your problem.
> 
> Ben
> 
-- 
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] enabling gprof for cross builds

[Ben Elliston]

On Mon, 2007-04-09 at 13:45 -0400, Sanjay Chadha wrote:

> [schadha@devjava1-fc4 binutils-2.15.91.0.2]$ ./configure
> --target=mipsel-linux --host==mipsel-linux
> [schadha@devjava1-fc4 binutils-2.15.91.0.2]$ make
> 
> However the compiled gprof was compiled for the host (i386) machine. Any
> ideas of what other changes may be required to cross compile gprof for
> the mips machine.

gprof runs on the host, not on the target (but it reads target object
code, of course).  In your configure command line above, I see you used
==, not =.  Perhaps that is your problem.

Ben

Re: [PATCH] enabling gprof for cross builds

[Sanjay Chadha]

I have a question regarding cross compiling gprof. There was a patch
which removed from gprof from native_only list.

-native_only="autoconf automake libtool fileutils find gawk gettext gzip
hello indent m4 rcs recode sed shellutils tar textutils uudecode wdiff
gprof target-groff guile perl time ash bash bzip2 prms gnuserv
target-gperf"
+native_only="autoconf automake libtool fileutils find gawk gettext gzip
hello indent m4 rcs recode sed shellutils tar textutils uudecode wdiff
target-groff guile perl time ash bash bzip2 prms gnuserv target-gperf"
 
I am not sure if above change alone will make gprof cross compile (and
link). gprof uses libbfd.a which is compiled as a host_libs hence there
would be a mismatch between gprof and libbfd.a. To circumvent this I
gave the following command (so both host and target are the target mips
platform)
 
[schadha@devjava1-fc4 binutils-2.15.91.0.2]$ ./configure
--target=mipsel-linux --host==mipsel-linux
[schadha@devjava1-fc4 binutils-2.15.91.0.2]$ make


However the compiled gprof was compiled for the host (i386) machine. Any
ideas of what other changes may be required to cross compile gprof for
the mips machine.

Regards,
    Sanjay
 
S5 Systems - providing custom embedded engineering services   
Direct:  (613) 226-4764 
Mobile: (613) 355-9298