Page MenuHomeFreeBSD

dtrace: Use a size_t to represent a buffer size in the printm action
ClosedPublic

Authored by markj on Aug 20 2025, 7:58 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sun, Oct 5, 10:15 PM
Unknown Object (File)
Sat, Oct 4, 8:22 PM
Unknown Object (File)
Fri, Oct 3, 3:45 AM
Unknown Object (File)
Thu, Oct 2, 5:46 PM
Unknown Object (File)
Thu, Oct 2, 3:02 PM
Unknown Object (File)
Wed, Oct 1, 3:31 PM
Unknown Object (File)
Tue, Sep 30, 1:19 PM
Unknown Object (File)
Tue, Sep 30, 8:54 AM
Subscribers

Details

Summary

printm is specific to the FreeBSD dtrace port. I believe it's
effectively the same as tracemem(), though printm apparently predates
it. It stores the size of the buffer of traced data inline. Currently
it represents that size using a uintptr_t, which isn't really right and
poses challenges when porting to CHERI because
DTRACE_STORE(uintptr_t, ... requires the destination to be suitably
aligned, but this isn't necessary since we're just storing a size.

Convert to using a size_t. This should be a no-op since
sizeof(uintptr_t) == sizeof(size_t) on non-CHERI platforms (and I don't
see a reason to use printm() when tracemem() is available and is simpler
to use.)

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

markj requested review of this revision.Aug 20 2025, 7:58 PM
avg added a subscriber: avg.

LGTM.

Maybe we can even retire printm...
I never knew it existed.

This revision is now accepted and ready to land.Aug 21 2025, 5:32 AM
In D52055#1189300, @avg wrote:

LGTM.

Maybe we can even retire printm...
I never knew it existed.

We probably should keep it, if only for backward compatibility purposes, but indeed I hadn't encountered it either.

In D52055#1189300, @avg wrote:

LGTM.

Maybe we can even retire printm...
I never knew it existed.

We probably should keep it, if only for backward compatibility purposes, but indeed I hadn't encountered it either.

That's a good candidate for the section BUILT-IN FUNCTIONS in d(7).

In D52055#1189603, @0mp wrote:
In D52055#1189300, @avg wrote:

LGTM.

Maybe we can even retire printm...
I never knew it existed.

We probably should keep it, if only for backward compatibility purposes, but indeed I hadn't encountered it either.

That's a good candidate for the section BUILT-IN FUNCTIONS in d(7).

Not really, I would rather document tracemem() instead and leave printm() undocumented to discourage its use. (Or find some reason that printm() is useful.)

In D52055#1189603, @0mp wrote:
In D52055#1189300, @avg wrote:

LGTM.

Maybe we can even retire printm...
I never knew it existed.

We probably should keep it, if only for backward compatibility purposes, but indeed I hadn't encountered it either.

That's a good candidate for the section BUILT-IN FUNCTIONS in d(7).

Not really, I would rather document tracemem() instead and leave printm() undocumented to discourage its use. (Or find some reason that printm() is useful.)

Fair enough, thanks for sharing the intuition!