This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
RE: Order "begin" probes are run
- From: "Stone, Joshua I" <joshua dot i dot stone at intel dot com>
- To: <fche at redhat dot com>
- Cc: <systemtap at sources dot redhat dot com>
- Date: Fri, 8 Dec 2006 12:18:32 -0800
- Subject: RE: Order "begin" probes are run
On Friday, December 08, 2006 11:54 AM, fche@redhat.com wrote:
> "Stone, Joshua I" <joshua.i.stone@intel.com> writes:
>> [...] Even changing [global initialization] to begin(-2^63) isn't
>> really correct, as it should happen *before* the beginning. [...]
>
> -2^63 is not actually a bad choice, and easily documented. The more
> interesting ordering conflict is between this and
> module-parameter-based initialization.
Well, changing it to C-style initialization should be easy enough, and
seems more intuitive to me. I'm not sure I understand the ordering
conflict you're talking about though.
> By the way, the new parse_literal variant does not check for numeric
> overflow for negative numbers quite right (running on x86-64):
>
> % ./stap -p1 -e 'probe
> begin(-9223372036854775808),begin(-9223372036854775809) {}' # parse
> tree dump # file <input>
> probe begin(-9223372036854775808),
> begin(9223372036854775807){
> }
Yeah, I know. It wraps around on the positive side too --
9223372036854775808 becomes -9223372036854775808. (Side note - that's
one of the answers to an interesting CS question: what are the *two*
values of 'int64_t x' where x == -x?)
The same problem exists in other parts of the language as well:
$ ./stap -e 'probe begin { printf("%d\n", -9223372036854775809) exit()}'
9223372036854775807
In that case, it's being parsed as a positive that wraps around, and
then operated by a unary minus.
It's not obvious to me that there's a right thing for the translator to
do in either case. It's up to the programmer to know that there are
limits to 64-bit numbers.
Josh