Re: [Perfctr-devel] Re: [perfmon] perfmon2 code review: 32-bit ABI on 64-bit OS
From: Stephane Eranian
Date: Tue Feb 14 2006 - 18:42:39 EST
Phil,
On Tue, Feb 14, 2006 at 12:57:55AM +0600, Philip Mucci wrote:
> Stefane,
>
> I know this is ugly, but what about in the user code checking the arch?
> Is it not true that if a kernel is running 64 bit, it has the 64 tagged
> on the the end of the arch? i.e. mips64, ppc64, x86_64?
>
> The other solution would be to add am information call to the API, like
> perfctr has. This would export the processor type along with other
> feature bits, including the number of bits of the IP.
>
The problem is at compile time and not so much at runtime.
Take a kernel struct that is shared with user (i.e., passed through syscall)
that has the following layout:
struct foo {
unsigned long bar;
int dummy;
};
For a 64-bit app on a 64-bit OS OR a 32-bit app on a 32-bit OS, this works
perfectly.
For a 32-bit on a 64-bit OS, there is a problem, the 32-bit app must be compiled
with the following definition instead:
struct foo {
unsigned long long bar;
int dummy;
};
to share the struct with the 64-bit OS. An application compile with the above
struct, would not work when run on a 32-bit OS.
So I think that we need to replace all unsigned long, size_t, void * by uint64_t
to make sure this works either way. It is overkill on pure 32-bit but ensures
that the application can be migrated over to a 64-bit OS without the need for
special recompilation.
--
-Stephane
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/