* Re: [PATCH] enabling gprof for cross builds @ 2007-04-09 17:46 Sanjay Chadha 2007-04-12 4:08 ` Ben Elliston 0 siblings, 1 reply; 13+ messages in thread From: Sanjay Chadha @ 2007-04-09 17:46 UTC (permalink / raw) To: binutils 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] enabling gprof for cross builds 2007-04-09 17:46 [PATCH] enabling gprof for cross builds Sanjay Chadha @ 2007-04-12 4:08 ` Ben Elliston 2007-04-12 15:13 ` Danny Backx 0 siblings, 1 reply; 13+ messages in thread From: Ben Elliston @ 2007-04-12 4:08 UTC (permalink / raw) To: Sanjay Chadha; +Cc: binutils 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] enabling gprof for cross builds 2007-04-12 4:08 ` Ben Elliston @ 2007-04-12 15:13 ` Danny Backx 2007-04-13 1:09 ` John Tytgat 2007-04-20 14:28 ` Nick Clifton 0 siblings, 2 replies; 13+ messages in thread From: Danny Backx @ 2007-04-12 15:13 UTC (permalink / raw) To: Ben Elliston; +Cc: Sanjay Chadha, binutils [-- 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 --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] enabling gprof for cross builds 2007-04-12 15:13 ` Danny Backx @ 2007-04-13 1:09 ` John Tytgat 2007-04-19 21:54 ` Danny Backx 2007-04-20 14:28 ` Nick Clifton 1 sibling, 1 reply; 13+ messages in thread From: John Tytgat @ 2007-04-13 1:09 UTC (permalink / raw) To: binutils 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/ ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] enabling gprof for cross builds 2007-04-13 1:09 ` John Tytgat @ 2007-04-19 21:54 ` Danny Backx 0 siblings, 0 replies; 13+ messages in thread From: Danny Backx @ 2007-04-19 21:54 UTC (permalink / raw) To: John Tytgat; +Cc: binutils [-- 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 --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] enabling gprof for cross builds 2007-04-12 15:13 ` Danny Backx 2007-04-13 1:09 ` John Tytgat @ 2007-04-20 14:28 ` Nick Clifton 1 sibling, 0 replies; 13+ messages in thread From: Nick Clifton @ 2007-04-20 14:28 UTC (permalink / raw) To: Danny Backx; +Cc: Ben Elliston, Sanjay Chadha, binutils 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH] enabling gprof for cross builds @ 2006-05-08 23:48 Mark Shinwell 2006-05-09 1:38 ` Daniel Jacobowitz 2006-05-09 2:05 ` Ben Elliston 0 siblings, 2 replies; 13+ messages in thread From: Mark Shinwell @ 2006-05-08 23:48 UTC (permalink / raw) To: binutils [-- 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] enabling gprof for cross builds 2006-05-08 23:48 Mark Shinwell @ 2006-05-09 1:38 ` Daniel Jacobowitz 2006-05-09 2:05 ` Ben Elliston 1 sibling, 0 replies; 13+ messages in thread From: Daniel Jacobowitz @ 2006-05-09 1:38 UTC (permalink / raw) To: Mark Shinwell; +Cc: binutils 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] enabling gprof for cross builds 2006-05-08 23:48 Mark Shinwell 2006-05-09 1:38 ` Daniel Jacobowitz @ 2006-05-09 2:05 ` Ben Elliston 2006-05-09 20:33 ` Mark Shinwell 1 sibling, 1 reply; 13+ messages in thread From: Ben Elliston @ 2006-05-09 2:05 UTC (permalink / raw) To: Mark Shinwell; +Cc: binutils > 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] enabling gprof for cross builds 2006-05-09 2:05 ` Ben Elliston @ 2006-05-09 20:33 ` Mark Shinwell 2006-05-24 12:31 ` Mark Shinwell 0 siblings, 1 reply; 13+ messages in thread From: Mark Shinwell @ 2006-05-09 20:33 UTC (permalink / raw) To: binutils 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] enabling gprof for cross builds 2006-05-09 20:33 ` Mark Shinwell @ 2006-05-24 12:31 ` Mark Shinwell 2006-05-24 14:28 ` Daniel Jacobowitz 0 siblings, 1 reply; 13+ messages in thread From: Mark Shinwell @ 2006-05-24 12:31 UTC (permalink / raw) To: binutils 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] enabling gprof for cross builds 2006-05-24 12:31 ` Mark Shinwell @ 2006-05-24 14:28 ` Daniel Jacobowitz 2006-05-24 17:09 ` Mark Shinwell 0 siblings, 1 reply; 13+ messages in thread From: Daniel Jacobowitz @ 2006-05-24 14:28 UTC (permalink / raw) To: binutils 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] enabling gprof for cross builds 2006-05-24 14:28 ` Daniel Jacobowitz @ 2006-05-24 17:09 ` Mark Shinwell 0 siblings, 0 replies; 13+ messages in thread From: Mark Shinwell @ 2006-05-24 17:09 UTC (permalink / raw) To: binutils; +Cc: gcc-patches [-- 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" ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2007-04-20 14:03 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-04-09 17:46 [PATCH] enabling gprof for cross builds Sanjay Chadha 2007-04-12 4:08 ` Ben Elliston 2007-04-12 15:13 ` Danny Backx 2007-04-13 1:09 ` John Tytgat 2007-04-19 21:54 ` Danny Backx 2007-04-20 14:28 ` Nick Clifton -- strict thread matches above, loose matches on Subject: below -- 2006-05-08 23:48 Mark Shinwell 2006-05-09 1:38 ` Daniel Jacobowitz 2006-05-09 2:05 ` Ben Elliston 2006-05-09 20:33 ` Mark Shinwell 2006-05-24 12:31 ` Mark Shinwell 2006-05-24 14:28 ` Daniel Jacobowitz 2006-05-24 17:09 ` Mark Shinwell
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).