This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
RE: test case bin3 failed in my x86_64 box
- From: "Stone, Joshua I" <joshua dot i dot stone at intel dot com>
- To: "Frank Ch. Eigler" <fche at redhat dot com>, "Martin Hunt" <hunt at redhat dot com>
- Cc: <systemtap at sources dot redhat dot com>
- Date: Thu, 27 Apr 2006 13:04:17 -0700
- Subject: RE: test case bin3 failed in my x86_64 box
On Thursday, April 27, 2006 12:29 PM, Frank Ch. Eigler wrote:
> Anyway, having explicit endian-conversion functions like those doesn't
> make much sense to me. Endianness is really an external
> representation (serialization) issue only, which would be naturally
> expressed as modified formatting options for binary printf.
Martin and I discussed this - one of the ideas I had was to (ab)use the
formatting flags as follows:
%b = native cpu order
%-b = little-endian
%+b = big-endian / network order
It is unlikely that one would want to mix endian types within a script,
so it seems a bit cleaner to have a single set_endian function that can
be called once from the begin probe. This is simply a semantic decision
-- it should be a pretty minimal change to have the formatting flags
control endianness instead of a global flag.
However, note that a global flag also allows tapsets to ignore endian
issues. For example, you could have a function
"print_binary_stacktrace" that makes no claims about endianness, so
whatever the user defined with set_endian will prevail.
Josh