Re: perfmon2 code review: 32-bit ABI on 64-bit OS

[Stephane Eranian]

Hello,

So I worked some more on these 32bit vs 64bit ABI issues. I came
to the conclusion that the only way to make this work cleanly
without any special compilation flags or runtime support is
to simply ensure that all data structures exchanged/shared between
the monitoring tool  and the kernel use only fixed size types.
This way, the sizeof struct  and fields offset remains constant
in ILP32 or LP64 mode. As a consequence I now have:
	- all bitmasks use u64
	- all size_t are replaced with u64
	- the default format IP (instruction pointer) is u64

For the IP, the most significant bits contain all zeroes in
ILP32 mode. With the default sampling buffer format, you add
4 bytes to the sample header but then you have nothing special
to do with user level code. I think this is also inline with
the fact that 64-bit computing is becoming widely available
for desktop and laptop computers.

As an example, I can now compile a tool for P4 in 32-bit and
run it on my 32-bit Xeon. But I can also run the same *binary*
on my EM64T and it works as expected including for the sampling
buffer. I believe the same would be possible with Opteron, although
I have not tried.

I hope this closes another sticking point about the interface.


On Tue, Feb 14, 2006 at 12:57:55AM +0600, Philip Mucci wrote:
> 
> 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. 
> 
> Either of these combined with compile time ABI/bitness constants should
> cover the cases no?
> 
> Phil
> 
> 
> > The problem is in the user level header file for the sampling buffer.
> > We would need a data type that is 64-bit for IP if the host OS is 64-bit
> > (regardless of the ABI used by the tool, i.e., the compiler). And a data
> > type that is 32-bit on 32-bit OS. The problem is that there is no compiler
> > flag or header flag somewhere that could guide the compiler. In the case
> > of MIPS, we have defined a libpfm compile flags that indicates we want
> > the 64-bit OS definition when compiling for a 32-bit application.
> > 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Perfctr-devel mailing list
> Perfctr-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/perfctr-devel

-- 

-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/