From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2991 invoked by alias); 9 May 2006 17:23:00 -0000 Received: (qmail 2981 invoked by uid 22791); 9 May 2006 17:22:59 -0000 X-Spam-Check-By: sourceware.org Received: from intranet.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.6) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 09 May 2006 17:22:58 +0000 Received: (qmail 14415 invoked from network); 9 May 2006 17:22:56 -0000 Received: from unknown (HELO ?10.0.0.101?) (shinwell@127.0.0.2) by mail.codesourcery.com with ESMTPA; 9 May 2006 17:22:56 -0000 Message-ID: <4460CFE9.3090106@codesourcery.com> Date: Tue, 09 May 2006 20:33:00 -0000 From: Mark Shinwell User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: binutils@sourceware.org Subject: Re: [PATCH] enabling gprof for cross builds References: <445F9A15.7000103@codesourcery.com> <20060508234927.GA19926@ozlabs.au.ibm.com> In-Reply-To: <20060508234927.GA19926@ozlabs.au.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2006-05/txt/msg00181.txt.bz2 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