This is the mail archive of the
mailing list for the binutils project.
Re: [RFC] Cross-gprof cleanup in gmon_io
- From: Ethan Solomita <ethan at cs dot columbia dot edu>
- To: binutils at sources dot redhat dot com
- Date: Fri, 12 Apr 2002 13:45:25 -0700
- Subject: Re: [RFC] Cross-gprof cleanup in gmon_io
There were recently some changes to gprof intended to support
cross-compilation. Unfortunately they seem to have broken gprof for
users of 64-bit sparc kernels. Almost always, user apps are 32-bit, and
historically gprof (being built in user space) expected the kernel to
supply it with 32-bit longs and pointers.
With the changes that were just made, gprof now looks at the target
configuration in bfd, sees that the kernel is 64-bits, and expects
64-bit longs and pointers in gmon.out. Until 2.12, gprof expected 32-bit
values. The problem on sparc64 is that there are two targets: the
user-land target and the kernel-space target.
The question is whether this is a bug or a feature. It definitely
breaks backwards compatibility for everyone using gprof with sparc64.
Perhaps it's a feature that user space has to move to 64-bits, but
user-space can't handle 64-bit values natively and will run slower.
So: is this a bug that needs to be fixed? or are we breaking backwards
compatibility and requiring kernel profiling support to be updated?
P.S. Doesn't the same problem exist for many mips64 users?