public inbox for dtrace@lists.linux.dev
 help / color / mirror / Atom feed
From: Kris Van Hees <kris.van.hees@oracle.com>
To: eugene.loh@oracle.com
Cc: dtrace@lists.linux.dev, dtrace-devel@oss.oracle.com
Subject: Re: [PATCH] doc: Add rudimentary documentation for using [u]stack as a value
Date: Tue, 21 Oct 2025 16:30:58 -0400	[thread overview]
Message-ID: <aPftglDfrOU7YCW6@oracle.com> (raw)
In-Reply-To: <20251010033337.4397-1-eugene.loh@oracle.com>

On Thu, Oct 09, 2025 at 11:33:37PM -0400, eugene.loh@oracle.com wrote:
> From: Eugene Loh <eugene.loh@oracle.com>
> 
> While we are at it, break up some of the super long source lines for
> future maintainability of these files.

One initial comment about a complication in the userguide that predates all
this...  It uses 'function' to mean both 'action' nd 'subroutine' although they
behave quite differently.  I guess we are stuck with that, though in documenting
stack() and ustack() I think you need to spell out the two forms because it is
going to be more confusing otherwise, especially because:

    stack();
        This is an action that records a stack trace to the output buffer.

    n ? stack(n) : stack();
        This is an expression that does nothing because it calls stack() as a
        subroutine, and thus the result is thrown away.  It will not be written
        to the output buffer.

Clear example of action vs subroutine usage (statement vs expression).

> Signed-off-by: Eugene Loh <eugene.loh@oracle.com>
> ---
>  doc/userguide/reference/function_stack.md  | 21 ++++++++++++++---
>  doc/userguide/reference/function_ustack.md | 27 +++++++++++++++++++---
>  2 files changed, 42 insertions(+), 6 deletions(-)
> 
> diff --git a/doc/userguide/reference/function_stack.md b/doc/userguide/reference/function_stack.md
> index a92c61a0f..d172dd017 100644
> --- a/doc/userguide/reference/function_stack.md
> +++ b/doc/userguide/reference/function_stack.md
> @@ -2,17 +2,25 @@
>  # stack
>  
>  Records a stack trace to the buffer.
> +Alternatively, returns a `dt_stack_t` value that can be stored in a variable.

The implementation actually makes using stack() as a function (subroutine) the
default, and using it as a singular statement (like an action) is the ore
specialized uae.  I think that the documentation should reflect that.

>  
>  ```
> -stack stack([uint32_t *frames*])
> +dt_stack_t stack([uint32_t *frames*])
>  ```
>  
> -The `stack` function records a kernel stack trace to the directed buffer. The function includes an option to specify the number of frames deep to record from the kernel stack. If no value is specified, the number of stack frames recorded is the number that's specified by the `stackframes` runtime option. The `dtrace` command reports frames, either up to the root frame or until the specified limit has been reached, whichever comes first.
> +The `stack` function records a kernel stack trace to the directed buffer.
> +The function includes an option to specify the number of frames deep to record from the kernel stack.
> +If no value is specified, the number of stack frames recorded is the number that's specified by the `stackframes` runtime option.
> +The `dtrace` command reports frames, either up to the root frame or until the specified limit has been reached, whichever comes first.
>  
> -The `stack` function, having a non-`void` return value, can also be used as the key to an aggregation.
> +The `stack` function can also be used as the key to an aggregation.
> +
> +Or, its value may be used as a value to a variable.

This again makes the use of stack() as a subroutine more of an exception, or
almost an afterthought, rather than reflecting that this is now the default.
The use as an action is the exception (preserved for backwards compatibility).

I would highlight that stack() returns a stack trace that can be assigned to a
variable or associative array element, or that can be used as a key to an
aggregation or associative array.  And then mention that when stack() is used
as a singular statement (action), its output is stored to the output buffer.

>  
>  ## How to use stack to obtain a kernel stack trace for a particular probe
>  
> +In this example, `stack()` is an action that prints the kernel stack.
> +
>  ```
>  fbt::ksys_write:entry
>  {
> @@ -22,5 +30,12 @@ fbt::ksys_write:entry
>  
>  ```
>  
> +Alternatively, here `stack()` is used to assign to a variable and print later using `%k` conversion.

I would drop the 'Alternatively' here.

> +
> +```
> +        v = stack(3);
> +        printf("%k", v);
> +```
> +
>  **Parent topic:**[DTrace Function Reference](../reference/dtrace_functions.md)
>  
> diff --git a/doc/userguide/reference/function_ustack.md b/doc/userguide/reference/function_ustack.md
> index be9436f82..01d282c7f 100644
> --- a/doc/userguide/reference/function_ustack.md
> +++ b/doc/userguide/reference/function_ustack.md
> @@ -2,14 +2,29 @@
>  # ustack

Same comments as stack() (see above).

>  
>  Records a user stack trace to the directed buffer.
> +Alternatively, returns a `dt_stack_t` value that can be stored in a variable.
>  
>  ```
> -stack ustack([uint32_t *nframes*, uint32_t *strsize*])
> +dt_stack_t ustack([uint32_t *nframes*, uint32_t *strsize*])
>  ```
>  
> -The `ustack` function records a user stack trace to the directed buffer. The user stack is, at most, *nframes* in depth. If *nframes* isn't specified, the number of stack frames recorded is the number specified by the `ustackframes` option. While `ustack` can determine the address of the calling frames when the probe fires, the stack frames aren't translated into symbols until the `ustack` function is processed at user level by the DTrace utility. If *strsize* is specified and is non zero, `ustack` allocates the specified amount of string space and then uses it to perform address-to-symbol translation directly from the kernel. Such direct user symbol translation is used only with stacktrace helpers that support this usage with DTrace. If such frames can't be translated, the frames appear only as hexadecimal addresses.
> +The `ustack` function records a user stack trace to the directed buffer.
> +The user stack is, at most, *nframes* in depth.
> +If *nframes* isn't specified, the number of stack frames recorded is the number specified by the `ustackframes` option.
> +While `ustack` can determine the address of the calling frames when the probe fires,
> +the stack frames aren't translated into symbols until the `ustack` function is processed at user level by the DTrace utility.
> +If *strsize* is specified and is non zero,
> +`ustack` allocates the specified amount of string space and then uses it to perform address-to-symbol translation directly from the kernel.
> +Such direct user symbol translation is used only with stacktrace helpers that support this usage with DTrace.
> +If such frames can't be translated, the frames appear only as hexadecimal addresses.
>  
> -The `ustack` symbol translation occurs after the stack data is recorded. Therefore, the corresponding user process might exit before symbol translation can be performed, making stack frame translation impossible. If the user process exits before symbol translation is performed, `dtrace` outputs a warning message, followed by the hexadecimal stack frames.
> +The `ustack` symbol translation occurs after the stack data is recorded.
> +Therefore, the corresponding user process might exit before symbol translation can be performed, making stack frame translation impossible.
> +If the user process exits before symbol translation is performed, `dtrace` outputs a warning message, followed by the hexadecimal stack frames.
> +
> +The `ustack` function can also be used as the key to an aggregation.
> +
> +Or, its value may be used as a value to a variable.
>  
>  ## How to use ustack to trace a stack with no address-to-symbol translation
>  
> @@ -35,7 +50,13 @@ Mon 20 Feb 17:38:15 GMT 2023
>                0x7f6d63fc2e65
>  ```
>  
> +This example shows a D clause that stores the user stack to a global variable,
> +then later print it with a `%k` conversion:
>  
> +```
> +        v = ustack(3);
> +        printf("%k", v);
> +```
>  
>  **Parent topic:**[DTrace Function Reference](../reference/dtrace_functions.md)
>  
> -- 
> 2.47.3
> 

      parent reply	other threads:[~2025-10-21 20:31 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-10  3:33 [PATCH] doc: Add rudimentary documentation for using [u]stack as a value eugene.loh
2025-10-13 19:15 ` Kris Van Hees
2025-10-13 19:20   ` [DTrace-devel] " Kris Van Hees
2025-10-21 20:30 ` Kris Van Hees [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aPftglDfrOU7YCW6@oracle.com \
    --to=kris.van.hees@oracle.com \
    --cc=dtrace-devel@oss.oracle.com \
    --cc=dtrace@lists.linux.dev \
    --cc=eugene.loh@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox