From: "Bryan O'Sullivan" <bos@serpentine.com>
To: eranian@hpl.hp.com
Cc: linux-kernel@vger.kernel.org, perfmon@napali.hpl.hp.com,
perfctr-devel@lists.sourceforge.net, linux-ia64@vger.kernel.org
Subject: Re: perfmon2 code review: 32-bit ABI on 64-bit OS
Date: Fri, 10 Feb 2006 18:27:02 +0000 [thread overview]
Message-ID: <1139596023.9646.111.camel@serpentine.pathscale.com> (raw)
In-Reply-To: <20060210153608.GC28311@frankl.hpl.hp.com>
On Fri, 2006-02-10 at 07:36 -0800, Stephane Eranian wrote:
> Many 64-bit Linux kernel do support running 32-bit native applications.
> That is the case on PPC64, MIPS64K, X86-64, for instance.
And sparc64 and s390.
> One could well
> write a 32-bit monitoring tool on top of a 64-bit OS.
On some 64-bit arches (e.g. x86_64), most userspace code is 64-bit,
while on others (e.g. powerpc), most is 32-bit. Reducing the number of
things that a userspace tool or library writer can trip over seems like
a good thing here, even if it slightly complicates perfmon's internals.
> Note that there are similar issues with the remapped sampling buffer.
> There, you need to explicitly compile your tool with a special option
> to force certain types to be 64-bit (size_t, void *).
It's pretty normal to just use 64-bit quantities in these cases, and
cast appropriately.
<b
WARNING: multiple messages have this Message-ID (diff)
From: "Bryan O'Sullivan" <bos@serpentine.com>
To: eranian@hpl.hp.com
Cc: linux-kernel@vger.kernel.org, perfmon@napali.hpl.hp.com,
perfctr-devel@lists.sourceforge.net, linux-ia64@vger.kernel.org
Subject: Re: perfmon2 code review: 32-bit ABI on 64-bit OS
Date: Fri, 10 Feb 2006 10:27:02 -0800 [thread overview]
Message-ID: <1139596023.9646.111.camel@serpentine.pathscale.com> (raw)
In-Reply-To: <20060210153608.GC28311@frankl.hpl.hp.com>
On Fri, 2006-02-10 at 07:36 -0800, Stephane Eranian wrote:
> Many 64-bit Linux kernel do support running 32-bit native applications.
> That is the case on PPC64, MIPS64K, X86-64, for instance.
And sparc64 and s390.
> One could well
> write a 32-bit monitoring tool on top of a 64-bit OS.
On some 64-bit arches (e.g. x86_64), most userspace code is 64-bit,
while on others (e.g. powerpc), most is 32-bit. Reducing the number of
things that a userspace tool or library writer can trip over seems like
a good thing here, even if it slightly complicates perfmon's internals.
> Note that there are similar issues with the remapped sampling buffer.
> There, you need to explicitly compile your tool with a special option
> to force certain types to be 64-bit (size_t, void *).
It's pretty normal to just use 64-bit quantities in these cases, and
cast appropriately.
<b
next prev parent reply other threads:[~2006-02-10 18:27 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-20 18:37 [perfmon] Re: quick overview of the perfmon2 interface Truong, Dan
2006-01-20 18:37 ` Truong, Dan
2006-01-20 22:22 ` Andrew Morton
2006-01-20 22:22 ` Andrew Morton
2006-01-25 20:33 ` Bryan O'Sullivan
2006-01-25 20:33 ` Bryan O'Sullivan
2006-01-25 22:28 ` [Perfctr-devel] " Stephane Eranian
2006-01-25 22:28 ` Stephane Eranian
2006-01-25 22:46 ` [Perfctr-devel] RE: [perfmon] Re: quick overview of the Bryan O'Sullivan
2006-01-25 22:46 ` [Perfctr-devel] RE: [perfmon] Re: quick overview of the perfmon2 interface Bryan O'Sullivan
2006-01-26 7:48 ` Stephane Eranian
2006-01-26 7:48 ` Stephane Eranian
2006-01-26 18:26 ` [Perfctr-devel] RE: [perfmon] Re: quick overview of the Bryan O'Sullivan
2006-01-26 18:26 ` [Perfctr-devel] RE: [perfmon] Re: quick overview of the perfmon2 interface Bryan O'Sullivan
[not found] ` <1138649612.4077.50.camel@localhost.localdomain>
[not found] ` <1138651545.4487.13.camel@camp4.serpentine.com>
[not found] ` <1139155731.4279.0.camel@localhost.localdomain>
[not found] ` <1139245253.27739.8.camel@camp4.serpentine.com>
2006-02-10 15:36 ` perfmon2 code review: 32-bit ABI on 64-bit OS Stephane Eranian
2006-02-10 15:36 ` Stephane Eranian
2006-02-10 18:27 ` Bryan O'Sullivan [this message]
2006-02-10 18:27 ` Bryan O'Sullivan
[not found] ` <1139681785.4316.33.camel@localhost.localdomain>
2006-02-11 22:33 ` [perfmon] " Stephane Eranian
2006-02-12 23:46 ` [Perfctr-devel] " David Gibson
2006-02-13 0:03 ` Eric Gouriou
2006-02-13 20:31 ` Stephane Eranian
[not found] ` <1139857076.4342.10.camel@localhost.localdomain>
2006-02-14 23:41 ` [Perfctr-devel] " Stephane Eranian
2006-02-20 17:54 ` Stephane Eranian
2006-02-13 20:34 ` Stephane Eranian
2006-02-13 20:34 ` Stephane Eranian
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=1139596023.9646.111.camel@serpentine.pathscale.com \
--to=bos@serpentine.com \
--cc=eranian@hpl.hp.com \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=perfctr-devel@lists.sourceforge.net \
--cc=perfmon@napali.hpl.hp.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.