Messages in this thread | | | Date | Tue, 14 Feb 2006 15:41:24 -0800 | From | Stephane Eranian <> | Subject | Re: [Perfctr-devel] Re: [perfmon] perfmon2 code review: 32-bit ABI on 64-bit OS |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |