From: Mark Shinwell <shinwell@codesourcery.com>
To: binutils@sourceware.org
Subject: Re: [PATCH] enabling gprof for cross builds
Date: Tue, 09 May 2006 20:33:00 -0000 [thread overview]
Message-ID: <4460CFE9.3090106@codesourcery.com> (raw)
In-Reply-To: <20060508234927.GA19926@ozlabs.au.ibm.com>
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
next prev parent reply other threads:[~2006-05-09 17:23 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-08 23:48 Mark Shinwell
2006-05-09 1:38 ` Daniel Jacobowitz
2006-05-09 2:05 ` Ben Elliston
2006-05-09 20:33 ` Mark Shinwell [this message]
2006-05-24 12:31 ` Mark Shinwell
2006-05-24 14:28 ` Daniel Jacobowitz
2006-05-24 17:09 ` Mark Shinwell
2007-04-09 17:46 Sanjay Chadha
2007-04-12 4:08 ` Ben Elliston
2007-04-12 15:13 ` Danny Backx
2007-04-13 1:09 ` John Tytgat
2007-04-19 21:54 ` Danny Backx
2007-04-20 14:28 ` Nick Clifton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4460CFE9.3090106@codesourcery.com \
--to=shinwell@codesourcery.com \
--cc=binutils@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).