[Bug 287752] DTrace error: no symbolic type information is available for kernel`ticks: No type information available for symbol

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=287752

--- Comment #2 from commit-hook@FreeBSD.org ---
A commit in branch main references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=dabde7d97680cac7e0ead56693d424f4e5631019

commit dabde7d97680cac7e0ead56693d424f4e5631019
Author:     Mark Johnston <markj@FreeBSD.org>
AuthorDate: 2025-07-21 13:34:30 +0000
Commit:     Mark Johnston <markj@FreeBSD.org>
CommitDate: 2025-07-21 14:57:58 +0000

    libdtrace: Permit taking the address of an identifier without type info

    Symbols defined using assembler directives lack type info, but in this
    case one ought to be able to cast a pointer to the symbol and
    dereference the pointer to get a value.  Without this change, D
    disallows this trick since it requires all identifiers to have a type.

    Relax the rules slightly and allow an identifier to have type "void" if
    we know we're just taking its address.

    As a result, the following dtrace invocation works:

      dtrace -n 'tick-1s {printf("%d", *(int *)&`ticks);}'

    In particular, since commit b2b974f7ef4c ("clock: Simplify subr_ticks
    and rename"), "ticks" does not have any type info associated with it, so
    its value couldn't be printed.  This trick provides a workaround and is
    probably generally useful.

    Add a regression test which exercises this functionality.

    PR:             287752
    Reviewed by:    avg
    MFC after:      1 month
    Differential Revision:  https://reviews.freebsd.org/D51417

 .../test/tst/common/profile-n/tst.ticks.d (new)    | 54 ++++++++++++++++++++++
 .../opensolaris/lib/libdtrace/common/dt_parser.c   | 25 ++++++++--
 .../opensolaris/lib/libdtrace/common/dt_parser.h   |  1 +
 .../dtrace/tests/common/profile-n/Makefile         |  1 +
 4 files changed, 78 insertions(+), 3 deletions(-)

-- 
You are receiving this mail because:
You are the assignee for the bug.