Ian Lance Taylor wrote:
"Mohamed Shafi" <shafitvm@xxxxxxxxx> writes:
I also couldn't find any particular startup file required for profiling.
Does this mean that profiling is not supported for any powerpc target
build with newlib?
That appears to be the case. I'm not sure why the file
newlib/libgloss/rs6000/mcount.S was created. It seems to simply
obscure the fact that -pg does not work for powerpc newlib. In my
opinion it would be better to get a link error, making it clear that
you need to provide a version of _mcount appropriate for your system.
There once was that Cygnus 'powerpc-cygwin32' target/host for the
WindowsNT4.0/PPC. And
Cygwin uses/used newlib as the basement for its custom C library. So
there is a 'winsup/mcount.c'
probably replacing that in 'libgloss' during build and install....
So theoretically there still is "profiling support for one powerpc
target build with newlib", for the
Cygwin/PPC :-)
Is there support for profiling for powerpc target with glibc?
Yes.
Also FreeBSD/PPC, NetBSD/PPC, MacOS X/PPC, AIX, BeOS etc. are available
for PPC...
Generally the clause: "Your program will write the profile data into a
file called `gmon.out' just
before exiting" taken from the DJGPP docs explains what the big problem
with newlib is... One
should ask the question: "Where this file will be written in an embedded
newlib-based system?"
When cross-developing and running the produced apps in a host system
capable to accept 'files',
via the 'PSIM' in GDB, it sounds obvious that the 'gmon.out' would be
written onto the host system's
default directory while "running" the program... But the 'target system'
really doesn't support any
'filesystem' in its 'runtime environment' - the real PPC based one !
The 'PSIM' in GDB simulates
only this kind of "dummy system" :-(
