[PATCH v3] trace: print alloca pointers as actual pointer values

[PATCH v3] trace: print alloca pointers as actual pointer values

[Kris Van Hees]

Because alloca pointers are stored internally as ofssets into the
scratchmem area, they were printed as small integers.  They are
now printed as actual pointer values into kernel space.

Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com>
---
 libdtrace/dt_cg.c                          | 45 ++++++++++++++++------
 test/unittest/actions/trace/tst.alloca.d   | 24 ++++++++++++
 test/unittest/actions/trace/tst.alloca.r   |  1 +
 test/unittest/actions/trace/tst.alloca.r.p | 11 ++++++
 4 files changed, 70 insertions(+), 11 deletions(-)
 create mode 100644 test/unittest/actions/trace/tst.alloca.d
 create mode 100644 test/unittest/actions/trace/tst.alloca.r
 create mode 100755 test/unittest/actions/trace/tst.alloca.r.p

diff --git a/libdtrace/dt_cg.c b/libdtrace/dt_cg.c
index 78f29a2a..c976782b 100644
--- a/libdtrace/dt_cg.c
+++ b/libdtrace/dt_cg.c
@@ -1687,18 +1687,41 @@ dt_cg_store_val(dt_pcb_t *pcb, dt_node_t *dnp, dtrace_actkind_t kind,
 		align = vtype.dtdt_align;
 
 		/*
-		 * A DEREF of a REF node does not get resolved in dt_cg_node()
-		 * because the ref node already holds the pointer.  But for
-		 * alloca pointers, that will be the offset into scratchmem so
-		 * we still need to turn it into a real pointer here.
+		 * Alloca pointers are stored as an offset into scratchmem, so
+		 * they need to be converted into real pointers before we go on.
+		 * An alloca pointer value either has the ALLOCA flag set, or
+		 * the value node is a DEREF of an alloca pointer child.
+		 * If the alloca pointer is a REF or ref-by-value is requested,
+		 * we need to do bounds checking before turning the alloca
+		 * pointer into a real pointer.
+		 * If not, we should scalarize it so that the BPF verifier does
+		 * not complain.
 		 */
-		if (dnp->dn_kind == DT_NODE_OP1 &&
-		    dnp->dn_op == DT_TOK_DEREF && (dnp->dn_flags & DT_NF_REF) &&
-		    (dnp->dn_child->dn_flags & DT_NF_ALLOCA)) {
-			dt_cg_alloca_access_check(dlp, drp, dnp->dn_reg,
-						  DT_ISIMM, size);
-			dt_cg_alloca_ptr(dlp, drp, dnp->dn_reg, dnp->dn_reg);
-			not_null = 1;
+		if ((dnp->dn_flags & DT_NF_ALLOCA) ||
+		    (dnp->dn_kind == DT_NODE_OP1 &&
+		     dnp->dn_op == DT_TOK_DEREF &&
+		     dnp->dn_child->dn_flags & DT_NF_ALLOCA)) {
+			if ((dnp->dn_flags & DT_NF_REF) || (arg & DT_NF_REF)) {
+				dt_cg_alloca_access_check(dlp, drp, dnp->dn_reg,
+							  DT_ISIMM, size);
+
+				dt_cg_alloca_ptr(dlp, drp, dnp->dn_reg, dnp->dn_reg);
+				not_null = 1;
+			} else {
+				int	reg;
+
+				dt_regset_xalloc(drp, BPF_REG_0);
+				emit(dlp,  BPF_LOAD(BPF_DW, BPF_REG_0, BPF_REG_FP, DT_STK_DCTX));
+				if ((reg = dt_regset_alloc(drp)) == -1)
+					longjmp(yypcb->pcb_jmpbuf, EDT_NOREG);
+				emit(dlp, BPF_LOAD(BPF_DW, reg, BPF_REG_0, DCTX_SCRATCHMEM));
+				emit(dlp, BPF_LOAD(BPF_DW, BPF_REG_0, BPF_REG_0, DCTX_MST));
+				emit(dlp, BPF_STORE(BPF_DW, BPF_REG_0, DMST_SCALARIZER, reg));
+				emit(dlp, BPF_LOAD(BPF_DW, reg, BPF_REG_0, DMST_SCALARIZER));
+				dt_regset_free(drp, BPF_REG_0);
+				emit(dlp,  BPF_ALU64_REG(BPF_ADD, dnp->dn_reg, reg));
+				dt_regset_free(drp, reg);
+			}
 		}
 	}
 
diff --git a/test/unittest/actions/trace/tst.alloca.d b/test/unittest/actions/trace/tst.alloca.d
new file mode 100644
index 00000000..d2ff5152
--- /dev/null
+++ b/test/unittest/actions/trace/tst.alloca.d
@@ -0,0 +1,24 @@
+#pragma D option quiet
+
+BEGIN
+{
+	arr = (int *)alloca(5 * sizeof(int));
+	idx = 4;
+	arr[0] = 1;
+	arr[1] = 22;
+	arr[2] = 333;
+	arr[3] = 4444;
+	arr[4] = 55555;
+	trace(arr);
+	trace(" ");
+	trace(*arr);
+	trace(" ");
+	trace(arr + 2);
+	trace(" ");
+	trace(*(arr + 2));
+	trace(" ");
+	trace(arr + idx);
+	trace(" ");
+	trace(*(arr + idx));
+	exit(0);
+}
diff --git a/test/unittest/actions/trace/tst.alloca.r b/test/unittest/actions/trace/tst.alloca.r
new file mode 100644
index 00000000..e9bbf2f5
--- /dev/null
+++ b/test/unittest/actions/trace/tst.alloca.r
@@ -0,0 +1 @@
+OK 1 OK 333 OK 55555
diff --git a/test/unittest/actions/trace/tst.alloca.r.p b/test/unittest/actions/trace/tst.alloca.r.p
new file mode 100755
index 00000000..8515861a
--- /dev/null
+++ b/test/unittest/actions/trace/tst.alloca.r.p
@@ -0,0 +1,11 @@
+#!/usr/bin/gawk -f
+
+{
+	$1 = $1 > 0x7fffffff ? "OK" : "BAD";
+	$3 = $3 > 0x7fffffff ? "OK" : "BAD";
+	$5 = $5 > 0x7fffffff ? "OK" : "BAD";
+}
+
+{
+	print;
+}
-- 
2.43.5

Re: [DTrace-devel] [PATCH v3] trace: print alloca pointers as actual pointer values

[Eugene Loh]

Largely similar comments to previous versions of this patch:

On 9/15/25 13:36, Kris Van Hees via DTrace-devel wrote:
> Because alloca pointers are stored internally as ofssets into the

The same as for v1 and v2:  s/ofssets/offsets/.

> scratchmem area, they were printed as small integers.  They are
> now printed as actual pointer values into kernel space.

And, again, the patch performs poorly against testing.

The new test gives me:
     -OK 1 OK 333 OK 55555
     +OK 1059965305 OK 1059965637 OK 1060020859
which is to say that the dereferenced values are wrong.  (They are all 
the correct values plus some offset.)

And with this patch, these pre-existing tests fail:
     test/unittest/builtinvar/tst.tid_pid.sh: FAIL: erroneous exitcode (1).
     test/unittest/funcs/alloca/tst.alloca-bcopy-top.d: FAIL: expected 
results differ.
     test/unittest/funcs/bcopy/tst.bcopy_arg_order.d: FAIL: expected 
results differ.
     test/unittest/funcs/copyinto/tst.copyinto_arg_order.d: FAIL: 
expected results differ.

btw...

> diff --git a/test/unittest/actions/trace/tst.alloca.r.p b/test/unittest/actions/trace/tst.alloca.r.p
> new file mode 100755
> @@ -0,0 +1,11 @@
> +#!/usr/bin/gawk -f
> +
> +{
> +	$1 = $1 > 0x7fffffff ? "OK" : "BAD";
> +	$3 = $3 > 0x7fffffff ? "OK" : "BAD";
> +	$5 = $5 > 0x7fffffff ? "OK" : "BAD";
> +}
> +
> +{
> +	print;
> +}

Why are these split over two awk clauses?  Can't they co-exist in the 
same clause?

Re: [DTrace-devel] [PATCH v3] trace: print alloca pointers as actual pointer values

[Kris Van Hees]

On Mon, Sep 15, 2025 at 04:41:43PM -0400, Eugene Loh wrote:
> Largely similar comments to previous versions of this patch:
> 
> On 9/15/25 13:36, Kris Van Hees via DTrace-devel wrote:
> > Because alloca pointers are stored internally as ofssets into the
> 
> The same as for v1 and v2:  s/ofssets/offsets/.

Ok, yes, sorry - been spending time on functionality over typos.

> > scratchmem area, they were printed as small integers.  They are
> > now printed as actual pointer values into kernel space.
> 
> And, again, the patch performs poorly against testing.
> 
> The new test gives me:
>     -OK 1 OK 333 OK 55555
>     +OK 1059965305 OK 1059965637 OK 1060020859
> which is to say that the dereferenced values are wrong.  (They are all the
> correct values plus some offset.)
> 
> And with this patch, these pre-existing tests fail:
>     test/unittest/builtinvar/tst.tid_pid.sh: FAIL: erroneous exitcode (1).
>     test/unittest/funcs/alloca/tst.alloca-bcopy-top.d: FAIL: expected
> results differ.
>     test/unittest/funcs/bcopy/tst.bcopy_arg_order.d: FAIL: expected results
> differ.
>     test/unittest/funcs/copyinto/tst.copyinto_arg_order.d: FAIL: expected
> results differ.

Hm, this is getting frustrating.  Tracking down why I was not seeing those
failures on my end.

> btw...
> 
> > diff --git a/test/unittest/actions/trace/tst.alloca.r.p b/test/unittest/actions/trace/tst.alloca.r.p
> > new file mode 100755
> > @@ -0,0 +1,11 @@
> > +#!/usr/bin/gawk -f
> > +
> > +{
> > +	$1 = $1 > 0x7fffffff ? "OK" : "BAD";
> > +	$3 = $3 > 0x7fffffff ? "OK" : "BAD";
> > +	$5 = $5 > 0x7fffffff ? "OK" : "BAD";
> > +}
> > +
> > +{
> > +	print;
> > +}
> 
> Why are these split over two awk clauses?  Can't they co-exist in the same
> clause?

Yes they can.  But they don't have to.

Re: [DTrace-devel] [PATCH v3] trace: print alloca pointers as actual pointer values

[Kris Van Hees]

On Mon, Sep 15, 2025 at 09:44:14PM -0400, Kris Van Hees wrote:
> On Mon, Sep 15, 2025 at 04:41:43PM -0400, Eugene Loh wrote:
> > Largely similar comments to previous versions of this patch:
> > 
> > On 9/15/25 13:36, Kris Van Hees via DTrace-devel wrote:
> > > Because alloca pointers are stored internally as ofssets into the
> > 
> > The same as for v1 and v2:  s/ofssets/offsets/.
> 
> Ok, yes, sorry - been spending time on functionality over typos.
> 
> > > scratchmem area, they were printed as small integers.  They are
> > > now printed as actual pointer values into kernel space.
> > 
> > And, again, the patch performs poorly against testing.
> > 
> > The new test gives me:
> >     -OK 1 OK 333 OK 55555
> >     +OK 1059965305 OK 1059965637 OK 1060020859
> > which is to say that the dereferenced values are wrong.  (They are all the
> > correct values plus some offset.)
> > 
> > And with this patch, these pre-existing tests fail:
> >     test/unittest/builtinvar/tst.tid_pid.sh: FAIL: erroneous exitcode (1).
> >     test/unittest/funcs/alloca/tst.alloca-bcopy-top.d: FAIL: expected
> > results differ.
> >     test/unittest/funcs/bcopy/tst.bcopy_arg_order.d: FAIL: expected results
> > differ.
> >     test/unittest/funcs/copyinto/tst.copyinto_arg_order.d: FAIL: expected
> > results differ.
> 
> Hm, this is getting frustrating.  Tracking down why I was not seeing those
> failures on my end.

Where are you seeing these failures?  Do you have the pointer subtraction patch
applied before this one?

> > btw...
> > 
> > > diff --git a/test/unittest/actions/trace/tst.alloca.r.p b/test/unittest/actions/trace/tst.alloca.r.p
> > > new file mode 100755
> > > @@ -0,0 +1,11 @@
> > > +#!/usr/bin/gawk -f
> > > +
> > > +{
> > > +	$1 = $1 > 0x7fffffff ? "OK" : "BAD";
> > > +	$3 = $3 > 0x7fffffff ? "OK" : "BAD";
> > > +	$5 = $5 > 0x7fffffff ? "OK" : "BAD";
> > > +}
> > > +
> > > +{
> > > +	print;
> > > +}
> > 
> > Why are these split over two awk clauses?  Can't they co-exist in the same
> > clause?
> 
> Yes they can.  But they don't have to.

Re: [DTrace-devel] [PATCH v3] trace: print alloca pointers as actual pointer values

[Kris Van Hees]

Eugene: Can you test with my kvh/2.0-branch-dev branch from ca-tools4?  I
cannot reproduce the failures you are seeing with this patch, so I wonder
if it is a combination of patches that resolves these issues, and testing
with just this one just doesn't give you the right picture.

On Mon, Sep 15, 2025 at 11:20:28PM -0400, Kris Van Hees wrote:
> On Mon, Sep 15, 2025 at 09:44:14PM -0400, Kris Van Hees wrote:
> > On Mon, Sep 15, 2025 at 04:41:43PM -0400, Eugene Loh wrote:
> > > Largely similar comments to previous versions of this patch:
> > > 
> > > On 9/15/25 13:36, Kris Van Hees via DTrace-devel wrote:
> > > > Because alloca pointers are stored internally as ofssets into the
> > > 
> > > The same as for v1 and v2:  s/ofssets/offsets/.
> > 
> > Ok, yes, sorry - been spending time on functionality over typos.
> > 
> > > > scratchmem area, they were printed as small integers.  They are
> > > > now printed as actual pointer values into kernel space.
> > > 
> > > And, again, the patch performs poorly against testing.
> > > 
> > > The new test gives me:
> > >     -OK 1 OK 333 OK 55555
> > >     +OK 1059965305 OK 1059965637 OK 1060020859
> > > which is to say that the dereferenced values are wrong.  (They are all the
> > > correct values plus some offset.)
> > > 
> > > And with this patch, these pre-existing tests fail:
> > >     test/unittest/builtinvar/tst.tid_pid.sh: FAIL: erroneous exitcode (1).
> > >     test/unittest/funcs/alloca/tst.alloca-bcopy-top.d: FAIL: expected
> > > results differ.
> > >     test/unittest/funcs/bcopy/tst.bcopy_arg_order.d: FAIL: expected results
> > > differ.
> > >     test/unittest/funcs/copyinto/tst.copyinto_arg_order.d: FAIL: expected
> > > results differ.
> > 
> > Hm, this is getting frustrating.  Tracking down why I was not seeing those
> > failures on my end.
> 
> Where are you seeing these failures?  Do you have the pointer subtraction patch
> applied before this one?
> 
> > > btw...
> > > 
> > > > diff --git a/test/unittest/actions/trace/tst.alloca.r.p b/test/unittest/actions/trace/tst.alloca.r.p
> > > > new file mode 100755
> > > > @@ -0,0 +1,11 @@
> > > > +#!/usr/bin/gawk -f
> > > > +
> > > > +{
> > > > +	$1 = $1 > 0x7fffffff ? "OK" : "BAD";
> > > > +	$3 = $3 > 0x7fffffff ? "OK" : "BAD";
> > > > +	$5 = $5 > 0x7fffffff ? "OK" : "BAD";
> > > > +}
> > > > +
> > > > +{
> > > > +	print;
> > > > +}
> > > 
> > > Why are these split over two awk clauses?  Can't they co-exist in the same
> > > clause?
> > 
> > Yes they can.  But they don't have to.

Re: [DTrace-devel] [PATCH v3] trace: print alloca pointers as actual pointer values

[Kris Van Hees]

On Tue, Sep 16, 2025 at 09:17:26AM -0400, Kris Van Hees wrote:
> Eugene: Can you test with my kvh/2.0-branch-dev branch from ca-tools4?  I
> cannot reproduce the failures you are seeing with this patch, so I wonder
> if it is a combination of patches that resolves these issues, and testing
> with just this one just doesn't give you the right picture.

Ah, I just took my tree, and merged dev-queue into it, and now I am seeing the
issue pop up with tst.tid_pid.sh at least so will look at that right now.

> On Mon, Sep 15, 2025 at 11:20:28PM -0400, Kris Van Hees wrote:
> > On Mon, Sep 15, 2025 at 09:44:14PM -0400, Kris Van Hees wrote:
> > > On Mon, Sep 15, 2025 at 04:41:43PM -0400, Eugene Loh wrote:
> > > > Largely similar comments to previous versions of this patch:
> > > > 
> > > > On 9/15/25 13:36, Kris Van Hees via DTrace-devel wrote:
> > > > > Because alloca pointers are stored internally as ofssets into the
> > > > 
> > > > The same as for v1 and v2:  s/ofssets/offsets/.
> > > 
> > > Ok, yes, sorry - been spending time on functionality over typos.
> > > 
> > > > > scratchmem area, they were printed as small integers.  They are
> > > > > now printed as actual pointer values into kernel space.
> > > > 
> > > > And, again, the patch performs poorly against testing.
> > > > 
> > > > The new test gives me:
> > > >     -OK 1 OK 333 OK 55555
> > > >     +OK 1059965305 OK 1059965637 OK 1060020859
> > > > which is to say that the dereferenced values are wrong.  (They are all the
> > > > correct values plus some offset.)
> > > > 
> > > > And with this patch, these pre-existing tests fail:
> > > >     test/unittest/builtinvar/tst.tid_pid.sh: FAIL: erroneous exitcode (1).
> > > >     test/unittest/funcs/alloca/tst.alloca-bcopy-top.d: FAIL: expected
> > > > results differ.
> > > >     test/unittest/funcs/bcopy/tst.bcopy_arg_order.d: FAIL: expected results
> > > > differ.
> > > >     test/unittest/funcs/copyinto/tst.copyinto_arg_order.d: FAIL: expected
> > > > results differ.
> > > 
> > > Hm, this is getting frustrating.  Tracking down why I was not seeing those
> > > failures on my end.
> > 
> > Where are you seeing these failures?  Do you have the pointer subtraction patch
> > applied before this one?
> > 
> > > > btw...
> > > > 
> > > > > diff --git a/test/unittest/actions/trace/tst.alloca.r.p b/test/unittest/actions/trace/tst.alloca.r.p
> > > > > new file mode 100755
> > > > > @@ -0,0 +1,11 @@
> > > > > +#!/usr/bin/gawk -f
> > > > > +
> > > > > +{
> > > > > +	$1 = $1 > 0x7fffffff ? "OK" : "BAD";
> > > > > +	$3 = $3 > 0x7fffffff ? "OK" : "BAD";
> > > > > +	$5 = $5 > 0x7fffffff ? "OK" : "BAD";
> > > > > +}
> > > > > +
> > > > > +{
> > > > > +	print;
> > > > > +}
> > > > 
> > > > Why are these split over two awk clauses?  Can't they co-exist in the same
> > > > clause?
> > > 
> > > Yes they can.  But they don't have to.

Re: [DTrace-devel] [PATCH v3] trace: print alloca pointers as actual pointer values

[Eugene Loh]

Just cleaning up my inbox...

On 9/16/25 12:02, Kris Van Hees wrote:

> On Tue, Sep 16, 2025 at 09:17:26AM -0400, Kris Van Hees wrote:
>> Eugene: Can you test with my kvh/2.0-branch-dev branch from ca-tools4?
Yeah.  I get the same issues.
> Ah, I just took my tree, and merged dev-queue into it, and now I am seeing the
> issue pop up with tst.tid_pid.sh at least so will look at that right now.
Cool.  Let me know if you need something else.
>> On Mon, Sep 15, 2025 at 11:20:28PM -0400, Kris Van Hees wrote:
>>> Do you have the pointer subtraction patch applied before this one?
Yes.

Re: [DTrace-devel] [PATCH v3] trace: print alloca pointers as actual pointer values

[Kris Van Hees]

On Tue, Sep 16, 2025 at 01:07:50PM -0400, Eugene Loh wrote:
> Just cleaning up my inbox...
> 
> On 9/16/25 12:02, Kris Van Hees wrote:
> 
> > On Tue, Sep 16, 2025 at 09:17:26AM -0400, Kris Van Hees wrote:
> > > Eugene: Can you test with my kvh/2.0-branch-dev branch from ca-tools4?
> Yeah.  I get the same issues.
> > Ah, I just took my tree, and merged dev-queue into it, and now I am seeing the
> > issue pop up with tst.tid_pid.sh at least so will look at that right now.
> Cool.  Let me know if you need something else.
> > > On Mon, Sep 15, 2025 at 11:20:28PM -0400, Kris Van Hees wrote:
> > > > Do you have the pointer subtraction patch applied before this one?
> Yes.

These are the failures I see:

test/unittest/aggs/tst.aggmod_full2.sh: FAIL: erroneous exitcode (1).
test/unittest/builtinvar/tst.tid_pid.sh: FAIL: erroneous exitcode (1).
test/unittest/consumer/tst.merge_ranges_bug25767469.c: FAIL: erroneous exitcode (1).
test/unittest/consumer/tst.symbols.c: FAIL: erroneous exitcode (1).
test/unittest/version/err.1.1.d: FAIL: core dumped.

Only the tid_pid one seems to be related to the alloca handling code in
store_val().

Do you see other failures in addition to this?

Re: [DTrace-devel] [PATCH v3] trace: print alloca pointers as actual pointer values

[Eugene Loh]

On 9/16/25 14:00, Kris Van Hees wrote:

> On Tue, Sep 16, 2025 at 01:07:50PM -0400, Eugene Loh wrote:
>> Just cleaning up my inbox...
>>
>> On 9/16/25 12:02, Kris Van Hees wrote:
>>
>>> On Tue, Sep 16, 2025 at 09:17:26AM -0400, Kris Van Hees wrote:
>>>> Eugene: Can you test with my kvh/2.0-branch-dev branch from ca-tools4?
>> Yeah.  I get the same issues.
>>> Ah, I just took my tree, and merged dev-queue into it, and now I am seeing the
>>> issue pop up with tst.tid_pid.sh at least so will look at that right now.
>> Cool.  Let me know if you need something else.
>>>> On Mon, Sep 15, 2025 at 11:20:28PM -0400, Kris Van Hees wrote:
>>>>> Do you have the pointer subtraction patch applied before this one?
>> Yes.
> These are the failures I see:
>
> test/unittest/aggs/tst.aggmod_full2.sh: FAIL: erroneous exitcode (1).
> test/unittest/builtinvar/tst.tid_pid.sh: FAIL: erroneous exitcode (1).
> test/unittest/consumer/tst.merge_ranges_bug25767469.c: FAIL: erroneous exitcode (1).
> test/unittest/consumer/tst.symbols.c: FAIL: erroneous exitcode (1).
> test/unittest/version/err.1.1.d: FAIL: core dumped.
>
> Only the tid_pid one seems to be related to the alloca handling code in
> store_val().

Agreed.

> Do you see other failures in addition to this?

Yes.  See 
https://oss.oracle.com/pipermail/dtrace-devel/2025-September/006645.html 
.  But I tried your fresh 2.0-branch-dev and it looked fine.  So I 
suspect things are good now, but I'll try the full test suite and check.