[DTrace-devel] [PATCH 5/6 v2] Implement associative array support

[Eugene Loh]

I have a question.

The comment block for dt_cg_arglist() points out:

+ * We must first generate code for all subexpressions because any 
subexpression
+ * could itself require the use of the tuple assembly area and we only 
provide
+ * one.

True enough.

But we store those results in a block of stack locations... of which we 
have only one such block.  So don't we have the same problem?

Consider:

BEGIN {
   one = 1;
   two = 2;
   three = 3;
   a[1, 2, 3] = 1234;
   a[3, 2, 3] = 4321;
   a[3, 2, 1] = 2;
   printf("%d\n", a[one, a[three, two, one], three]);
   exit(0);
}

Since a[three, two, one] is 2, the result we print should be a[1, 2, 3], 
which is 1234.  That's the result I get with Solaris and with legacy 
DTrace on Linux.

With the proposed patch series, however, I get 4321.  Presumably that's 
because the first arg is overwritten and I end up retrieving a[3, 2, 3].

On 3/10/22 1:14 AM, Kris Van Hees via DTrace-devel wrote:
> Associative arrays (global or TLS) are variables that are indexed with
> a tuple (one or more values).  The underlying storage is provided by
> the dvar (dynamic variables) BPF hash map.  Since dvar elements are
> indexed using a unique 64-bit ID, and given that it provides storage
> for both regular TLS variables and associate array elements, the
> algorithms to calculate the ID are designed to provide orthogonal
> value ranges.