From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3404 invoked by alias); 24 May 2006 07:24:32 -0000 Received: (qmail 3377 invoked by uid 22791); 24 May 2006 07:24:30 -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; Wed, 24 May 2006 07:24:22 +0000 Received: (qmail 6148 invoked from network); 24 May 2006 07:24:20 -0000 Received: from unknown (HELO ?10.0.0.101?) (shinwell@127.0.0.2) by mail.codesourcery.com with ESMTPA; 24 May 2006 07:24:20 -0000 Message-ID: <44740A1D.70007@codesourcery.com> Date: Wed, 24 May 2006 12:31: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> <4460CFE9.3090106@codesourcery.com> In-Reply-To: <4460CFE9.3090106@codesourcery.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/msg00424.txt.bz2 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