Re: [RFC] Cross-gprof cleanup in gmon_io

[Ethan Solomita <ethan at cs dot columbia dot edu>]

	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?

	Thanks!
	-- Ethan

P.S. Doesn't the same problem exist for many mips64 users?