* [PATCH v2 06/20] doc: Clean up dangling anchor links
2025-10-22 3:22 [PATCH v2 05/20] doc: Replace duplicate id eugene.loh
@ 2025-10-22 3:22 ` eugene.loh
2025-10-23 19:53 ` Elena Zannoni
2025-10-22 3:22 ` [PATCH v2 08/20] doc: Fix anchor links for built-in variables eugene.loh
` (14 subsequent siblings)
15 siblings, 1 reply; 28+ messages in thread
From: eugene.loh @ 2025-10-22 3:22 UTC (permalink / raw)
To: dtrace, dtrace-devel
From: Eugene Loh <eugene.loh@oracle.com>
Links within the User Guide can point to specific anchor tags within a
page by appending '#' to the page in the link. A number of links have
the '#' but no tag. That's okay, but tidy them up for a cleaner look.
Signed-off-by: Eugene Loh <eugene.loh@oracle.com>
---
.../dtrace-components-and-terminology.md | 10 +++----
doc/userguide/explanation/dtrace-concepts.md | 4 +--
doc/userguide/how-to/dtrace-guide.md | 8 ++---
.../dtrace-howto-create-a-dtrace-script.md | 2 +-
.../reference/d_program_syntax_reference.md | 16 +++++-----
.../dtrace-ref-DTraceSupportforStrings.md | 4 +--
.../dtrace-ref-PointersandScalarArrays.md | 2 +-
...dtrace-ref-TypesOperatorsandExpressions.md | 4 +--
.../reference/dtrace-ref-Variables.md | 4 +--
.../dtrace_builtin_variable_reference.md | 2 +-
.../reference/dtrace_command_reference.md | 8 ++---
doc/userguide/reference/dtrace_providers.md | 30 +++++++++----------
.../reference/dtrace_providers_proc.md | 2 +-
.../reference/dtrace_providers_sched.md | 2 +-
.../reference/dtrace_runtime_options.md | 14 ++++-----
15 files changed, 56 insertions(+), 56 deletions(-)
diff --git a/doc/userguide/explanation/dtrace-components-and-terminology.md b/doc/userguide/explanation/dtrace-components-and-terminology.md
index be6c649d7..b187055a4 100644
--- a/doc/userguide/explanation/dtrace-components-and-terminology.md
+++ b/doc/userguide/explanation/dtrace-components-and-terminology.md
@@ -3,7 +3,7 @@
Learn about the different components and the terms used to describe them within the DTrace framework.
-DTrace is a framework that dynamically traces data into buffers that are read by the `dtrace` command line utility. The `dtrace` command line utility can run programs that can implement certain functions by compiling D programs to generate eBPF code that's loaded into the kernel. In practice, all interaction with DTrace is performed by using the `dtrace` command line utility. See [Install DTrace](../how-to/dtrace-howto-install-dtrace.md#) for information on how to install the command line utility.
+DTrace is a framework that dynamically traces data into buffers that are read by the `dtrace` command line utility. The `dtrace` command line utility can run programs that can implement certain functions by compiling D programs to generate eBPF code that's loaded into the kernel. In practice, all interaction with DTrace is performed by using the `dtrace` command line utility. See [Install DTrace](../how-to/dtrace-howto-install-dtrace.md) for information on how to install the command line utility.
**Parent topic:**[DTrace Concepts](../explanation/dtrace-concepts.md)
@@ -31,7 +31,7 @@ Output is displayed to show each of the different values that are used to refere
...
```
-See [List and Enable Probes](../how-to/dtrace-howto-list-and-enable-probes.md#) for more information on how to list and enable specific probes.
+See [List and Enable Probes](../how-to/dtrace-howto-list-and-enable-probes.md) for more information on how to list and enable specific probes.
Probes are made available by *providers*, which group particular kinds of instrumentation together. If a provider is related to source code, its probes might also include information about the piece of code that the probe relates to in a *module* and a *function* identifier. Therefore, a probe is identified by a *probe description*, grouped into four fields:
@@ -64,7 +64,7 @@ Some probes don't have a module or function identifier when they're listed. When
dtrace:::BEGIN
```
-Probes aren't required to have a module and function. The dtrace `BEGIN`, `END` and `ERROR` probes are good examples of this because these probes don't correspond to any specific instrumented program function or location. Instead, these probes are used for more abstract concepts, such as the idea of the end a tracing request. Other probes, such as those made available by the [Profile Provider](../reference/dtrace_providers_profile.md#) or the [CPC Provider](../reference/dtrace_providers_cpc.md#), also don't include module or function identifiers in their descriptions.
+Probes aren't required to have a module and function. The dtrace `BEGIN`, `END` and `ERROR` probes are good examples of this because these probes don't correspond to any specific instrumented program function or location. Instead, these probes are used for more abstract concepts, such as the idea of the end a tracing request. Other probes, such as those made available by the [Profile Provider](../reference/dtrace_providers_profile.md) or the [CPC Provider](../reference/dtrace_providers_cpc.md), also don't include module or function identifiers in their descriptions.
## D Programs {#concept_terms_programs}
@@ -119,12 +119,12 @@ The program probe description matches all system call functions at the entry poi
Although you could code an application to calculate an aggregation for a set of data, when many probes are firing concurrently, they can overwrite each other's updates to the aggregating variable or the calculation can become a serial bottleneck.
-DTrace aggregation functions apply to the data as it's traced, so that the dataset doesn't need to be stored and the aggregation is always available as events occur. In this way, aggregation functions are more efficient and exact, and avoid overwrites. See [Aggregations](../reference/aggregation.md#) for more information.
+DTrace aggregation functions apply to the data as it's traced, so that the dataset doesn't need to be stored and the aggregation is always available as events occur. In this way, aggregation functions are more efficient and exact, and avoid overwrites. See [Aggregations](../reference/aggregation.md) for more information.
## Speculation {#concept_terms_speculation}
While predicates can be used to filter out uninteresting events, they're only useful if you already know which events you need to filter. Because DTrace is often used to help debug particular system behaviors, DTrace includes a set of *speculation* functions that can be used to trace data speculatively.
-Speculation is used to trace quantities temporarily until particular information is known, at which case the data can be discarded or committed. By performing speculative tracing you can trace data until you know whether it's useful. For example, to trace data about events that might trigger a particular return code or error, you could speculatively trace all events and discard the trace data if it doesn't match the return code that you're interested in. See [Speculation](../reference/dtrace-ref-speculation.md#) for more information.
+Speculation is used to trace quantities temporarily until particular information is known, at which case the data can be discarded or committed. By performing speculative tracing you can trace data until you know whether it's useful. For example, to trace data about events that might trigger a particular return code or error, you could speculatively trace all events and discard the trace data if it doesn't match the return code that you're interested in. See [Speculation](../reference/dtrace-ref-speculation.md) for more information.
diff --git a/doc/userguide/explanation/dtrace-concepts.md b/doc/userguide/explanation/dtrace-concepts.md
index adb5413d3..6e2b91a65 100644
--- a/doc/userguide/explanation/dtrace-concepts.md
+++ b/doc/userguide/explanation/dtrace-concepts.md
@@ -5,8 +5,8 @@ Explore DTrace at a conceptual level and understand DTrace components and termin
The topics in this section are general and can help you to understand what DTrace is and how it works.
-- **[About DTrace](../explanation/dtrace-about.md#)**
+- **[About DTrace](../explanation/dtrace-about.md)**
DTrace is a powerful tracing tool that's available on Linux. DTrace has low overhead and is safe to use on production systems to analyze what a system is doing in real time.
-- **[DTrace Components and Terminology](../explanation/dtrace-components-and-terminology.md#)**
+- **[DTrace Components and Terminology](../explanation/dtrace-components-and-terminology.md)**
Learn about the different components and the terms used to describe them within the DTrace framework.
diff --git a/doc/userguide/how-to/dtrace-guide.md b/doc/userguide/how-to/dtrace-guide.md
index 137d62e3a..02863588b 100644
--- a/doc/userguide/how-to/dtrace-guide.md
+++ b/doc/userguide/how-to/dtrace-guide.md
@@ -8,12 +8,12 @@ Most of the information in this document is generic and applies to all flavors o
The topics in this section provide guidance on how to perform particular operations with DTrace and serve as an introduction to installing and using DTrace. By following steps in this guide, you can get started with DTrace immediately. After you have explored these topics, you can either review [DTrace Concepts](../explanation/dtrace-concepts.md) to get a better understanding of how DTrace works and how you can improve the way that you use it, or you can use the various references that are included to find out more about writing D programs that do what you need them to do.
-- **[Install DTrace](../how-to/dtrace-howto-install-dtrace.md#)**
+- **[Install DTrace](../how-to/dtrace-howto-install-dtrace.md)**
-- **[List and Enable Probes](../how-to/dtrace-howto-list-and-enable-probes.md#)**
+- **[List and Enable Probes](../how-to/dtrace-howto-list-and-enable-probes.md)**
DTrace providers publish available probes to DTrace so that you can enable them to perform functions when they fire. You can use the `dtrace` command to list all available probes or to enable a probe.
-- **[Create a DTrace Script](../how-to/dtrace-howto-create-a-dtrace-script.md#)**
+- **[Create a DTrace Script](../how-to/dtrace-howto-create-a-dtrace-script.md)**
Learn how to create a DTrace script to develop understanding of the D Programming language.
-- **[Use Predicates For Control Flow](../how-to/dtrace-howto-use-predicates.md#)**
+- **[Use Predicates For Control Flow](../how-to/dtrace-howto-use-predicates.md)**
For runtime safety, one major difference between D and other programming languages such as C, C++, and the Java programming language is the absence of control-flow constructs such as `if`-statements and loops. D program clauses are written as single straight-line statement lists that trace an optional, fixed amount of data. D does provide the ability to conditionally trace data and change control flow using logical expressions called *predicates*. This tutorial shows how to use predicates to control D programs.
diff --git a/doc/userguide/how-to/dtrace-howto-create-a-dtrace-script.md b/doc/userguide/how-to/dtrace-howto-create-a-dtrace-script.md
index c4fcb4ed3..199649a9f 100644
--- a/doc/userguide/how-to/dtrace-howto-create-a-dtrace-script.md
+++ b/doc/userguide/how-to/dtrace-howto-create-a-dtrace-script.md
@@ -3,7 +3,7 @@
Learn how to create a DTrace script to develop understanding of the D Programming language.
-Ensure that DTrace is installed on the system and that you can list and enable probes. See [Install DTrace](../how-to/dtrace-howto-install-dtrace.md#) and [List and Enable Probes](../how-to/dtrace-howto-list-and-enable-probes.md#).
+Ensure that DTrace is installed on the system and that you can list and enable probes. See [Install DTrace](../how-to/dtrace-howto-install-dtrace.md) and [List and Enable Probes](../how-to/dtrace-howto-list-and-enable-probes.md).
This tutorial provides successive steps toward developing a DTrace script that you can use on a system to gather useful information. You can use this tutorial as a framework to create other scripts for DTrace, in future.
diff --git a/doc/userguide/reference/d_program_syntax_reference.md b/doc/userguide/reference/d_program_syntax_reference.md
index cd1ad5c1b..862ce0322 100644
--- a/doc/userguide/reference/d_program_syntax_reference.md
+++ b/doc/userguide/reference/d_program_syntax_reference.md
@@ -3,20 +3,20 @@
This reference describes how to write D programs that can be used with DTrace to enable probes and perform operations.
-- **[Program Structure](../reference/d_program_syntax_reference_program_structure.md#)**
+- **[Program Structure](../reference/d_program_syntax_reference_program_structure.md)**
A D program consists of a set of clauses that describe the probes to enable, an optional predicate that controls when to run, and one or more statements that often describe some functionality to implement when the probe fires.
-- **[Types, Operators, and Expressions](../reference/dtrace-ref-TypesOperatorsandExpressions.md#)**
+- **[Types, Operators, and Expressions](../reference/dtrace-ref-TypesOperatorsandExpressions.md)**
-- **[Variables](../reference/dtrace-ref-Variables.md#)**
+- **[Variables](../reference/dtrace-ref-Variables.md)**
-- **[Pointers](../reference/dtrace-ref-PointersandScalarArrays.md#)**
+- **[Pointers](../reference/dtrace-ref-PointersandScalarArrays.md)**
-- **[Structs and Unions](../reference/dtrace-ref-StructsandUnions.md#)**
+- **[Structs and Unions](../reference/dtrace-ref-StructsandUnions.md)**
-- **[DTrace String Processing](../reference/dtrace-ref-DTraceSupportforStrings.md#)**
+- **[DTrace String Processing](../reference/dtrace-ref-DTraceSupportforStrings.md)**
-- **[Aggregations](../reference/aggregation.md#)**
+- **[Aggregations](../reference/aggregation.md)**
-- **[Speculation](../reference/dtrace-ref-speculation.md#)**
+- **[Speculation](../reference/dtrace-ref-speculation.md)**
diff --git a/doc/userguide/reference/dtrace-ref-DTraceSupportforStrings.md b/doc/userguide/reference/dtrace-ref-DTraceSupportforStrings.md
index ea9dfa306..98f482c63 100644
--- a/doc/userguide/reference/dtrace-ref-DTraceSupportforStrings.md
+++ b/doc/userguide/reference/dtrace-ref-DTraceSupportforStrings.md
@@ -31,7 +31,7 @@ In the next D statement, if `s` is of type `string`, the string type indicates t
trace(s);
```
-You can also perform lexical comparison of expressions of type string. See [String Comparison](dtrace-ref-DTraceSupportforStrings.md#).
+You can also perform lexical comparison of expressions of type string. See [String Comparison](dtrace-ref-DTraceSupportforStrings.md).
## String Constants {#dt_strcon_dlang}
@@ -80,7 +80,7 @@ Scalar type expressions, such as a pointer or integer, or a scalar array address
## String Comparison {#dt_strcomp_dlang}
-D overloads the binary relational operators and permits them to be used for string comparisons, as well as integer comparisons. The relational operators perform string comparison whenever both operands are of type `string` or when one operand is of type `string` and the other operand can be promoted to type `string`. See [String Assignment](dtrace-ref-DTraceSupportforStrings.md#) for a detailed description. See also [Table 1](dtrace-ref-DTraceSupportforStrings.md#dt_t14_dlang), which lists the relational operators that can be used to compare strings.
+D overloads the binary relational operators and permits them to be used for string comparisons, as well as integer comparisons. The relational operators perform string comparison whenever both operands are of type `string` or when one operand is of type `string` and the other operand can be promoted to type `string`. See [String Assignment](dtrace-ref-DTraceSupportforStrings.md) for a detailed description. See also [Table 1](dtrace-ref-DTraceSupportforStrings.md#dt_t14_dlang), which lists the relational operators that can be used to compare strings.
<table><thead><tr><th>
diff --git a/doc/userguide/reference/dtrace-ref-PointersandScalarArrays.md b/doc/userguide/reference/dtrace-ref-PointersandScalarArrays.md
index c68982d40..da4b69333 100644
--- a/doc/userguide/reference/dtrace-ref-PointersandScalarArrays.md
+++ b/doc/userguide/reference/dtrace-ref-PointersandScalarArrays.md
@@ -53,7 +53,7 @@ dtrace: script '/tmp/badptr.d' matched 1 probe
dtrace: error on enabled probe ID 2 (ID 1: dtrace:::BEGIN): invalid address (0x0) in action #1 at BPF pc 156
```
-Notice that the D program moves past the error and continues to run; the system and all observed processes remain unperturbed. You can also add an `ERROR` probe to any script to handle D errors. For details about the DTrace error mechanism, see [ERROR Probe](dtrace_providers_dtrace.md#).
+Notice that the D program moves past the error and continues to run; the system and all observed processes remain unperturbed. You can also add an `ERROR` probe to any script to handle D errors. For details about the DTrace error mechanism, see [ERROR Probe](dtrace_providers_dtrace.md).
## Pointer and Array Relationship {#dt_ptrarel_dlang}
diff --git a/doc/userguide/reference/dtrace-ref-TypesOperatorsandExpressions.md b/doc/userguide/reference/dtrace-ref-TypesOperatorsandExpressions.md
index 0e776867c..1a1549445 100644
--- a/doc/userguide/reference/dtrace-ref-TypesOperatorsandExpressions.md
+++ b/doc/userguide/reference/dtrace-ref-TypesOperatorsandExpressions.md
@@ -390,7 +390,7 @@ Type Name
16 bytes
</td></tr><tbody></table>
-D also provides the special type `string` to represent ASCII strings. Strings are discussed in more detail in [DTrace String Processing](dtrace-ref-DTraceSupportforStrings.md#).
+D also provides the special type `string` to represent ASCII strings. Strings are discussed in more detail in [DTrace String Processing](dtrace-ref-DTraceSupportforStrings.md).
## Constants {#dt_consts_dlang}
@@ -664,7 +664,7 @@ Arithmetic in D can only be performed on integer operands or on pointers. Arithm
However, the DTrace execution environment does automatically check for and report division by zero errors resulting from improper use of the `/` and `%` operators. If a D program contains an invalid division operation that's detectable at compile time, a compile error is returned and the compilation fails. If the invalid division operation takes place at run time, processing of the current clause is quit, and the `ERROR` probe is activated. If the D program has no clause for the `ERROR` probe, the error is printed and tracing continues. Otherwise, the actions in the clause assigned to the `ERROR` probe are processed. Errors that are detected by DTrace have no effect on other DTrace users or on the OS kernel. You therefore don't need to be concerned about causing any damage if a D program inadvertently contains one of these errors.
-In addition to these binary operators, the `+` and `-` operators can also be used as unary operators, and these operators have higher precedence than any of the binary arithmetic operators. The order of precedence and associativity properties for all D operators is presented in [Operator Precedence](dtrace-ref-TypesOperatorsandExpressions.md#). You can control precedence by grouping expressions in parentheses \(`()`\).
+In addition to these binary operators, the `+` and `-` operators can also be used as unary operators, and these operators have higher precedence than any of the binary arithmetic operators. The order of precedence and associativity properties for all D operators is presented in [Operator Precedence](dtrace-ref-TypesOperatorsandExpressions.md). You can control precedence by grouping expressions in parentheses \(`()`\).
## Relational Operators {#dt_relatops_dlang}
diff --git a/doc/userguide/reference/dtrace-ref-Variables.md b/doc/userguide/reference/dtrace-ref-Variables.md
index da2130fa6..bc10071ca 100644
--- a/doc/userguide/reference/dtrace-ref-Variables.md
+++ b/doc/userguide/reference/dtrace-ref-Variables.md
@@ -15,7 +15,7 @@ D provides several variable types: scalar variables, associative arrays, scalar
where *name* is any valid D identifier and *expression* is any value or expression that the variable contains.
- DTrace includes several built-in scalar variables that can be referenced within D programs. The values of these variables are automatically populated by DTrace. See [DTrace Built-in Variable Reference](dtrace_builtin_variable_reference.md#) for a complete list of these variables.
+ DTrace includes several built-in scalar variables that can be referenced within D programs. The values of these variables are automatically populated by DTrace. See [DTrace Built-in Variable Reference](dtrace_builtin_variable_reference.md) for a complete list of these variables.
- **Associative Arrays**
@@ -29,7 +29,7 @@ D provides several variable types: scalar variables, associative arrays, scalar
Where *name* is any valid D identifier, *key* is a comma-separated list of one or more expressions, often as string values, and *expression* is the value that's contained by the array for the specified key.
- The type of each object that's contained in the array is also fixed for all elements in the array. You can use any of the assignment operators that are defined in [Types, Operators, and Expressions](dtrace-ref-TypesOperatorsandExpressions.md#) to change associative array elements, subject to the operand rules defined for each operator. The D compiler produces an appropriate error message if you try an incompatible assignment. You can use any type with an associative array key or value that can be used with a scalar variable.
+ The type of each object that's contained in the array is also fixed for all elements in the array. You can use any of the assignment operators that are defined in [Types, Operators, and Expressions](dtrace-ref-TypesOperatorsandExpressions.md) to change associative array elements, subject to the operand rules defined for each operator. The D compiler produces an appropriate error message if you try an incompatible assignment. You can use any type with an associative array key or value that can be used with a scalar variable.
You can reference values in an associative array by specifying the array name and the appropriate key.
diff --git a/doc/userguide/reference/dtrace_builtin_variable_reference.md b/doc/userguide/reference/dtrace_builtin_variable_reference.md
index 607c8f0dd..28b3001ae 100644
--- a/doc/userguide/reference/dtrace_builtin_variable_reference.md
+++ b/doc/userguide/reference/dtrace_builtin_variable_reference.md
@@ -325,7 +325,7 @@ The built-in variable `execname` references the name that was passed to `execve(
fileinfo_t fds[]
```
-The built-in `variable fds[]` is an array which has the files the current process has opened in a `fileinfo_t` array, indexed by file descriptor number. See [fileinfo\_t](dtrace_providers_io.md#).
+The built-in `variable fds[]` is an array which has the files the current process has opened in a `fileinfo_t` array, indexed by file descriptor number. See [fileinfo\_t](dtrace_providers_io.md).
## gid {#dt_ref_var_gid}
diff --git a/doc/userguide/reference/dtrace_command_reference.md b/doc/userguide/reference/dtrace_command_reference.md
index 90209d123..2c45d8e4b 100644
--- a/doc/userguide/reference/dtrace_command_reference.md
+++ b/doc/userguide/reference/dtrace_command_reference.md
@@ -3,12 +3,12 @@
The `dtrace` command is a generic front-end utility for the DTrace facility. The command implements an interface to invoke the D language compiler. The `dtrace` command can also retrieve buffered trace data from the DTrace kernel facility and includes a set of basic routines to format and print traced data.
-- **[About the dtrace Command](../reference/dtrace_command_desc.md#)**
+- **[About the dtrace Command](../reference/dtrace_command_desc.md)**
The `dtrace` command provides a generic interface to all the essential services that are provided by the DTrace facility.
-- **[dtrace Command Options](../reference/dtrace_command_options.md#)**
+- **[dtrace Command Options](../reference/dtrace_command_options.md)**
-- **[dtrace Command Operands](../reference/dtrace_command_operands.md#)**
+- **[dtrace Command Operands](../reference/dtrace_command_operands.md)**
-- **[dtrace Command Exit Status](../reference/dtrace_command_exit_status.md#)**
+- **[dtrace Command Exit Status](../reference/dtrace_command_exit_status.md)**
diff --git a/doc/userguide/reference/dtrace_providers.md b/doc/userguide/reference/dtrace_providers.md
index 6fd0fec6e..70fcb583f 100644
--- a/doc/userguide/reference/dtrace_providers.md
+++ b/doc/userguide/reference/dtrace_providers.md
@@ -3,30 +3,30 @@
DTrace exposes different providers that publish probes that are grouped together for particular instrumentation or functionality.
-- **[CPC Provider](../reference/dtrace_providers_cpc.md#)**
+- **[CPC Provider](../reference/dtrace_providers_cpc.md)**
The CPU performance counter \(`cpc`\) provider makes available probes that are associated with CPU performance counter events.
-- **[DTrace Provider](../reference/dtrace_providers_dtrace.md#)**
+- **[DTrace Provider](../reference/dtrace_providers_dtrace.md)**
The `dtrace` provider includes several probes that are specific to DTrace itself.
-- **[FBT Provider](../reference/dtrace_providers_fbt.md#)**
+- **[FBT Provider](../reference/dtrace_providers_fbt.md)**
The `fbt` \(Function Boundary Tracing\) provider includes probes that are associated with the entry to and return from most functions in the Linux kernel. Therefore, there could be tens of thousands of `fbt` probes.
-- **[IO Provider](../reference/dtrace_providers_io.md#)**
- The `io` provider makes available probes that relate to data input and output.
-- **[Lockstat Provider](../reference/dtrace_providers_lockstat.md#)**
+- **[IO Provider](../reference/dtrace_providers_io.md)**
+The `io` provider makes available probes that relate to data input and output.
+- **[Lockstat Provider](../reference/dtrace_providers_lockstat.md)**
The `lockstat` provider provides probes that can be used to study lock usage and contention.
-- **[Pid Provider](../reference/dtrace_providers_pid.md#)**
+- **[Pid Provider](../reference/dtrace_providers_pid.md)**
The `pid` provider traces a user process, both function `entry` and `return`, and an arbitrary instruction.
-- **[Proc Provider](../reference/dtrace_providers_proc.md#)**
+- **[Proc Provider](../reference/dtrace_providers_proc.md)**
The `proc` provider makes available the probes that pertain to the following activities: process creation and termination, LWP creation and termination, execution of new program images, and signal sending and handling.
-- **[Profile Provider](../reference/dtrace_providers_profile.md#)**
+- **[Profile Provider](../reference/dtrace_providers_profile.md)**
The `profile` provider includes probes that are associated with an interrupt that fires at some regular, specified time interval.
-- **[Rawtp Provider](../reference/dtrace_providers_rawtp.md#)**
+- **[Rawtp Provider](../reference/dtrace_providers_rawtp.md)**
The `rawtp` provider gives DTrace users access to the raw tracepoints exposed by the kernel tracing system, including access to the untranslated arguments of the associated tracepoint events.
-- **[Sched Provider](../reference/dtrace_providers_sched.md#)**
+- **[Sched Provider](../reference/dtrace_providers_sched.md)**
The `sched` provider makes available probes related to CPU scheduling.
-- **[SDT Provider](../reference/dtrace_providers_sdt.md#)**
- The Statically Defined Tracing \(SDT\) provider \(`sdt`\) creates probes at sites that a software programmer has formally designated. Thus, the SDT provider is chiefly of interest only to developers of new providers. Most users access SDT only indirectly by using other providers.
-- **[Syscall Provider](../reference/dtrace_providers_syscall.md#)**
+- **[SDT Provider](../reference/dtrace_providers_sdt.md)**
+The Statically Defined Tracing \(SDT\) provider \(`sdt`\) creates probes at sites that a software programmer has formally designated. Thus, the SDT provider is chiefly of interest only to developers of new providers. Most users access SDT only indirectly by using other providers.
+- **[Syscall Provider](../reference/dtrace_providers_syscall.md)**
The `syscall` provider makes available a probe at the entry to and return from every system call in the system.
-- **[USDT Provider](../reference/dtrace-ref-StaticallyDefinedTracingofUserApplications.md#)**
+- **[USDT Provider](../reference/dtrace-ref-StaticallyDefinedTracingofUserApplications.md)**
Use the USDT provider, for user space statically defined tracing, to instrument user space code with probes that are meaningful for an application.
diff --git a/doc/userguide/reference/dtrace_providers_proc.md b/doc/userguide/reference/dtrace_providers_proc.md
index 40903775d..6c1fa8ecf 100644
--- a/doc/userguide/reference/dtrace_providers_proc.md
+++ b/doc/userguide/reference/dtrace_providers_proc.md
@@ -130,7 +130,7 @@ No fundamental difference between a process and a thread that a process creates,
## proc Probe Arguments {#dt_ref_procargs_prov}
-The following table lists the argument types for the `proc` probes. See [proc Probes](dtrace_providers_proc.md#) for a description of the arguments. The `argN` are implementation specific. Use `args[]` to access the probe arguments.
+The following table lists the argument types for the `proc` probes. See [proc Probes](dtrace_providers_proc.md) for a description of the arguments. The `argN` are implementation specific. Use `args[]` to access the probe arguments.
<table><thead><tr><th>
diff --git a/doc/userguide/reference/dtrace_providers_sched.md b/doc/userguide/reference/dtrace_providers_sched.md
index 68bcdf715..f6d183708 100644
--- a/doc/userguide/reference/dtrace_providers_sched.md
+++ b/doc/userguide/reference/dtrace_providers_sched.md
@@ -245,7 +245,7 @@ Probe
</td></tr><tbody></table>
### lwpsinfo\_t and psinfo\_t {#dt_ref_lwpsinfo_t_psinfo_t_sched_prov}
-The `lwpsinfo_t` and `psinfo_t` structures are described in [Proc Provider](dtrace_providers_proc.md#).
+The `lwpsinfo_t` and `psinfo_t` structures are described in [Proc Provider](dtrace_providers_proc.md).
### cpuinfo\_t {#dt_ref_cpuinfo_sched_prov}
diff --git a/doc/userguide/reference/dtrace_runtime_options.md b/doc/userguide/reference/dtrace_runtime_options.md
index b721f64e6..766709af2 100644
--- a/doc/userguide/reference/dtrace_runtime_options.md
+++ b/doc/userguide/reference/dtrace_runtime_options.md
@@ -5,19 +5,19 @@ DTrace uses reasonable default values and flexible default policies for runtime
Options that can be specified when running the `dtrace` utility can be categorized into three types:
-- [Compile-time Options](compiler_options.md#): affect the compilation process but might also affect runtime behavior.
+- [Compile-time Options](compiler_options.md): affect the compilation process but might also affect runtime behavior.
-- [Runtime Options](runtime_options.md#): affect the runtime behavior of DTrace but which are often set at compile time.
+- [Runtime Options](runtime_options.md): affect the runtime behavior of DTrace but which are often set at compile time.
-- [Dynamic Runtime Options](dynamic_runtime_options.md#): affect the runtime behavior of DTrace but which can be changed while tracing, by using the `[setopt](function_setopt.md)` function.
+- [Dynamic Runtime Options](dynamic_runtime_options.md): affect the runtime behavior of DTrace but which can be changed while tracing, by using the `[setopt](function_setopt.md)` function.
-- **[Setting DTrace Compile-time and Runtime Options](../reference/setting_dtrace_compiler_and_runtime_options.md#)**
+- **[Setting DTrace Compile-time and Runtime Options](../reference/setting_dtrace_compiler_and_runtime_options.md)**
You can tune DTrace by setting or enabling a selection of runtime or compiler options. You can set options by either using the `-x` command line switch when running the `dtrace` command, or by specifying `pragma` lines in D programs. If an option takes a value, follow the option name with an equal sign \(`=`\) and the option value.
-- **[Compile-time Options](../reference/compiler_options.md#)**
+- **[Compile-time Options](../reference/compiler_options.md)**
Compile-time options can control how DTrace programs are compiled into eBPF code that's loaded into kernel space.
-- **[Runtime Options](../reference/runtime_options.md#)**
+- **[Runtime Options](../reference/runtime_options.md)**
Runtime options can control how the DTrace utility behaves.
-- **[Dynamic Runtime Options](../reference/dynamic_runtime_options.md#)**
+- **[Dynamic Runtime Options](../reference/dynamic_runtime_options.md)**
Dynamic runtime options are specific to D programs themselves and are likely to change depending on program functionality and requirements.
--
2.47.3
^ permalink raw reply related [flat|nested] 28+ messages in thread* Re: [PATCH v2 06/20] doc: Clean up dangling anchor links
2025-10-22 3:22 ` [PATCH v2 06/20] doc: Clean up dangling anchor links eugene.loh
@ 2025-10-23 19:53 ` Elena Zannoni
0 siblings, 0 replies; 28+ messages in thread
From: Elena Zannoni @ 2025-10-23 19:53 UTC (permalink / raw)
To: eugene.loh, dtrace, dtrace-devel
Reviewed-by: Elena Zannoni <elena.zannoni@oracle.com>
On 10/21/25 9:22 PM, eugene.loh@oracle.com wrote:
> From: Eugene Loh <eugene.loh@oracle.com>
>
> Links within the User Guide can point to specific anchor tags within a
> page by appending '#' to the page in the link. A number of links have
> the '#' but no tag. That's okay, but tidy them up for a cleaner look.
>
> Signed-off-by: Eugene Loh <eugene.loh@oracle.com>
> ---
> .../dtrace-components-and-terminology.md | 10 +++----
> doc/userguide/explanation/dtrace-concepts.md | 4 +--
> doc/userguide/how-to/dtrace-guide.md | 8 ++---
> .../dtrace-howto-create-a-dtrace-script.md | 2 +-
> .../reference/d_program_syntax_reference.md | 16 +++++-----
> .../dtrace-ref-DTraceSupportforStrings.md | 4 +--
> .../dtrace-ref-PointersandScalarArrays.md | 2 +-
> ...dtrace-ref-TypesOperatorsandExpressions.md | 4 +--
> .../reference/dtrace-ref-Variables.md | 4 +--
> .../dtrace_builtin_variable_reference.md | 2 +-
> .../reference/dtrace_command_reference.md | 8 ++---
> doc/userguide/reference/dtrace_providers.md | 30 +++++++++----------
> .../reference/dtrace_providers_proc.md | 2 +-
> .../reference/dtrace_providers_sched.md | 2 +-
> .../reference/dtrace_runtime_options.md | 14 ++++-----
> 15 files changed, 56 insertions(+), 56 deletions(-)
>
> diff --git a/doc/userguide/explanation/dtrace-components-and-terminology.md b/doc/userguide/explanation/dtrace-components-and-terminology.md
> index be6c649d7..b187055a4 100644
> --- a/doc/userguide/explanation/dtrace-components-and-terminology.md
> +++ b/doc/userguide/explanation/dtrace-components-and-terminology.md
> @@ -3,7 +3,7 @@
>
> Learn about the different components and the terms used to describe them within the DTrace framework.
>
> -DTrace is a framework that dynamically traces data into buffers that are read by the `dtrace` command line utility. The `dtrace` command line utility can run programs that can implement certain functions by compiling D programs to generate eBPF code that's loaded into the kernel. In practice, all interaction with DTrace is performed by using the `dtrace` command line utility. See [Install DTrace](../how-to/dtrace-howto-install-dtrace.md#) for information on how to install the command line utility.
> +DTrace is a framework that dynamically traces data into buffers that are read by the `dtrace` command line utility. The `dtrace` command line utility can run programs that can implement certain functions by compiling D programs to generate eBPF code that's loaded into the kernel. In practice, all interaction with DTrace is performed by using the `dtrace` command line utility. See [Install DTrace](../how-to/dtrace-howto-install-dtrace.md) for information on how to install the command line utility.
>
> **Parent topic:**[DTrace Concepts](../explanation/dtrace-concepts.md)
>
> @@ -31,7 +31,7 @@ Output is displayed to show each of the different values that are used to refere
> ...
> ```
>
> -See [List and Enable Probes](../how-to/dtrace-howto-list-and-enable-probes.md#) for more information on how to list and enable specific probes.
> +See [List and Enable Probes](../how-to/dtrace-howto-list-and-enable-probes.md) for more information on how to list and enable specific probes.
>
> Probes are made available by *providers*, which group particular kinds of instrumentation together. If a provider is related to source code, its probes might also include information about the piece of code that the probe relates to in a *module* and a *function* identifier. Therefore, a probe is identified by a *probe description*, grouped into four fields:
>
> @@ -64,7 +64,7 @@ Some probes don't have a module or function identifier when they're listed. When
> dtrace:::BEGIN
> ```
>
> -Probes aren't required to have a module and function. The dtrace `BEGIN`, `END` and `ERROR` probes are good examples of this because these probes don't correspond to any specific instrumented program function or location. Instead, these probes are used for more abstract concepts, such as the idea of the end a tracing request. Other probes, such as those made available by the [Profile Provider](../reference/dtrace_providers_profile.md#) or the [CPC Provider](../reference/dtrace_providers_cpc.md#), also don't include module or function identifiers in their descriptions.
> +Probes aren't required to have a module and function. The dtrace `BEGIN`, `END` and `ERROR` probes are good examples of this because these probes don't correspond to any specific instrumented program function or location. Instead, these probes are used for more abstract concepts, such as the idea of the end a tracing request. Other probes, such as those made available by the [Profile Provider](../reference/dtrace_providers_profile.md) or the [CPC Provider](../reference/dtrace_providers_cpc.md), also don't include module or function identifiers in their descriptions.
>
> ## D Programs {#concept_terms_programs}
>
> @@ -119,12 +119,12 @@ The program probe description matches all system call functions at the entry poi
>
> Although you could code an application to calculate an aggregation for a set of data, when many probes are firing concurrently, they can overwrite each other's updates to the aggregating variable or the calculation can become a serial bottleneck.
>
> -DTrace aggregation functions apply to the data as it's traced, so that the dataset doesn't need to be stored and the aggregation is always available as events occur. In this way, aggregation functions are more efficient and exact, and avoid overwrites. See [Aggregations](../reference/aggregation.md#) for more information.
> +DTrace aggregation functions apply to the data as it's traced, so that the dataset doesn't need to be stored and the aggregation is always available as events occur. In this way, aggregation functions are more efficient and exact, and avoid overwrites. See [Aggregations](../reference/aggregation.md) for more information.
>
> ## Speculation {#concept_terms_speculation}
>
> While predicates can be used to filter out uninteresting events, they're only useful if you already know which events you need to filter. Because DTrace is often used to help debug particular system behaviors, DTrace includes a set of *speculation* functions that can be used to trace data speculatively.
>
> -Speculation is used to trace quantities temporarily until particular information is known, at which case the data can be discarded or committed. By performing speculative tracing you can trace data until you know whether it's useful. For example, to trace data about events that might trigger a particular return code or error, you could speculatively trace all events and discard the trace data if it doesn't match the return code that you're interested in. See [Speculation](../reference/dtrace-ref-speculation.md#) for more information.
> +Speculation is used to trace quantities temporarily until particular information is known, at which case the data can be discarded or committed. By performing speculative tracing you can trace data until you know whether it's useful. For example, to trace data about events that might trigger a particular return code or error, you could speculatively trace all events and discard the trace data if it doesn't match the return code that you're interested in. See [Speculation](../reference/dtrace-ref-speculation.md) for more information.
>
>
> diff --git a/doc/userguide/explanation/dtrace-concepts.md b/doc/userguide/explanation/dtrace-concepts.md
> index adb5413d3..6e2b91a65 100644
> --- a/doc/userguide/explanation/dtrace-concepts.md
> +++ b/doc/userguide/explanation/dtrace-concepts.md
> @@ -5,8 +5,8 @@ Explore DTrace at a conceptual level and understand DTrace components and termin
>
> The topics in this section are general and can help you to understand what DTrace is and how it works.
>
> -- **[About DTrace](../explanation/dtrace-about.md#)**
> +- **[About DTrace](../explanation/dtrace-about.md)**
> DTrace is a powerful tracing tool that's available on Linux. DTrace has low overhead and is safe to use on production systems to analyze what a system is doing in real time.
> -- **[DTrace Components and Terminology](../explanation/dtrace-components-and-terminology.md#)**
> +- **[DTrace Components and Terminology](../explanation/dtrace-components-and-terminology.md)**
> Learn about the different components and the terms used to describe them within the DTrace framework.
>
> diff --git a/doc/userguide/how-to/dtrace-guide.md b/doc/userguide/how-to/dtrace-guide.md
> index 137d62e3a..02863588b 100644
> --- a/doc/userguide/how-to/dtrace-guide.md
> +++ b/doc/userguide/how-to/dtrace-guide.md
> @@ -8,12 +8,12 @@ Most of the information in this document is generic and applies to all flavors o
>
> The topics in this section provide guidance on how to perform particular operations with DTrace and serve as an introduction to installing and using DTrace. By following steps in this guide, you can get started with DTrace immediately. After you have explored these topics, you can either review [DTrace Concepts](../explanation/dtrace-concepts.md) to get a better understanding of how DTrace works and how you can improve the way that you use it, or you can use the various references that are included to find out more about writing D programs that do what you need them to do.
>
> -- **[Install DTrace](../how-to/dtrace-howto-install-dtrace.md#)**
> +- **[Install DTrace](../how-to/dtrace-howto-install-dtrace.md)**
>
> -- **[List and Enable Probes](../how-to/dtrace-howto-list-and-enable-probes.md#)**
> +- **[List and Enable Probes](../how-to/dtrace-howto-list-and-enable-probes.md)**
> DTrace providers publish available probes to DTrace so that you can enable them to perform functions when they fire. You can use the `dtrace` command to list all available probes or to enable a probe.
> -- **[Create a DTrace Script](../how-to/dtrace-howto-create-a-dtrace-script.md#)**
> +- **[Create a DTrace Script](../how-to/dtrace-howto-create-a-dtrace-script.md)**
> Learn how to create a DTrace script to develop understanding of the D Programming language.
> -- **[Use Predicates For Control Flow](../how-to/dtrace-howto-use-predicates.md#)**
> +- **[Use Predicates For Control Flow](../how-to/dtrace-howto-use-predicates.md)**
> For runtime safety, one major difference between D and other programming languages such as C, C++, and the Java programming language is the absence of control-flow constructs such as `if`-statements and loops. D program clauses are written as single straight-line statement lists that trace an optional, fixed amount of data. D does provide the ability to conditionally trace data and change control flow using logical expressions called *predicates*. This tutorial shows how to use predicates to control D programs.
>
> diff --git a/doc/userguide/how-to/dtrace-howto-create-a-dtrace-script.md b/doc/userguide/how-to/dtrace-howto-create-a-dtrace-script.md
> index c4fcb4ed3..199649a9f 100644
> --- a/doc/userguide/how-to/dtrace-howto-create-a-dtrace-script.md
> +++ b/doc/userguide/how-to/dtrace-howto-create-a-dtrace-script.md
> @@ -3,7 +3,7 @@
>
> Learn how to create a DTrace script to develop understanding of the D Programming language.
>
> -Ensure that DTrace is installed on the system and that you can list and enable probes. See [Install DTrace](../how-to/dtrace-howto-install-dtrace.md#) and [List and Enable Probes](../how-to/dtrace-howto-list-and-enable-probes.md#).
> +Ensure that DTrace is installed on the system and that you can list and enable probes. See [Install DTrace](../how-to/dtrace-howto-install-dtrace.md) and [List and Enable Probes](../how-to/dtrace-howto-list-and-enable-probes.md).
>
> This tutorial provides successive steps toward developing a DTrace script that you can use on a system to gather useful information. You can use this tutorial as a framework to create other scripts for DTrace, in future.
>
> diff --git a/doc/userguide/reference/d_program_syntax_reference.md b/doc/userguide/reference/d_program_syntax_reference.md
> index cd1ad5c1b..862ce0322 100644
> --- a/doc/userguide/reference/d_program_syntax_reference.md
> +++ b/doc/userguide/reference/d_program_syntax_reference.md
> @@ -3,20 +3,20 @@
>
> This reference describes how to write D programs that can be used with DTrace to enable probes and perform operations.
>
> -- **[Program Structure](../reference/d_program_syntax_reference_program_structure.md#)**
> +- **[Program Structure](../reference/d_program_syntax_reference_program_structure.md)**
> A D program consists of a set of clauses that describe the probes to enable, an optional predicate that controls when to run, and one or more statements that often describe some functionality to implement when the probe fires.
> -- **[Types, Operators, and Expressions](../reference/dtrace-ref-TypesOperatorsandExpressions.md#)**
> +- **[Types, Operators, and Expressions](../reference/dtrace-ref-TypesOperatorsandExpressions.md)**
>
> -- **[Variables](../reference/dtrace-ref-Variables.md#)**
> +- **[Variables](../reference/dtrace-ref-Variables.md)**
>
> -- **[Pointers](../reference/dtrace-ref-PointersandScalarArrays.md#)**
> +- **[Pointers](../reference/dtrace-ref-PointersandScalarArrays.md)**
>
> -- **[Structs and Unions](../reference/dtrace-ref-StructsandUnions.md#)**
> +- **[Structs and Unions](../reference/dtrace-ref-StructsandUnions.md)**
>
> -- **[DTrace String Processing](../reference/dtrace-ref-DTraceSupportforStrings.md#)**
> +- **[DTrace String Processing](../reference/dtrace-ref-DTraceSupportforStrings.md)**
>
> -- **[Aggregations](../reference/aggregation.md#)**
> +- **[Aggregations](../reference/aggregation.md)**
>
> -- **[Speculation](../reference/dtrace-ref-speculation.md#)**
> +- **[Speculation](../reference/dtrace-ref-speculation.md)**
>
>
> diff --git a/doc/userguide/reference/dtrace-ref-DTraceSupportforStrings.md b/doc/userguide/reference/dtrace-ref-DTraceSupportforStrings.md
> index ea9dfa306..98f482c63 100644
> --- a/doc/userguide/reference/dtrace-ref-DTraceSupportforStrings.md
> +++ b/doc/userguide/reference/dtrace-ref-DTraceSupportforStrings.md
> @@ -31,7 +31,7 @@ In the next D statement, if `s` is of type `string`, the string type indicates t
> trace(s);
> ```
>
> -You can also perform lexical comparison of expressions of type string. See [String Comparison](dtrace-ref-DTraceSupportforStrings.md#).
> +You can also perform lexical comparison of expressions of type string. See [String Comparison](dtrace-ref-DTraceSupportforStrings.md).
>
> ## String Constants {#dt_strcon_dlang}
>
> @@ -80,7 +80,7 @@ Scalar type expressions, such as a pointer or integer, or a scalar array address
>
> ## String Comparison {#dt_strcomp_dlang}
>
> -D overloads the binary relational operators and permits them to be used for string comparisons, as well as integer comparisons. The relational operators perform string comparison whenever both operands are of type `string` or when one operand is of type `string` and the other operand can be promoted to type `string`. See [String Assignment](dtrace-ref-DTraceSupportforStrings.md#) for a detailed description. See also [Table 1](dtrace-ref-DTraceSupportforStrings.md#dt_t14_dlang), which lists the relational operators that can be used to compare strings.
> +D overloads the binary relational operators and permits them to be used for string comparisons, as well as integer comparisons. The relational operators perform string comparison whenever both operands are of type `string` or when one operand is of type `string` and the other operand can be promoted to type `string`. See [String Assignment](dtrace-ref-DTraceSupportforStrings.md) for a detailed description. See also [Table 1](dtrace-ref-DTraceSupportforStrings.md#dt_t14_dlang), which lists the relational operators that can be used to compare strings.
>
> <table><thead><tr><th>
>
> diff --git a/doc/userguide/reference/dtrace-ref-PointersandScalarArrays.md b/doc/userguide/reference/dtrace-ref-PointersandScalarArrays.md
> index c68982d40..da4b69333 100644
> --- a/doc/userguide/reference/dtrace-ref-PointersandScalarArrays.md
> +++ b/doc/userguide/reference/dtrace-ref-PointersandScalarArrays.md
> @@ -53,7 +53,7 @@ dtrace: script '/tmp/badptr.d' matched 1 probe
> dtrace: error on enabled probe ID 2 (ID 1: dtrace:::BEGIN): invalid address (0x0) in action #1 at BPF pc 156
> ```
>
> -Notice that the D program moves past the error and continues to run; the system and all observed processes remain unperturbed. You can also add an `ERROR` probe to any script to handle D errors. For details about the DTrace error mechanism, see [ERROR Probe](dtrace_providers_dtrace.md#).
> +Notice that the D program moves past the error and continues to run; the system and all observed processes remain unperturbed. You can also add an `ERROR` probe to any script to handle D errors. For details about the DTrace error mechanism, see [ERROR Probe](dtrace_providers_dtrace.md).
>
> ## Pointer and Array Relationship {#dt_ptrarel_dlang}
>
> diff --git a/doc/userguide/reference/dtrace-ref-TypesOperatorsandExpressions.md b/doc/userguide/reference/dtrace-ref-TypesOperatorsandExpressions.md
> index 0e776867c..1a1549445 100644
> --- a/doc/userguide/reference/dtrace-ref-TypesOperatorsandExpressions.md
> +++ b/doc/userguide/reference/dtrace-ref-TypesOperatorsandExpressions.md
> @@ -390,7 +390,7 @@ Type Name
> 16 bytes
>
> </td></tr><tbody></table>
> -D also provides the special type `string` to represent ASCII strings. Strings are discussed in more detail in [DTrace String Processing](dtrace-ref-DTraceSupportforStrings.md#).
> +D also provides the special type `string` to represent ASCII strings. Strings are discussed in more detail in [DTrace String Processing](dtrace-ref-DTraceSupportforStrings.md).
>
> ## Constants {#dt_consts_dlang}
>
> @@ -664,7 +664,7 @@ Arithmetic in D can only be performed on integer operands or on pointers. Arithm
>
> However, the DTrace execution environment does automatically check for and report division by zero errors resulting from improper use of the `/` and `%` operators. If a D program contains an invalid division operation that's detectable at compile time, a compile error is returned and the compilation fails. If the invalid division operation takes place at run time, processing of the current clause is quit, and the `ERROR` probe is activated. If the D program has no clause for the `ERROR` probe, the error is printed and tracing continues. Otherwise, the actions in the clause assigned to the `ERROR` probe are processed. Errors that are detected by DTrace have no effect on other DTrace users or on the OS kernel. You therefore don't need to be concerned about causing any damage if a D program inadvertently contains one of these errors.
>
> -In addition to these binary operators, the `+` and `-` operators can also be used as unary operators, and these operators have higher precedence than any of the binary arithmetic operators. The order of precedence and associativity properties for all D operators is presented in [Operator Precedence](dtrace-ref-TypesOperatorsandExpressions.md#). You can control precedence by grouping expressions in parentheses \(`()`\).
> +In addition to these binary operators, the `+` and `-` operators can also be used as unary operators, and these operators have higher precedence than any of the binary arithmetic operators. The order of precedence and associativity properties for all D operators is presented in [Operator Precedence](dtrace-ref-TypesOperatorsandExpressions.md). You can control precedence by grouping expressions in parentheses \(`()`\).
>
> ## Relational Operators {#dt_relatops_dlang}
>
> diff --git a/doc/userguide/reference/dtrace-ref-Variables.md b/doc/userguide/reference/dtrace-ref-Variables.md
> index da2130fa6..bc10071ca 100644
> --- a/doc/userguide/reference/dtrace-ref-Variables.md
> +++ b/doc/userguide/reference/dtrace-ref-Variables.md
> @@ -15,7 +15,7 @@ D provides several variable types: scalar variables, associative arrays, scalar
>
> where *name* is any valid D identifier and *expression* is any value or expression that the variable contains.
>
> - DTrace includes several built-in scalar variables that can be referenced within D programs. The values of these variables are automatically populated by DTrace. See [DTrace Built-in Variable Reference](dtrace_builtin_variable_reference.md#) for a complete list of these variables.
> + DTrace includes several built-in scalar variables that can be referenced within D programs. The values of these variables are automatically populated by DTrace. See [DTrace Built-in Variable Reference](dtrace_builtin_variable_reference.md) for a complete list of these variables.
>
> - **Associative Arrays**
>
> @@ -29,7 +29,7 @@ D provides several variable types: scalar variables, associative arrays, scalar
>
> Where *name* is any valid D identifier, *key* is a comma-separated list of one or more expressions, often as string values, and *expression* is the value that's contained by the array for the specified key.
>
> - The type of each object that's contained in the array is also fixed for all elements in the array. You can use any of the assignment operators that are defined in [Types, Operators, and Expressions](dtrace-ref-TypesOperatorsandExpressions.md#) to change associative array elements, subject to the operand rules defined for each operator. The D compiler produces an appropriate error message if you try an incompatible assignment. You can use any type with an associative array key or value that can be used with a scalar variable.
> + The type of each object that's contained in the array is also fixed for all elements in the array. You can use any of the assignment operators that are defined in [Types, Operators, and Expressions](dtrace-ref-TypesOperatorsandExpressions.md) to change associative array elements, subject to the operand rules defined for each operator. The D compiler produces an appropriate error message if you try an incompatible assignment. You can use any type with an associative array key or value that can be used with a scalar variable.
>
> You can reference values in an associative array by specifying the array name and the appropriate key.
>
> diff --git a/doc/userguide/reference/dtrace_builtin_variable_reference.md b/doc/userguide/reference/dtrace_builtin_variable_reference.md
> index 607c8f0dd..28b3001ae 100644
> --- a/doc/userguide/reference/dtrace_builtin_variable_reference.md
> +++ b/doc/userguide/reference/dtrace_builtin_variable_reference.md
> @@ -325,7 +325,7 @@ The built-in variable `execname` references the name that was passed to `execve(
> fileinfo_t fds[]
> ```
>
> -The built-in `variable fds[]` is an array which has the files the current process has opened in a `fileinfo_t` array, indexed by file descriptor number. See [fileinfo\_t](dtrace_providers_io.md#).
> +The built-in `variable fds[]` is an array which has the files the current process has opened in a `fileinfo_t` array, indexed by file descriptor number. See [fileinfo\_t](dtrace_providers_io.md).
>
> ## gid {#dt_ref_var_gid}
>
> diff --git a/doc/userguide/reference/dtrace_command_reference.md b/doc/userguide/reference/dtrace_command_reference.md
> index 90209d123..2c45d8e4b 100644
> --- a/doc/userguide/reference/dtrace_command_reference.md
> +++ b/doc/userguide/reference/dtrace_command_reference.md
> @@ -3,12 +3,12 @@
>
> The `dtrace` command is a generic front-end utility for the DTrace facility. The command implements an interface to invoke the D language compiler. The `dtrace` command can also retrieve buffered trace data from the DTrace kernel facility and includes a set of basic routines to format and print traced data.
>
> -- **[About the dtrace Command](../reference/dtrace_command_desc.md#)**
> +- **[About the dtrace Command](../reference/dtrace_command_desc.md)**
> The `dtrace` command provides a generic interface to all the essential services that are provided by the DTrace facility.
> -- **[dtrace Command Options](../reference/dtrace_command_options.md#)**
> +- **[dtrace Command Options](../reference/dtrace_command_options.md)**
>
> -- **[dtrace Command Operands](../reference/dtrace_command_operands.md#)**
> +- **[dtrace Command Operands](../reference/dtrace_command_operands.md)**
>
> -- **[dtrace Command Exit Status](../reference/dtrace_command_exit_status.md#)**
> +- **[dtrace Command Exit Status](../reference/dtrace_command_exit_status.md)**
>
>
> diff --git a/doc/userguide/reference/dtrace_providers.md b/doc/userguide/reference/dtrace_providers.md
> index 6fd0fec6e..70fcb583f 100644
> --- a/doc/userguide/reference/dtrace_providers.md
> +++ b/doc/userguide/reference/dtrace_providers.md
> @@ -3,30 +3,30 @@
>
> DTrace exposes different providers that publish probes that are grouped together for particular instrumentation or functionality.
>
> -- **[CPC Provider](../reference/dtrace_providers_cpc.md#)**
> +- **[CPC Provider](../reference/dtrace_providers_cpc.md)**
> The CPU performance counter \(`cpc`\) provider makes available probes that are associated with CPU performance counter events.
> -- **[DTrace Provider](../reference/dtrace_providers_dtrace.md#)**
> +- **[DTrace Provider](../reference/dtrace_providers_dtrace.md)**
> The `dtrace` provider includes several probes that are specific to DTrace itself.
> -- **[FBT Provider](../reference/dtrace_providers_fbt.md#)**
> +- **[FBT Provider](../reference/dtrace_providers_fbt.md)**
> The `fbt` \(Function Boundary Tracing\) provider includes probes that are associated with the entry to and return from most functions in the Linux kernel. Therefore, there could be tens of thousands of `fbt` probes.
> -- **[IO Provider](../reference/dtrace_providers_io.md#)**
> - The `io` provider makes available probes that relate to data input and output.
> -- **[Lockstat Provider](../reference/dtrace_providers_lockstat.md#)**
> +- **[IO Provider](../reference/dtrace_providers_io.md)**
> +The `io` provider makes available probes that relate to data input and output.
> +- **[Lockstat Provider](../reference/dtrace_providers_lockstat.md)**
> The `lockstat` provider provides probes that can be used to study lock usage and contention.
> -- **[Pid Provider](../reference/dtrace_providers_pid.md#)**
> +- **[Pid Provider](../reference/dtrace_providers_pid.md)**
> The `pid` provider traces a user process, both function `entry` and `return`, and an arbitrary instruction.
> -- **[Proc Provider](../reference/dtrace_providers_proc.md#)**
> +- **[Proc Provider](../reference/dtrace_providers_proc.md)**
> The `proc` provider makes available the probes that pertain to the following activities: process creation and termination, LWP creation and termination, execution of new program images, and signal sending and handling.
> -- **[Profile Provider](../reference/dtrace_providers_profile.md#)**
> +- **[Profile Provider](../reference/dtrace_providers_profile.md)**
> The `profile` provider includes probes that are associated with an interrupt that fires at some regular, specified time interval.
> -- **[Rawtp Provider](../reference/dtrace_providers_rawtp.md#)**
> +- **[Rawtp Provider](../reference/dtrace_providers_rawtp.md)**
> The `rawtp` provider gives DTrace users access to the raw tracepoints exposed by the kernel tracing system, including access to the untranslated arguments of the associated tracepoint events.
> -- **[Sched Provider](../reference/dtrace_providers_sched.md#)**
> +- **[Sched Provider](../reference/dtrace_providers_sched.md)**
> The `sched` provider makes available probes related to CPU scheduling.
> -- **[SDT Provider](../reference/dtrace_providers_sdt.md#)**
> - The Statically Defined Tracing \(SDT\) provider \(`sdt`\) creates probes at sites that a software programmer has formally designated. Thus, the SDT provider is chiefly of interest only to developers of new providers. Most users access SDT only indirectly by using other providers.
> -- **[Syscall Provider](../reference/dtrace_providers_syscall.md#)**
> +- **[SDT Provider](../reference/dtrace_providers_sdt.md)**
> +The Statically Defined Tracing \(SDT\) provider \(`sdt`\) creates probes at sites that a software programmer has formally designated. Thus, the SDT provider is chiefly of interest only to developers of new providers. Most users access SDT only indirectly by using other providers.
> +- **[Syscall Provider](../reference/dtrace_providers_syscall.md)**
> The `syscall` provider makes available a probe at the entry to and return from every system call in the system.
> -- **[USDT Provider](../reference/dtrace-ref-StaticallyDefinedTracingofUserApplications.md#)**
> +- **[USDT Provider](../reference/dtrace-ref-StaticallyDefinedTracingofUserApplications.md)**
> Use the USDT provider, for user space statically defined tracing, to instrument user space code with probes that are meaningful for an application.
>
> diff --git a/doc/userguide/reference/dtrace_providers_proc.md b/doc/userguide/reference/dtrace_providers_proc.md
> index 40903775d..6c1fa8ecf 100644
> --- a/doc/userguide/reference/dtrace_providers_proc.md
> +++ b/doc/userguide/reference/dtrace_providers_proc.md
> @@ -130,7 +130,7 @@ No fundamental difference between a process and a thread that a process creates,
>
> ## proc Probe Arguments {#dt_ref_procargs_prov}
>
> -The following table lists the argument types for the `proc` probes. See [proc Probes](dtrace_providers_proc.md#) for a description of the arguments. The `argN` are implementation specific. Use `args[]` to access the probe arguments.
> +The following table lists the argument types for the `proc` probes. See [proc Probes](dtrace_providers_proc.md) for a description of the arguments. The `argN` are implementation specific. Use `args[]` to access the probe arguments.
>
> <table><thead><tr><th>
>
> diff --git a/doc/userguide/reference/dtrace_providers_sched.md b/doc/userguide/reference/dtrace_providers_sched.md
> index 68bcdf715..f6d183708 100644
> --- a/doc/userguide/reference/dtrace_providers_sched.md
> +++ b/doc/userguide/reference/dtrace_providers_sched.md
> @@ -245,7 +245,7 @@ Probe
> </td></tr><tbody></table>
> ### lwpsinfo\_t and psinfo\_t {#dt_ref_lwpsinfo_t_psinfo_t_sched_prov}
>
> -The `lwpsinfo_t` and `psinfo_t` structures are described in [Proc Provider](dtrace_providers_proc.md#).
> +The `lwpsinfo_t` and `psinfo_t` structures are described in [Proc Provider](dtrace_providers_proc.md).
>
> ### cpuinfo\_t {#dt_ref_cpuinfo_sched_prov}
>
> diff --git a/doc/userguide/reference/dtrace_runtime_options.md b/doc/userguide/reference/dtrace_runtime_options.md
> index b721f64e6..766709af2 100644
> --- a/doc/userguide/reference/dtrace_runtime_options.md
> +++ b/doc/userguide/reference/dtrace_runtime_options.md
> @@ -5,19 +5,19 @@ DTrace uses reasonable default values and flexible default policies for runtime
>
> Options that can be specified when running the `dtrace` utility can be categorized into three types:
>
> -- [Compile-time Options](compiler_options.md#): affect the compilation process but might also affect runtime behavior.
> +- [Compile-time Options](compiler_options.md): affect the compilation process but might also affect runtime behavior.
>
> -- [Runtime Options](runtime_options.md#): affect the runtime behavior of DTrace but which are often set at compile time.
> +- [Runtime Options](runtime_options.md): affect the runtime behavior of DTrace but which are often set at compile time.
>
> -- [Dynamic Runtime Options](dynamic_runtime_options.md#): affect the runtime behavior of DTrace but which can be changed while tracing, by using the `[setopt](function_setopt.md)` function.
> +- [Dynamic Runtime Options](dynamic_runtime_options.md): affect the runtime behavior of DTrace but which can be changed while tracing, by using the `[setopt](function_setopt.md)` function.
>
>
> -- **[Setting DTrace Compile-time and Runtime Options](../reference/setting_dtrace_compiler_and_runtime_options.md#)**
> +- **[Setting DTrace Compile-time and Runtime Options](../reference/setting_dtrace_compiler_and_runtime_options.md)**
> You can tune DTrace by setting or enabling a selection of runtime or compiler options. You can set options by either using the `-x` command line switch when running the `dtrace` command, or by specifying `pragma` lines in D programs. If an option takes a value, follow the option name with an equal sign \(`=`\) and the option value.
> -- **[Compile-time Options](../reference/compiler_options.md#)**
> +- **[Compile-time Options](../reference/compiler_options.md)**
> Compile-time options can control how DTrace programs are compiled into eBPF code that's loaded into kernel space.
> -- **[Runtime Options](../reference/runtime_options.md#)**
> +- **[Runtime Options](../reference/runtime_options.md)**
> Runtime options can control how the DTrace utility behaves.
> -- **[Dynamic Runtime Options](../reference/dynamic_runtime_options.md#)**
> +- **[Dynamic Runtime Options](../reference/dynamic_runtime_options.md)**
> Dynamic runtime options are specific to D programs themselves and are likely to change depending on program functionality and requirements.
>
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v2 08/20] doc: Fix anchor links for built-in variables
2025-10-22 3:22 [PATCH v2 05/20] doc: Replace duplicate id eugene.loh
2025-10-22 3:22 ` [PATCH v2 06/20] doc: Clean up dangling anchor links eugene.loh
@ 2025-10-22 3:22 ` eugene.loh
2025-10-23 19:26 ` Elena Zannoni
2025-10-22 3:22 ` [PATCH v2 09/20] doc: Fix anchor links for providers eugene.loh
` (13 subsequent siblings)
15 siblings, 1 reply; 28+ messages in thread
From: eugene.loh @ 2025-10-22 3:22 UTC (permalink / raw)
To: dtrace, dtrace-devel
From: Eugene Loh <eugene.loh@oracle.com>
Anchor links (links pointing to specific locations within files) are
broken, at least for viewing the Markdown version of the DTrace User
Guide on github from common browsers, in at least two respects:
*) The arcane ID names are displayed at the anchor sites.
*) The links do not point to the specific locations within the files.
The problem is that the {#ID} syntax is not recognized.
Replace the {#ID} tags with more universal HTML <a id="ID"> tags.
This patch addresses the documentation on built-in variables.
Signed-off-by: Eugene Loh <eugene.loh@oracle.com>
---
.../dtrace_builtin_variable_reference.md | 60 +++++++++----------
1 file changed, 30 insertions(+), 30 deletions(-)
diff --git a/doc/userguide/reference/dtrace_builtin_variable_reference.md b/doc/userguide/reference/dtrace_builtin_variable_reference.md
index 28b3001ae..787137929 100644
--- a/doc/userguide/reference/dtrace_builtin_variable_reference.md
+++ b/doc/userguide/reference/dtrace_builtin_variable_reference.md
@@ -1,9 +1,9 @@
-# DTrace Built-in Variable Reference {#dt_ref_builtin_vars}
+# DTrace Built-in Variable Reference <a id="dt_ref_builtin_vars">
DTrace includes a set of built-in scalar variables that can be used in D programs or scripts.
-## Macro Variables {#dt_macrov_scrpt}
+## Macro Variables <a id="dt_macrov_scrpt">
Macro variables are variables that are populated at runtime and identify information about the running `dtrace` process or the process running the compiler.
@@ -169,7 +169,7 @@ However, in probe descriptions, macro variables are expanded and concatenated wi
Macro variables are only expanded one time within each probe description field and they can't contain probe description delimiters \(`:`\).
-### Macro Arguments {#dt_macroa_scrpt}
+### Macro Arguments <a id="dt_macroa_scrpt">
The D compiler also provides a set of macro variables corresponding to any more argument operands that are specified as part of the `dtrace` command invocation. These *macro arguments* are accessed by using the built-in names `$0`, for the name of the D program file or `dtrace` command, `$1`, for the first extra operand, `$2` for the second operand, and so on. If you use the `-s` option, `$0` expands to the value of the name of the input file that's used with this option. For D programs that are specified on the command line, `$0` expands to the value of `argv[0]`, which is used to run the `dtrace` command itself.
@@ -243,7 +243,7 @@ To find the number of system calls made by the `date` command, save the script i
sudo dtrace -s syscall.d -c date
```
-## args\[\] {#dt_ref_vars_args}
+## args\[\] <a id="dt_ref_vars_args">
The typed and mapped arguments, if any, to the current probe. The `args[]` array is accessed using an integer index. Use `dtrace -l -v` and check `Argument Types` for the type of each argument of each probe. For example, consider the system call `prlimit()`. The prototype on its `man` page \(`man -s 2 prlimit`\) is consistent with its DTrace probe listing \(`dtrace -lvn 'syscall:vmlinux:prlimit*:entry' | grep args`\). Specifically, argument 2, if non NULL, points to a `struct rlimit` with the requested resource limit, which can be traced with:
@@ -255,7 +255,7 @@ syscall:vmlinux:prlimit*:entry
}
```
-## arg0, …, arg9 {#dt_ref_var_arg0-9}
+## arg0, …, arg9 <a id="dt_ref_var_arg0-9">
```
int64_t arg0, ..., arg9
@@ -271,7 +271,7 @@ rawfbt:vmlinux:ksys_write:entry
}
```
-## caller {#dt_ref_var_caller}
+## caller <a id="dt_ref_var_caller">
```
uintptr_t caller
@@ -279,7 +279,7 @@ uintptr_t caller
The built-in variable `caller` references the program counter location of the current kernel thread at the time the probe fired.
-## curcpu {#dt_ref_var_curcpu}
+## curcpu <a id="dt_ref_var_curcpu">
```
cpuinfo_t * curcpu
@@ -287,7 +287,7 @@ cpuinfo_t * curcpu
The built-in variable `curcpu` references the current physical CPU.
-## curthread {#dt_ref_var_curthread}
+## curthread <a id="dt_ref_var_curthread">
```
vmlinux`struct task_struct * curthread
@@ -295,7 +295,7 @@ vmlinux`struct task_struct * curthread
The built-in variable `curthread` references a `vmlinux` data type, for which members can be found by searching for "task\_struct" on the Internet.
-## epid {#dt_ref_var_epid}
+## epid <a id="dt_ref_var_epid">
```
uint_t epid
@@ -306,12 +306,12 @@ The built-in variable `epid` references the enabled probe ID \(EPID\) for the cu
## errno
```
-int errno {#dt_ref_var_errno}
+int errno <a id="dt_ref_var_errno">
```
The built-in variable `errno` references the error value returned by the last system call run by this thread.
-## execname {#dt_ref_var_execname}
+## execname <a id="dt_ref_var_execname">
```
string execname
@@ -319,7 +319,7 @@ string execname
The built-in variable `execname` references the name that was passed to `execve()` to run the current process.
-## fds {#dt_ref_var_fds}
+## fds <a id="dt_ref_var_fds">
```
fileinfo_t fds[]
@@ -327,7 +327,7 @@ fileinfo_t fds[]
The built-in `variable fds[]` is an array which has the files the current process has opened in a `fileinfo_t` array, indexed by file descriptor number. See [fileinfo\_t](dtrace_providers_io.md).
-## gid {#dt_ref_var_gid}
+## gid <a id="dt_ref_var_gid">
```
gid_t gid
@@ -335,7 +335,7 @@ gid_t gid
The built-in variable `gid` references the real group ID of the current process.
-## id {#dt_ref_var_id}
+## id <a id="dt_ref_var_id">
```
uint_t id
@@ -343,7 +343,7 @@ uint_t id
The built-in variable `id` references the probe ID for the current probe. This ID is the system-wide unique identifier for the probe, as published by DTrace and listed in the output of `dtrace -l`.
-## ipl {#dt_ref_var_ipl}
+## ipl <a id="dt_ref_var_ipl">
```
uint_t ipl
@@ -355,7 +355,7 @@ The built-in variable `ipl` references the interrupt priority level \(IPL\) on t
This value is non-zero if interrupts are firing and zero otherwise. The non-zero value depends on whether preemption is active, and other factors, and can vary between kernel releases and kernel configurations.
-## pid {#dt_ref_var_pid}
+## pid <a id="dt_ref_var_pid">
```
pid_t pid
@@ -363,7 +363,7 @@ pid_t pid
The built-in variable `pid` references the process ID of the current process.
-## ppid {#dt_ref_var_ppid}
+## ppid <a id="dt_ref_var_ppid">
```
pid_t ppid
@@ -371,7 +371,7 @@ pid_t ppid
The built-in variable `ppid` references the parent process ID of the current process.
-## probefunc {#dt_ref_var_probefunc}
+## probefunc <a id="dt_ref_var_probefunc">
```
string probefunc
@@ -379,7 +379,7 @@ string probefunc
The built-in variable `probefunc` references the function name part of the current probe's description.
-## probemod {#dt_ref_var_probemod}
+## probemod <a id="dt_ref_var_probemod">
```
string probemod
@@ -387,7 +387,7 @@ string probemod
The built-in variable `probemod` references the module name part of the current probe's description.
-## probename {#dt_ref_var_probename}
+## probename <a id="dt_ref_var_probename">
```
string probename
@@ -395,7 +395,7 @@ string probename
The built-in variable `probename` references the name part of the current probe's description.
-## probeprov {#dt_ref_var_probeprov}
+## probeprov <a id="dt_ref_var_probeprov">
```
string probeprov
@@ -403,7 +403,7 @@ string probeprov
The built-in variable `probeprov` references the provider name part of the current probe's description.
-## stackdepth {#dt_ref_var_stackdepth}
+## stackdepth <a id="dt_ref_var_stackdepth">
```
uint32_t stackdepth
@@ -411,7 +411,7 @@ uint32_t stackdepth
The built-in variable `stackdepth` references the current thread's stack frame depth at probe firing time.
-## tid {#dt_ref_var_tid}
+## tid <a id="dt_ref_var_tid">
```
id_t tid
@@ -419,7 +419,7 @@ id_t tid
The built-in variable `tid` references the thread ID of the current thread.
-## timestamp {#dt_ref_var_timestamp}
+## timestamp <a id="dt_ref_var_timestamp">
```
uint64_t timestamp
@@ -427,7 +427,7 @@ uint64_t timestamp
The built-in variable `timestamp` references the current value of a nanosecond timestamp counter. This counter increments from an arbitrary point in the past. Therefore, only use the timestamp counter for relative computations.
-## ucaller {#dt_ref_var_ucaller}
+## ucaller <a id="dt_ref_var_ucaller">
```
uint64_t ucaller
@@ -435,7 +435,7 @@ uint64_t ucaller
The built-in variable `ucaller` references the program counter location of the current user thread at the time the probe fired.
-## uid {#dt_ref_var_uid}
+## uid <a id="dt_ref_var_uid">
```
uid_t uid
@@ -443,7 +443,7 @@ uid_t uid
The built-in variable `uid` references the real user ID of the current process.
-## uregs {#dt_ref_var_uregs}
+## uregs <a id="dt_ref_var_uregs">
```
uint64_t uregs[]
@@ -451,7 +451,7 @@ uint64_t uregs[]
The current thread's saved user-mode register values at probe firing time.
-## ustackdepth {#dt_ref_var_ustackdepth}
+## ustackdepth <a id="dt_ref_var_ustackdepth">
```
uint32_t ustackdepth
@@ -459,7 +459,7 @@ uint32_t ustackdepth
The built-in variable `ustackdepth` references the user thread's stack frame depth at probe firing time.
-## vtimestamp {#dt_ref_var_vtimestamp}
+## vtimestamp <a id="dt_ref_var_vtimestamp">
```
uint64_t vtimestamp
@@ -467,7 +467,7 @@ uint64_t vtimestamp
The built-in variable `vtimestamp` references the current value of a nanosecond timestamp counter that's virtualized to the amount of time that the current thread has been running on a CPU, minus the time spent in DTrace predicates and functions. This counter increments from an arbitrary point in the past. Therefore, only use the vtimestamp counter for relative time computations.
-## walltimestamp {#dt_ref_var_walltimestamp}
+## walltimestamp <a id="dt_ref_var_walltimestamp">
```
int64_t walltimestamp
--
2.47.3
^ permalink raw reply related [flat|nested] 28+ messages in thread* Re: [PATCH v2 08/20] doc: Fix anchor links for built-in variables
2025-10-22 3:22 ` [PATCH v2 08/20] doc: Fix anchor links for built-in variables eugene.loh
@ 2025-10-23 19:26 ` Elena Zannoni
0 siblings, 0 replies; 28+ messages in thread
From: Elena Zannoni @ 2025-10-23 19:26 UTC (permalink / raw)
To: eugene.loh, dtrace, dtrace-devel
Reviewed-by: Elena Zannoni <elena.zannoni@oracle.com>
On 10/21/25 9:22 PM, eugene.loh@oracle.com wrote:
> From: Eugene Loh <eugene.loh@oracle.com>
>
> Anchor links (links pointing to specific locations within files) are
> broken, at least for viewing the Markdown version of the DTrace User
> Guide on github from common browsers, in at least two respects:
>
> *) The arcane ID names are displayed at the anchor sites.
>
> *) The links do not point to the specific locations within the files.
>
> The problem is that the {#ID} syntax is not recognized.
>
> Replace the {#ID} tags with more universal HTML <a id="ID"> tags.
>
> This patch addresses the documentation on built-in variables.
>
> Signed-off-by: Eugene Loh <eugene.loh@oracle.com>
> ---
> .../dtrace_builtin_variable_reference.md | 60 +++++++++----------
> 1 file changed, 30 insertions(+), 30 deletions(-)
>
> diff --git a/doc/userguide/reference/dtrace_builtin_variable_reference.md b/doc/userguide/reference/dtrace_builtin_variable_reference.md
> index 28b3001ae..787137929 100644
> --- a/doc/userguide/reference/dtrace_builtin_variable_reference.md
> +++ b/doc/userguide/reference/dtrace_builtin_variable_reference.md
> @@ -1,9 +1,9 @@
>
> -# DTrace Built-in Variable Reference {#dt_ref_builtin_vars}
> +# DTrace Built-in Variable Reference <a id="dt_ref_builtin_vars">
>
> DTrace includes a set of built-in scalar variables that can be used in D programs or scripts.
>
> -## Macro Variables {#dt_macrov_scrpt}
> +## Macro Variables <a id="dt_macrov_scrpt">
>
> Macro variables are variables that are populated at runtime and identify information about the running `dtrace` process or the process running the compiler.
>
> @@ -169,7 +169,7 @@ However, in probe descriptions, macro variables are expanded and concatenated wi
>
> Macro variables are only expanded one time within each probe description field and they can't contain probe description delimiters \(`:`\).
>
> -### Macro Arguments {#dt_macroa_scrpt}
> +### Macro Arguments <a id="dt_macroa_scrpt">
>
> The D compiler also provides a set of macro variables corresponding to any more argument operands that are specified as part of the `dtrace` command invocation. These *macro arguments* are accessed by using the built-in names `$0`, for the name of the D program file or `dtrace` command, `$1`, for the first extra operand, `$2` for the second operand, and so on. If you use the `-s` option, `$0` expands to the value of the name of the input file that's used with this option. For D programs that are specified on the command line, `$0` expands to the value of `argv[0]`, which is used to run the `dtrace` command itself.
>
> @@ -243,7 +243,7 @@ To find the number of system calls made by the `date` command, save the script i
> sudo dtrace -s syscall.d -c date
> ```
>
> -## args\[\] {#dt_ref_vars_args}
> +## args\[\] <a id="dt_ref_vars_args">
>
> The typed and mapped arguments, if any, to the current probe. The `args[]` array is accessed using an integer index. Use `dtrace -l -v` and check `Argument Types` for the type of each argument of each probe. For example, consider the system call `prlimit()`. The prototype on its `man` page \(`man -s 2 prlimit`\) is consistent with its DTrace probe listing \(`dtrace -lvn 'syscall:vmlinux:prlimit*:entry' | grep args`\). Specifically, argument 2, if non NULL, points to a `struct rlimit` with the requested resource limit, which can be traced with:
>
> @@ -255,7 +255,7 @@ syscall:vmlinux:prlimit*:entry
> }
> ```
>
> -## arg0, …, arg9 {#dt_ref_var_arg0-9}
> +## arg0, …, arg9 <a id="dt_ref_var_arg0-9">
>
> ```
> int64_t arg0, ..., arg9
> @@ -271,7 +271,7 @@ rawfbt:vmlinux:ksys_write:entry
> }
> ```
>
> -## caller {#dt_ref_var_caller}
> +## caller <a id="dt_ref_var_caller">
>
> ```
> uintptr_t caller
> @@ -279,7 +279,7 @@ uintptr_t caller
>
> The built-in variable `caller` references the program counter location of the current kernel thread at the time the probe fired.
>
> -## curcpu {#dt_ref_var_curcpu}
> +## curcpu <a id="dt_ref_var_curcpu">
>
> ```
> cpuinfo_t * curcpu
> @@ -287,7 +287,7 @@ cpuinfo_t * curcpu
>
> The built-in variable `curcpu` references the current physical CPU.
>
> -## curthread {#dt_ref_var_curthread}
> +## curthread <a id="dt_ref_var_curthread">
>
> ```
> vmlinux`struct task_struct * curthread
> @@ -295,7 +295,7 @@ vmlinux`struct task_struct * curthread
>
> The built-in variable `curthread` references a `vmlinux` data type, for which members can be found by searching for "task\_struct" on the Internet.
>
> -## epid {#dt_ref_var_epid}
> +## epid <a id="dt_ref_var_epid">
>
> ```
> uint_t epid
> @@ -306,12 +306,12 @@ The built-in variable `epid` references the enabled probe ID \(EPID\) for the cu
> ## errno
>
> ```
> -int errno {#dt_ref_var_errno}
> +int errno <a id="dt_ref_var_errno">
> ```
>
> The built-in variable `errno` references the error value returned by the last system call run by this thread.
>
> -## execname {#dt_ref_var_execname}
> +## execname <a id="dt_ref_var_execname">
>
> ```
> string execname
> @@ -319,7 +319,7 @@ string execname
>
> The built-in variable `execname` references the name that was passed to `execve()` to run the current process.
>
> -## fds {#dt_ref_var_fds}
> +## fds <a id="dt_ref_var_fds">
>
> ```
> fileinfo_t fds[]
> @@ -327,7 +327,7 @@ fileinfo_t fds[]
>
> The built-in `variable fds[]` is an array which has the files the current process has opened in a `fileinfo_t` array, indexed by file descriptor number. See [fileinfo\_t](dtrace_providers_io.md).
>
> -## gid {#dt_ref_var_gid}
> +## gid <a id="dt_ref_var_gid">
>
> ```
> gid_t gid
> @@ -335,7 +335,7 @@ gid_t gid
>
> The built-in variable `gid` references the real group ID of the current process.
>
> -## id {#dt_ref_var_id}
> +## id <a id="dt_ref_var_id">
>
> ```
> uint_t id
> @@ -343,7 +343,7 @@ uint_t id
>
> The built-in variable `id` references the probe ID for the current probe. This ID is the system-wide unique identifier for the probe, as published by DTrace and listed in the output of `dtrace -l`.
>
> -## ipl {#dt_ref_var_ipl}
> +## ipl <a id="dt_ref_var_ipl">
>
> ```
> uint_t ipl
> @@ -355,7 +355,7 @@ The built-in variable `ipl` references the interrupt priority level \(IPL\) on t
>
> This value is non-zero if interrupts are firing and zero otherwise. The non-zero value depends on whether preemption is active, and other factors, and can vary between kernel releases and kernel configurations.
>
> -## pid {#dt_ref_var_pid}
> +## pid <a id="dt_ref_var_pid">
>
> ```
> pid_t pid
> @@ -363,7 +363,7 @@ pid_t pid
>
> The built-in variable `pid` references the process ID of the current process.
>
> -## ppid {#dt_ref_var_ppid}
> +## ppid <a id="dt_ref_var_ppid">
>
> ```
> pid_t ppid
> @@ -371,7 +371,7 @@ pid_t ppid
>
> The built-in variable `ppid` references the parent process ID of the current process.
>
> -## probefunc {#dt_ref_var_probefunc}
> +## probefunc <a id="dt_ref_var_probefunc">
>
> ```
> string probefunc
> @@ -379,7 +379,7 @@ string probefunc
>
> The built-in variable `probefunc` references the function name part of the current probe's description.
>
> -## probemod {#dt_ref_var_probemod}
> +## probemod <a id="dt_ref_var_probemod">
>
> ```
> string probemod
> @@ -387,7 +387,7 @@ string probemod
>
> The built-in variable `probemod` references the module name part of the current probe's description.
>
> -## probename {#dt_ref_var_probename}
> +## probename <a id="dt_ref_var_probename">
>
> ```
> string probename
> @@ -395,7 +395,7 @@ string probename
>
> The built-in variable `probename` references the name part of the current probe's description.
>
> -## probeprov {#dt_ref_var_probeprov}
> +## probeprov <a id="dt_ref_var_probeprov">
>
> ```
> string probeprov
> @@ -403,7 +403,7 @@ string probeprov
>
> The built-in variable `probeprov` references the provider name part of the current probe's description.
>
> -## stackdepth {#dt_ref_var_stackdepth}
> +## stackdepth <a id="dt_ref_var_stackdepth">
>
> ```
> uint32_t stackdepth
> @@ -411,7 +411,7 @@ uint32_t stackdepth
>
> The built-in variable `stackdepth` references the current thread's stack frame depth at probe firing time.
>
> -## tid {#dt_ref_var_tid}
> +## tid <a id="dt_ref_var_tid">
>
> ```
> id_t tid
> @@ -419,7 +419,7 @@ id_t tid
>
> The built-in variable `tid` references the thread ID of the current thread.
>
> -## timestamp {#dt_ref_var_timestamp}
> +## timestamp <a id="dt_ref_var_timestamp">
>
> ```
> uint64_t timestamp
> @@ -427,7 +427,7 @@ uint64_t timestamp
>
> The built-in variable `timestamp` references the current value of a nanosecond timestamp counter. This counter increments from an arbitrary point in the past. Therefore, only use the timestamp counter for relative computations.
>
> -## ucaller {#dt_ref_var_ucaller}
> +## ucaller <a id="dt_ref_var_ucaller">
>
> ```
> uint64_t ucaller
> @@ -435,7 +435,7 @@ uint64_t ucaller
>
> The built-in variable `ucaller` references the program counter location of the current user thread at the time the probe fired.
>
> -## uid {#dt_ref_var_uid}
> +## uid <a id="dt_ref_var_uid">
>
> ```
> uid_t uid
> @@ -443,7 +443,7 @@ uid_t uid
>
> The built-in variable `uid` references the real user ID of the current process.
>
> -## uregs {#dt_ref_var_uregs}
> +## uregs <a id="dt_ref_var_uregs">
>
> ```
> uint64_t uregs[]
> @@ -451,7 +451,7 @@ uint64_t uregs[]
>
> The current thread's saved user-mode register values at probe firing time.
>
> -## ustackdepth {#dt_ref_var_ustackdepth}
> +## ustackdepth <a id="dt_ref_var_ustackdepth">
>
> ```
> uint32_t ustackdepth
> @@ -459,7 +459,7 @@ uint32_t ustackdepth
>
> The built-in variable `ustackdepth` references the user thread's stack frame depth at probe firing time.
>
> -## vtimestamp {#dt_ref_var_vtimestamp}
> +## vtimestamp <a id="dt_ref_var_vtimestamp">
>
> ```
> uint64_t vtimestamp
> @@ -467,7 +467,7 @@ uint64_t vtimestamp
>
> The built-in variable `vtimestamp` references the current value of a nanosecond timestamp counter that's virtualized to the amount of time that the current thread has been running on a CPU, minus the time spent in DTrace predicates and functions. This counter increments from an arbitrary point in the past. Therefore, only use the vtimestamp counter for relative time computations.
>
> -## walltimestamp {#dt_ref_var_walltimestamp}
> +## walltimestamp <a id="dt_ref_var_walltimestamp">
>
> ```
> int64_t walltimestamp
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v2 09/20] doc: Fix anchor links for providers
2025-10-22 3:22 [PATCH v2 05/20] doc: Replace duplicate id eugene.loh
2025-10-22 3:22 ` [PATCH v2 06/20] doc: Clean up dangling anchor links eugene.loh
2025-10-22 3:22 ` [PATCH v2 08/20] doc: Fix anchor links for built-in variables eugene.loh
@ 2025-10-22 3:22 ` eugene.loh
2025-10-23 19:27 ` [DTrace-devel] " Elena Zannoni
2025-10-22 3:22 ` [PATCH v2 10/20] doc: Fix anchor links for explanation/ eugene.loh
` (12 subsequent siblings)
15 siblings, 1 reply; 28+ messages in thread
From: eugene.loh @ 2025-10-22 3:22 UTC (permalink / raw)
To: dtrace, dtrace-devel
From: Eugene Loh <eugene.loh@oracle.com>
Signed-off-by: Eugene Loh <eugene.loh@oracle.com>
---
...StaticallyDefinedTracingofUserApplications.md | 10 +++++-----
doc/userguide/reference/dtrace_providers_cpc.md | 10 +++++-----
.../reference/dtrace_providers_dtrace.md | 10 +++++-----
doc/userguide/reference/dtrace_providers_fbt.md | 10 +++++-----
doc/userguide/reference/dtrace_providers_io.md | 16 ++++++++--------
.../reference/dtrace_providers_lockstat.md | 10 +++++-----
doc/userguide/reference/dtrace_providers_pid.md | 10 +++++-----
doc/userguide/reference/dtrace_providers_proc.md | 14 +++++++-------
.../reference/dtrace_providers_profile.md | 12 ++++++------
.../reference/dtrace_providers_rawtp.md | 4 ++--
.../reference/dtrace_providers_sched.md | 14 +++++++-------
doc/userguide/reference/dtrace_providers_sdt.md | 10 +++++-----
.../reference/dtrace_providers_syscall.md | 8 ++++----
13 files changed, 69 insertions(+), 69 deletions(-)
diff --git a/doc/userguide/reference/dtrace-ref-StaticallyDefinedTracingofUserApplications.md b/doc/userguide/reference/dtrace-ref-StaticallyDefinedTracingofUserApplications.md
index 7548bad83..e8298dea8 100644
--- a/doc/userguide/reference/dtrace-ref-StaticallyDefinedTracingofUserApplications.md
+++ b/doc/userguide/reference/dtrace-ref-StaticallyDefinedTracingofUserApplications.md
@@ -1,5 +1,5 @@
-# USDT Provider {#dt_ref_usdt_prov}
+# USDT Provider <a id="dt_ref_usdt_prov">
Use the USDT provider, for user space statically defined tracing, to instrument user space code with probes that are meaningful for an application.
@@ -9,7 +9,7 @@ USDT is for user space processes. For kernel modules, statically defined tracing
**Parent topic:**[DTrace Provider Reference](../reference/dtrace_providers.md)
-## Defining USDT Providers and Probes {#dt_ref_usdtprobes_prov}
+## Defining USDT Providers and Probes <a id="dt_ref_usdtprobes_prov">
Define USDT providers and probes in a `.d` file that you add to the source code. For example, a file `myproviders.d` contains:
@@ -37,7 +37,7 @@ The following example traces all processes with `myprov` probes, even if they ha
sudo dtrace -Z -n 'myprov*:::my-put { printf("put %d %d\n", arg0, arg1); }'
```
-## Adding USDT Probes to Application Code {#dt_ref_usdt_probe_add_prov}
+## Adding USDT Probes to Application Code <a id="dt_ref_usdt_probe_add_prov">
Consider this C code `func.c`:
@@ -66,7 +66,7 @@ You can place probes in the code, referring to the probes by using the macros, w
An optional optimization is to test if a probe is enabled. While the computational overhead of a disabled DTrace probe is often similar to a few no-op instructions, setting up probe arguments can be expensive. In this example, `bar(1111)` and `bar(2222)`might be costly function calls. Therefore, for each probe, DTrace also supplies an `is-enabled` macro, named by appending `_ENABLED`. In the example, `MYPROV_MY_PUT_ENABLED()` for the `my-put` probe, to help minimize the cost of any work associated with disabled probes.
-## Building Applications With USDT Probes {#dt_ref_usdt_build_prov}
+## Building Applications With USDT Probes <a id="dt_ref_usdt_build_prov">
The `dtrace` command becomes part of the build procedure, which can be thought of in four parts:
@@ -101,7 +101,7 @@ The `dtrace` command becomes part of the build procedure, which can be thought o
```
-## USDT Examples {#dt_ref_usdtexamples_prov}
+## USDT Examples <a id="dt_ref_usdtexamples_prov">
1. Create a file `myproviders.d` that contains:
diff --git a/doc/userguide/reference/dtrace_providers_cpc.md b/doc/userguide/reference/dtrace_providers_cpc.md
index 39b2ca6f5..742fd001b 100644
--- a/doc/userguide/reference/dtrace_providers_cpc.md
+++ b/doc/userguide/reference/dtrace_providers_cpc.md
@@ -1,5 +1,5 @@
-# CPC Provider {#dt_ref_cpc_prov}
+# CPC Provider <a id="dt_ref_cpc_prov">
The CPU performance counter \(`cpc`\) provider makes available probes that are associated with CPU performance counter events.
@@ -11,7 +11,7 @@ Start with higher event counter values for CPC probes and reduce them through tr
**Parent topic:**[DTrace Provider Reference](../reference/dtrace_providers.md)
-## cpc Probes {#dt_ref_cpcprobes_prov}
+## cpc Probes <a id="dt_ref_cpcprobes_prov">
Probes made available by the `cpc` provider have the following probe description format:
@@ -29,7 +29,7 @@ The definitions of the components of the probe name are listed in table.
Note that when you list CPC probes, example count values are provided in the probe listings. The count values are artificially set high as a guideline.
-## cpc Probe Arguments {#dt_ref_cpcargs_prov}
+## cpc Probe Arguments <a id="dt_ref_cpcargs_prov">
The following table lists the argument types for the `cpc` probes.
@@ -40,7 +40,7 @@ The following table lists the argument types for the `cpc` probes.
As the descriptions imply, if `arg0` is non-zero then `arg1` is zero; if `arg0` is zero then `arg1` is non-zero.
-## cpc Examples {#dt_ref_cpcexamples_prov}
+## cpc Examples <a id="dt_ref_cpcexamples_prov">
The following example illustrates the use of a probe published by the `cpc` provider.
@@ -56,7 +56,7 @@ cpc:::cycles-all-50000000
```
-## cpc Stability {#dt_ref_cpcstab_prov}
+## cpc Stability <a id="dt_ref_cpcstab_prov">
The `cpc` provider uses DTrace's stability mechanism to describe its stabilities. These values are listed in the following table.
diff --git a/doc/userguide/reference/dtrace_providers_dtrace.md b/doc/userguide/reference/dtrace_providers_dtrace.md
index ef62c5040..cfe485848 100644
--- a/doc/userguide/reference/dtrace_providers_dtrace.md
+++ b/doc/userguide/reference/dtrace_providers_dtrace.md
@@ -1,5 +1,5 @@
-# DTrace Provider {#dt_ref_dt_prov}
+# DTrace Provider <a id="dt_ref_dt_prov">
The `dtrace` provider includes several probes that are specific to DTrace itself.
@@ -7,7 +7,7 @@ Use these probes to initialize state before tracing begins, process state after
**Parent topic:**[DTrace Provider Reference](../reference/dtrace_providers.md)
-## BEGIN Probe {#dt_ref_begin_prov}
+## BEGIN Probe <a id="dt_ref_begin_prov">
The `BEGIN` probe fires before any other probe.
@@ -34,7 +34,7 @@ syscall::mmap:entry
The `BEGIN` probe fires in an unspecified context, which means the output of `stack` or `ustack`, and the value of context-specific variables such as `execname`, are all arbitrary. These values should not be relied upon or interpreted to infer any meaningful information. No arguments are defined for the `BEGIN` probe.
-## END Probe {#dt_ref_end_prov}
+## END Probe <a id="dt_ref_end_prov">
The `END` probe fires after all other probes.
@@ -64,7 +64,7 @@ As with the `BEGIN` probe, no arguments are defined for the `END` probe. The con
The `[exit](function_exit.md)` function causes tracing to stop and the `END` probe to fire. However, a delay exists between the invocation of the `exit` function and when the `END` probe fires. During this delay, no further probes can fire. After a probe invokes the `exit` function, the `END` probe isn't fired until DTrace determines that `exit` has been called and stops tracing. The rate at which the exit status is checked can be set by using `statusrate` option.
-## ERROR Probe {#dt_ref_error_prov}
+## ERROR Probe <a id="dt_ref_error_prov">
The `ERROR` probe fires when a runtime error occurs during the processing of a clause for a DTrace probe.
@@ -311,7 +311,7 @@ None.
</td></tr><tbody></table>
If the actions that are taken in the `ERROR` probe cause an error, that error is silently dropped. The `ERROR` probe isn't recursively invoked.
-## dtrace Stability {#dt_ref_dtstability_prov}
+## dtrace Stability <a id="dt_ref_dtstability_prov">
The `dtrace` provider uses DTrace's stability mechanism to describe its stabilities. These values are listed in the following table.
diff --git a/doc/userguide/reference/dtrace_providers_fbt.md b/doc/userguide/reference/dtrace_providers_fbt.md
index 885d59230..295a21d83 100644
--- a/doc/userguide/reference/dtrace_providers_fbt.md
+++ b/doc/userguide/reference/dtrace_providers_fbt.md
@@ -1,5 +1,5 @@
-# FBT Provider {#dt_ref_fbt_prov}
+# FBT Provider <a id="dt_ref_fbt_prov">
The `fbt` \(Function Boundary Tracing\) provider includes probes that are associated with the entry to and return from most functions in the Linux kernel. Therefore, there could be tens of thousands of `fbt` probes.
@@ -15,17 +15,17 @@ Because of the large number of FPB probes that are available, be specific about
**Parent topic:**[DTrace Provider Reference](../reference/dtrace_providers.md)
-## fbt Probes {#dt_ref_fbtprobes_prov}
+## fbt Probes <a id="dt_ref_fbtprobes_prov">
FBT provides an `entry` probe and a `return` probe for most functions in the kernel.
-## fbt Probe Arguments {#dt_ref_fbtargs_prov}
+## fbt Probe Arguments <a id="dt_ref_fbtargs_prov">
The arguments to `entry` probes are the same as the arguments to the corresponding operating system kernel function. These arguments can be accessed as `int64_t` values by using the `arg0`, `arg1`, `arg2`, ... variables.
If the function has a return value, the return value is stored in `arg1` of the `return` probe. If a function doesn't have a return value, `arg1` isn't defined.
-## fbt Examples {#dt_ref_fbtexamples_prov}
+## fbt Examples <a id="dt_ref_fbtexamples_prov">
You can use the `fbt` provider to explore the kernel's implementation. The following example script creates an aggregation on the number of times different functions allocate kernel virtual memory. The results of the aggregation are printed when the script exits. This would help somebody to monitor what functions are memory intensive. Type the following D source code and save it in a file named `getkmemalloc.d`:
@@ -74,7 +74,7 @@ Running this script results in output similar to the following:
The output shows the internal kernel functions that are making calls to the `kmem*alloc` system calls and can be used to find which kernel functions most often allocate kernel virtual memory on a system.
-## fbt Stability {#dt_ref_fbtstab_prov}
+## fbt Stability <a id="dt_ref_fbtstab_prov">
The `fbt` provider uses DTrace's stability mechanism to describe its stabilities. These stability values are listed in the following table.
diff --git a/doc/userguide/reference/dtrace_providers_io.md b/doc/userguide/reference/dtrace_providers_io.md
index a458ab284..40851042c 100644
--- a/doc/userguide/reference/dtrace_providers_io.md
+++ b/doc/userguide/reference/dtrace_providers_io.md
@@ -1,5 +1,5 @@
-# IO Provider {#dt_ref_io_prov}
+# IO Provider <a id="dt_ref_io_prov">
The `io` provider makes available probes that relate to data input and output.
@@ -7,7 +7,7 @@ For example, you can use the `io` provider to understand I/O by device, I/O type
**Parent topic:**[DTrace Provider Reference](../reference/dtrace_providers.md)
-## io Probes {#dt_ref_ioprobes_prov}
+## io Probes <a id="dt_ref_ioprobes_prov">
The following table describes the probes for the `io` provider. For all `io` probes, the module is `vmlinux` and the function is an empty string.
@@ -54,7 +54,7 @@ Fires when a thread finishes waiting for the completion of an I/O request. The `
</td></tr><tbody></table>
The `io` probes fire for all I/O requests to peripheral devices, and for all file read and file write requests to an NFS server. Requests for metadata from an NFS server, for example, don't trigger `io` probes because of a `readdir()` request.
-## io Probe Arguments {#dt_ref_ioargs_prov}
+## io Probe Arguments <a id="dt_ref_ioargs_prov">
The following table describes the arguments for the `io` probes. The `argN` are implementation specific. Use `args[]` to access the probe arguments.
@@ -143,7 +143,7 @@ Probe
DTrace doesn't provide the option to use `fileinfo_t` with `io` probes. In Linux, no information is accessible at the level where the `io` probes fire about the file where an I/O request originated.
-### bufinfo\_t {#dt_ref_iobuf_prov}
+### bufinfo\_t <a id="dt_ref_iobuf_prov">
The `bufinfo_t` structure is the abstraction that describes an I/O request. The buffer that corresponds to an I/O request is pointed to by `args[0]` in the `start`, `done`, `wait-start`, and `wait-done` probes. Detailed information about this data structure can be found in `/usr/lib64/dtrace/*version*/io.d`. The definition of `bufinfo_t` is as follows:
@@ -289,7 +289,7 @@ Indicates that the data is to be transferred from main memory to the peripheral
`b_edev`: Contains the major and minor device numbers of the device accessed. You can use the D subroutines `getmajor` and `getminor` to extract the major and minor device numbers from the `b_edev` field.
-### devinfo\_t {#dt_ref_iodev_prov}
+### devinfo\_t <a id="dt_ref_iodev_prov">
The `devinfo_t` structure provides information about a device. The `devinfo_t` structure that corresponds to the destination device of an I/O is pointed to by `args[1]` in the `start`, `done`, `wait-start`, and `wait-done` probes. Detailed information about this data structure can be found in `/usr/lib64/dtrace/*version*/io.d`. The definition of `devinfo_t` is as follows:
@@ -318,7 +318,7 @@ DTrace translates the members of `devinfo_t` from the `buffer_head` for the Linu
`dev_pathname`: Is the full path of the device. The path that's specified by `dev_pathname` includes components expressing the device node, the instance number, and the minor node. However, note that all three of these elements aren't necessarily expressed in the statistics name. For some devices, the statistics name consists of the device name and the instance number. For other devices, the name consists of the device name and the number of the minor node. So, two devices that have the same `dev_statname` migh differ in their `dev_pathname`.
-### fileinfo\_t {#dt_ref_iofile_prov}
+### fileinfo\_t <a id="dt_ref_iofile_prov">
**Note:**
@@ -352,7 +352,7 @@ The `fi_fs` field contains the name of the file system type, or `<none>`, if no
The `fi_oflags` field contains the flags that were specified when opening the file.
-## io Examples {#dt_ref_ioexamples_prov}
+## io Examples <a id="dt_ref_ioexamples_prov">
The following example script displays information for every I/O as it's issued. Type the following source code and save it in a file named `iosnoop.d`.
@@ -517,7 +517,7 @@ sdc1 (/dev/sdc1)
The previous output shows that the USB drive \(`sdc1`\) is clearly the limiting device. The throughput of `sdc1` is between 256K/sec and 512K/sec, while `dm-00` delivered I/O at anywhere from 8 MB/second to over 64 MB/second.
-## io Stability {#dt_ref_iostab_prov}
+## io Stability <a id="dt_ref_iostab_prov">
The `io` provider uses DTrace's stability mechanism to describe its stabilities. These values are listed in the following table.
diff --git a/doc/userguide/reference/dtrace_providers_lockstat.md b/doc/userguide/reference/dtrace_providers_lockstat.md
index 98affd838..c1d3eb4de 100644
--- a/doc/userguide/reference/dtrace_providers_lockstat.md
+++ b/doc/userguide/reference/dtrace_providers_lockstat.md
@@ -1,11 +1,11 @@
-# Lockstat Provider {#dt_ref_lockstat_prov}
+# Lockstat Provider <a id="dt_ref_lockstat_prov">
The `lockstat` provider provides probes that can be used to study lock usage and contention.
**Parent topic:**[DTrace Provider Reference](../reference/dtrace_providers.md)
-## lockstat Probes {#dt_ref_lockstatprobes_prov}
+## lockstat Probes <a id="dt_ref_lockstatprobes_prov">
For all `lockstat` probes, the module name is `vmlinux` and the function name is an empty string.
@@ -44,7 +44,7 @@ The following probe fires before a lock is acquired if there was contention for
Finally, an `adaptive-acquire-error` probe indicates an error acquiring an adaptive lock.
-## lockstat Probe Arguments {#dt_ref_lockstatargs_prov}
+## lockstat Probe Arguments <a id="dt_ref_lockstatargs_prov">
The following table lists the argument types for the `lockstat` probes. The `argN` are implementation specific. Use `args[]` to access the probe arguments.
@@ -245,7 +245,7 @@ Probe
`args[0]` has a pointer to the lock in question. The probes that fire in case of contention report a `uint64_t` `args[1]`, which is the wait time in nanoseconds. The `rw` probes also report an `int` that's either `RW_READER` or `RW_WRITER`. Finally, `adaptive-acquire-error` reports an `int` with a non zero error.
-## lockstat Examples {#dt_ref_lockstatexamples_prov}
+## lockstat Examples <a id="dt_ref_lockstatexamples_prov">
The following examples illustrate the use of the probes that are published by the `lockstat` provider.
@@ -271,7 +271,7 @@ Run the program on the `date` command using `sudo dtrace -qs whatlock.d -c date`
It might be surprising that so many locks are acquired with the `date` command. The large number of locks is a natural artifact of the fine-grained locking required of a scalable system such as the Linux kernel.
-## lockstat Stability {#dt_ref_lockstatstab_prov}
+## lockstat Stability <a id="dt_ref_lockstatstab_prov">
The `lockstat` provider uses DTrace's stability mechanism to describe its stabilities. These values are listed in the following table.
diff --git a/doc/userguide/reference/dtrace_providers_pid.md b/doc/userguide/reference/dtrace_providers_pid.md
index c0c7bbb9a..184f2c081 100644
--- a/doc/userguide/reference/dtrace_providers_pid.md
+++ b/doc/userguide/reference/dtrace_providers_pid.md
@@ -1,11 +1,11 @@
-# Pid Provider {#dt_ref_pid_prov}
+# Pid Provider <a id="dt_ref_pid_prov">
The `pid` provider traces a user process, both function `entry` and `return`, and an arbitrary instruction.
**Parent topic:**[DTrace Provider Reference](../reference/dtrace_providers.md)
-## pid Probes {#dt_ref_pidprobes_prov}
+## pid Probes <a id="dt_ref_pidprobes_prov">
A probe is fully specified by naming its provider, module, function, and name.
@@ -52,7 +52,7 @@ The probe name is one of:
- An instruction offset. The hexadecimal offset, without a leading `0x`, is relative to the named function, but it's an absolute offset when the function name is `-`.
-## pid Probe Arguments {#dt_ref_pidargs_prov}
+## pid Probe Arguments <a id="dt_ref_pidargs_prov">
For `entry` probes, the probe arguments are the same arguments as those of the probed function.
@@ -60,7 +60,7 @@ For `return` probes, `arg1` is the return value of the probed function.
For offset probes, there are no probe arguments.
-## pid Examples {#dt_ref_pidexamples_prov}
+## pid Examples <a id="dt_ref_pidexamples_prov">
Consider the following program, named `main.c`, that calls a function `foo()`:
@@ -173,7 +173,7 @@ The output looks similar to:
We probe on the chosen instruction, using both a relative offset `foo:4`, and an absolute offset `-:40110a`. Both probes fire, both reporting the same PC `0x40110a`.
-## pid Stability {#dt_ref_pidstab_prov}
+## pid Stability <a id="dt_ref_pidstab_prov">
The `pid` provider uses DTrace's stability mechanism to describe its stabilities. These values are listed in the following table.
diff --git a/doc/userguide/reference/dtrace_providers_proc.md b/doc/userguide/reference/dtrace_providers_proc.md
index 6c1fa8ecf..cf64bc28f 100644
--- a/doc/userguide/reference/dtrace_providers_proc.md
+++ b/doc/userguide/reference/dtrace_providers_proc.md
@@ -1,5 +1,5 @@
-# Proc Provider {#dt_ref_proc_prov}
+# Proc Provider <a id="dt_ref_proc_prov">
The `proc` provider makes available the probes that pertain to the following activities: process creation and termination, LWP creation and termination, execution of new program images, and signal sending and handling.
@@ -7,7 +7,7 @@ The `proc` provider makes available the probes that pertain to the following act
**Parent topic:**[DTrace Provider Reference](../reference/dtrace_providers.md)
-## proc Probes {#dt_ref_procprobes_prov}
+## proc Probes <a id="dt_ref_procprobes_prov">
The probes for the `proc` provider are listed in the following table.
@@ -128,7 +128,7 @@ Fires in the context of a newly created process. The `start` probe fires before
No fundamental difference between a process and a thread that a process creates, exists in Linux. The threads of a process are set up so that they can share resources, but each thread has its own entry in the process table with its own process ID.
-## proc Probe Arguments {#dt_ref_procargs_prov}
+## proc Probe Arguments <a id="dt_ref_procargs_prov">
The following table lists the argument types for the `proc` probes. See [proc Probes](dtrace_providers_proc.md) for a description of the arguments. The `argN` are implementation specific. Use `args[]` to access the probe arguments.
@@ -357,7 +357,7 @@ Probe
—
</td></tr><tbody></table>
-### lwpsinfo\_t {#dt_ref_lwpsinfoproc_prov}
+### lwpsinfo\_t <a id="dt_ref_lwpsinfoproc_prov">
Several `proc` probes have arguments of type `lwpsinfo_t`. Detailed information about this data structure can be found in `/usr/lib64/dtrace/*version*/procfs.d`. Some structure members, while still recognized for historical reasons, aren't implemented. The definition of the `lwpsinfo_t` structure is as follows:
@@ -475,7 +475,7 @@ The thread is a zombie.
The equivalent Linux task state is `EXIT_ZOMBIE`, `EXIT_DEAD`, or `TASK_DEAD`.
</td></tr><tbody></table>
-### psinfo\_t {#dt_ref_procpsinfo_prov}
+### psinfo\_t <a id="dt_ref_procpsinfo_prov">
Several `proc` probes have an argument of type `psinfo_t`. Detailed information about this data structure can be found in `/usr/lib64/dtrace/*version*/procfs.d`. The definition of the `psinfo_t` structure, is as follows:
@@ -527,7 +527,7 @@ Lightweight processes don't exist in Linux. In Linux, processes and threads are
`pr_dmodel` is set to either `PR_MODEL_ILP32`, denoting a 32–bit process, or `PR_MODEL_LP64`, denoting a 64–bit process.
-## proc Examples {#dt_ref_procexamples_prov}
+## proc Examples <a id="dt_ref_procexamples_prov">
The following examples illustrate the use of the probes that are published by the `proc` provider.
@@ -691,7 +691,7 @@ Running this script results in output similar to the following:
swapper/6 pmlogger 14 1
```
-## proc Stability {#dt_ref_procstab_prov}
+## proc Stability <a id="dt_ref_procstab_prov">
The `proc` provider uses DTrace's stability mechanism to describe its stabilities. These values are listed in the following table.
diff --git a/doc/userguide/reference/dtrace_providers_profile.md b/doc/userguide/reference/dtrace_providers_profile.md
index bcc8c64d2..da83e8561 100644
--- a/doc/userguide/reference/dtrace_providers_profile.md
+++ b/doc/userguide/reference/dtrace_providers_profile.md
@@ -1,5 +1,5 @@
-# Profile Provider {#dt_ref_profile_prov}
+# Profile Provider <a id="dt_ref_profile_prov">
The `profile` provider includes probes that are associated with an interrupt that fires at some regular, specified time interval.
@@ -7,7 +7,7 @@ Such probes aren't associated with any particular point of execution, but rather
**Parent topic:**[DTrace Provider Reference](../reference/dtrace_providers.md)
-## profile-*n* Probes {#dt_ref_profile-n_prov}
+## profile-*n* Probes <a id="dt_ref_profile-n_prov">
The `profile-*n*` probes fire at a fixed interval, at a high-interrupt level on all active CPUs.
@@ -86,7 +86,7 @@ days
hertz \(frequency expressed as rate per second\)
</td></tr><tbody></table>
-## tick-*n* Probes {#dt_ref_profile-tick-n_prov}
+## tick-*n* Probes <a id="dt_ref_profile-tick-n_prov">
The `tick-*n*` probes fire at fixed intervals, at a high interrupt level on only one CPU per interval.
@@ -98,7 +98,7 @@ The `tick-*n*` probes have several uses, such as providing some periodic output
The highest available tick frequency is 5000 Hz \(`tick-5000`\).
-## profile Probe Arguments {#dt_ref_profargs_prov}
+## profile Probe Arguments <a id="dt_ref_profargs_prov">
The following table describes the arguments for the `profile` probes.
@@ -146,13 +146,13 @@ The arguments are as follows:
- `upc`: user-space program counter
-## profile Probe Creation {#dt_ref_profprobecreate_prov}
+## profile Probe Creation <a id="dt_ref_profprobecreate_prov">
Unlike other providers, the `profile` provider creates probes dynamically on an as-needed basis. Thus, the preferred probe might not appear in a listing of all probes, for example, when using the `dtrace -l -P profile` command, but the probe is created when it's explicitly enabled.
A time interval that's too short causes the machine to continuously field time-based interrupts and denies service on the machine. The `profile` provider refuses to create a probe that would result in an interval of less than two hundred microseconds and returns an error.
-## prof Stability {#dt_ref_profstab_prov}
+## prof Stability <a id="dt_ref_profstab_prov">
The `profile` provider uses DTrace's stability mechanism to describe its stabilities. These stability values are listed in the following table.
diff --git a/doc/userguide/reference/dtrace_providers_rawtp.md b/doc/userguide/reference/dtrace_providers_rawtp.md
index d85dd45a8..67cb0bedc 100644
--- a/doc/userguide/reference/dtrace_providers_rawtp.md
+++ b/doc/userguide/reference/dtrace_providers_rawtp.md
@@ -1,5 +1,5 @@
-# Rawtp Provider {#dt_ref_rawtp_prov}
+# Rawtp Provider <a id="dt_ref_rawtp_prov">
The `rawtp` provider gives DTrace users access to the raw tracepoints exposed by the kernel tracing system, including access to the untranslated arguments of the associated tracepoint events.
@@ -17,7 +17,7 @@ sudo dtrace -lvP rawtp
**Parent topic:**[DTrace Provider Reference](../reference/dtrace_providers.md)
-## rawtp Stability {#dt_ref_rawtpstab_prov}
+## rawtp Stability <a id="dt_ref_rawtpstab_prov">
The `rawtp` provider uses DTrace's stability mechanism to describe its stabilities. These stability values are listed in the following table.
diff --git a/doc/userguide/reference/dtrace_providers_sched.md b/doc/userguide/reference/dtrace_providers_sched.md
index f6d183708..42f318e77 100644
--- a/doc/userguide/reference/dtrace_providers_sched.md
+++ b/doc/userguide/reference/dtrace_providers_sched.md
@@ -1,5 +1,5 @@
-# Sched Provider {#dt_ref_sched_prov}
+# Sched Provider <a id="dt_ref_sched_prov">
The `sched` provider makes available probes related to CPU scheduling.
@@ -7,7 +7,7 @@ Because CPUs are the one resource that all threads must consume, the `sched` pro
**Parent topic:**[DTrace Provider Reference](../reference/dtrace_providers.md)
-## sched Probes {#dt_ref_schedprob_prov}
+## sched Probes <a id="dt_ref_schedprob_prov">
The probes for the `sched` provider are listed in the following table. For all `sched` probes, the module is `vmlinux` and the function is an empty string.
@@ -76,7 +76,7 @@ Fires as a part of clock tick-based accounting. In clock tick-based accounting,
Fires immediately before the current thread wakes a thread sleeping on a synchronization object. Here, `args[0]` and `args[1]` refer to the sleeping thread, as an `lwpsinfo_t *` and `psinfo_t *`, respectively. The type and address of the synchronization object are contained in the `pr_stype` and `pr_wchan` members of the `lwpsinfo_t` of the sleeping thread. The meaning of this address is a private implementation detail, but the address value might be treated as a token unique to the synchronization object.
</td></tr><tbody></table>
-## sched Probe Arguments {#dt_ref_schedargs_prov}
+## sched Probe Arguments <a id="dt_ref_schedargs_prov">
Many of these probes refer to a particular thread. For these probes, the thread's `lwpsinfo_t` is pointed to by `args[0]` and the `psinfo_t` of the process containing the thread by `args[1]`. A few probes refer to a particular CPU. Its `cpuinfo_t` is pointed to by `args[2]`. Only `enqueue` has an `args[3]`, and that argument is a Boolean, as described. The `argN` values are implementation specific. Instead, use `args[]` to access the probe arguments.
@@ -243,11 +243,11 @@ Probe
—
</td></tr><tbody></table>
-### lwpsinfo\_t and psinfo\_t {#dt_ref_lwpsinfo_t_psinfo_t_sched_prov}
+### lwpsinfo\_t and psinfo\_t <a id="dt_ref_lwpsinfo_t_psinfo_t_sched_prov">
The `lwpsinfo_t` and `psinfo_t` structures are described in [Proc Provider](dtrace_providers_proc.md).
-### cpuinfo\_t {#dt_ref_cpuinfo_sched_prov}
+### cpuinfo\_t <a id="dt_ref_cpuinfo_sched_prov">
The `cpuinfo_t` structure defines a CPU. The `args[2]` arguments for the `enqueue` and `dequeue` probes point to the `cpuinfo_t` for the CPU associated with the run queue, which is sometimes different from the current CPU, whose `cpuinfo_t` is pointed to by the `curcpu` variable.
@@ -262,7 +262,7 @@ typedef struct cpuinfo {
} cpuinfo_t;
```
-## sched Examples {#dt_ref_schedexamples_prov}
+## sched Examples <a id="dt_ref_schedexamples_prov">
The following examples illustrate the use of the probes that are published by the `sched` provider.
@@ -810,7 +810,7 @@ The output of the example script is two distributions of the millisecond offset
The output histogram named `tick` shows that the clock tick is firing at a 1 millisecond offset. In this example, the output for `enqueue` is evenly spread across the ten millisecond interval and no spike is visible at 1 millisecond, so it seems the threads aren't being scheduled on a time basis.
-## sched Stability {#dt_ref_schedstab_prov}
+## sched Stability <a id="dt_ref_schedstab_prov">
The `sched` provider uses DTrace's stability mechanism to describe its stabilities. These values are listed in the following table.
diff --git a/doc/userguide/reference/dtrace_providers_sdt.md b/doc/userguide/reference/dtrace_providers_sdt.md
index 442911fc7..b4490401a 100644
--- a/doc/userguide/reference/dtrace_providers_sdt.md
+++ b/doc/userguide/reference/dtrace_providers_sdt.md
@@ -1,5 +1,5 @@
-# SDT Provider {#dt_ref_sdt_prov}
+# SDT Provider <a id="dt_ref_sdt_prov">
The Statically Defined Tracing \(SDT\) provider \(`sdt`\) creates probes at sites that a software programmer has formally designated. Thus, the SDT provider is chiefly of interest only to developers of new providers. Most users access SDT only indirectly by using other providers.
@@ -11,13 +11,13 @@ Both the name stability and the data stability of the probes are Private, which
**Parent topic:**[DTrace Provider Reference](../reference/dtrace_providers.md)
-## Creating sdt Probes {#dt_ref_sdtcreatep_prov}
+## Creating sdt Probes <a id="dt_ref_sdtcreatep_prov">
If you are a device driver developer, you might be interested in creating `sdt` probes for a Linux driver that you are working on. The disabled probe effect of SDT is only the cost of several no-operation machine instructions. You are therefore encouraged to add `sdt` probes to device driver code as needed. Unless these probes negatively affect performance, you can leave them in shipped code.
DTrace also provides a mechanism for application developers to define user-space static probes.
-### Declaring Probes {#dt_ref_sdtdeclp_prov}
+### Declaring Probes <a id="dt_ref_sdtdeclp_prov">
The `sdt` probes are declared by using the `DTRACE_PROBE` macro from `<linux/sdt.h>`.
@@ -34,11 +34,11 @@ SDT can also act as a metaprovider by registering probes so that they appear to
Probes that use such macros appear to come from a provider other than `sdt`. The leading double underscore, provider name, and trailing underscore in the `name` argument are used to match the provider and aren't included in the probe name.
-### sdt Probe Arguments {#dt_ref_sdtparg_prov}
+### sdt Probe Arguments <a id="dt_ref_sdtparg_prov">
The arguments for each `sdt` probe are the arguments that are specified in the kernel source code in the corresponding `DTRACE_PROBE` macro reference. When declaring `sdt` probes, you can minimize their disabled probe effect by not dereferencing pointers and by not loading from global variables in the probe arguments. Both pointer dereferencing and global variable loading can be done safely in D functions that enable probes, so DTrace users can request these functions only when they're needed.
-## sdt Stability {#dt_ref_sdtstab_prov}
+## sdt Stability <a id="dt_ref_sdtstab_prov">
The `sdt` provider uses DTrace's stability mechanism to describe its stabilities. These values are listed in the following table.
diff --git a/doc/userguide/reference/dtrace_providers_syscall.md b/doc/userguide/reference/dtrace_providers_syscall.md
index 880b7de69..dbd90303e 100644
--- a/doc/userguide/reference/dtrace_providers_syscall.md
+++ b/doc/userguide/reference/dtrace_providers_syscall.md
@@ -1,5 +1,5 @@
-# Syscall Provider {#dt_ref_syscall_prov}
+# Syscall Provider <a id="dt_ref_syscall_prov">
The `syscall` provider makes available a probe at the entry to and return from every system call in the system.
@@ -7,17 +7,17 @@ Because system calls are the primary interface between user-level applications a
**Parent topic:**[DTrace Provider Reference](../reference/dtrace_providers.md)
-## syscall Probes {#dt_ref_syscallprobes_prov}
+## syscall Probes <a id="dt_ref_syscallprobes_prov">
`syscall` provides a pair of probes for each system call: an `entry` probe that fires before the system call is entered, and a `return` probe that fires after the system call has completed, but before control has been transferred back to user-level. For all `syscall` probes, the function name is set as the name of the instrumented system call.
Often, the system call names that are provided by `syscall` correspond to names in the Section 2 manual pages. However, some `syscall` provider probes don't directly correspond to any documented system call, such as the case where a system call might be a sub operation of another system call or where a system call might be private in that they span the user-kernel boundary.
-## syscall Probe Arguments {#dt_ref_syscallargs_prov}
+## syscall Probe Arguments <a id="dt_ref_syscallargs_prov">
For `entry` probes, the arguments, `arg0` ... `arg*n*`, are arguments to the system call. For return probes, both `arg0` and `arg1` contain the return value. A non-zero value in the D variable `errno` indicates a system call failure.
-## syscall Stability {#dt_ref_syscallstab_prov}
+## syscall Stability <a id="dt_ref_syscallstab_prov">
The `syscall` provider uses DTrace's stability mechanism to describe its stabilities. These stability values are listed in the following table.
--
2.47.3
^ permalink raw reply related [flat|nested] 28+ messages in thread* Re: [DTrace-devel] [PATCH v2 09/20] doc: Fix anchor links for providers
2025-10-22 3:22 ` [PATCH v2 09/20] doc: Fix anchor links for providers eugene.loh
@ 2025-10-23 19:27 ` Elena Zannoni
0 siblings, 0 replies; 28+ messages in thread
From: Elena Zannoni @ 2025-10-23 19:27 UTC (permalink / raw)
To: eugene.loh, dtrace, dtrace-devel
Reviewed-by: Elena Zannoni <elena.zannoni@oracle.com>
On 10/21/25 9:22 PM, eugene.loh--- via DTrace-devel wrote:
> From: Eugene Loh <eugene.loh@oracle.com>
>
> Signed-off-by: Eugene Loh <eugene.loh@oracle.com>
> ---
> ...StaticallyDefinedTracingofUserApplications.md | 10 +++++-----
> doc/userguide/reference/dtrace_providers_cpc.md | 10 +++++-----
> .../reference/dtrace_providers_dtrace.md | 10 +++++-----
> doc/userguide/reference/dtrace_providers_fbt.md | 10 +++++-----
> doc/userguide/reference/dtrace_providers_io.md | 16 ++++++++--------
> .../reference/dtrace_providers_lockstat.md | 10 +++++-----
> doc/userguide/reference/dtrace_providers_pid.md | 10 +++++-----
> doc/userguide/reference/dtrace_providers_proc.md | 14 +++++++-------
> .../reference/dtrace_providers_profile.md | 12 ++++++------
> .../reference/dtrace_providers_rawtp.md | 4 ++--
> .../reference/dtrace_providers_sched.md | 14 +++++++-------
> doc/userguide/reference/dtrace_providers_sdt.md | 10 +++++-----
> .../reference/dtrace_providers_syscall.md | 8 ++++----
> 13 files changed, 69 insertions(+), 69 deletions(-)
>
> diff --git a/doc/userguide/reference/dtrace-ref-StaticallyDefinedTracingofUserApplications.md b/doc/userguide/reference/dtrace-ref-StaticallyDefinedTracingofUserApplications.md
> index 7548bad83..e8298dea8 100644
> --- a/doc/userguide/reference/dtrace-ref-StaticallyDefinedTracingofUserApplications.md
> +++ b/doc/userguide/reference/dtrace-ref-StaticallyDefinedTracingofUserApplications.md
> @@ -1,5 +1,5 @@
>
> -# USDT Provider {#dt_ref_usdt_prov}
> +# USDT Provider <a id="dt_ref_usdt_prov">
>
> Use the USDT provider, for user space statically defined tracing, to instrument user space code with probes that are meaningful for an application.
>
> @@ -9,7 +9,7 @@ USDT is for user space processes. For kernel modules, statically defined tracing
>
> **Parent topic:**[DTrace Provider Reference](../reference/dtrace_providers.md)
>
> -## Defining USDT Providers and Probes {#dt_ref_usdtprobes_prov}
> +## Defining USDT Providers and Probes <a id="dt_ref_usdtprobes_prov">
>
> Define USDT providers and probes in a `.d` file that you add to the source code. For example, a file `myproviders.d` contains:
>
> @@ -37,7 +37,7 @@ The following example traces all processes with `myprov` probes, even if they ha
> sudo dtrace -Z -n 'myprov*:::my-put { printf("put %d %d\n", arg0, arg1); }'
> ```
>
> -## Adding USDT Probes to Application Code {#dt_ref_usdt_probe_add_prov}
> +## Adding USDT Probes to Application Code <a id="dt_ref_usdt_probe_add_prov">
>
> Consider this C code `func.c`:
>
> @@ -66,7 +66,7 @@ You can place probes in the code, referring to the probes by using the macros, w
>
> An optional optimization is to test if a probe is enabled. While the computational overhead of a disabled DTrace probe is often similar to a few no-op instructions, setting up probe arguments can be expensive. In this example, `bar(1111)` and `bar(2222)`might be costly function calls. Therefore, for each probe, DTrace also supplies an `is-enabled` macro, named by appending `_ENABLED`. In the example, `MYPROV_MY_PUT_ENABLED()` for the `my-put` probe, to help minimize the cost of any work associated with disabled probes.
>
> -## Building Applications With USDT Probes {#dt_ref_usdt_build_prov}
> +## Building Applications With USDT Probes <a id="dt_ref_usdt_build_prov">
>
> The `dtrace` command becomes part of the build procedure, which can be thought of in four parts:
>
> @@ -101,7 +101,7 @@ The `dtrace` command becomes part of the build procedure, which can be thought o
> ```
>
>
> -## USDT Examples {#dt_ref_usdtexamples_prov}
> +## USDT Examples <a id="dt_ref_usdtexamples_prov">
>
> 1. Create a file `myproviders.d` that contains:
>
> diff --git a/doc/userguide/reference/dtrace_providers_cpc.md b/doc/userguide/reference/dtrace_providers_cpc.md
> index 39b2ca6f5..742fd001b 100644
> --- a/doc/userguide/reference/dtrace_providers_cpc.md
> +++ b/doc/userguide/reference/dtrace_providers_cpc.md
> @@ -1,5 +1,5 @@
>
> -# CPC Provider {#dt_ref_cpc_prov}
> +# CPC Provider <a id="dt_ref_cpc_prov">
>
> The CPU performance counter \(`cpc`\) provider makes available probes that are associated with CPU performance counter events.
>
> @@ -11,7 +11,7 @@ Start with higher event counter values for CPC probes and reduce them through tr
>
> **Parent topic:**[DTrace Provider Reference](../reference/dtrace_providers.md)
>
> -## cpc Probes {#dt_ref_cpcprobes_prov}
> +## cpc Probes <a id="dt_ref_cpcprobes_prov">
>
> Probes made available by the `cpc` provider have the following probe description format:
>
> @@ -29,7 +29,7 @@ The definitions of the components of the probe name are listed in table.
>
> Note that when you list CPC probes, example count values are provided in the probe listings. The count values are artificially set high as a guideline.
>
> -## cpc Probe Arguments {#dt_ref_cpcargs_prov}
> +## cpc Probe Arguments <a id="dt_ref_cpcargs_prov">
>
> The following table lists the argument types for the `cpc` probes.
>
> @@ -40,7 +40,7 @@ The following table lists the argument types for the `cpc` probes.
>
> As the descriptions imply, if `arg0` is non-zero then `arg1` is zero; if `arg0` is zero then `arg1` is non-zero.
>
> -## cpc Examples {#dt_ref_cpcexamples_prov}
> +## cpc Examples <a id="dt_ref_cpcexamples_prov">
>
> The following example illustrates the use of a probe published by the `cpc` provider.
>
> @@ -56,7 +56,7 @@ cpc:::cycles-all-50000000
>
> ```
>
> -## cpc Stability {#dt_ref_cpcstab_prov}
> +## cpc Stability <a id="dt_ref_cpcstab_prov">
>
> The `cpc` provider uses DTrace's stability mechanism to describe its stabilities. These values are listed in the following table.
>
> diff --git a/doc/userguide/reference/dtrace_providers_dtrace.md b/doc/userguide/reference/dtrace_providers_dtrace.md
> index ef62c5040..cfe485848 100644
> --- a/doc/userguide/reference/dtrace_providers_dtrace.md
> +++ b/doc/userguide/reference/dtrace_providers_dtrace.md
> @@ -1,5 +1,5 @@
>
> -# DTrace Provider {#dt_ref_dt_prov}
> +# DTrace Provider <a id="dt_ref_dt_prov">
>
> The `dtrace` provider includes several probes that are specific to DTrace itself.
>
> @@ -7,7 +7,7 @@ Use these probes to initialize state before tracing begins, process state after
>
> **Parent topic:**[DTrace Provider Reference](../reference/dtrace_providers.md)
>
> -## BEGIN Probe {#dt_ref_begin_prov}
> +## BEGIN Probe <a id="dt_ref_begin_prov">
>
> The `BEGIN` probe fires before any other probe.
>
> @@ -34,7 +34,7 @@ syscall::mmap:entry
>
> The `BEGIN` probe fires in an unspecified context, which means the output of `stack` or `ustack`, and the value of context-specific variables such as `execname`, are all arbitrary. These values should not be relied upon or interpreted to infer any meaningful information. No arguments are defined for the `BEGIN` probe.
>
> -## END Probe {#dt_ref_end_prov}
> +## END Probe <a id="dt_ref_end_prov">
>
> The `END` probe fires after all other probes.
>
> @@ -64,7 +64,7 @@ As with the `BEGIN` probe, no arguments are defined for the `END` probe. The con
>
> The `[exit](function_exit.md)` function causes tracing to stop and the `END` probe to fire. However, a delay exists between the invocation of the `exit` function and when the `END` probe fires. During this delay, no further probes can fire. After a probe invokes the `exit` function, the `END` probe isn't fired until DTrace determines that `exit` has been called and stops tracing. The rate at which the exit status is checked can be set by using `statusrate` option.
>
> -## ERROR Probe {#dt_ref_error_prov}
> +## ERROR Probe <a id="dt_ref_error_prov">
>
> The `ERROR` probe fires when a runtime error occurs during the processing of a clause for a DTrace probe.
>
> @@ -311,7 +311,7 @@ None.
> </td></tr><tbody></table>
> If the actions that are taken in the `ERROR` probe cause an error, that error is silently dropped. The `ERROR` probe isn't recursively invoked.
>
> -## dtrace Stability {#dt_ref_dtstability_prov}
> +## dtrace Stability <a id="dt_ref_dtstability_prov">
>
> The `dtrace` provider uses DTrace's stability mechanism to describe its stabilities. These values are listed in the following table.
>
> diff --git a/doc/userguide/reference/dtrace_providers_fbt.md b/doc/userguide/reference/dtrace_providers_fbt.md
> index 885d59230..295a21d83 100644
> --- a/doc/userguide/reference/dtrace_providers_fbt.md
> +++ b/doc/userguide/reference/dtrace_providers_fbt.md
> @@ -1,5 +1,5 @@
>
> -# FBT Provider {#dt_ref_fbt_prov}
> +# FBT Provider <a id="dt_ref_fbt_prov">
>
> The `fbt` \(Function Boundary Tracing\) provider includes probes that are associated with the entry to and return from most functions in the Linux kernel. Therefore, there could be tens of thousands of `fbt` probes.
>
> @@ -15,17 +15,17 @@ Because of the large number of FPB probes that are available, be specific about
>
> **Parent topic:**[DTrace Provider Reference](../reference/dtrace_providers.md)
>
> -## fbt Probes {#dt_ref_fbtprobes_prov}
> +## fbt Probes <a id="dt_ref_fbtprobes_prov">
>
> FBT provides an `entry` probe and a `return` probe for most functions in the kernel.
>
> -## fbt Probe Arguments {#dt_ref_fbtargs_prov}
> +## fbt Probe Arguments <a id="dt_ref_fbtargs_prov">
>
> The arguments to `entry` probes are the same as the arguments to the corresponding operating system kernel function. These arguments can be accessed as `int64_t` values by using the `arg0`, `arg1`, `arg2`, ... variables.
>
> If the function has a return value, the return value is stored in `arg1` of the `return` probe. If a function doesn't have a return value, `arg1` isn't defined.
>
> -## fbt Examples {#dt_ref_fbtexamples_prov}
> +## fbt Examples <a id="dt_ref_fbtexamples_prov">
>
> You can use the `fbt` provider to explore the kernel's implementation. The following example script creates an aggregation on the number of times different functions allocate kernel virtual memory. The results of the aggregation are printed when the script exits. This would help somebody to monitor what functions are memory intensive. Type the following D source code and save it in a file named `getkmemalloc.d`:
>
> @@ -74,7 +74,7 @@ Running this script results in output similar to the following:
>
> The output shows the internal kernel functions that are making calls to the `kmem*alloc` system calls and can be used to find which kernel functions most often allocate kernel virtual memory on a system.
>
> -## fbt Stability {#dt_ref_fbtstab_prov}
> +## fbt Stability <a id="dt_ref_fbtstab_prov">
>
> The `fbt` provider uses DTrace's stability mechanism to describe its stabilities. These stability values are listed in the following table.
>
> diff --git a/doc/userguide/reference/dtrace_providers_io.md b/doc/userguide/reference/dtrace_providers_io.md
> index a458ab284..40851042c 100644
> --- a/doc/userguide/reference/dtrace_providers_io.md
> +++ b/doc/userguide/reference/dtrace_providers_io.md
> @@ -1,5 +1,5 @@
>
> -# IO Provider {#dt_ref_io_prov}
> +# IO Provider <a id="dt_ref_io_prov">
>
> The `io` provider makes available probes that relate to data input and output.
>
> @@ -7,7 +7,7 @@ For example, you can use the `io` provider to understand I/O by device, I/O type
>
> **Parent topic:**[DTrace Provider Reference](../reference/dtrace_providers.md)
>
> -## io Probes {#dt_ref_ioprobes_prov}
> +## io Probes <a id="dt_ref_ioprobes_prov">
>
> The following table describes the probes for the `io` provider. For all `io` probes, the module is `vmlinux` and the function is an empty string.
>
> @@ -54,7 +54,7 @@ Fires when a thread finishes waiting for the completion of an I/O request. The `
> </td></tr><tbody></table>
> The `io` probes fire for all I/O requests to peripheral devices, and for all file read and file write requests to an NFS server. Requests for metadata from an NFS server, for example, don't trigger `io` probes because of a `readdir()` request.
>
> -## io Probe Arguments {#dt_ref_ioargs_prov}
> +## io Probe Arguments <a id="dt_ref_ioargs_prov">
>
> The following table describes the arguments for the `io` probes. The `argN` are implementation specific. Use `args[]` to access the probe arguments.
>
> @@ -143,7 +143,7 @@ Probe
>
> DTrace doesn't provide the option to use `fileinfo_t` with `io` probes. In Linux, no information is accessible at the level where the `io` probes fire about the file where an I/O request originated.
>
> -### bufinfo\_t {#dt_ref_iobuf_prov}
> +### bufinfo\_t <a id="dt_ref_iobuf_prov">
>
> The `bufinfo_t` structure is the abstraction that describes an I/O request. The buffer that corresponds to an I/O request is pointed to by `args[0]` in the `start`, `done`, `wait-start`, and `wait-done` probes. Detailed information about this data structure can be found in `/usr/lib64/dtrace/*version*/io.d`. The definition of `bufinfo_t` is as follows:
>
> @@ -289,7 +289,7 @@ Indicates that the data is to be transferred from main memory to the peripheral
>
> `b_edev`: Contains the major and minor device numbers of the device accessed. You can use the D subroutines `getmajor` and `getminor` to extract the major and minor device numbers from the `b_edev` field.
>
> -### devinfo\_t {#dt_ref_iodev_prov}
> +### devinfo\_t <a id="dt_ref_iodev_prov">
>
> The `devinfo_t` structure provides information about a device. The `devinfo_t` structure that corresponds to the destination device of an I/O is pointed to by `args[1]` in the `start`, `done`, `wait-start`, and `wait-done` probes. Detailed information about this data structure can be found in `/usr/lib64/dtrace/*version*/io.d`. The definition of `devinfo_t` is as follows:
>
> @@ -318,7 +318,7 @@ DTrace translates the members of `devinfo_t` from the `buffer_head` for the Linu
>
> `dev_pathname`: Is the full path of the device. The path that's specified by `dev_pathname` includes components expressing the device node, the instance number, and the minor node. However, note that all three of these elements aren't necessarily expressed in the statistics name. For some devices, the statistics name consists of the device name and the instance number. For other devices, the name consists of the device name and the number of the minor node. So, two devices that have the same `dev_statname` migh differ in their `dev_pathname`.
>
> -### fileinfo\_t {#dt_ref_iofile_prov}
> +### fileinfo\_t <a id="dt_ref_iofile_prov">
>
> **Note:**
>
> @@ -352,7 +352,7 @@ The `fi_fs` field contains the name of the file system type, or `<none>`, if no
>
> The `fi_oflags` field contains the flags that were specified when opening the file.
>
> -## io Examples {#dt_ref_ioexamples_prov}
> +## io Examples <a id="dt_ref_ioexamples_prov">
>
> The following example script displays information for every I/O as it's issued. Type the following source code and save it in a file named `iosnoop.d`.
>
> @@ -517,7 +517,7 @@ sdc1 (/dev/sdc1)
>
> The previous output shows that the USB drive \(`sdc1`\) is clearly the limiting device. The throughput of `sdc1` is between 256K/sec and 512K/sec, while `dm-00` delivered I/O at anywhere from 8 MB/second to over 64 MB/second.
>
> -## io Stability {#dt_ref_iostab_prov}
> +## io Stability <a id="dt_ref_iostab_prov">
>
> The `io` provider uses DTrace's stability mechanism to describe its stabilities. These values are listed in the following table.
>
> diff --git a/doc/userguide/reference/dtrace_providers_lockstat.md b/doc/userguide/reference/dtrace_providers_lockstat.md
> index 98affd838..c1d3eb4de 100644
> --- a/doc/userguide/reference/dtrace_providers_lockstat.md
> +++ b/doc/userguide/reference/dtrace_providers_lockstat.md
> @@ -1,11 +1,11 @@
>
> -# Lockstat Provider {#dt_ref_lockstat_prov}
> +# Lockstat Provider <a id="dt_ref_lockstat_prov">
>
> The `lockstat` provider provides probes that can be used to study lock usage and contention.
>
> **Parent topic:**[DTrace Provider Reference](../reference/dtrace_providers.md)
>
> -## lockstat Probes {#dt_ref_lockstatprobes_prov}
> +## lockstat Probes <a id="dt_ref_lockstatprobes_prov">
>
> For all `lockstat` probes, the module name is `vmlinux` and the function name is an empty string.
>
> @@ -44,7 +44,7 @@ The following probe fires before a lock is acquired if there was contention for
>
> Finally, an `adaptive-acquire-error` probe indicates an error acquiring an adaptive lock.
>
> -## lockstat Probe Arguments {#dt_ref_lockstatargs_prov}
> +## lockstat Probe Arguments <a id="dt_ref_lockstatargs_prov">
>
> The following table lists the argument types for the `lockstat` probes. The `argN` are implementation specific. Use `args[]` to access the probe arguments.
>
> @@ -245,7 +245,7 @@ Probe
>
> `args[0]` has a pointer to the lock in question. The probes that fire in case of contention report a `uint64_t` `args[1]`, which is the wait time in nanoseconds. The `rw` probes also report an `int` that's either `RW_READER` or `RW_WRITER`. Finally, `adaptive-acquire-error` reports an `int` with a non zero error.
>
> -## lockstat Examples {#dt_ref_lockstatexamples_prov}
> +## lockstat Examples <a id="dt_ref_lockstatexamples_prov">
>
> The following examples illustrate the use of the probes that are published by the `lockstat` provider.
>
> @@ -271,7 +271,7 @@ Run the program on the `date` command using `sudo dtrace -qs whatlock.d -c date`
>
> It might be surprising that so many locks are acquired with the `date` command. The large number of locks is a natural artifact of the fine-grained locking required of a scalable system such as the Linux kernel.
>
> -## lockstat Stability {#dt_ref_lockstatstab_prov}
> +## lockstat Stability <a id="dt_ref_lockstatstab_prov">
>
> The `lockstat` provider uses DTrace's stability mechanism to describe its stabilities. These values are listed in the following table.
>
> diff --git a/doc/userguide/reference/dtrace_providers_pid.md b/doc/userguide/reference/dtrace_providers_pid.md
> index c0c7bbb9a..184f2c081 100644
> --- a/doc/userguide/reference/dtrace_providers_pid.md
> +++ b/doc/userguide/reference/dtrace_providers_pid.md
> @@ -1,11 +1,11 @@
>
> -# Pid Provider {#dt_ref_pid_prov}
> +# Pid Provider <a id="dt_ref_pid_prov">
>
> The `pid` provider traces a user process, both function `entry` and `return`, and an arbitrary instruction.
>
> **Parent topic:**[DTrace Provider Reference](../reference/dtrace_providers.md)
>
> -## pid Probes {#dt_ref_pidprobes_prov}
> +## pid Probes <a id="dt_ref_pidprobes_prov">
>
> A probe is fully specified by naming its provider, module, function, and name.
>
> @@ -52,7 +52,7 @@ The probe name is one of:
> - An instruction offset. The hexadecimal offset, without a leading `0x`, is relative to the named function, but it's an absolute offset when the function name is `-`.
>
>
> -## pid Probe Arguments {#dt_ref_pidargs_prov}
> +## pid Probe Arguments <a id="dt_ref_pidargs_prov">
>
> For `entry` probes, the probe arguments are the same arguments as those of the probed function.
>
> @@ -60,7 +60,7 @@ For `return` probes, `arg1` is the return value of the probed function.
>
> For offset probes, there are no probe arguments.
>
> -## pid Examples {#dt_ref_pidexamples_prov}
> +## pid Examples <a id="dt_ref_pidexamples_prov">
>
> Consider the following program, named `main.c`, that calls a function `foo()`:
>
> @@ -173,7 +173,7 @@ The output looks similar to:
>
> We probe on the chosen instruction, using both a relative offset `foo:4`, and an absolute offset `-:40110a`. Both probes fire, both reporting the same PC `0x40110a`.
>
> -## pid Stability {#dt_ref_pidstab_prov}
> +## pid Stability <a id="dt_ref_pidstab_prov">
>
> The `pid` provider uses DTrace's stability mechanism to describe its stabilities. These values are listed in the following table.
>
> diff --git a/doc/userguide/reference/dtrace_providers_proc.md b/doc/userguide/reference/dtrace_providers_proc.md
> index 6c1fa8ecf..cf64bc28f 100644
> --- a/doc/userguide/reference/dtrace_providers_proc.md
> +++ b/doc/userguide/reference/dtrace_providers_proc.md
> @@ -1,5 +1,5 @@
>
> -# Proc Provider {#dt_ref_proc_prov}
> +# Proc Provider <a id="dt_ref_proc_prov">
>
> The `proc` provider makes available the probes that pertain to the following activities: process creation and termination, LWP creation and termination, execution of new program images, and signal sending and handling.
>
> @@ -7,7 +7,7 @@ The `proc` provider makes available the probes that pertain to the following act
>
> **Parent topic:**[DTrace Provider Reference](../reference/dtrace_providers.md)
>
> -## proc Probes {#dt_ref_procprobes_prov}
> +## proc Probes <a id="dt_ref_procprobes_prov">
>
> The probes for the `proc` provider are listed in the following table.
>
> @@ -128,7 +128,7 @@ Fires in the context of a newly created process. The `start` probe fires before
>
> No fundamental difference between a process and a thread that a process creates, exists in Linux. The threads of a process are set up so that they can share resources, but each thread has its own entry in the process table with its own process ID.
>
> -## proc Probe Arguments {#dt_ref_procargs_prov}
> +## proc Probe Arguments <a id="dt_ref_procargs_prov">
>
> The following table lists the argument types for the `proc` probes. See [proc Probes](dtrace_providers_proc.md) for a description of the arguments. The `argN` are implementation specific. Use `args[]` to access the probe arguments.
>
> @@ -357,7 +357,7 @@ Probe
> —
>
> </td></tr><tbody></table>
> -### lwpsinfo\_t {#dt_ref_lwpsinfoproc_prov}
> +### lwpsinfo\_t <a id="dt_ref_lwpsinfoproc_prov">
>
> Several `proc` probes have arguments of type `lwpsinfo_t`. Detailed information about this data structure can be found in `/usr/lib64/dtrace/*version*/procfs.d`. Some structure members, while still recognized for historical reasons, aren't implemented. The definition of the `lwpsinfo_t` structure is as follows:
>
> @@ -475,7 +475,7 @@ The thread is a zombie.
> The equivalent Linux task state is `EXIT_ZOMBIE`, `EXIT_DEAD`, or `TASK_DEAD`.
>
> </td></tr><tbody></table>
> -### psinfo\_t {#dt_ref_procpsinfo_prov}
> +### psinfo\_t <a id="dt_ref_procpsinfo_prov">
>
> Several `proc` probes have an argument of type `psinfo_t`. Detailed information about this data structure can be found in `/usr/lib64/dtrace/*version*/procfs.d`. The definition of the `psinfo_t` structure, is as follows:
>
> @@ -527,7 +527,7 @@ Lightweight processes don't exist in Linux. In Linux, processes and threads are
>
> `pr_dmodel` is set to either `PR_MODEL_ILP32`, denoting a 32–bit process, or `PR_MODEL_LP64`, denoting a 64–bit process.
>
> -## proc Examples {#dt_ref_procexamples_prov}
> +## proc Examples <a id="dt_ref_procexamples_prov">
>
> The following examples illustrate the use of the probes that are published by the `proc` provider.
>
> @@ -691,7 +691,7 @@ Running this script results in output similar to the following:
> swapper/6 pmlogger 14 1
> ```
>
> -## proc Stability {#dt_ref_procstab_prov}
> +## proc Stability <a id="dt_ref_procstab_prov">
>
> The `proc` provider uses DTrace's stability mechanism to describe its stabilities. These values are listed in the following table.
>
> diff --git a/doc/userguide/reference/dtrace_providers_profile.md b/doc/userguide/reference/dtrace_providers_profile.md
> index bcc8c64d2..da83e8561 100644
> --- a/doc/userguide/reference/dtrace_providers_profile.md
> +++ b/doc/userguide/reference/dtrace_providers_profile.md
> @@ -1,5 +1,5 @@
>
> -# Profile Provider {#dt_ref_profile_prov}
> +# Profile Provider <a id="dt_ref_profile_prov">
>
> The `profile` provider includes probes that are associated with an interrupt that fires at some regular, specified time interval.
>
> @@ -7,7 +7,7 @@ Such probes aren't associated with any particular point of execution, but rather
>
> **Parent topic:**[DTrace Provider Reference](../reference/dtrace_providers.md)
>
> -## profile-*n* Probes {#dt_ref_profile-n_prov}
> +## profile-*n* Probes <a id="dt_ref_profile-n_prov">
>
> The `profile-*n*` probes fire at a fixed interval, at a high-interrupt level on all active CPUs.
>
> @@ -86,7 +86,7 @@ days
> hertz \(frequency expressed as rate per second\)
>
> </td></tr><tbody></table>
> -## tick-*n* Probes {#dt_ref_profile-tick-n_prov}
> +## tick-*n* Probes <a id="dt_ref_profile-tick-n_prov">
>
> The `tick-*n*` probes fire at fixed intervals, at a high interrupt level on only one CPU per interval.
>
> @@ -98,7 +98,7 @@ The `tick-*n*` probes have several uses, such as providing some periodic output
>
> The highest available tick frequency is 5000 Hz \(`tick-5000`\).
>
> -## profile Probe Arguments {#dt_ref_profargs_prov}
> +## profile Probe Arguments <a id="dt_ref_profargs_prov">
>
> The following table describes the arguments for the `profile` probes.
>
> @@ -146,13 +146,13 @@ The arguments are as follows:
> - `upc`: user-space program counter
>
>
> -## profile Probe Creation {#dt_ref_profprobecreate_prov}
> +## profile Probe Creation <a id="dt_ref_profprobecreate_prov">
>
> Unlike other providers, the `profile` provider creates probes dynamically on an as-needed basis. Thus, the preferred probe might not appear in a listing of all probes, for example, when using the `dtrace -l -P profile` command, but the probe is created when it's explicitly enabled.
>
> A time interval that's too short causes the machine to continuously field time-based interrupts and denies service on the machine. The `profile` provider refuses to create a probe that would result in an interval of less than two hundred microseconds and returns an error.
>
> -## prof Stability {#dt_ref_profstab_prov}
> +## prof Stability <a id="dt_ref_profstab_prov">
>
> The `profile` provider uses DTrace's stability mechanism to describe its stabilities. These stability values are listed in the following table.
>
> diff --git a/doc/userguide/reference/dtrace_providers_rawtp.md b/doc/userguide/reference/dtrace_providers_rawtp.md
> index d85dd45a8..67cb0bedc 100644
> --- a/doc/userguide/reference/dtrace_providers_rawtp.md
> +++ b/doc/userguide/reference/dtrace_providers_rawtp.md
> @@ -1,5 +1,5 @@
>
> -# Rawtp Provider {#dt_ref_rawtp_prov}
> +# Rawtp Provider <a id="dt_ref_rawtp_prov">
>
> The `rawtp` provider gives DTrace users access to the raw tracepoints exposed by the kernel tracing system, including access to the untranslated arguments of the associated tracepoint events.
>
> @@ -17,7 +17,7 @@ sudo dtrace -lvP rawtp
>
> **Parent topic:**[DTrace Provider Reference](../reference/dtrace_providers.md)
>
> -## rawtp Stability {#dt_ref_rawtpstab_prov}
> +## rawtp Stability <a id="dt_ref_rawtpstab_prov">
>
> The `rawtp` provider uses DTrace's stability mechanism to describe its stabilities. These stability values are listed in the following table.
>
> diff --git a/doc/userguide/reference/dtrace_providers_sched.md b/doc/userguide/reference/dtrace_providers_sched.md
> index f6d183708..42f318e77 100644
> --- a/doc/userguide/reference/dtrace_providers_sched.md
> +++ b/doc/userguide/reference/dtrace_providers_sched.md
> @@ -1,5 +1,5 @@
>
> -# Sched Provider {#dt_ref_sched_prov}
> +# Sched Provider <a id="dt_ref_sched_prov">
>
> The `sched` provider makes available probes related to CPU scheduling.
>
> @@ -7,7 +7,7 @@ Because CPUs are the one resource that all threads must consume, the `sched` pro
>
> **Parent topic:**[DTrace Provider Reference](../reference/dtrace_providers.md)
>
> -## sched Probes {#dt_ref_schedprob_prov}
> +## sched Probes <a id="dt_ref_schedprob_prov">
>
> The probes for the `sched` provider are listed in the following table. For all `sched` probes, the module is `vmlinux` and the function is an empty string.
>
> @@ -76,7 +76,7 @@ Fires as a part of clock tick-based accounting. In clock tick-based accounting,
> Fires immediately before the current thread wakes a thread sleeping on a synchronization object. Here, `args[0]` and `args[1]` refer to the sleeping thread, as an `lwpsinfo_t *` and `psinfo_t *`, respectively. The type and address of the synchronization object are contained in the `pr_stype` and `pr_wchan` members of the `lwpsinfo_t` of the sleeping thread. The meaning of this address is a private implementation detail, but the address value might be treated as a token unique to the synchronization object.
>
> </td></tr><tbody></table>
> -## sched Probe Arguments {#dt_ref_schedargs_prov}
> +## sched Probe Arguments <a id="dt_ref_schedargs_prov">
>
> Many of these probes refer to a particular thread. For these probes, the thread's `lwpsinfo_t` is pointed to by `args[0]` and the `psinfo_t` of the process containing the thread by `args[1]`. A few probes refer to a particular CPU. Its `cpuinfo_t` is pointed to by `args[2]`. Only `enqueue` has an `args[3]`, and that argument is a Boolean, as described. The `argN` values are implementation specific. Instead, use `args[]` to access the probe arguments.
>
> @@ -243,11 +243,11 @@ Probe
> —
>
> </td></tr><tbody></table>
> -### lwpsinfo\_t and psinfo\_t {#dt_ref_lwpsinfo_t_psinfo_t_sched_prov}
> +### lwpsinfo\_t and psinfo\_t <a id="dt_ref_lwpsinfo_t_psinfo_t_sched_prov">
>
> The `lwpsinfo_t` and `psinfo_t` structures are described in [Proc Provider](dtrace_providers_proc.md).
>
> -### cpuinfo\_t {#dt_ref_cpuinfo_sched_prov}
> +### cpuinfo\_t <a id="dt_ref_cpuinfo_sched_prov">
>
> The `cpuinfo_t` structure defines a CPU. The `args[2]` arguments for the `enqueue` and `dequeue` probes point to the `cpuinfo_t` for the CPU associated with the run queue, which is sometimes different from the current CPU, whose `cpuinfo_t` is pointed to by the `curcpu` variable.
>
> @@ -262,7 +262,7 @@ typedef struct cpuinfo {
> } cpuinfo_t;
> ```
>
> -## sched Examples {#dt_ref_schedexamples_prov}
> +## sched Examples <a id="dt_ref_schedexamples_prov">
>
> The following examples illustrate the use of the probes that are published by the `sched` provider.
>
> @@ -810,7 +810,7 @@ The output of the example script is two distributions of the millisecond offset
>
> The output histogram named `tick` shows that the clock tick is firing at a 1 millisecond offset. In this example, the output for `enqueue` is evenly spread across the ten millisecond interval and no spike is visible at 1 millisecond, so it seems the threads aren't being scheduled on a time basis.
>
> -## sched Stability {#dt_ref_schedstab_prov}
> +## sched Stability <a id="dt_ref_schedstab_prov">
>
> The `sched` provider uses DTrace's stability mechanism to describe its stabilities. These values are listed in the following table.
>
> diff --git a/doc/userguide/reference/dtrace_providers_sdt.md b/doc/userguide/reference/dtrace_providers_sdt.md
> index 442911fc7..b4490401a 100644
> --- a/doc/userguide/reference/dtrace_providers_sdt.md
> +++ b/doc/userguide/reference/dtrace_providers_sdt.md
> @@ -1,5 +1,5 @@
>
> -# SDT Provider {#dt_ref_sdt_prov}
> +# SDT Provider <a id="dt_ref_sdt_prov">
>
> The Statically Defined Tracing \(SDT\) provider \(`sdt`\) creates probes at sites that a software programmer has formally designated. Thus, the SDT provider is chiefly of interest only to developers of new providers. Most users access SDT only indirectly by using other providers.
>
> @@ -11,13 +11,13 @@ Both the name stability and the data stability of the probes are Private, which
>
> **Parent topic:**[DTrace Provider Reference](../reference/dtrace_providers.md)
>
> -## Creating sdt Probes {#dt_ref_sdtcreatep_prov}
> +## Creating sdt Probes <a id="dt_ref_sdtcreatep_prov">
>
> If you are a device driver developer, you might be interested in creating `sdt` probes for a Linux driver that you are working on. The disabled probe effect of SDT is only the cost of several no-operation machine instructions. You are therefore encouraged to add `sdt` probes to device driver code as needed. Unless these probes negatively affect performance, you can leave them in shipped code.
>
> DTrace also provides a mechanism for application developers to define user-space static probes.
>
> -### Declaring Probes {#dt_ref_sdtdeclp_prov}
> +### Declaring Probes <a id="dt_ref_sdtdeclp_prov">
>
> The `sdt` probes are declared by using the `DTRACE_PROBE` macro from `<linux/sdt.h>`.
>
> @@ -34,11 +34,11 @@ SDT can also act as a metaprovider by registering probes so that they appear to
>
> Probes that use such macros appear to come from a provider other than `sdt`. The leading double underscore, provider name, and trailing underscore in the `name` argument are used to match the provider and aren't included in the probe name.
>
> -### sdt Probe Arguments {#dt_ref_sdtparg_prov}
> +### sdt Probe Arguments <a id="dt_ref_sdtparg_prov">
>
> The arguments for each `sdt` probe are the arguments that are specified in the kernel source code in the corresponding `DTRACE_PROBE` macro reference. When declaring `sdt` probes, you can minimize their disabled probe effect by not dereferencing pointers and by not loading from global variables in the probe arguments. Both pointer dereferencing and global variable loading can be done safely in D functions that enable probes, so DTrace users can request these functions only when they're needed.
>
> -## sdt Stability {#dt_ref_sdtstab_prov}
> +## sdt Stability <a id="dt_ref_sdtstab_prov">
>
> The `sdt` provider uses DTrace's stability mechanism to describe its stabilities. These values are listed in the following table.
>
> diff --git a/doc/userguide/reference/dtrace_providers_syscall.md b/doc/userguide/reference/dtrace_providers_syscall.md
> index 880b7de69..dbd90303e 100644
> --- a/doc/userguide/reference/dtrace_providers_syscall.md
> +++ b/doc/userguide/reference/dtrace_providers_syscall.md
> @@ -1,5 +1,5 @@
>
> -# Syscall Provider {#dt_ref_syscall_prov}
> +# Syscall Provider <a id="dt_ref_syscall_prov">
>
> The `syscall` provider makes available a probe at the entry to and return from every system call in the system.
>
> @@ -7,17 +7,17 @@ Because system calls are the primary interface between user-level applications a
>
> **Parent topic:**[DTrace Provider Reference](../reference/dtrace_providers.md)
>
> -## syscall Probes {#dt_ref_syscallprobes_prov}
> +## syscall Probes <a id="dt_ref_syscallprobes_prov">
>
> `syscall` provides a pair of probes for each system call: an `entry` probe that fires before the system call is entered, and a `return` probe that fires after the system call has completed, but before control has been transferred back to user-level. For all `syscall` probes, the function name is set as the name of the instrumented system call.
>
> Often, the system call names that are provided by `syscall` correspond to names in the Section 2 manual pages. However, some `syscall` provider probes don't directly correspond to any documented system call, such as the case where a system call might be a sub operation of another system call or where a system call might be private in that they span the user-kernel boundary.
>
> -## syscall Probe Arguments {#dt_ref_syscallargs_prov}
> +## syscall Probe Arguments <a id="dt_ref_syscallargs_prov">
>
> For `entry` probes, the arguments, `arg0` ... `arg*n*`, are arguments to the system call. For return probes, both `arg0` and `arg1` contain the return value. A non-zero value in the D variable `errno` indicates a system call failure.
>
> -## syscall Stability {#dt_ref_syscallstab_prov}
> +## syscall Stability <a id="dt_ref_syscallstab_prov">
>
> The `syscall` provider uses DTrace's stability mechanism to describe its stabilities. These stability values are listed in the following table.
>
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v2 10/20] doc: Fix anchor links for explanation/
2025-10-22 3:22 [PATCH v2 05/20] doc: Replace duplicate id eugene.loh
` (2 preceding siblings ...)
2025-10-22 3:22 ` [PATCH v2 09/20] doc: Fix anchor links for providers eugene.loh
@ 2025-10-22 3:22 ` eugene.loh
2025-10-23 19:27 ` Elena Zannoni
2025-10-22 3:22 ` [PATCH v2 11/20] doc: Fix anchor links for how-to/ eugene.loh
` (11 subsequent siblings)
15 siblings, 1 reply; 28+ messages in thread
From: eugene.loh @ 2025-10-22 3:22 UTC (permalink / raw)
To: dtrace, dtrace-devel
From: Eugene Loh <eugene.loh@oracle.com>
Signed-off-by: Eugene Loh <eugene.loh@oracle.com>
---
doc/userguide/explanation/dtrace-about.md | 2 +-
.../explanation/dtrace-components-and-terminology.md | 10 +++++-----
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/doc/userguide/explanation/dtrace-about.md b/doc/userguide/explanation/dtrace-about.md
index 4ab252a79..b832799e4 100644
--- a/doc/userguide/explanation/dtrace-about.md
+++ b/doc/userguide/explanation/dtrace-about.md
@@ -1,5 +1,5 @@
-# About DTrace {#concept_about}
+# About DTrace <a id="concept_about">
DTrace is a powerful tracing tool that's available on Linux. DTrace has low overhead and is safe to use on production systems to analyze what a system is doing in real time.
diff --git a/doc/userguide/explanation/dtrace-components-and-terminology.md b/doc/userguide/explanation/dtrace-components-and-terminology.md
index b187055a4..9d08928ac 100644
--- a/doc/userguide/explanation/dtrace-components-and-terminology.md
+++ b/doc/userguide/explanation/dtrace-components-and-terminology.md
@@ -1,5 +1,5 @@
-# DTrace Components and Terminology {#concept_terms}
+# DTrace Components and Terminology <a id="concept_terms">
Learn about the different components and the terms used to describe them within the DTrace framework.
@@ -7,7 +7,7 @@ DTrace is a framework that dynamically traces data into buffers that are read by
**Parent topic:**[DTrace Concepts](../explanation/dtrace-concepts.md)
-## Probes {#concept_terms_probes}
+## Probes <a id="concept_terms_probes">
DTrace works by using *probes* that identify particular instrumentation in the kernel or within a user space application, or which can be used to identify interval counters or performance event counters. Events such as when particular code is run or when a specific counter is incremented cause a probe to fire and DTrace can perform functions that are bound to the event in a program or script. For example, a probe can fire when a particular file is opened and a DTrace program can print information related to the event that can be useful for debugging or resolving an issue. Equally, at the moment that DTrace starts or ends any tracing activity, the `BEGIN` and `END` probes dedicated to these actions always fire.
@@ -66,7 +66,7 @@ dtrace:::BEGIN
Probes aren't required to have a module and function. The dtrace `BEGIN`, `END` and `ERROR` probes are good examples of this because these probes don't correspond to any specific instrumented program function or location. Instead, these probes are used for more abstract concepts, such as the idea of the end a tracing request. Other probes, such as those made available by the [Profile Provider](../reference/dtrace_providers_profile.md) or the [CPC Provider](../reference/dtrace_providers_cpc.md), also don't include module or function identifiers in their descriptions.
-## D Programs {#concept_terms_programs}
+## D Programs <a id="concept_terms_programs">
You can bind a set of processing instructions called statements to one or more DTrace probes, so that when a probe fires, the specified statements are run to perform some required functionality. The set of enabled probes, the statements, and any conditions that might be evaluated when the probe fires, can all be collated into a *D program*.
@@ -102,7 +102,7 @@ Wed 22 Feb 11:54:51 GMT 2023
The program probe description matches all system call functions at the entry point. The program predicate evaluates a *built-in variable*, `execname`, against a string using an operator. The clause includes an *aggregation*, `@reads`, that's used to gather data about the firing probe. In this case, the aggregation stores a counter that increments every time the probe fires and the predicate resolves. The counter is implemented by the `count()` *function* and stores count values for each system call probe function. See [D Program Syntax Reference](../reference/d_program_syntax_reference.md) for more information on program structure and syntax.
-## Aggregations {#concept_terms_aggregations}
+## Aggregations <a id="concept_terms_aggregations">
*Aggregations* can be used to reduce large bodies of data to smaller, meaningful statistical metrics. Many common functions that are used to understand a set of data are aggregating functions. These functions include the following:
@@ -121,7 +121,7 @@ Although you could code an application to calculate an aggregation for a set of
DTrace aggregation functions apply to the data as it's traced, so that the dataset doesn't need to be stored and the aggregation is always available as events occur. In this way, aggregation functions are more efficient and exact, and avoid overwrites. See [Aggregations](../reference/aggregation.md) for more information.
-## Speculation {#concept_terms_speculation}
+## Speculation <a id="concept_terms_speculation">
While predicates can be used to filter out uninteresting events, they're only useful if you already know which events you need to filter. Because DTrace is often used to help debug particular system behaviors, DTrace includes a set of *speculation* functions that can be used to trace data speculatively.
--
2.47.3
^ permalink raw reply related [flat|nested] 28+ messages in thread* Re: [PATCH v2 10/20] doc: Fix anchor links for explanation/
2025-10-22 3:22 ` [PATCH v2 10/20] doc: Fix anchor links for explanation/ eugene.loh
@ 2025-10-23 19:27 ` Elena Zannoni
0 siblings, 0 replies; 28+ messages in thread
From: Elena Zannoni @ 2025-10-23 19:27 UTC (permalink / raw)
To: eugene.loh, dtrace, dtrace-devel
Reviewed-by: Elena Zannoni <elena.zannoni@oracle.com>
On 10/21/25 9:22 PM, eugene.loh@oracle.com wrote:
> From: Eugene Loh <eugene.loh@oracle.com>
>
> Signed-off-by: Eugene Loh <eugene.loh@oracle.com>
> ---
> doc/userguide/explanation/dtrace-about.md | 2 +-
> .../explanation/dtrace-components-and-terminology.md | 10 +++++-----
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/doc/userguide/explanation/dtrace-about.md b/doc/userguide/explanation/dtrace-about.md
> index 4ab252a79..b832799e4 100644
> --- a/doc/userguide/explanation/dtrace-about.md
> +++ b/doc/userguide/explanation/dtrace-about.md
> @@ -1,5 +1,5 @@
>
> -# About DTrace {#concept_about}
> +# About DTrace <a id="concept_about">
>
> DTrace is a powerful tracing tool that's available on Linux. DTrace has low overhead and is safe to use on production systems to analyze what a system is doing in real time.
>
> diff --git a/doc/userguide/explanation/dtrace-components-and-terminology.md b/doc/userguide/explanation/dtrace-components-and-terminology.md
> index b187055a4..9d08928ac 100644
> --- a/doc/userguide/explanation/dtrace-components-and-terminology.md
> +++ b/doc/userguide/explanation/dtrace-components-and-terminology.md
> @@ -1,5 +1,5 @@
>
> -# DTrace Components and Terminology {#concept_terms}
> +# DTrace Components and Terminology <a id="concept_terms">
>
> Learn about the different components and the terms used to describe them within the DTrace framework.
>
> @@ -7,7 +7,7 @@ DTrace is a framework that dynamically traces data into buffers that are read by
>
> **Parent topic:**[DTrace Concepts](../explanation/dtrace-concepts.md)
>
> -## Probes {#concept_terms_probes}
> +## Probes <a id="concept_terms_probes">
>
> DTrace works by using *probes* that identify particular instrumentation in the kernel or within a user space application, or which can be used to identify interval counters or performance event counters. Events such as when particular code is run or when a specific counter is incremented cause a probe to fire and DTrace can perform functions that are bound to the event in a program or script. For example, a probe can fire when a particular file is opened and a DTrace program can print information related to the event that can be useful for debugging or resolving an issue. Equally, at the moment that DTrace starts or ends any tracing activity, the `BEGIN` and `END` probes dedicated to these actions always fire.
>
> @@ -66,7 +66,7 @@ dtrace:::BEGIN
>
> Probes aren't required to have a module and function. The dtrace `BEGIN`, `END` and `ERROR` probes are good examples of this because these probes don't correspond to any specific instrumented program function or location. Instead, these probes are used for more abstract concepts, such as the idea of the end a tracing request. Other probes, such as those made available by the [Profile Provider](../reference/dtrace_providers_profile.md) or the [CPC Provider](../reference/dtrace_providers_cpc.md), also don't include module or function identifiers in their descriptions.
>
> -## D Programs {#concept_terms_programs}
> +## D Programs <a id="concept_terms_programs">
>
> You can bind a set of processing instructions called statements to one or more DTrace probes, so that when a probe fires, the specified statements are run to perform some required functionality. The set of enabled probes, the statements, and any conditions that might be evaluated when the probe fires, can all be collated into a *D program*.
>
> @@ -102,7 +102,7 @@ Wed 22 Feb 11:54:51 GMT 2023
>
> The program probe description matches all system call functions at the entry point. The program predicate evaluates a *built-in variable*, `execname`, against a string using an operator. The clause includes an *aggregation*, `@reads`, that's used to gather data about the firing probe. In this case, the aggregation stores a counter that increments every time the probe fires and the predicate resolves. The counter is implemented by the `count()` *function* and stores count values for each system call probe function. See [D Program Syntax Reference](../reference/d_program_syntax_reference.md) for more information on program structure and syntax.
>
> -## Aggregations {#concept_terms_aggregations}
> +## Aggregations <a id="concept_terms_aggregations">
>
> *Aggregations* can be used to reduce large bodies of data to smaller, meaningful statistical metrics. Many common functions that are used to understand a set of data are aggregating functions. These functions include the following:
>
> @@ -121,7 +121,7 @@ Although you could code an application to calculate an aggregation for a set of
>
> DTrace aggregation functions apply to the data as it's traced, so that the dataset doesn't need to be stored and the aggregation is always available as events occur. In this way, aggregation functions are more efficient and exact, and avoid overwrites. See [Aggregations](../reference/aggregation.md) for more information.
>
> -## Speculation {#concept_terms_speculation}
> +## Speculation <a id="concept_terms_speculation">
>
> While predicates can be used to filter out uninteresting events, they're only useful if you already know which events you need to filter. Because DTrace is often used to help debug particular system behaviors, DTrace includes a set of *speculation* functions that can be used to trace data speculatively.
>
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v2 11/20] doc: Fix anchor links for how-to/
2025-10-22 3:22 [PATCH v2 05/20] doc: Replace duplicate id eugene.loh
` (3 preceding siblings ...)
2025-10-22 3:22 ` [PATCH v2 10/20] doc: Fix anchor links for explanation/ eugene.loh
@ 2025-10-22 3:22 ` eugene.loh
2025-10-23 19:28 ` [DTrace-devel] " Elena Zannoni
2025-10-22 3:22 ` [PATCH v2 12/20] doc: Fix anchor links for reference/ eugene.loh
` (10 subsequent siblings)
15 siblings, 1 reply; 28+ messages in thread
From: eugene.loh @ 2025-10-22 3:22 UTC (permalink / raw)
To: dtrace, dtrace-devel
From: Eugene Loh <eugene.loh@oracle.com>
Signed-off-by: Eugene Loh <eugene.loh@oracle.com>
---
.../how-to/dtrace-howto-create-a-dtrace-script.md | 2 +-
.../how-to/dtrace-howto-install-dtrace.md | 15 ++++++++-------
.../how-to/dtrace-howto-list-and-enable-probes.md | 2 +-
.../how-to/dtrace-howto-use-predicates.md | 2 +-
4 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/doc/userguide/how-to/dtrace-howto-create-a-dtrace-script.md b/doc/userguide/how-to/dtrace-howto-create-a-dtrace-script.md
index 199649a9f..949ade0bf 100644
--- a/doc/userguide/how-to/dtrace-howto-create-a-dtrace-script.md
+++ b/doc/userguide/how-to/dtrace-howto-create-a-dtrace-script.md
@@ -1,5 +1,5 @@
-# Create a DTrace Script {#dt_create_script}
+# Create a DTrace Script <a id="dt_create_script">
Learn how to create a DTrace script to develop understanding of the D Programming language.
diff --git a/doc/userguide/how-to/dtrace-howto-install-dtrace.md b/doc/userguide/how-to/dtrace-howto-install-dtrace.md
index 45da88fd8..3bc29e14e 100644
--- a/doc/userguide/how-to/dtrace-howto-install-dtrace.md
+++ b/doc/userguide/how-to/dtrace-howto-install-dtrace.md
@@ -1,10 +1,11 @@
-# Install DTrace{#install_dtrace}
+
+# Install DTrace <a id="install_dtrace">
The following instructions provide steps to install DTrace on different Linux distributions and to verify that the installation was successful.
**Parent topic:**[Get Started With DTrace](../how-to/dtrace-guide.md)
-## Build and Install DTrace on Gentoo Linux {#build_install_dtrace_gentoo_linux}
+## Build and Install DTrace on Gentoo Linux <a id="build_install_dtrace_gentoo_linux">
```
emerge dev-debug/dtrace
@@ -15,7 +16,7 @@ The following instructions provide steps to install DTrace on different Linux di
## Install DTrace on Oracle Linux
-### Install DTrace on Oracle Linux 10 {#install_dtrace_oracle_linux_10}
+### Install DTrace on Oracle Linux 10 <a id="install_dtrace_oracle_linux_10">
1. Enable the yum repository.
@@ -38,7 +39,7 @@ The following instructions provide steps to install DTrace on different Linux di
```
-### Install DTrace on Oracle Linux 9 {#install_dtrace_oracle_linux_9}
+### Install DTrace on Oracle Linux 9 <a id="install_dtrace_oracle_linux_9">
1. Enable the yum repository.
@@ -61,7 +62,7 @@ The following instructions provide steps to install DTrace on different Linux di
```
-### Install DTrace on Oracle Linux 8 {#install_dtrace_oracle_linux_8}
+### Install DTrace on Oracle Linux 8 <a id="install_dtrace_oracle_linux_8">
1. Enable the yum repository.
@@ -86,7 +87,7 @@ The following instructions provide steps to install DTrace on different Linux di
```
-### Install DTrace on Oracle Linux 7 {#install_dtrace_oracle_linux_7}
+### Install DTrace on Oracle Linux 7 <a id="install_dtrace_oracle_linux_7">
**Warning:**
@@ -111,7 +112,7 @@ Migrate applications and data to Oracle Linux 8, Oracle Linux 9, or Oracle Linux
```
-## Verify the DTrace Installation {#verify_install}
+## Verify the DTrace Installation <a id="verify_install">
Check that DTrace is installed to the correct location and verify the DTrace version.
diff --git a/doc/userguide/how-to/dtrace-howto-list-and-enable-probes.md b/doc/userguide/how-to/dtrace-howto-list-and-enable-probes.md
index ad9c3a4d3..9325c6f1d 100644
--- a/doc/userguide/how-to/dtrace-howto-list-and-enable-probes.md
+++ b/doc/userguide/how-to/dtrace-howto-list-and-enable-probes.md
@@ -1,5 +1,5 @@
-# List and Enable Probes {#list_enable_probes}
+# List and Enable Probes <a id="list_enable_probes">
DTrace providers publish available probes to DTrace so that you can enable them to perform functions when they fire. You can use the `dtrace` command to list all available probes or to enable a probe.
diff --git a/doc/userguide/how-to/dtrace-howto-use-predicates.md b/doc/userguide/how-to/dtrace-howto-use-predicates.md
index c32f3050f..d00d31a01 100644
--- a/doc/userguide/how-to/dtrace-howto-use-predicates.md
+++ b/doc/userguide/how-to/dtrace-howto-use-predicates.md
@@ -1,5 +1,5 @@
-# Use Predicates For Control Flow {#dt_preds_dlang}
+# Use Predicates For Control Flow <a id="dt_preds_dlang">
For runtime safety, one major difference between D and other programming languages such as C, C++, and the Java programming language is the absence of control-flow constructs such as `if`-statements and loops. D program clauses are written as single straight-line statement lists that trace an optional, fixed amount of data. D does provide the ability to conditionally trace data and change control flow using logical expressions called *predicates*. This tutorial shows how to use predicates to control D programs.
--
2.47.3
^ permalink raw reply related [flat|nested] 28+ messages in thread* Re: [DTrace-devel] [PATCH v2 11/20] doc: Fix anchor links for how-to/
2025-10-22 3:22 ` [PATCH v2 11/20] doc: Fix anchor links for how-to/ eugene.loh
@ 2025-10-23 19:28 ` Elena Zannoni
0 siblings, 0 replies; 28+ messages in thread
From: Elena Zannoni @ 2025-10-23 19:28 UTC (permalink / raw)
To: eugene.loh, dtrace, dtrace-devel
Reviewed-by: Elena Zannoni <elena.zannoni@oracle.com>
On 10/21/25 9:22 PM, eugene.loh--- via DTrace-devel wrote:
> From: Eugene Loh <eugene.loh@oracle.com>
>
> Signed-off-by: Eugene Loh <eugene.loh@oracle.com>
> ---
> .../how-to/dtrace-howto-create-a-dtrace-script.md | 2 +-
> .../how-to/dtrace-howto-install-dtrace.md | 15 ++++++++-------
> .../how-to/dtrace-howto-list-and-enable-probes.md | 2 +-
> .../how-to/dtrace-howto-use-predicates.md | 2 +-
> 4 files changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/doc/userguide/how-to/dtrace-howto-create-a-dtrace-script.md b/doc/userguide/how-to/dtrace-howto-create-a-dtrace-script.md
> index 199649a9f..949ade0bf 100644
> --- a/doc/userguide/how-to/dtrace-howto-create-a-dtrace-script.md
> +++ b/doc/userguide/how-to/dtrace-howto-create-a-dtrace-script.md
> @@ -1,5 +1,5 @@
>
> -# Create a DTrace Script {#dt_create_script}
> +# Create a DTrace Script <a id="dt_create_script">
>
> Learn how to create a DTrace script to develop understanding of the D Programming language.
>
> diff --git a/doc/userguide/how-to/dtrace-howto-install-dtrace.md b/doc/userguide/how-to/dtrace-howto-install-dtrace.md
> index 45da88fd8..3bc29e14e 100644
> --- a/doc/userguide/how-to/dtrace-howto-install-dtrace.md
> +++ b/doc/userguide/how-to/dtrace-howto-install-dtrace.md
> @@ -1,10 +1,11 @@
> -# Install DTrace{#install_dtrace}
> +
> +# Install DTrace <a id="install_dtrace">
>
> The following instructions provide steps to install DTrace on different Linux distributions and to verify that the installation was successful.
>
> **Parent topic:**[Get Started With DTrace](../how-to/dtrace-guide.md)
>
> -## Build and Install DTrace on Gentoo Linux {#build_install_dtrace_gentoo_linux}
> +## Build and Install DTrace on Gentoo Linux <a id="build_install_dtrace_gentoo_linux">
>
> ```
> emerge dev-debug/dtrace
> @@ -15,7 +16,7 @@ The following instructions provide steps to install DTrace on different Linux di
> ## Install DTrace on Oracle Linux
>
>
> -### Install DTrace on Oracle Linux 10 {#install_dtrace_oracle_linux_10}
> +### Install DTrace on Oracle Linux 10 <a id="install_dtrace_oracle_linux_10">
>
> 1. Enable the yum repository.
>
> @@ -38,7 +39,7 @@ The following instructions provide steps to install DTrace on different Linux di
> ```
>
>
> -### Install DTrace on Oracle Linux 9 {#install_dtrace_oracle_linux_9}
> +### Install DTrace on Oracle Linux 9 <a id="install_dtrace_oracle_linux_9">
>
> 1. Enable the yum repository.
>
> @@ -61,7 +62,7 @@ The following instructions provide steps to install DTrace on different Linux di
> ```
>
>
> -### Install DTrace on Oracle Linux 8 {#install_dtrace_oracle_linux_8}
> +### Install DTrace on Oracle Linux 8 <a id="install_dtrace_oracle_linux_8">
>
> 1. Enable the yum repository.
>
> @@ -86,7 +87,7 @@ The following instructions provide steps to install DTrace on different Linux di
> ```
>
>
> -### Install DTrace on Oracle Linux 7 {#install_dtrace_oracle_linux_7}
> +### Install DTrace on Oracle Linux 7 <a id="install_dtrace_oracle_linux_7">
>
> **Warning:**
>
> @@ -111,7 +112,7 @@ Migrate applications and data to Oracle Linux 8, Oracle Linux 9, or Oracle Linux
> ```
>
>
> -## Verify the DTrace Installation {#verify_install}
> +## Verify the DTrace Installation <a id="verify_install">
>
> Check that DTrace is installed to the correct location and verify the DTrace version.
>
> diff --git a/doc/userguide/how-to/dtrace-howto-list-and-enable-probes.md b/doc/userguide/how-to/dtrace-howto-list-and-enable-probes.md
> index ad9c3a4d3..9325c6f1d 100644
> --- a/doc/userguide/how-to/dtrace-howto-list-and-enable-probes.md
> +++ b/doc/userguide/how-to/dtrace-howto-list-and-enable-probes.md
> @@ -1,5 +1,5 @@
>
> -# List and Enable Probes {#list_enable_probes}
> +# List and Enable Probes <a id="list_enable_probes">
>
> DTrace providers publish available probes to DTrace so that you can enable them to perform functions when they fire. You can use the `dtrace` command to list all available probes or to enable a probe.
>
> diff --git a/doc/userguide/how-to/dtrace-howto-use-predicates.md b/doc/userguide/how-to/dtrace-howto-use-predicates.md
> index c32f3050f..d00d31a01 100644
> --- a/doc/userguide/how-to/dtrace-howto-use-predicates.md
> +++ b/doc/userguide/how-to/dtrace-howto-use-predicates.md
> @@ -1,5 +1,5 @@
>
> -# Use Predicates For Control Flow {#dt_preds_dlang}
> +# Use Predicates For Control Flow <a id="dt_preds_dlang">
>
> For runtime safety, one major difference between D and other programming languages such as C, C++, and the Java programming language is the absence of control-flow constructs such as `if`-statements and loops. D program clauses are written as single straight-line statement lists that trace an optional, fixed amount of data. D does provide the ability to conditionally trace data and change control flow using logical expressions called *predicates*. This tutorial shows how to use predicates to control D programs.
>
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v2 12/20] doc: Fix anchor links for reference/
2025-10-22 3:22 [PATCH v2 05/20] doc: Replace duplicate id eugene.loh
` (4 preceding siblings ...)
2025-10-22 3:22 ` [PATCH v2 11/20] doc: Fix anchor links for how-to/ eugene.loh
@ 2025-10-22 3:22 ` eugene.loh
2025-10-23 19:28 ` [DTrace-devel] " Elena Zannoni
2025-10-22 3:22 ` [PATCH v2 13/20] doc: Clean up the table for string relational operators eugene.loh
` (9 subsequent siblings)
15 siblings, 1 reply; 28+ messages in thread
From: eugene.loh @ 2025-10-22 3:22 UTC (permalink / raw)
To: dtrace, dtrace-devel
From: Eugene Loh <eugene.loh@oracle.com>
Signed-off-by: Eugene Loh <eugene.loh@oracle.com>
---
doc/userguide/reference/aggregation.md | 8 ++---
doc/userguide/reference/compiler_options.md | 2 +-
...gram_syntax_reference_program_structure.md | 2 +-
.../dtrace-ref-DTraceSupportforStrings.md | 12 +++----
.../dtrace-ref-PointersandScalarArrays.md | 14 ++++----
.../reference/dtrace-ref-StructsandUnions.md | 12 +++----
...dtrace-ref-TypesOperatorsandExpressions.md | 36 +++++++++----------
.../reference/dtrace-ref-Variables.md | 4 +--
.../reference/dtrace-ref-speculation.md | 2 +-
.../reference/dtrace_command_desc.md | 2 +-
.../reference/dtrace_command_exit_status.md | 2 +-
.../reference/dtrace_command_operands.md | 2 +-
.../reference/dtrace_command_options.md | 2 +-
.../reference/dtrace_runtime_options.md | 2 +-
.../reference/dynamic_runtime_options.md | 2 +-
...ing_dtrace_compiler_and_runtime_options.md | 2 +-
16 files changed, 53 insertions(+), 53 deletions(-)
diff --git a/doc/userguide/reference/aggregation.md b/doc/userguide/reference/aggregation.md
index 8bdd44b49..5fada5410 100644
--- a/doc/userguide/reference/aggregation.md
+++ b/doc/userguide/reference/aggregation.md
@@ -1,5 +1,5 @@
-# Aggregations {#dt_ref_aggregations}
+# Aggregations <a id="dt_ref_aggregations">
Aggregations enable you to accumulate data for statistical analysis. The aggregation is calculated at runtime, so that post-processing isn't required and processing is highly efficient and accurate. Aggregations function similarly to associative arrays, but are populated by aggregating functions. In D, the syntax for an aggregation is as follows:
@@ -13,7 +13,7 @@ Aggregations can be regular or indexed. Indexed aggregations use keys, where *ke
The *aggfunc* is one of the DTrace aggregating functions, and *args* is a comma-separated list of arguments appropriate to that function. Most aggregating functions take a single argument that represents the new datum.
-## Aggregation Functions {#dt_ref_aggr_funcs}
+## Aggregation Functions <a id="dt_ref_aggr_funcs">
The following functions are aggregating functions that can be used in a program to collect data and present it in a meaningful way.
@@ -36,7 +36,7 @@ The following functions are aggregating functions that can be used in a program
- `[llquantize](aggregation_llquantize.md)`: Stores the log-linear frequency distribution in an aggregation.
-## Printing Aggregations {#dt_ref_aggr_print}
+## Printing Aggregations <a id="dt_ref_aggr_print">
By default, several aggregations are displayed in the order in which they're introduced in the D program. You can override this behavior by using the `[printa](function_printa.md)` function to print the aggregations. The `printa` function also lets you precisely format the aggregation data by using a format string.
@@ -44,7 +44,7 @@ If an aggregation isn't formatted with a `printa` statement in a D program, the
The default output format for the `avg`, `count`, `min`, `max`, `stddev`, and `sum` aggregating functions displays an integer decimal value corresponding to the aggregated value for each tuple. The default output format for the `quantize`, `lquantize`, and `llquantize` aggregating functions displays an ASCII histogram with the results. Aggregation tuples are printed as though `trace` had been applied to each tuple element.
-## Data Normalization {#dt_ref_aggr_dnorm}
+## Data Normalization <a id="dt_ref_aggr_dnorm">
When aggregating data over some period, you might want to normalize the data based on some constant factor. This technique lets you compare disjointed data more easily. For example, when aggregating system calls, you might want to output system calls as a per-second rate instead of as an absolute value over the course of the run. The DTrace `[normalize](function_normalize.md)` function lets you normalize data in this way. The parameters to `normalize` are an aggregation and a normalization factor. The output of the aggregation shows each value divided by the normalization factor.
diff --git a/doc/userguide/reference/compiler_options.md b/doc/userguide/reference/compiler_options.md
index 8e2813c1f..3cc4c72ff 100644
--- a/doc/userguide/reference/compiler_options.md
+++ b/doc/userguide/reference/compiler_options.md
@@ -1,5 +1,5 @@
-# Compile-time Options {#dt_compiler_options}
+# Compile-time Options <a id="dt_compiler_options">
Compile-time options can control how DTrace programs are compiled into eBPF code that's loaded into kernel space.
diff --git a/doc/userguide/reference/d_program_syntax_reference_program_structure.md b/doc/userguide/reference/d_program_syntax_reference_program_structure.md
index 547fd7a36..dc6a31a3b 100644
--- a/doc/userguide/reference/d_program_syntax_reference_program_structure.md
+++ b/doc/userguide/reference/d_program_syntax_reference_program_structure.md
@@ -1,5 +1,5 @@
-# Program Structure {#dt_prog_struct}
+# Program Structure <a id="dt_prog_struct">
A D program consists of a set of clauses that describe the probes to enable, an optional predicate that controls when to run, and one or more statements that often describe some functionality to implement when the probe fires.
diff --git a/doc/userguide/reference/dtrace-ref-DTraceSupportforStrings.md b/doc/userguide/reference/dtrace-ref-DTraceSupportforStrings.md
index 98f482c63..ea44523ed 100644
--- a/doc/userguide/reference/dtrace-ref-DTraceSupportforStrings.md
+++ b/doc/userguide/reference/dtrace-ref-DTraceSupportforStrings.md
@@ -1,11 +1,11 @@
-# DTrace String Processing {#dt_strings_dlang}
+# DTrace String Processing <a id="dt_strings_dlang">
DTrace provides facilities for tracing and manipulating strings. This section describes the complete set of D language features for declaring and manipulating strings. Unlike ANSI C, strings in D have their own built-in type and operator support to enable you to easily and unambiguously use them in tracing programs.
**Parent topic:**[D Program Syntax Reference](../reference/d_program_syntax_reference.md)
-## String Representation {#dt_strrep_dlang}
+## String Representation <a id="dt_strrep_dlang">
In DTrace, strings are represented as an array of characters ending in a null byte, which is a byte with a value of zero, usually written as `'\0'`. The visible part of the string is of variable length, depending on the location of the null byte, but DTrace stores each string in a fixed-size array so that each probe traces a consistent amount of data. Strings cannot exceed the length of the predefined string limit. However, the limit can be modified in your D program or on the `dtrace` command line by tuning the `strsize` option. The default string limit is 256 bytes.
@@ -33,13 +33,13 @@ trace(s);
You can also perform lexical comparison of expressions of type string. See [String Comparison](dtrace-ref-DTraceSupportforStrings.md).
-## String Constants {#dt_strcon_dlang}
+## String Constants <a id="dt_strcon_dlang">
String constants are enclosed in pairs of double quotes \(`""`\) and are automatically assigned the type `string` by the D compiler. You can define string constants of any length, limited only by the amount of memory DTrace is permitted to consume on the system and by whatever limit you have set for the `strsize` DTrace runtime option. The terminating null byte \(`\0`\) is added automatically by the D compiler to any string constants that you declare. The size of a string constant object is the number of bytes associated with the string, plus one additional byte for the terminating null byte.
A string constant can't contain a literal newline character. To create strings containing newlines, use the `\n` escape sequence instead of a literal newline. String constants can also contain any of the special character escape sequences that are defined for character constants.
-## String Assignment {#dt_strasg_dlang}
+## String Assignment <a id="dt_strasg_dlang">
Unlike the assignment of `char *` variables, strings are copied by value and not by reference. The string assignment operator `=` copies the actual bytes of the string from the source operand up to and including the null byte to the variable on the left-hand side, which must be of type `string`.
@@ -63,7 +63,7 @@ String assignment is analogous to the C library function `strcpy()`, with the ex
You can also assign to a string variable an expression of a type that's compatible with strings. In this case, the D compiler automatically promotes the source expression to the string type and performs a string assignment. The D compiler permits any expression of type `char *` or of type `char[n]`, a scalar array of `char` of any size, to be promoted to a string.
-## String Conversion {#dt_strconv_dlang}
+## String Conversion <a id="dt_strconv_dlang">
Expressions of other types can be explicitly converted to type `string` by using a cast expression or by applying the special `stringof` operator, which are equivalent in the following meaning:
@@ -78,7 +78,7 @@ The `stringof` operator binds very tightly to the operand on its right-hand side
Scalar type expressions, such as a pointer or integer, or a scalar array address can be converted to strings, in that the scalar is interpreted as an address to a char type. Expressions of other types such as `void` may not be converted to `string`. If you erroneously convert an invalid address to a string, the DTrace safety features prevents you from damaging the system or DTrace, but you might end up tracing a sequence of undecipherable characters.
-## String Comparison {#dt_strcomp_dlang}
+## String Comparison <a id="dt_strcomp_dlang">
D overloads the binary relational operators and permits them to be used for string comparisons, as well as integer comparisons. The relational operators perform string comparison whenever both operands are of type `string` or when one operand is of type `string` and the other operand can be promoted to type `string`. See [String Assignment](dtrace-ref-DTraceSupportforStrings.md) for a detailed description. See also [Table 1](dtrace-ref-DTraceSupportforStrings.md#dt_t14_dlang), which lists the relational operators that can be used to compare strings.
diff --git a/doc/userguide/reference/dtrace-ref-PointersandScalarArrays.md b/doc/userguide/reference/dtrace-ref-PointersandScalarArrays.md
index da4b69333..8746ae2fd 100644
--- a/doc/userguide/reference/dtrace-ref-PointersandScalarArrays.md
+++ b/doc/userguide/reference/dtrace-ref-PointersandScalarArrays.md
@@ -1,5 +1,5 @@
-# Pointers {#dt_ptrarr_dlang}
+# Pointers <a id="dt_ptrarr_dlang">
Pointers are memory addresses of data objects and reference memory used by the OS, by the user program, or by the D script. Pointers in D are data objects that store an integer virtual address value and associate it with a D type that describes the format of the data stored at the corresponding memory location.
@@ -29,7 +29,7 @@ In this example, the first fragment creates a D global variable pointer `q`. Bec
**Parent topic:**[D Program Syntax Reference](../reference/d_program_syntax_reference.md)
-## Pointer Safety {#dt_ptrsafety_dlang}
+## Pointer Safety <a id="dt_ptrsafety_dlang">
DTrace is a robust, safe environment for running D programs. You might write a buggy D program, but invalid D pointer accesses don't cause DTrace or the OS kernel to fail or crash in any way. Instead, the DTrace software detects any invalid pointer accesses, and returns a `BADADDR` fault; the current clause execution quits, an ERROR probe fires, and tracing continues unless the program called `[exit](function_exit.md)` for the ERROR probe.
@@ -55,7 +55,7 @@ dtrace: error on enabled probe ID 2 (ID 1: dtrace:::BEGIN): invalid address (0x0
Notice that the D program moves past the error and continues to run; the system and all observed processes remain unperturbed. You can also add an `ERROR` probe to any script to handle D errors. For details about the DTrace error mechanism, see [ERROR Probe](dtrace_providers_dtrace.md).
-## Pointer and Array Relationship {#dt_ptrarel_dlang}
+## Pointer and Array Relationship <a id="dt_ptrarel_dlang">
A scalar array is represented by a variable that's associated with the address of its first storage location. A pointer is also the address of a storage location with a defined type. Thus, D permits the use of the array `[]` index notation with both pointer variables and array variables. For example, the following two D fragments are equivalent in meaning:
@@ -71,7 +71,7 @@ The difference between pointers and arrays is that a pointer variable refers to
This difference is manifested in the D syntax if you try to assign pointers and scalar arrays. If `x` and `y` are pointer variables, the expression `x = y` is legal; it copies the pointer address in `y` to the storage location that's named by `x`. If `x` and `y` are scalar array variables, the expression `x = y` isn't legal. Arrays can't be assigned as a whole in D. If `p` is a pointer and `a` is a scalar array, the statement `p = a` is permitted. This statement is equivalent to the statement `p = &a[0]`.
-## Pointer Arithmetic {#dt_ptrarith_dlang}
+## Pointer Arithmetic <a id="dt_ptrarith_dlang">
As in C, pointer arithmetic in D isn't identical to integer arithmetic. Pointer arithmetic implicitly adjusts the underlying address by multiplying or dividing the operands by the size of the type referenced by the pointer.
@@ -106,17 +106,17 @@ BEGIN
}
```
-## Generic Pointers {#dt_genptr_dlang}
+## Generic Pointers <a id="dt_genptr_dlang">
Sometimes it's useful to represent or manipulate a generic pointer address in a D program without specifying the type of data referred to by the pointer. Generic pointers can be specified by using the type `void *`, where the keyword `void` represents the absence of specific type information, or by using the built-in type alias `uintptr_t`, which is aliased to an unsigned integer type of size that's appropriate for a pointer in the current data model. You can't apply pointer arithmetic to an object of type `void *`, and these pointers can't be dereferenced without casting them to another type first. You can cast a pointer to the `uintptr_t` type when you need to perform integer arithmetic on the pointer value.
Pointers to `void` can be used in any context where a pointer to another data type is required, such as an associative array tuple expression or the right-hand side of an assignment statement. Similarly, a pointer to any data type can be used in a context where a pointer to `void` is required. To use a pointer to a non-`void` type in place of another non-`void` pointer type, an explicit cast is required. You must always use explicit casts to convert pointers to integer types, such as `uintptr_t`, or to convert these integers back to the appropriate pointer type.
-## Pointers to DTrace Objects {#dt_ptrobj_dlang}
+## Pointers to DTrace Objects <a id="dt_ptrobj_dlang">
The D compiler prohibits you from using the `&` operator to obtain pointers to DTrace objects such as associative arrays, built-in functions, and variables. You're prohibited from obtaining the address of these variables so that the DTrace runtime environment is free to relocate them as needed between probe firings . In this way, DTrace can more efficiently manage the memory required for programs. If you create composite structures, it's possible to construct expressions that retrieve the kernel address of DTrace object storage. Avoid creating such expressions in D programs. If you need to use such an expression, don't rely on the address being the same across probe firings.
-## Pointers and Address Spaces {#dt_ptraddrsp_dlang}
+## Pointers and Address Spaces <a id="dt_ptraddrsp_dlang">
A pointer is an address that provides a translation within some *virtual address space* to a piece of physical memory. DTrace runs D programs within the address space of the OS kernel itself. The Linux system manages many address spaces: one for the OS kernel itself, and one for each user process. Because each address space provides the illusion that it can access all the memory on the system, the same virtual address pointer value can be reused across address spaces, but translate to different physical memory. Therefore, when writing D programs that use pointers, you must be aware of the address space corresponding to the pointers you intend to use.
diff --git a/doc/userguide/reference/dtrace-ref-StructsandUnions.md b/doc/userguide/reference/dtrace-ref-StructsandUnions.md
index aa4f092df..ba55bcf55 100644
--- a/doc/userguide/reference/dtrace-ref-StructsandUnions.md
+++ b/doc/userguide/reference/dtrace-ref-StructsandUnions.md
@@ -1,11 +1,11 @@
-# Structs and Unions {#dt_structunion_dlang}
+# Structs and Unions <a id="dt_structunion_dlang">
Collections of related variables can be grouped together into composite data objects called *structs* and *unions*. You define these objects in D by creating new type definitions for them. You can use any new types for any D variables, including associative array values. This section explores the syntax and semantics for creating and manipulating these composite types and the D operators that interact with them.
**Parent topic:**[D Program Syntax Reference](../reference/d_program_syntax_reference.md)
-## Structs {#dt_structs_dlang}
+## Structs <a id="dt_structs_dlang">
The D keyword `struct`, short for *structure*, is used to introduce a new type that's composed of a group of other types. The new `struct` type can be used as the type for D variables and arrays, enabling you to define groups of related variables under a single name. D structs are the same as the corresponding construct in C and C++. If you have programmed in the Java programming language, think of a D struct as a class that contains only data members and no methods.
@@ -122,7 +122,7 @@ The `date` program runs and is traced until it exits and fires the `END` probe w
write 1 29 9817
```
-## Pointers to Structs {#dt_ptrstructs_dlang}
+## Pointers to Structs <a id="dt_ptrstructs_dlang">
Referring to structs by using pointers is common in C and D. You can use the operator `->` to access struct members through a pointer. If `struct s` has a member `m`, and you have a pointer to this struct named `sp`, where `sp` is a variable of type `struct s *`, you can either use the `*` operator to first dereference the `sp` pointer to access the member:
@@ -217,11 +217,11 @@ date -R run by UID 500
Complex data structures are used often in C programs, so the ability to describe and reference structs from D also provides a powerful capability for observing the inner workings of the Linux kernel and its system interfaces.
-## Unions {#dt_unions_dlang}
+## Unions <a id="dt_unions_dlang">
Unions are another kind of composite type available in ANSI C and D and are related to structs. A union is a composite type where a set of members of different types are defined and the member objects all occupy the same region of storage. A union is therefore an object of variant type, where only one member is valid at any particular time, depending on how the union has been assigned. Typically, some other variable, or piece of state is used to indicate which union member is currently valid. The size of a union is the size of its largest member. The memory alignment that's used for the union is the maximum alignment required by the union members.
-## Member Sizes and Offsets {#dt_memsz_dlang}
+## Member Sizes and Offsets <a id="dt_memsz_dlang">
You can determine the size in bytes of any D type or expression, including a `struct` or `union`, by using the `sizeof` operator. The `sizeof` operator can be applied either to an expression or to the name of a type surrounded by parentheses, as illustrated in the following two examples:
@@ -240,7 +240,7 @@ offsetof (*type-name*, *member-name*)
Here, *type-name* is the name of any `struct` or `union` type or type alias, and *member-name* is the identifier naming a member of that struct or union. Similar to `sizeof`, `offsetof` returns a `size_t` and you can use it anywhere in a D program that an integer constant can be used.
-## Bit-Fields {#dt_bitflds_dlang}
+## Bit-Fields <a id="dt_bitflds_dlang">
D also permits the definition of integer struct and union members of arbitrary numbers of bits, known as *bit-fields*. A bit-field is declared by specifying a signed or unsigned integer base type, a member name, and a suffix indicating the number of bits to be assigned for the field, as shown in the following example:
diff --git a/doc/userguide/reference/dtrace-ref-TypesOperatorsandExpressions.md b/doc/userguide/reference/dtrace-ref-TypesOperatorsandExpressions.md
index 1a1549445..c76d293c7 100644
--- a/doc/userguide/reference/dtrace-ref-TypesOperatorsandExpressions.md
+++ b/doc/userguide/reference/dtrace-ref-TypesOperatorsandExpressions.md
@@ -1,11 +1,11 @@
-# Types, Operators, and Expressions {#dt_types_dlang}
+# Types, Operators, and Expressions <a id="dt_types_dlang">
D provides the ability to access and manipulate various data objects: variables and data structures can be created and changed, data objects that are defined in the OS kernel and user processes can be accessed, and integer, floating-point, and string constants can be declared. D provides a superset of the ANSI C operators that are used to manipulate objects and create complex expressions. This section describes the detailed set of rules for types, operators, and expressions.
**Parent topic:**[D Program Syntax Reference](../reference/d_program_syntax_reference.md)
-## Identifier Names and Keywords {#dt_ident_dlang}
+## Identifier Names and Keywords <a id="dt_ident_dlang">
D identifier names are composed of uppercase and lowercase letters, digits, and underscores, where the first character must be a letter or underscore. All identifier names beginning with an underscore \(`_`\) are reserved for use by the D system libraries. Avoid using these names in D programs. By convention, D programmers typically use mixed-case names for variables and all uppercase names for constants.
@@ -203,7 +203,7 @@ D language keywords are special identifiers that are reserved for use in the pro
</td></tr><tbody></table>
D reserves for use as keywords a superset of the ANSI C keywords. The keywords reserved for future use by the D language are marked with `*`. The D compiler produces a syntax error if you try to use a keyword that's reserved for future use. The keywords that are defined by D but not defined by ANSI C are marked with `+`. D provides the complete set of types and operators found in ANSI C. The major difference in D programming is the absence of control-flow constructs. Note that keywords associated with control-flow in ANSI C are reserved for future use in D.
-## Data Types and Sizes {#dt_dtypes_dlang}
+## Data Types and Sizes <a id="dt_dtypes_dlang">
D provides fundamental data types for integers and floating-point constants. Arithmetic can only be performed on integers in D programs. Floating-point constants can be used to initialize data structures, but floating-point arithmetic isn't permitted in D. D provides a 64-bit data model for use in writing programs.
@@ -392,7 +392,7 @@ Type Name
</td></tr><tbody></table>
D also provides the special type `string` to represent ASCII strings. Strings are discussed in more detail in [DTrace String Processing](dtrace-ref-DTraceSupportforStrings.md).
-## Constants {#dt_consts_dlang}
+## Constants <a id="dt_consts_dlang">
Integer constants can be written in decimal \(`12345`\), octal \(`012345`\), or hexadecimal `(0x12345`\) format. Octal \(base 8\) constants must be prefixed with a leading zero. Hexadecimal \(base 16\) constants must be prefixed with either `0x` or `0X`. Integer constants are assigned the smallest type among `int`, `long`, and `long long` that can represent their value. If the value is negative, the signed version of the type is used. If the value is positive and too large to fit in the signed type representation, the unsigned type representation is used. You can apply one of the suffixes listed in the following table to any integer constant to explicitly specify its D type.
@@ -607,7 +607,7 @@ You can include more than one character specifier inside single quotes to create
Strings constants of any length can be composed by enclosing them in a pair of double quotes \(`"hello"`\). A string constant can't contain a literal newline character. To create strings containing newlines, use the `\n` escape sequence instead of a literal newline. String constants can contain any of the special character escape sequences that are shown for character constants before. Similar to ANSI C, strings are represented as arrays of characters that end with a null character \(`\0`\) that's implicitly added to each string constant you declare. String constants are assigned the special D type `string`. The D compiler provides a set of special features for comparing and tracing character arrays that are declared as strings.
-## Arithmetic Operators {#dt_arithops_dlang}
+## Arithmetic Operators <a id="dt_arithops_dlang">
Binary arithmetic operators are described in the following table. These operators all have the same meaning for integers that they do in ANSI C.
@@ -666,7 +666,7 @@ However, the DTrace execution environment does automatically check for and repor
In addition to these binary operators, the `+` and `-` operators can also be used as unary operators, and these operators have higher precedence than any of the binary arithmetic operators. The order of precedence and associativity properties for all D operators is presented in [Operator Precedence](dtrace-ref-TypesOperatorsandExpressions.md). You can control precedence by grouping expressions in parentheses \(`()`\).
-## Relational Operators {#dt_relatops_dlang}
+## Relational Operators <a id="dt_relatops_dlang">
Binary relational operators are described in the following table. These operators all have the same meaning that they do in ANSI C.
@@ -766,7 +766,7 @@ Returns 0 \(`false`\)
</td></tr><tbody></table>
Relational operators can also be used to compare a data object associated with an enumeration type with any of the enumerator tags defined by the enumeration.
-## Logical Operators {#dt_logicops_dlang}
+## Logical Operators <a id="dt_logicops_dlang">
Binary logical operators are listed in the following table. The first two operators are equivalent to the corresponding ANSI C operators.
@@ -809,7 +809,7 @@ In addition to the binary logical operators, the unary `!` operator can be used
The logical operators can be applied to operands of integer or pointer types. The logical operators interpret pointer operands as unsigned integer values. As with all logical and relational operators in D, operands are true if they have a non-zero integer value and false if they have a zero integer value.
-## Bitwise Operators {#dt_bitwiseops_dlang}
+## Bitwise Operators <a id="dt_bitwiseops_dlang">
D provides the bitwise operators that are listed in the following table for manipulating individual bits inside integer operands. These operators all have the same meaning as in ANSI C.
@@ -874,7 +874,7 @@ The shift operators are used to move bits left or right in a particular integer
Shifting an integer value by a negative number of bits or by a number of bits larger than the number of bits in the left-hand operand itself produces an undefined result. The D compiler produces an error message if the compiler can detect this condition when you compile the D program.
-## Assignment Operators {#dt_assignops_dlang}
+## Assignment Operators <a id="dt_assignops_dlang">
Binary assignment operators are listed in the following table. You can only modify D variables and arrays. Kernel data objects and constants can not be modified using the D assignment operators. The assignment operators have the same meaning as they do in ANSI C.
@@ -979,7 +979,7 @@ Aside from the assignment operator `=`, the other assignment operators are provi
The result of any assignment operator is an expression equal to the new value of the left-hand expression. You can use the assignment operators or any of the operators described thus far in combination to form expressions of arbitrary complexity. You can use parentheses `()` to group terms in complex expressions.
-## Increment and Decrement Operators {#dt_incdecops_dlang}
+## Increment and Decrement Operators <a id="dt_incdecops_dlang">
D provides the special unary `++` and `--` operators for incrementing and decrementing pointers and integers. These operators have the same meaning as they do in ANSI C. These operators can be applied to variables and to the individual elements of a struct, union, or array. The operators can be applied either before or after the variable name. If the operator appears before the variable name, the variable is first changed and then the resulting expression is equal to the new value of the variable. For example, the following two code fragments produce identical results:
@@ -1012,7 +1012,7 @@ foo[1]++;
The increment and decrement operators can be applied to integer or pointer variables. When applied to integer variables, the operators increment, or decrement the corresponding value by one. When applied to pointer variables, the operators increment, or decrement the pointer address by the size of the data type that's referenced by the pointer.
-## Conditional Expressions {#dt_condexp_dlang}
+## Conditional Expressions <a id="dt_condexp_dlang">
D doesn't provide the facility to use `if-then-else` constructs. Instead, conditional expressions, by using the ternary operator \(`?:`\), can be used to approximate some of this functionality. The ternary operator associates a triplet of expressions, where the first expression is used to conditionally evaluate one of the other two.
@@ -1032,7 +1032,7 @@ hexval = (c >= '0' && c <= '9') ? c - '0' : (c >= 'a' && c <= 'f') ? c + 10 - 'a
To be evaluated for its truth value, the first expression that's used with `?:` must be a pointer or integer. The second and third expressions can be of any compatible types. You can't construct a conditional expression where, for example, one path returns a string and another path returns an integer. The second and third expressions must be true expressions that have a value. Therefore, data reporting functions can't be used in these expressions because those functions don't return a value. To conditionally trace data, use a predicate instead.
-## Type Conversions {#dt_typeconv_dlang}
+## Type Conversions <a id="dt_typeconv_dlang">
When expressions are constructed by using operands of different but compatible types, type conversions are performed to determine the type of the resulting expression. The D rules for type conversions are the same as the arithmetic conversion rules for integers in ANSI C. These rules are sometimes referred to as the *usual arithmetic conversions*.
@@ -1052,7 +1052,7 @@ In this example, the destination type is within parentheses and used to prefix t
Because D doesn't include floating-point arithmetic, no floating-point operand conversion or casting is permitted and no rules for implicit floating-point conversion are defined.
-## Operator Precedence {#dt_preced_dlang}
+## Operator Precedence <a id="dt_preced_dlang">
D includes complex rules for operator precedence and associativity. The rules provide precise compatibility with the ANSI C operator precedence rules. The entries in the following table are in order from highest precedence to lowest precedence.
@@ -1268,11 +1268,11 @@ Dereferences a pointer to an object.
Accesses a member of a structure or union type.
</td></tr><tbody></table>
-## Type and Constant Definitions {#dt_typcondef_dlang}
+## Type and Constant Definitions <a id="dt_typcondef_dlang">
This section describes how to declare type aliases and named constants in D. It also discusses D type and namespace management for program and OS types and identifiers.
-### typedefs {#dt_typedefs_dlang}
+### typedefs <a id="dt_typedefs_dlang">
The `typedef` keyword is used to declare an identifier as an alias for an existing type. The `typedef` declaration is used outside of probe clauses in the following form:
@@ -1297,7 +1297,7 @@ typedef struct foo {
In the previous example, `struct foo` is defined using the same type as its alias, `foo_t`. Linux C system headers often use the suffix `_t` to denote a `typedef` alias.
-### Enumerations {#dt_enums_dlang}
+### Enumerations <a id="dt_enums_dlang">
Defining symbolic names for constants in a program eases readability and simplifies the process of maintaining the program in the future. One method is to define an *enumeration*, which associates a set of integers with a set of identifiers called enumerators that the compiler recognizes and replaces with the corresponding integer value. An enumeration is defined by using a declaration such as the following:
@@ -1329,7 +1329,7 @@ The D enumeration syntax is the same as the corresponding syntax in ANSI C. D al
-### Inlines {#dt_inlines_dlang}
+### Inlines <a id="dt_inlines_dlang">
D named constants can also be defined by using `inline` directives, which provide a more general means of creating identifiers that are replaced by predefined values or expressions during compilation. Inline directives are a more powerful form of lexical replacement than the `#define` directive provided by the C preprocessor because the replacement is assigned an actual type and is performed by using the compiled syntax tree and not a set of lexical tokens. An `inline` directive is specified by using a declaration of the following form:
@@ -1371,7 +1371,7 @@ These inline definitions provide you with access to the current set of Linux sig
By default, the D compiler includes all the provided D library files automatically so that you can use these definitions in any D program.
-### Type Namespaces {#dt_typens_dlang}
+### Type Namespaces <a id="dt_typens_dlang">
In traditional languages such as ANSI C, type visibility is determined by whether a type is nested inside a function or other declaration. Types declared at the outer scope of a C program are associated with a single global namespace and are visible throughout the entire program. Types that are defined in C header files are typically included in this outer scope. Unlike these languages, D provides access to types from several outer scopes.
diff --git a/doc/userguide/reference/dtrace-ref-Variables.md b/doc/userguide/reference/dtrace-ref-Variables.md
index bc10071ca..d3afa3833 100644
--- a/doc/userguide/reference/dtrace-ref-Variables.md
+++ b/doc/userguide/reference/dtrace-ref-Variables.md
@@ -1,5 +1,5 @@
-# Variables {#dt_vars_dlang}
+# Variables <a id="dt_vars_dlang">
D provides several variable types: scalar variables, associative arrays, scalar arrays, and multidimensional scalar arrays. Variables can be created by declaring them explicitly, but are most often created implicitly on first use. Variables can be restricted to clause or thread scope to avoid name conflicts and to control the lifetime of a variable explicitly.
@@ -80,7 +80,7 @@ D provides several variable types: scalar variables, associative arrays, scalar
**Parent topic:**[D Program Syntax Reference](../reference/d_program_syntax_reference.md)
-## Variable Scope {#dt_vscope_dlang}
+## Variable Scope <a id="dt_vscope_dlang">
Variable scoping is used to define where variable names are valid within a program and to avoid variable naming collisions. By using scoped variables you can control the availability of the variable instance to the whole program, a particular thread, or a specific clause.
diff --git a/doc/userguide/reference/dtrace-ref-speculation.md b/doc/userguide/reference/dtrace-ref-speculation.md
index 181d45db3..30c5e6eaa 100644
--- a/doc/userguide/reference/dtrace-ref-speculation.md
+++ b/doc/userguide/reference/dtrace-ref-speculation.md
@@ -1,5 +1,5 @@
-# Speculation {#dt_ref_speculation}
+# Speculation <a id="dt_ref_speculation">
DTrace includes a speculative tracing facility that can be used to tentatively trace data at one or more probe locations. You can then decide to commit the data to the principal buffer at another probe location. You can use speculation to trace data that only contains the output that's of interest; no extra processing is required and the DTrace overhead is minimized.
diff --git a/doc/userguide/reference/dtrace_command_desc.md b/doc/userguide/reference/dtrace_command_desc.md
index eeb45509c..64edfe648 100644
--- a/doc/userguide/reference/dtrace_command_desc.md
+++ b/doc/userguide/reference/dtrace_command_desc.md
@@ -1,5 +1,5 @@
-# About the dtrace Command {#dtrace_command_desc}
+# About the dtrace Command <a id="dtrace_command_desc">
The `dtrace` command provides a generic interface to all the essential services that are provided by the DTrace facility.
diff --git a/doc/userguide/reference/dtrace_command_exit_status.md b/doc/userguide/reference/dtrace_command_exit_status.md
index 97aaa7100..d1a321799 100644
--- a/doc/userguide/reference/dtrace_command_exit_status.md
+++ b/doc/userguide/reference/dtrace_command_exit_status.md
@@ -1,5 +1,5 @@
-# dtrace Command Exit Status {#dtrace_command_exit_status}
+# dtrace Command Exit Status <a id="dtrace_command_exit_status">
The following exit values are returned by the `dtrace` command:
diff --git a/doc/userguide/reference/dtrace_command_operands.md b/doc/userguide/reference/dtrace_command_operands.md
index d5261b225..03db4b976 100644
--- a/doc/userguide/reference/dtrace_command_operands.md
+++ b/doc/userguide/reference/dtrace_command_operands.md
@@ -1,5 +1,5 @@
-# dtrace Command Operands {#dtrace_command_operands}
+# dtrace Command Operands <a id="dtrace_command_operands">
You can specify zero or more extra arguments on the `dtrace` command line to define a set of macro variables, such as `$1`, `$2`, and so on, to be used in any D programs that are specified with the `-s` option or on the command line.
diff --git a/doc/userguide/reference/dtrace_command_options.md b/doc/userguide/reference/dtrace_command_options.md
index 86c41abf1..8b8bcea19 100644
--- a/doc/userguide/reference/dtrace_command_options.md
+++ b/doc/userguide/reference/dtrace_command_options.md
@@ -1,5 +1,5 @@
-# dtrace Command Options {#dtrace_command_options}
+# dtrace Command Options <a id="dtrace_command_options">
The `dtrace` command accepts the following options:
diff --git a/doc/userguide/reference/dtrace_runtime_options.md b/doc/userguide/reference/dtrace_runtime_options.md
index 766709af2..f59223916 100644
--- a/doc/userguide/reference/dtrace_runtime_options.md
+++ b/doc/userguide/reference/dtrace_runtime_options.md
@@ -1,5 +1,5 @@
-# DTrace Runtime and Compile-time Options Reference {#dt_runtime_options}
+# DTrace Runtime and Compile-time Options Reference <a id="dt_runtime_options">
DTrace uses reasonable default values and flexible default policies for runtime configuration. Tuning mechanisms in the form of DTrace compiler or runtime option can change the default behavior of the `dtrace` utility. You can find more information about the `dtrace` utility and various command line options in the `dtrace(8)` manual page.
diff --git a/doc/userguide/reference/dynamic_runtime_options.md b/doc/userguide/reference/dynamic_runtime_options.md
index a42ed3e7b..5c56a05e3 100644
--- a/doc/userguide/reference/dynamic_runtime_options.md
+++ b/doc/userguide/reference/dynamic_runtime_options.md
@@ -1,5 +1,5 @@
-# Dynamic Runtime Options {#dt_dynamic_runtime_options}
+# Dynamic Runtime Options <a id="dt_dynamic_runtime_options">
Dynamic runtime options are specific to D programs themselves and are likely to change depending on program functionality and requirements.
diff --git a/doc/userguide/reference/setting_dtrace_compiler_and_runtime_options.md b/doc/userguide/reference/setting_dtrace_compiler_and_runtime_options.md
index f978c7825..0f0224bf3 100644
--- a/doc/userguide/reference/setting_dtrace_compiler_and_runtime_options.md
+++ b/doc/userguide/reference/setting_dtrace_compiler_and_runtime_options.md
@@ -1,5 +1,5 @@
-# Setting DTrace Compile-time and Runtime Options {#dt_runtime_option_description}
+# Setting DTrace Compile-time and Runtime Options <a id="dt_runtime_option_description">
You can tune DTrace by setting or enabling a selection of runtime or compiler options. You can set options by either using the `-x` command line switch when running the `dtrace` command, or by specifying `pragma` lines in D programs. If an option takes a value, follow the option name with an equal sign \(`=`\) and the option value.
--
2.47.3
^ permalink raw reply related [flat|nested] 28+ messages in thread* Re: [DTrace-devel] [PATCH v2 12/20] doc: Fix anchor links for reference/
2025-10-22 3:22 ` [PATCH v2 12/20] doc: Fix anchor links for reference/ eugene.loh
@ 2025-10-23 19:28 ` Elena Zannoni
0 siblings, 0 replies; 28+ messages in thread
From: Elena Zannoni @ 2025-10-23 19:28 UTC (permalink / raw)
To: eugene.loh, dtrace, dtrace-devel
Reviewed-by: Elena Zannoni <elena.zannoni@oracle.com>
On 10/21/25 9:22 PM, eugene.loh--- via DTrace-devel wrote:
> From: Eugene Loh <eugene.loh@oracle.com>
>
> Signed-off-by: Eugene Loh <eugene.loh@oracle.com>
> ---
> doc/userguide/reference/aggregation.md | 8 ++---
> doc/userguide/reference/compiler_options.md | 2 +-
> ...gram_syntax_reference_program_structure.md | 2 +-
> .../dtrace-ref-DTraceSupportforStrings.md | 12 +++----
> .../dtrace-ref-PointersandScalarArrays.md | 14 ++++----
> .../reference/dtrace-ref-StructsandUnions.md | 12 +++----
> ...dtrace-ref-TypesOperatorsandExpressions.md | 36 +++++++++----------
> .../reference/dtrace-ref-Variables.md | 4 +--
> .../reference/dtrace-ref-speculation.md | 2 +-
> .../reference/dtrace_command_desc.md | 2 +-
> .../reference/dtrace_command_exit_status.md | 2 +-
> .../reference/dtrace_command_operands.md | 2 +-
> .../reference/dtrace_command_options.md | 2 +-
> .../reference/dtrace_runtime_options.md | 2 +-
> .../reference/dynamic_runtime_options.md | 2 +-
> ...ing_dtrace_compiler_and_runtime_options.md | 2 +-
> 16 files changed, 53 insertions(+), 53 deletions(-)
>
> diff --git a/doc/userguide/reference/aggregation.md b/doc/userguide/reference/aggregation.md
> index 8bdd44b49..5fada5410 100644
> --- a/doc/userguide/reference/aggregation.md
> +++ b/doc/userguide/reference/aggregation.md
> @@ -1,5 +1,5 @@
>
> -# Aggregations {#dt_ref_aggregations}
> +# Aggregations <a id="dt_ref_aggregations">
>
> Aggregations enable you to accumulate data for statistical analysis. The aggregation is calculated at runtime, so that post-processing isn't required and processing is highly efficient and accurate. Aggregations function similarly to associative arrays, but are populated by aggregating functions. In D, the syntax for an aggregation is as follows:
>
> @@ -13,7 +13,7 @@ Aggregations can be regular or indexed. Indexed aggregations use keys, where *ke
>
> The *aggfunc* is one of the DTrace aggregating functions, and *args* is a comma-separated list of arguments appropriate to that function. Most aggregating functions take a single argument that represents the new datum.
>
> -## Aggregation Functions {#dt_ref_aggr_funcs}
> +## Aggregation Functions <a id="dt_ref_aggr_funcs">
>
> The following functions are aggregating functions that can be used in a program to collect data and present it in a meaningful way.
>
> @@ -36,7 +36,7 @@ The following functions are aggregating functions that can be used in a program
> - `[llquantize](aggregation_llquantize.md)`: Stores the log-linear frequency distribution in an aggregation.
>
>
> -## Printing Aggregations {#dt_ref_aggr_print}
> +## Printing Aggregations <a id="dt_ref_aggr_print">
>
> By default, several aggregations are displayed in the order in which they're introduced in the D program. You can override this behavior by using the `[printa](function_printa.md)` function to print the aggregations. The `printa` function also lets you precisely format the aggregation data by using a format string.
>
> @@ -44,7 +44,7 @@ If an aggregation isn't formatted with a `printa` statement in a D program, the
>
> The default output format for the `avg`, `count`, `min`, `max`, `stddev`, and `sum` aggregating functions displays an integer decimal value corresponding to the aggregated value for each tuple. The default output format for the `quantize`, `lquantize`, and `llquantize` aggregating functions displays an ASCII histogram with the results. Aggregation tuples are printed as though `trace` had been applied to each tuple element.
>
> -## Data Normalization {#dt_ref_aggr_dnorm}
> +## Data Normalization <a id="dt_ref_aggr_dnorm">
>
> When aggregating data over some period, you might want to normalize the data based on some constant factor. This technique lets you compare disjointed data more easily. For example, when aggregating system calls, you might want to output system calls as a per-second rate instead of as an absolute value over the course of the run. The DTrace `[normalize](function_normalize.md)` function lets you normalize data in this way. The parameters to `normalize` are an aggregation and a normalization factor. The output of the aggregation shows each value divided by the normalization factor.
>
> diff --git a/doc/userguide/reference/compiler_options.md b/doc/userguide/reference/compiler_options.md
> index 8e2813c1f..3cc4c72ff 100644
> --- a/doc/userguide/reference/compiler_options.md
> +++ b/doc/userguide/reference/compiler_options.md
> @@ -1,5 +1,5 @@
>
> -# Compile-time Options {#dt_compiler_options}
> +# Compile-time Options <a id="dt_compiler_options">
>
> Compile-time options can control how DTrace programs are compiled into eBPF code that's loaded into kernel space.
>
> diff --git a/doc/userguide/reference/d_program_syntax_reference_program_structure.md b/doc/userguide/reference/d_program_syntax_reference_program_structure.md
> index 547fd7a36..dc6a31a3b 100644
> --- a/doc/userguide/reference/d_program_syntax_reference_program_structure.md
> +++ b/doc/userguide/reference/d_program_syntax_reference_program_structure.md
> @@ -1,5 +1,5 @@
>
> -# Program Structure {#dt_prog_struct}
> +# Program Structure <a id="dt_prog_struct">
>
> A D program consists of a set of clauses that describe the probes to enable, an optional predicate that controls when to run, and one or more statements that often describe some functionality to implement when the probe fires.
>
> diff --git a/doc/userguide/reference/dtrace-ref-DTraceSupportforStrings.md b/doc/userguide/reference/dtrace-ref-DTraceSupportforStrings.md
> index 98f482c63..ea44523ed 100644
> --- a/doc/userguide/reference/dtrace-ref-DTraceSupportforStrings.md
> +++ b/doc/userguide/reference/dtrace-ref-DTraceSupportforStrings.md
> @@ -1,11 +1,11 @@
>
> -# DTrace String Processing {#dt_strings_dlang}
> +# DTrace String Processing <a id="dt_strings_dlang">
>
> DTrace provides facilities for tracing and manipulating strings. This section describes the complete set of D language features for declaring and manipulating strings. Unlike ANSI C, strings in D have their own built-in type and operator support to enable you to easily and unambiguously use them in tracing programs.
>
> **Parent topic:**[D Program Syntax Reference](../reference/d_program_syntax_reference.md)
>
> -## String Representation {#dt_strrep_dlang}
> +## String Representation <a id="dt_strrep_dlang">
>
> In DTrace, strings are represented as an array of characters ending in a null byte, which is a byte with a value of zero, usually written as `'\0'`. The visible part of the string is of variable length, depending on the location of the null byte, but DTrace stores each string in a fixed-size array so that each probe traces a consistent amount of data. Strings cannot exceed the length of the predefined string limit. However, the limit can be modified in your D program or on the `dtrace` command line by tuning the `strsize` option. The default string limit is 256 bytes.
>
> @@ -33,13 +33,13 @@ trace(s);
>
> You can also perform lexical comparison of expressions of type string. See [String Comparison](dtrace-ref-DTraceSupportforStrings.md).
>
> -## String Constants {#dt_strcon_dlang}
> +## String Constants <a id="dt_strcon_dlang">
>
> String constants are enclosed in pairs of double quotes \(`""`\) and are automatically assigned the type `string` by the D compiler. You can define string constants of any length, limited only by the amount of memory DTrace is permitted to consume on the system and by whatever limit you have set for the `strsize` DTrace runtime option. The terminating null byte \(`\0`\) is added automatically by the D compiler to any string constants that you declare. The size of a string constant object is the number of bytes associated with the string, plus one additional byte for the terminating null byte.
>
> A string constant can't contain a literal newline character. To create strings containing newlines, use the `\n` escape sequence instead of a literal newline. String constants can also contain any of the special character escape sequences that are defined for character constants.
>
> -## String Assignment {#dt_strasg_dlang}
> +## String Assignment <a id="dt_strasg_dlang">
>
> Unlike the assignment of `char *` variables, strings are copied by value and not by reference. The string assignment operator `=` copies the actual bytes of the string from the source operand up to and including the null byte to the variable on the left-hand side, which must be of type `string`.
>
> @@ -63,7 +63,7 @@ String assignment is analogous to the C library function `strcpy()`, with the ex
>
> You can also assign to a string variable an expression of a type that's compatible with strings. In this case, the D compiler automatically promotes the source expression to the string type and performs a string assignment. The D compiler permits any expression of type `char *` or of type `char[n]`, a scalar array of `char` of any size, to be promoted to a string.
>
> -## String Conversion {#dt_strconv_dlang}
> +## String Conversion <a id="dt_strconv_dlang">
>
> Expressions of other types can be explicitly converted to type `string` by using a cast expression or by applying the special `stringof` operator, which are equivalent in the following meaning:
>
> @@ -78,7 +78,7 @@ The `stringof` operator binds very tightly to the operand on its right-hand side
>
> Scalar type expressions, such as a pointer or integer, or a scalar array address can be converted to strings, in that the scalar is interpreted as an address to a char type. Expressions of other types such as `void` may not be converted to `string`. If you erroneously convert an invalid address to a string, the DTrace safety features prevents you from damaging the system or DTrace, but you might end up tracing a sequence of undecipherable characters.
>
> -## String Comparison {#dt_strcomp_dlang}
> +## String Comparison <a id="dt_strcomp_dlang">
>
> D overloads the binary relational operators and permits them to be used for string comparisons, as well as integer comparisons. The relational operators perform string comparison whenever both operands are of type `string` or when one operand is of type `string` and the other operand can be promoted to type `string`. See [String Assignment](dtrace-ref-DTraceSupportforStrings.md) for a detailed description. See also [Table 1](dtrace-ref-DTraceSupportforStrings.md#dt_t14_dlang), which lists the relational operators that can be used to compare strings.
>
> diff --git a/doc/userguide/reference/dtrace-ref-PointersandScalarArrays.md b/doc/userguide/reference/dtrace-ref-PointersandScalarArrays.md
> index da4b69333..8746ae2fd 100644
> --- a/doc/userguide/reference/dtrace-ref-PointersandScalarArrays.md
> +++ b/doc/userguide/reference/dtrace-ref-PointersandScalarArrays.md
> @@ -1,5 +1,5 @@
>
> -# Pointers {#dt_ptrarr_dlang}
> +# Pointers <a id="dt_ptrarr_dlang">
>
> Pointers are memory addresses of data objects and reference memory used by the OS, by the user program, or by the D script. Pointers in D are data objects that store an integer virtual address value and associate it with a D type that describes the format of the data stored at the corresponding memory location.
>
> @@ -29,7 +29,7 @@ In this example, the first fragment creates a D global variable pointer `q`. Bec
>
> **Parent topic:**[D Program Syntax Reference](../reference/d_program_syntax_reference.md)
>
> -## Pointer Safety {#dt_ptrsafety_dlang}
> +## Pointer Safety <a id="dt_ptrsafety_dlang">
>
> DTrace is a robust, safe environment for running D programs. You might write a buggy D program, but invalid D pointer accesses don't cause DTrace or the OS kernel to fail or crash in any way. Instead, the DTrace software detects any invalid pointer accesses, and returns a `BADADDR` fault; the current clause execution quits, an ERROR probe fires, and tracing continues unless the program called `[exit](function_exit.md)` for the ERROR probe.
>
> @@ -55,7 +55,7 @@ dtrace: error on enabled probe ID 2 (ID 1: dtrace:::BEGIN): invalid address (0x0
>
> Notice that the D program moves past the error and continues to run; the system and all observed processes remain unperturbed. You can also add an `ERROR` probe to any script to handle D errors. For details about the DTrace error mechanism, see [ERROR Probe](dtrace_providers_dtrace.md).
>
> -## Pointer and Array Relationship {#dt_ptrarel_dlang}
> +## Pointer and Array Relationship <a id="dt_ptrarel_dlang">
>
> A scalar array is represented by a variable that's associated with the address of its first storage location. A pointer is also the address of a storage location with a defined type. Thus, D permits the use of the array `[]` index notation with both pointer variables and array variables. For example, the following two D fragments are equivalent in meaning:
>
> @@ -71,7 +71,7 @@ The difference between pointers and arrays is that a pointer variable refers to
>
> This difference is manifested in the D syntax if you try to assign pointers and scalar arrays. If `x` and `y` are pointer variables, the expression `x = y` is legal; it copies the pointer address in `y` to the storage location that's named by `x`. If `x` and `y` are scalar array variables, the expression `x = y` isn't legal. Arrays can't be assigned as a whole in D. If `p` is a pointer and `a` is a scalar array, the statement `p = a` is permitted. This statement is equivalent to the statement `p = &a[0]`.
>
> -## Pointer Arithmetic {#dt_ptrarith_dlang}
> +## Pointer Arithmetic <a id="dt_ptrarith_dlang">
>
> As in C, pointer arithmetic in D isn't identical to integer arithmetic. Pointer arithmetic implicitly adjusts the underlying address by multiplying or dividing the operands by the size of the type referenced by the pointer.
>
> @@ -106,17 +106,17 @@ BEGIN
> }
> ```
>
> -## Generic Pointers {#dt_genptr_dlang}
> +## Generic Pointers <a id="dt_genptr_dlang">
>
> Sometimes it's useful to represent or manipulate a generic pointer address in a D program without specifying the type of data referred to by the pointer. Generic pointers can be specified by using the type `void *`, where the keyword `void` represents the absence of specific type information, or by using the built-in type alias `uintptr_t`, which is aliased to an unsigned integer type of size that's appropriate for a pointer in the current data model. You can't apply pointer arithmetic to an object of type `void *`, and these pointers can't be dereferenced without casting them to another type first. You can cast a pointer to the `uintptr_t` type when you need to perform integer arithmetic on the pointer value.
>
> Pointers to `void` can be used in any context where a pointer to another data type is required, such as an associative array tuple expression or the right-hand side of an assignment statement. Similarly, a pointer to any data type can be used in a context where a pointer to `void` is required. To use a pointer to a non-`void` type in place of another non-`void` pointer type, an explicit cast is required. You must always use explicit casts to convert pointers to integer types, such as `uintptr_t`, or to convert these integers back to the appropriate pointer type.
>
> -## Pointers to DTrace Objects {#dt_ptrobj_dlang}
> +## Pointers to DTrace Objects <a id="dt_ptrobj_dlang">
>
> The D compiler prohibits you from using the `&` operator to obtain pointers to DTrace objects such as associative arrays, built-in functions, and variables. You're prohibited from obtaining the address of these variables so that the DTrace runtime environment is free to relocate them as needed between probe firings . In this way, DTrace can more efficiently manage the memory required for programs. If you create composite structures, it's possible to construct expressions that retrieve the kernel address of DTrace object storage. Avoid creating such expressions in D programs. If you need to use such an expression, don't rely on the address being the same across probe firings.
>
> -## Pointers and Address Spaces {#dt_ptraddrsp_dlang}
> +## Pointers and Address Spaces <a id="dt_ptraddrsp_dlang">
>
> A pointer is an address that provides a translation within some *virtual address space* to a piece of physical memory. DTrace runs D programs within the address space of the OS kernel itself. The Linux system manages many address spaces: one for the OS kernel itself, and one for each user process. Because each address space provides the illusion that it can access all the memory on the system, the same virtual address pointer value can be reused across address spaces, but translate to different physical memory. Therefore, when writing D programs that use pointers, you must be aware of the address space corresponding to the pointers you intend to use.
>
> diff --git a/doc/userguide/reference/dtrace-ref-StructsandUnions.md b/doc/userguide/reference/dtrace-ref-StructsandUnions.md
> index aa4f092df..ba55bcf55 100644
> --- a/doc/userguide/reference/dtrace-ref-StructsandUnions.md
> +++ b/doc/userguide/reference/dtrace-ref-StructsandUnions.md
> @@ -1,11 +1,11 @@
>
> -# Structs and Unions {#dt_structunion_dlang}
> +# Structs and Unions <a id="dt_structunion_dlang">
>
> Collections of related variables can be grouped together into composite data objects called *structs* and *unions*. You define these objects in D by creating new type definitions for them. You can use any new types for any D variables, including associative array values. This section explores the syntax and semantics for creating and manipulating these composite types and the D operators that interact with them.
>
> **Parent topic:**[D Program Syntax Reference](../reference/d_program_syntax_reference.md)
>
> -## Structs {#dt_structs_dlang}
> +## Structs <a id="dt_structs_dlang">
>
> The D keyword `struct`, short for *structure*, is used to introduce a new type that's composed of a group of other types. The new `struct` type can be used as the type for D variables and arrays, enabling you to define groups of related variables under a single name. D structs are the same as the corresponding construct in C and C++. If you have programmed in the Java programming language, think of a D struct as a class that contains only data members and no methods.
>
> @@ -122,7 +122,7 @@ The `date` program runs and is traced until it exits and fires the `END` probe w
> write 1 29 9817
> ```
>
> -## Pointers to Structs {#dt_ptrstructs_dlang}
> +## Pointers to Structs <a id="dt_ptrstructs_dlang">
>
> Referring to structs by using pointers is common in C and D. You can use the operator `->` to access struct members through a pointer. If `struct s` has a member `m`, and you have a pointer to this struct named `sp`, where `sp` is a variable of type `struct s *`, you can either use the `*` operator to first dereference the `sp` pointer to access the member:
>
> @@ -217,11 +217,11 @@ date -R run by UID 500
>
> Complex data structures are used often in C programs, so the ability to describe and reference structs from D also provides a powerful capability for observing the inner workings of the Linux kernel and its system interfaces.
>
> -## Unions {#dt_unions_dlang}
> +## Unions <a id="dt_unions_dlang">
>
> Unions are another kind of composite type available in ANSI C and D and are related to structs. A union is a composite type where a set of members of different types are defined and the member objects all occupy the same region of storage. A union is therefore an object of variant type, where only one member is valid at any particular time, depending on how the union has been assigned. Typically, some other variable, or piece of state is used to indicate which union member is currently valid. The size of a union is the size of its largest member. The memory alignment that's used for the union is the maximum alignment required by the union members.
>
> -## Member Sizes and Offsets {#dt_memsz_dlang}
> +## Member Sizes and Offsets <a id="dt_memsz_dlang">
>
> You can determine the size in bytes of any D type or expression, including a `struct` or `union`, by using the `sizeof` operator. The `sizeof` operator can be applied either to an expression or to the name of a type surrounded by parentheses, as illustrated in the following two examples:
>
> @@ -240,7 +240,7 @@ offsetof (*type-name*, *member-name*)
>
> Here, *type-name* is the name of any `struct` or `union` type or type alias, and *member-name* is the identifier naming a member of that struct or union. Similar to `sizeof`, `offsetof` returns a `size_t` and you can use it anywhere in a D program that an integer constant can be used.
>
> -## Bit-Fields {#dt_bitflds_dlang}
> +## Bit-Fields <a id="dt_bitflds_dlang">
>
> D also permits the definition of integer struct and union members of arbitrary numbers of bits, known as *bit-fields*. A bit-field is declared by specifying a signed or unsigned integer base type, a member name, and a suffix indicating the number of bits to be assigned for the field, as shown in the following example:
>
> diff --git a/doc/userguide/reference/dtrace-ref-TypesOperatorsandExpressions.md b/doc/userguide/reference/dtrace-ref-TypesOperatorsandExpressions.md
> index 1a1549445..c76d293c7 100644
> --- a/doc/userguide/reference/dtrace-ref-TypesOperatorsandExpressions.md
> +++ b/doc/userguide/reference/dtrace-ref-TypesOperatorsandExpressions.md
> @@ -1,11 +1,11 @@
>
> -# Types, Operators, and Expressions {#dt_types_dlang}
> +# Types, Operators, and Expressions <a id="dt_types_dlang">
>
> D provides the ability to access and manipulate various data objects: variables and data structures can be created and changed, data objects that are defined in the OS kernel and user processes can be accessed, and integer, floating-point, and string constants can be declared. D provides a superset of the ANSI C operators that are used to manipulate objects and create complex expressions. This section describes the detailed set of rules for types, operators, and expressions.
>
> **Parent topic:**[D Program Syntax Reference](../reference/d_program_syntax_reference.md)
>
> -## Identifier Names and Keywords {#dt_ident_dlang}
> +## Identifier Names and Keywords <a id="dt_ident_dlang">
>
> D identifier names are composed of uppercase and lowercase letters, digits, and underscores, where the first character must be a letter or underscore. All identifier names beginning with an underscore \(`_`\) are reserved for use by the D system libraries. Avoid using these names in D programs. By convention, D programmers typically use mixed-case names for variables and all uppercase names for constants.
>
> @@ -203,7 +203,7 @@ D language keywords are special identifiers that are reserved for use in the pro
> </td></tr><tbody></table>
> D reserves for use as keywords a superset of the ANSI C keywords. The keywords reserved for future use by the D language are marked with `*`. The D compiler produces a syntax error if you try to use a keyword that's reserved for future use. The keywords that are defined by D but not defined by ANSI C are marked with `+`. D provides the complete set of types and operators found in ANSI C. The major difference in D programming is the absence of control-flow constructs. Note that keywords associated with control-flow in ANSI C are reserved for future use in D.
>
> -## Data Types and Sizes {#dt_dtypes_dlang}
> +## Data Types and Sizes <a id="dt_dtypes_dlang">
>
> D provides fundamental data types for integers and floating-point constants. Arithmetic can only be performed on integers in D programs. Floating-point constants can be used to initialize data structures, but floating-point arithmetic isn't permitted in D. D provides a 64-bit data model for use in writing programs.
>
> @@ -392,7 +392,7 @@ Type Name
> </td></tr><tbody></table>
> D also provides the special type `string` to represent ASCII strings. Strings are discussed in more detail in [DTrace String Processing](dtrace-ref-DTraceSupportforStrings.md).
>
> -## Constants {#dt_consts_dlang}
> +## Constants <a id="dt_consts_dlang">
>
> Integer constants can be written in decimal \(`12345`\), octal \(`012345`\), or hexadecimal `(0x12345`\) format. Octal \(base 8\) constants must be prefixed with a leading zero. Hexadecimal \(base 16\) constants must be prefixed with either `0x` or `0X`. Integer constants are assigned the smallest type among `int`, `long`, and `long long` that can represent their value. If the value is negative, the signed version of the type is used. If the value is positive and too large to fit in the signed type representation, the unsigned type representation is used. You can apply one of the suffixes listed in the following table to any integer constant to explicitly specify its D type.
>
> @@ -607,7 +607,7 @@ You can include more than one character specifier inside single quotes to create
>
> Strings constants of any length can be composed by enclosing them in a pair of double quotes \(`"hello"`\). A string constant can't contain a literal newline character. To create strings containing newlines, use the `\n` escape sequence instead of a literal newline. String constants can contain any of the special character escape sequences that are shown for character constants before. Similar to ANSI C, strings are represented as arrays of characters that end with a null character \(`\0`\) that's implicitly added to each string constant you declare. String constants are assigned the special D type `string`. The D compiler provides a set of special features for comparing and tracing character arrays that are declared as strings.
>
> -## Arithmetic Operators {#dt_arithops_dlang}
> +## Arithmetic Operators <a id="dt_arithops_dlang">
>
> Binary arithmetic operators are described in the following table. These operators all have the same meaning for integers that they do in ANSI C.
>
> @@ -666,7 +666,7 @@ However, the DTrace execution environment does automatically check for and repor
>
> In addition to these binary operators, the `+` and `-` operators can also be used as unary operators, and these operators have higher precedence than any of the binary arithmetic operators. The order of precedence and associativity properties for all D operators is presented in [Operator Precedence](dtrace-ref-TypesOperatorsandExpressions.md). You can control precedence by grouping expressions in parentheses \(`()`\).
>
> -## Relational Operators {#dt_relatops_dlang}
> +## Relational Operators <a id="dt_relatops_dlang">
>
> Binary relational operators are described in the following table. These operators all have the same meaning that they do in ANSI C.
>
> @@ -766,7 +766,7 @@ Returns 0 \(`false`\)
> </td></tr><tbody></table>
> Relational operators can also be used to compare a data object associated with an enumeration type with any of the enumerator tags defined by the enumeration.
>
> -## Logical Operators {#dt_logicops_dlang}
> +## Logical Operators <a id="dt_logicops_dlang">
>
> Binary logical operators are listed in the following table. The first two operators are equivalent to the corresponding ANSI C operators.
>
> @@ -809,7 +809,7 @@ In addition to the binary logical operators, the unary `!` operator can be used
>
> The logical operators can be applied to operands of integer or pointer types. The logical operators interpret pointer operands as unsigned integer values. As with all logical and relational operators in D, operands are true if they have a non-zero integer value and false if they have a zero integer value.
>
> -## Bitwise Operators {#dt_bitwiseops_dlang}
> +## Bitwise Operators <a id="dt_bitwiseops_dlang">
>
> D provides the bitwise operators that are listed in the following table for manipulating individual bits inside integer operands. These operators all have the same meaning as in ANSI C.
>
> @@ -874,7 +874,7 @@ The shift operators are used to move bits left or right in a particular integer
>
> Shifting an integer value by a negative number of bits or by a number of bits larger than the number of bits in the left-hand operand itself produces an undefined result. The D compiler produces an error message if the compiler can detect this condition when you compile the D program.
>
> -## Assignment Operators {#dt_assignops_dlang}
> +## Assignment Operators <a id="dt_assignops_dlang">
>
> Binary assignment operators are listed in the following table. You can only modify D variables and arrays. Kernel data objects and constants can not be modified using the D assignment operators. The assignment operators have the same meaning as they do in ANSI C.
>
> @@ -979,7 +979,7 @@ Aside from the assignment operator `=`, the other assignment operators are provi
>
> The result of any assignment operator is an expression equal to the new value of the left-hand expression. You can use the assignment operators or any of the operators described thus far in combination to form expressions of arbitrary complexity. You can use parentheses `()` to group terms in complex expressions.
>
> -## Increment and Decrement Operators {#dt_incdecops_dlang}
> +## Increment and Decrement Operators <a id="dt_incdecops_dlang">
>
> D provides the special unary `++` and `--` operators for incrementing and decrementing pointers and integers. These operators have the same meaning as they do in ANSI C. These operators can be applied to variables and to the individual elements of a struct, union, or array. The operators can be applied either before or after the variable name. If the operator appears before the variable name, the variable is first changed and then the resulting expression is equal to the new value of the variable. For example, the following two code fragments produce identical results:
>
> @@ -1012,7 +1012,7 @@ foo[1]++;
>
> The increment and decrement operators can be applied to integer or pointer variables. When applied to integer variables, the operators increment, or decrement the corresponding value by one. When applied to pointer variables, the operators increment, or decrement the pointer address by the size of the data type that's referenced by the pointer.
>
> -## Conditional Expressions {#dt_condexp_dlang}
> +## Conditional Expressions <a id="dt_condexp_dlang">
>
> D doesn't provide the facility to use `if-then-else` constructs. Instead, conditional expressions, by using the ternary operator \(`?:`\), can be used to approximate some of this functionality. The ternary operator associates a triplet of expressions, where the first expression is used to conditionally evaluate one of the other two.
>
> @@ -1032,7 +1032,7 @@ hexval = (c >= '0' && c <= '9') ? c - '0' : (c >= 'a' && c <= 'f') ? c + 10 - 'a
>
> To be evaluated for its truth value, the first expression that's used with `?:` must be a pointer or integer. The second and third expressions can be of any compatible types. You can't construct a conditional expression where, for example, one path returns a string and another path returns an integer. The second and third expressions must be true expressions that have a value. Therefore, data reporting functions can't be used in these expressions because those functions don't return a value. To conditionally trace data, use a predicate instead.
>
> -## Type Conversions {#dt_typeconv_dlang}
> +## Type Conversions <a id="dt_typeconv_dlang">
>
> When expressions are constructed by using operands of different but compatible types, type conversions are performed to determine the type of the resulting expression. The D rules for type conversions are the same as the arithmetic conversion rules for integers in ANSI C. These rules are sometimes referred to as the *usual arithmetic conversions*.
>
> @@ -1052,7 +1052,7 @@ In this example, the destination type is within parentheses and used to prefix t
>
> Because D doesn't include floating-point arithmetic, no floating-point operand conversion or casting is permitted and no rules for implicit floating-point conversion are defined.
>
> -## Operator Precedence {#dt_preced_dlang}
> +## Operator Precedence <a id="dt_preced_dlang">
>
> D includes complex rules for operator precedence and associativity. The rules provide precise compatibility with the ANSI C operator precedence rules. The entries in the following table are in order from highest precedence to lowest precedence.
>
> @@ -1268,11 +1268,11 @@ Dereferences a pointer to an object.
> Accesses a member of a structure or union type.
>
> </td></tr><tbody></table>
> -## Type and Constant Definitions {#dt_typcondef_dlang}
> +## Type and Constant Definitions <a id="dt_typcondef_dlang">
>
> This section describes how to declare type aliases and named constants in D. It also discusses D type and namespace management for program and OS types and identifiers.
>
> -### typedefs {#dt_typedefs_dlang}
> +### typedefs <a id="dt_typedefs_dlang">
>
> The `typedef` keyword is used to declare an identifier as an alias for an existing type. The `typedef` declaration is used outside of probe clauses in the following form:
>
> @@ -1297,7 +1297,7 @@ typedef struct foo {
>
> In the previous example, `struct foo` is defined using the same type as its alias, `foo_t`. Linux C system headers often use the suffix `_t` to denote a `typedef` alias.
>
> -### Enumerations {#dt_enums_dlang}
> +### Enumerations <a id="dt_enums_dlang">
>
> Defining symbolic names for constants in a program eases readability and simplifies the process of maintaining the program in the future. One method is to define an *enumeration*, which associates a set of integers with a set of identifiers called enumerators that the compiler recognizes and replaces with the corresponding integer value. An enumeration is defined by using a declaration such as the following:
>
> @@ -1329,7 +1329,7 @@ The D enumeration syntax is the same as the corresponding syntax in ANSI C. D al
>
>
>
> -### Inlines {#dt_inlines_dlang}
> +### Inlines <a id="dt_inlines_dlang">
>
> D named constants can also be defined by using `inline` directives, which provide a more general means of creating identifiers that are replaced by predefined values or expressions during compilation. Inline directives are a more powerful form of lexical replacement than the `#define` directive provided by the C preprocessor because the replacement is assigned an actual type and is performed by using the compiled syntax tree and not a set of lexical tokens. An `inline` directive is specified by using a declaration of the following form:
>
> @@ -1371,7 +1371,7 @@ These inline definitions provide you with access to the current set of Linux sig
>
> By default, the D compiler includes all the provided D library files automatically so that you can use these definitions in any D program.
>
> -### Type Namespaces {#dt_typens_dlang}
> +### Type Namespaces <a id="dt_typens_dlang">
>
> In traditional languages such as ANSI C, type visibility is determined by whether a type is nested inside a function or other declaration. Types declared at the outer scope of a C program are associated with a single global namespace and are visible throughout the entire program. Types that are defined in C header files are typically included in this outer scope. Unlike these languages, D provides access to types from several outer scopes.
>
> diff --git a/doc/userguide/reference/dtrace-ref-Variables.md b/doc/userguide/reference/dtrace-ref-Variables.md
> index bc10071ca..d3afa3833 100644
> --- a/doc/userguide/reference/dtrace-ref-Variables.md
> +++ b/doc/userguide/reference/dtrace-ref-Variables.md
> @@ -1,5 +1,5 @@
>
> -# Variables {#dt_vars_dlang}
> +# Variables <a id="dt_vars_dlang">
>
> D provides several variable types: scalar variables, associative arrays, scalar arrays, and multidimensional scalar arrays. Variables can be created by declaring them explicitly, but are most often created implicitly on first use. Variables can be restricted to clause or thread scope to avoid name conflicts and to control the lifetime of a variable explicitly.
>
> @@ -80,7 +80,7 @@ D provides several variable types: scalar variables, associative arrays, scalar
>
> **Parent topic:**[D Program Syntax Reference](../reference/d_program_syntax_reference.md)
>
> -## Variable Scope {#dt_vscope_dlang}
> +## Variable Scope <a id="dt_vscope_dlang">
>
> Variable scoping is used to define where variable names are valid within a program and to avoid variable naming collisions. By using scoped variables you can control the availability of the variable instance to the whole program, a particular thread, or a specific clause.
>
> diff --git a/doc/userguide/reference/dtrace-ref-speculation.md b/doc/userguide/reference/dtrace-ref-speculation.md
> index 181d45db3..30c5e6eaa 100644
> --- a/doc/userguide/reference/dtrace-ref-speculation.md
> +++ b/doc/userguide/reference/dtrace-ref-speculation.md
> @@ -1,5 +1,5 @@
>
> -# Speculation {#dt_ref_speculation}
> +# Speculation <a id="dt_ref_speculation">
>
> DTrace includes a speculative tracing facility that can be used to tentatively trace data at one or more probe locations. You can then decide to commit the data to the principal buffer at another probe location. You can use speculation to trace data that only contains the output that's of interest; no extra processing is required and the DTrace overhead is minimized.
>
> diff --git a/doc/userguide/reference/dtrace_command_desc.md b/doc/userguide/reference/dtrace_command_desc.md
> index eeb45509c..64edfe648 100644
> --- a/doc/userguide/reference/dtrace_command_desc.md
> +++ b/doc/userguide/reference/dtrace_command_desc.md
> @@ -1,5 +1,5 @@
>
> -# About the dtrace Command {#dtrace_command_desc}
> +# About the dtrace Command <a id="dtrace_command_desc">
>
> The `dtrace` command provides a generic interface to all the essential services that are provided by the DTrace facility.
>
> diff --git a/doc/userguide/reference/dtrace_command_exit_status.md b/doc/userguide/reference/dtrace_command_exit_status.md
> index 97aaa7100..d1a321799 100644
> --- a/doc/userguide/reference/dtrace_command_exit_status.md
> +++ b/doc/userguide/reference/dtrace_command_exit_status.md
> @@ -1,5 +1,5 @@
>
> -# dtrace Command Exit Status {#dtrace_command_exit_status}
> +# dtrace Command Exit Status <a id="dtrace_command_exit_status">
>
> The following exit values are returned by the `dtrace` command:
>
> diff --git a/doc/userguide/reference/dtrace_command_operands.md b/doc/userguide/reference/dtrace_command_operands.md
> index d5261b225..03db4b976 100644
> --- a/doc/userguide/reference/dtrace_command_operands.md
> +++ b/doc/userguide/reference/dtrace_command_operands.md
> @@ -1,5 +1,5 @@
>
> -# dtrace Command Operands {#dtrace_command_operands}
> +# dtrace Command Operands <a id="dtrace_command_operands">
>
> You can specify zero or more extra arguments on the `dtrace` command line to define a set of macro variables, such as `$1`, `$2`, and so on, to be used in any D programs that are specified with the `-s` option or on the command line.
>
> diff --git a/doc/userguide/reference/dtrace_command_options.md b/doc/userguide/reference/dtrace_command_options.md
> index 86c41abf1..8b8bcea19 100644
> --- a/doc/userguide/reference/dtrace_command_options.md
> +++ b/doc/userguide/reference/dtrace_command_options.md
> @@ -1,5 +1,5 @@
>
> -# dtrace Command Options {#dtrace_command_options}
> +# dtrace Command Options <a id="dtrace_command_options">
>
> The `dtrace` command accepts the following options:
>
> diff --git a/doc/userguide/reference/dtrace_runtime_options.md b/doc/userguide/reference/dtrace_runtime_options.md
> index 766709af2..f59223916 100644
> --- a/doc/userguide/reference/dtrace_runtime_options.md
> +++ b/doc/userguide/reference/dtrace_runtime_options.md
> @@ -1,5 +1,5 @@
>
> -# DTrace Runtime and Compile-time Options Reference {#dt_runtime_options}
> +# DTrace Runtime and Compile-time Options Reference <a id="dt_runtime_options">
>
> DTrace uses reasonable default values and flexible default policies for runtime configuration. Tuning mechanisms in the form of DTrace compiler or runtime option can change the default behavior of the `dtrace` utility. You can find more information about the `dtrace` utility and various command line options in the `dtrace(8)` manual page.
>
> diff --git a/doc/userguide/reference/dynamic_runtime_options.md b/doc/userguide/reference/dynamic_runtime_options.md
> index a42ed3e7b..5c56a05e3 100644
> --- a/doc/userguide/reference/dynamic_runtime_options.md
> +++ b/doc/userguide/reference/dynamic_runtime_options.md
> @@ -1,5 +1,5 @@
>
> -# Dynamic Runtime Options {#dt_dynamic_runtime_options}
> +# Dynamic Runtime Options <a id="dt_dynamic_runtime_options">
>
> Dynamic runtime options are specific to D programs themselves and are likely to change depending on program functionality and requirements.
>
> diff --git a/doc/userguide/reference/setting_dtrace_compiler_and_runtime_options.md b/doc/userguide/reference/setting_dtrace_compiler_and_runtime_options.md
> index f978c7825..0f0224bf3 100644
> --- a/doc/userguide/reference/setting_dtrace_compiler_and_runtime_options.md
> +++ b/doc/userguide/reference/setting_dtrace_compiler_and_runtime_options.md
> @@ -1,5 +1,5 @@
>
> -# Setting DTrace Compile-time and Runtime Options {#dt_runtime_option_description}
> +# Setting DTrace Compile-time and Runtime Options <a id="dt_runtime_option_description">
>
> You can tune DTrace by setting or enabling a selection of runtime or compiler options. You can set options by either using the `-x` command line switch when running the `dtrace` command, or by specifying `pragma` lines in D programs. If an option takes a value, follow the option name with an equal sign \(`=`\) and the option value.
>
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v2 13/20] doc: Clean up the table for string relational operators
2025-10-22 3:22 [PATCH v2 05/20] doc: Replace duplicate id eugene.loh
` (5 preceding siblings ...)
2025-10-22 3:22 ` [PATCH v2 12/20] doc: Fix anchor links for reference/ eugene.loh
@ 2025-10-22 3:22 ` eugene.loh
2025-10-23 19:30 ` [DTrace-devel] " Elena Zannoni
2025-10-22 3:22 ` [PATCH v2 14/20] doc: Link to "Character Escape Sequences" table eugene.loh
` (8 subsequent siblings)
15 siblings, 1 reply; 28+ messages in thread
From: eugene.loh @ 2025-10-22 3:22 UTC (permalink / raw)
To: dtrace, dtrace-devel
From: Eugene Loh <eugene.loh@oracle.com>
The text referred to "Table 1", which is not otherwise identified. It
included a link using an undefined ID. Scrap both, especially since the
table immediately follows the text anyhow. Clean that up.
Also, the "String Assignment" link was missing its anchor tag. Add one.
While we are at it, for better readability and maintainability of the
source file:
- convert the table from HTML to Markdown
- introduce line breaks into the very long text line
Signed-off-by: Eugene Loh <eugene.loh@oracle.com>
---
.../dtrace-ref-DTraceSupportforStrings.md | 73 ++++---------------
1 file changed, 14 insertions(+), 59 deletions(-)
diff --git a/doc/userguide/reference/dtrace-ref-DTraceSupportforStrings.md b/doc/userguide/reference/dtrace-ref-DTraceSupportforStrings.md
index ea44523ed..e9239026f 100644
--- a/doc/userguide/reference/dtrace-ref-DTraceSupportforStrings.md
+++ b/doc/userguide/reference/dtrace-ref-DTraceSupportforStrings.md
@@ -80,65 +80,21 @@ Scalar type expressions, such as a pointer or integer, or a scalar array address
## String Comparison <a id="dt_strcomp_dlang">
-D overloads the binary relational operators and permits them to be used for string comparisons, as well as integer comparisons. The relational operators perform string comparison whenever both operands are of type `string` or when one operand is of type `string` and the other operand can be promoted to type `string`. See [String Assignment](dtrace-ref-DTraceSupportforStrings.md) for a detailed description. See also [Table 1](dtrace-ref-DTraceSupportforStrings.md#dt_t14_dlang), which lists the relational operators that can be used to compare strings.
+D overloads the binary relational operators and permits them to be used for string comparisons, as well as integer comparisons.
+The relational operators perform string comparison whenever both operands are of type `string`
+or when one operand is of type `string` and the other operand can be promoted to type `string`.
+See [String Assignment](dtrace-ref-DTraceSupportforStrings.md#dt_strasg_dlang) for a detailed description.
+See also the following table, which lists the relational operators that can be used to compare strings.
+
+| Operator | Description |
+| :--- | :--- |
+| `<` | Left-hand operand is less than right-operand. |
+| `<=` | Left-hand operand is less than or equal to right-hand operand. |
+| `>` | Left-hand operand is greater than right-hand operand. |
+| `>=` | Left-hand operand is greater than or equal to right-hand operand. |
+| `==` | Left-hand operand is equal to right-hand operand. |
+| `!=` | Left-hand operand is not equal to right-hand operand. |
-<table><thead><tr><th>
-
-Operator
-
-</th><th>
-
-Description
-
-</th></tr></thead><tbody><tr><td>
-
-`<`
-
-</td><td>
-
-Left-hand operand is less than right-operand.
-
-</td></tr><tr><td>
-
-`<=`
-
-</td><td>
-
-Left-hand operand is less than or equal to right-hand operand.
-
-</td></tr><tr><td>
-
-`>`
-
-</td><td>
-
-Left-hand operand is greater than right-hand operand.
-
-</td></tr><tr><td>
-
-`>=`
-
-</td><td>
-
-Left-hand operand is greater than or equal to right-hand operand.
-
-</td></tr><tr><td>
-
-`==`
-
-</td><td>
-
-Left-hand operand is equal to right-hand operand.
-
-</td></tr><tr><td>
-
-`!=`
-
-</td><td>
-
-Left-hand operand is not equal to right-hand operand.
-
-</td></tr><tbody></table>
As with integers, each operator evaluates to a value of type `int`, which is equal to one if the condition is true or zero if it is false.
The relational operators compare the two input strings byte-by-byte, similarly to the C library routine `strcmp()`. Each byte is compared by using its corresponding integer value in the ASCII character set until a null byte is read or the maximum string length is reached. See the `ascii(7)` manual page for more information. Some example D string comparisons and their results are shown in the following table.
@@ -179,4 +135,3 @@ Returns 0 \(false\)
**Note:**
Identical Unicode strings might compare as being different if one or the other of the strings isn't normalized.
-
--
2.47.3
^ permalink raw reply related [flat|nested] 28+ messages in thread* Re: [DTrace-devel] [PATCH v2 13/20] doc: Clean up the table for string relational operators
2025-10-22 3:22 ` [PATCH v2 13/20] doc: Clean up the table for string relational operators eugene.loh
@ 2025-10-23 19:30 ` Elena Zannoni
0 siblings, 0 replies; 28+ messages in thread
From: Elena Zannoni @ 2025-10-23 19:30 UTC (permalink / raw)
To: eugene.loh, dtrace, dtrace-devel
Reviewed-by: Elena Zannoni <elena.zannoni@oracle.com>
On 10/21/25 9:22 PM, eugene.loh--- via DTrace-devel wrote:
> From: Eugene Loh <eugene.loh@oracle.com>
>
> The text referred to "Table 1", which is not otherwise identified. It
> included a link using an undefined ID. Scrap both, especially since the
> table immediately follows the text anyhow. Clean that up.
>
> Also, the "String Assignment" link was missing its anchor tag. Add one.
>
> While we are at it, for better readability and maintainability of the
> source file:
>
> - convert the table from HTML to Markdown
>
> - introduce line breaks into the very long text line
>
> Signed-off-by: Eugene Loh <eugene.loh@oracle.com>
> ---
> .../dtrace-ref-DTraceSupportforStrings.md | 73 ++++---------------
> 1 file changed, 14 insertions(+), 59 deletions(-)
>
> diff --git a/doc/userguide/reference/dtrace-ref-DTraceSupportforStrings.md b/doc/userguide/reference/dtrace-ref-DTraceSupportforStrings.md
> index ea44523ed..e9239026f 100644
> --- a/doc/userguide/reference/dtrace-ref-DTraceSupportforStrings.md
> +++ b/doc/userguide/reference/dtrace-ref-DTraceSupportforStrings.md
> @@ -80,65 +80,21 @@ Scalar type expressions, such as a pointer or integer, or a scalar array address
>
> ## String Comparison <a id="dt_strcomp_dlang">
>
> -D overloads the binary relational operators and permits them to be used for string comparisons, as well as integer comparisons. The relational operators perform string comparison whenever both operands are of type `string` or when one operand is of type `string` and the other operand can be promoted to type `string`. See [String Assignment](dtrace-ref-DTraceSupportforStrings.md) for a detailed description. See also [Table 1](dtrace-ref-DTraceSupportforStrings.md#dt_t14_dlang), which lists the relational operators that can be used to compare strings.
> +D overloads the binary relational operators and permits them to be used for string comparisons, as well as integer comparisons.
> +The relational operators perform string comparison whenever both operands are of type `string`
> +or when one operand is of type `string` and the other operand can be promoted to type `string`.
> +See [String Assignment](dtrace-ref-DTraceSupportforStrings.md#dt_strasg_dlang) for a detailed description.
> +See also the following table, which lists the relational operators that can be used to compare strings.
> +
> +| Operator | Description |
> +| :--- | :--- |
> +| `<` | Left-hand operand is less than right-operand. |
> +| `<=` | Left-hand operand is less than or equal to right-hand operand. |
> +| `>` | Left-hand operand is greater than right-hand operand. |
> +| `>=` | Left-hand operand is greater than or equal to right-hand operand. |
> +| `==` | Left-hand operand is equal to right-hand operand. |
> +| `!=` | Left-hand operand is not equal to right-hand operand. |
>
> -<table><thead><tr><th>
> -
> -Operator
> -
> -</th><th>
> -
> -Description
> -
> -</th></tr></thead><tbody><tr><td>
> -
> -`<`
> -
> -</td><td>
> -
> -Left-hand operand is less than right-operand.
> -
> -</td></tr><tr><td>
> -
> -`<=`
> -
> -</td><td>
> -
> -Left-hand operand is less than or equal to right-hand operand.
> -
> -</td></tr><tr><td>
> -
> -`>`
> -
> -</td><td>
> -
> -Left-hand operand is greater than right-hand operand.
> -
> -</td></tr><tr><td>
> -
> -`>=`
> -
> -</td><td>
> -
> -Left-hand operand is greater than or equal to right-hand operand.
> -
> -</td></tr><tr><td>
> -
> -`==`
> -
> -</td><td>
> -
> -Left-hand operand is equal to right-hand operand.
> -
> -</td></tr><tr><td>
> -
> -`!=`
> -
> -</td><td>
> -
> -Left-hand operand is not equal to right-hand operand.
> -
> -</td></tr><tbody></table>
> As with integers, each operator evaluates to a value of type `int`, which is equal to one if the condition is true or zero if it is false.
>
> The relational operators compare the two input strings byte-by-byte, similarly to the C library routine `strcmp()`. Each byte is compared by using its corresponding integer value in the ASCII character set until a null byte is read or the maximum string length is reached. See the `ascii(7)` manual page for more information. Some example D string comparisons and their results are shown in the following table.
> @@ -179,4 +135,3 @@ Returns 0 \(false\)
> **Note:**
>
> Identical Unicode strings might compare as being different if one or the other of the strings isn't normalized.
> -
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v2 14/20] doc: Link to "Character Escape Sequences" table
2025-10-22 3:22 [PATCH v2 05/20] doc: Replace duplicate id eugene.loh
` (6 preceding siblings ...)
2025-10-22 3:22 ` [PATCH v2 13/20] doc: Clean up the table for string relational operators eugene.loh
@ 2025-10-22 3:22 ` eugene.loh
2025-10-23 19:32 ` [DTrace-devel] " Elena Zannoni
2025-10-22 3:22 ` [PATCH v2 15/20] doc: Clean up profile unit table eugene.loh
` (7 subsequent siblings)
15 siblings, 1 reply; 28+ messages in thread
From: eugene.loh @ 2025-10-22 3:22 UTC (permalink / raw)
To: dtrace, dtrace-devel
From: Eugene Loh <eugene.loh@oracle.com>
A link to this table did not work since it referenced an ID that did not
exist. Add an anchor ID by the table and use it.
While we're at it, convert the table from HTML to Markdown and break up
some longer lines, improving readability and maintainability of the
Markdown source file.
Signed-off-by: Eugene Loh <eugene.loh@oracle.com>
---
...dtrace-ref-TypesOperatorsandExpressions.md | 140 ++----------------
.../dtrace_builtin_variable_reference.md | 11 +-
2 files changed, 20 insertions(+), 131 deletions(-)
diff --git a/doc/userguide/reference/dtrace-ref-TypesOperatorsandExpressions.md b/doc/userguide/reference/dtrace-ref-TypesOperatorsandExpressions.md
index c76d293c7..bb1c49949 100644
--- a/doc/userguide/reference/dtrace-ref-TypesOperatorsandExpressions.md
+++ b/doc/userguide/reference/dtrace-ref-TypesOperatorsandExpressions.md
@@ -474,135 +474,18 @@ D type
</td></tr><tbody></table>
Character constants are written as a single character or escape sequence that's inside a pair of single quotes \(`'a'`\). Character constants are assigned the `int` type rather than `char` and are equivalent to an integer constant with a value that's determined by that character's value in the ASCII character set. See the `ascii(7)` manual page for a list of characters and their values. You can also use any of the special escape sequences that are listed in the following table. D uses the same escape sequences as those found in ANSI C.
-<table><thead><tr><th>
-
-Escape Sequence
-
-</th><th>
-
-Represents
-
-</th><th>
-
-Escape Sequence
-
-</th><th>
-
-Represents
-
-</th></tr></thead><tbody><tr><td>
-
-`\a`
-
-</td><td>
-
-alert
-
-</td><td>
-
-`\\`
-
-</td><td>
-
-backslash
-
-</td></tr><tr><td>
-
-`\b`
-
-</td><td>
-
-backspace
-
-</td><td>
-
-`\?`
-
-</td><td>
-
-question mark
-
-</td></tr><tr><td>
-
-`\f`
-
-</td><td>
-
-form feed
-
-</td><td>
-
-`\'`
-
-</td><td>
-
-single quote
-
-</td></tr><tr><td>
+**Table:** Character Escape Sequences<a id="char_esc_seqs">
+
+| Escape Sequence | Represents | | Escape Sequence | Represents |
+| :--- | :--- | --- | :--- | :--- |
+| `\a` | alert | | `\\` | backslash |
+| `\b` | backspace | | `\?` | question mark |
+| `\f` | form feed | | `\'` | single quote |
+| `\n` | newline | | `\"` | double quote |
+| `\r` | carriage return | | `\0`*oo* | octal value 0*oo* |
+| `\t` | horizontal tab | | `\x`*hh* | hexadecimal value 0x*hh* |
+| `\v` | vertical tab | | `\0` | null character |
-`\n`
-
-</td><td>
-
-newline
-
-</td><td>
-
-`\"`
-
-</td><td>
-
-double quote
-
-</td></tr><tr><td>
-
-`\r`
-
-</td><td>
-
-carriage return
-
-</td><td>
-
-`\0*oo*`
-
-</td><td>
-
-octal value 0*oo*
-
-</td></tr><tr><td>
-
-`\t`
-
-</td><td>
-
-horizontal tab
-
-</td><td>
-
-`\x*hh*`
-
-</td><td>
-
-hexadecimal value 0x*hh*
-
-</td></tr><tr><td>
-
-`\v`
-
-</td><td>
-
-vertical tab
-
-</td><td>
-
-`\0`
-
-</td><td>
-
-null character
-
-</td></tr><tbody></table>
You can include more than one character specifier inside single quotes to create integers with individual bytes that are initialized according to the corresponding character specifiers. The bytes are read left-to-right from a character constant and assigned to the resulting integer in the order corresponding to the native endianness of the operating environment. Up to eight character specifiers can be included in a single character constant.
Strings constants of any length can be composed by enclosing them in a pair of double quotes \(`"hello"`\). A string constant can't contain a literal newline character. To create strings containing newlines, use the `\n` escape sequence instead of a literal newline. String constants can contain any of the special character escape sequences that are shown for character constants before. Similar to ANSI C, strings are represented as arrays of characters that end with a null character \(`\0`\) that's implicitly added to each string constant you declare. String constants are assigned the special D type `string`. The D compiler provides a set of special features for comparing and tracing character arrays that are declared as strings.
@@ -1407,4 +1290,3 @@ The D type namespace is initially populated with the D type intrinsics, such as
When the D compiler encounters a type declaration that doesn't specify an explicit namespace using the back quote operator, the compiler searches the set of active type namespaces to find a match by using the specified type name. The C namespace is always searched first, followed by the D namespace. If the type name isn't found in either the C or D namespace, the type namespaces of the active kernel modules are searched in load address order, which doesn't guarantee any ordering properties among the loadable modules. To avoid type name conflicts with other kernel modules, use the scoping operator when accessing types that are defined in loadable kernel modules.
The D compiler uses the compressed ANSI C debugging information that's provided with the core Linux kernel modules to access the types that are associated with the OS source code, without the need to access the corresponding C include files. Note that this symbolic debugging information might not be available for all kernel modules on the system. The D compiler reports an error if you try to access a type within the namespace of a module that lacks the compressed C debugging information that's intended for use with DTrace.
-
diff --git a/doc/userguide/reference/dtrace_builtin_variable_reference.md b/doc/userguide/reference/dtrace_builtin_variable_reference.md
index 787137929..aecd2308c 100644
--- a/doc/userguide/reference/dtrace_builtin_variable_reference.md
+++ b/doc/userguide/reference/dtrace_builtin_variable_reference.md
@@ -221,7 +221,15 @@ The macro argument values must match the form of an integer, identifier, or stri
sudo ./foo '"a string argument"'
```
-If you want D macro arguments to be interpreted as string tokens, even if they match the form of an integer or identifier, prefix the macro variable or argument name with two leading dollar signs, for example, `$$1`, which forces the D compiler to interpret the argument value as if it were a string surrounded by double quotes. All the usual D string escape sequences, per [Table 5](dtrace-ref-TypesOperatorsandExpressions.md#dt_t6_dlang), are expanded inside any string macro arguments, regardless of whether they're referenced by using the `$arg` or `$$arg` form of the macro. If the `defaultargs` option is set, unspecified arguments that are referenced with the `$$arg` form have the value of the empty string \(`""`\).
+If you want D macro arguments to be interpreted as string tokens,
+even if they match the form of an integer or identifier,
+prefix the macro variable or argument name with two leading dollar signs,
+for example, `$$1`, which forces the D compiler to interpret the argument value as if it were a string surrounded by double quotes.
+All the usual D string escape sequences, in the table of [Character Escape Sequences](dtrace-ref-TypesOperatorsandExpressions.md#char_esc_seqs),
+are expanded inside any string macro arguments,
+regardless of whether they're referenced by using the `$arg` or `$$arg` form of the macro.
+If the `defaultargs` option is set,
+unspecified arguments that are referenced with the `$$arg` form have the value of the empty string \(`""`\).
### Target Process ID
@@ -474,4 +482,3 @@ int64_t walltimestamp
```
The built-in variable `walltimestamp` references the current number of nanoseconds since 00:00 Universal Coordinated Time, January 1, 1970.
-
--
2.47.3
^ permalink raw reply related [flat|nested] 28+ messages in thread* Re: [DTrace-devel] [PATCH v2 14/20] doc: Link to "Character Escape Sequences" table
2025-10-22 3:22 ` [PATCH v2 14/20] doc: Link to "Character Escape Sequences" table eugene.loh
@ 2025-10-23 19:32 ` Elena Zannoni
0 siblings, 0 replies; 28+ messages in thread
From: Elena Zannoni @ 2025-10-23 19:32 UTC (permalink / raw)
To: eugene.loh, dtrace, dtrace-devel
Reviewed-by: Elena Zannoni <elena.zannoni@oracle.com>
On 10/21/25 9:22 PM, eugene.loh--- via DTrace-devel wrote:
> From: Eugene Loh <eugene.loh@oracle.com>
>
> A link to this table did not work since it referenced an ID that did not
> exist. Add an anchor ID by the table and use it.
>
> While we're at it, convert the table from HTML to Markdown and break up
> some longer lines, improving readability and maintainability of the
> Markdown source file.
>
> Signed-off-by: Eugene Loh <eugene.loh@oracle.com>
> ---
> ...dtrace-ref-TypesOperatorsandExpressions.md | 140 ++----------------
> .../dtrace_builtin_variable_reference.md | 11 +-
> 2 files changed, 20 insertions(+), 131 deletions(-)
>
> diff --git a/doc/userguide/reference/dtrace-ref-TypesOperatorsandExpressions.md b/doc/userguide/reference/dtrace-ref-TypesOperatorsandExpressions.md
> index c76d293c7..bb1c49949 100644
> --- a/doc/userguide/reference/dtrace-ref-TypesOperatorsandExpressions.md
> +++ b/doc/userguide/reference/dtrace-ref-TypesOperatorsandExpressions.md
> @@ -474,135 +474,18 @@ D type
> </td></tr><tbody></table>
> Character constants are written as a single character or escape sequence that's inside a pair of single quotes \(`'a'`\). Character constants are assigned the `int` type rather than `char` and are equivalent to an integer constant with a value that's determined by that character's value in the ASCII character set. See the `ascii(7)` manual page for a list of characters and their values. You can also use any of the special escape sequences that are listed in the following table. D uses the same escape sequences as those found in ANSI C.
>
> -<table><thead><tr><th>
> -
> -Escape Sequence
> -
> -</th><th>
> -
> -Represents
> -
> -</th><th>
> -
> -Escape Sequence
> -
> -</th><th>
> -
> -Represents
> -
> -</th></tr></thead><tbody><tr><td>
> -
> -`\a`
> -
> -</td><td>
> -
> -alert
> -
> -</td><td>
> -
> -`\\`
> -
> -</td><td>
> -
> -backslash
> -
> -</td></tr><tr><td>
> -
> -`\b`
> -
> -</td><td>
> -
> -backspace
> -
> -</td><td>
> -
> -`\?`
> -
> -</td><td>
> -
> -question mark
> -
> -</td></tr><tr><td>
> -
> -`\f`
> -
> -</td><td>
> -
> -form feed
> -
> -</td><td>
> -
> -`\'`
> -
> -</td><td>
> -
> -single quote
> -
> -</td></tr><tr><td>
> +**Table:** Character Escape Sequences<a id="char_esc_seqs">
> +
> +| Escape Sequence | Represents | | Escape Sequence | Represents |
> +| :--- | :--- | --- | :--- | :--- |
> +| `\a` | alert | | `\\` | backslash |
> +| `\b` | backspace | | `\?` | question mark |
> +| `\f` | form feed | | `\'` | single quote |
> +| `\n` | newline | | `\"` | double quote |
> +| `\r` | carriage return | | `\0`*oo* | octal value 0*oo* |
> +| `\t` | horizontal tab | | `\x`*hh* | hexadecimal value 0x*hh* |
> +| `\v` | vertical tab | | `\0` | null character |
>
> -`\n`
> -
> -</td><td>
> -
> -newline
> -
> -</td><td>
> -
> -`\"`
> -
> -</td><td>
> -
> -double quote
> -
> -</td></tr><tr><td>
> -
> -`\r`
> -
> -</td><td>
> -
> -carriage return
> -
> -</td><td>
> -
> -`\0*oo*`
> -
> -</td><td>
> -
> -octal value 0*oo*
> -
> -</td></tr><tr><td>
> -
> -`\t`
> -
> -</td><td>
> -
> -horizontal tab
> -
> -</td><td>
> -
> -`\x*hh*`
> -
> -</td><td>
> -
> -hexadecimal value 0x*hh*
> -
> -</td></tr><tr><td>
> -
> -`\v`
> -
> -</td><td>
> -
> -vertical tab
> -
> -</td><td>
> -
> -`\0`
> -
> -</td><td>
> -
> -null character
> -
> -</td></tr><tbody></table>
> You can include more than one character specifier inside single quotes to create integers with individual bytes that are initialized according to the corresponding character specifiers. The bytes are read left-to-right from a character constant and assigned to the resulting integer in the order corresponding to the native endianness of the operating environment. Up to eight character specifiers can be included in a single character constant.
>
> Strings constants of any length can be composed by enclosing them in a pair of double quotes \(`"hello"`\). A string constant can't contain a literal newline character. To create strings containing newlines, use the `\n` escape sequence instead of a literal newline. String constants can contain any of the special character escape sequences that are shown for character constants before. Similar to ANSI C, strings are represented as arrays of characters that end with a null character \(`\0`\) that's implicitly added to each string constant you declare. String constants are assigned the special D type `string`. The D compiler provides a set of special features for comparing and tracing character arrays that are declared as strings.
> @@ -1407,4 +1290,3 @@ The D type namespace is initially populated with the D type intrinsics, such as
> When the D compiler encounters a type declaration that doesn't specify an explicit namespace using the back quote operator, the compiler searches the set of active type namespaces to find a match by using the specified type name. The C namespace is always searched first, followed by the D namespace. If the type name isn't found in either the C or D namespace, the type namespaces of the active kernel modules are searched in load address order, which doesn't guarantee any ordering properties among the loadable modules. To avoid type name conflicts with other kernel modules, use the scoping operator when accessing types that are defined in loadable kernel modules.
>
> The D compiler uses the compressed ANSI C debugging information that's provided with the core Linux kernel modules to access the types that are associated with the OS source code, without the need to access the corresponding C include files. Note that this symbolic debugging information might not be available for all kernel modules on the system. The D compiler reports an error if you try to access a type within the namespace of a module that lacks the compressed C debugging information that's intended for use with DTrace.
> -
> diff --git a/doc/userguide/reference/dtrace_builtin_variable_reference.md b/doc/userguide/reference/dtrace_builtin_variable_reference.md
> index 787137929..aecd2308c 100644
> --- a/doc/userguide/reference/dtrace_builtin_variable_reference.md
> +++ b/doc/userguide/reference/dtrace_builtin_variable_reference.md
> @@ -221,7 +221,15 @@ The macro argument values must match the form of an integer, identifier, or stri
> sudo ./foo '"a string argument"'
> ```
>
> -If you want D macro arguments to be interpreted as string tokens, even if they match the form of an integer or identifier, prefix the macro variable or argument name with two leading dollar signs, for example, `$$1`, which forces the D compiler to interpret the argument value as if it were a string surrounded by double quotes. All the usual D string escape sequences, per [Table 5](dtrace-ref-TypesOperatorsandExpressions.md#dt_t6_dlang), are expanded inside any string macro arguments, regardless of whether they're referenced by using the `$arg` or `$$arg` form of the macro. If the `defaultargs` option is set, unspecified arguments that are referenced with the `$$arg` form have the value of the empty string \(`""`\).
> +If you want D macro arguments to be interpreted as string tokens,
> +even if they match the form of an integer or identifier,
> +prefix the macro variable or argument name with two leading dollar signs,
> +for example, `$$1`, which forces the D compiler to interpret the argument value as if it were a string surrounded by double quotes.
> +All the usual D string escape sequences, in the table of [Character Escape Sequences](dtrace-ref-TypesOperatorsandExpressions.md#char_esc_seqs),
> +are expanded inside any string macro arguments,
> +regardless of whether they're referenced by using the `$arg` or `$$arg` form of the macro.
> +If the `defaultargs` option is set,
> +unspecified arguments that are referenced with the `$$arg` form have the value of the empty string \(`""`\).
>
> ### Target Process ID
>
> @@ -474,4 +482,3 @@ int64_t walltimestamp
> ```
>
> The built-in variable `walltimestamp` references the current number of nanoseconds since 00:00 Universal Coordinated Time, January 1, 1970.
> -
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v2 15/20] doc: Clean up profile unit table
2025-10-22 3:22 [PATCH v2 05/20] doc: Replace duplicate id eugene.loh
` (7 preceding siblings ...)
2025-10-22 3:22 ` [PATCH v2 14/20] doc: Link to "Character Escape Sequences" table eugene.loh
@ 2025-10-22 3:22 ` eugene.loh
2025-10-23 19:33 ` [DTrace-devel] " Elena Zannoni
2025-10-22 3:22 ` [PATCH v2 16/20] doc: Clean up undefined anchor links eugene.loh
` (6 subsequent siblings)
15 siblings, 1 reply; 28+ messages in thread
From: eugene.loh @ 2025-10-22 3:22 UTC (permalink / raw)
To: dtrace, dtrace-devel
From: Eugene Loh <eugene.loh@oracle.com>
There are two references to "Table 1" (which is not otherwise
identified), along with links to an undefined ID. Rework these
references.
While we're at it, convert the table from HTML to Markdown and break up
some longer lines, improving readability and maintainability of the
Markdown source file.
Signed-off-by: Eugene Loh <eugene.loh@oracle.com>
---
.../reference/dtrace_providers_profile.md | 95 ++++---------------
1 file changed, 20 insertions(+), 75 deletions(-)
diff --git a/doc/userguide/reference/dtrace_providers_profile.md b/doc/userguide/reference/dtrace_providers_profile.md
index da83e8561..762109d02 100644
--- a/doc/userguide/reference/dtrace_providers_profile.md
+++ b/doc/userguide/reference/dtrace_providers_profile.md
@@ -11,86 +11,31 @@ Such probes aren't associated with any particular point of execution, but rather
The `profile-*n*` probes fire at a fixed interval, at a high-interrupt level on all active CPUs.
-The units of *n* default to a frequency that's expressed as a rate of firing per second, but the value can also have an optional suffix , as shown in [Table 1](dtrace_providers_profile.md#dt_t1_prov), which specifies either a time interval or a frequency. The following table describes valid time suffixes for a `tick-` *n* probe.
+The units of *n* default to a frequency that's expressed as a rate of firing per second,
+but the value can also have an optional suffix, as shown in the following table,
+which specifies either a time interval or a frequency.
+The following table describes valid time suffixes for a `tick-` *n* probe.
+
+| Suffix | Time Units |
+| :--- | :--- |
+| `nsec` or `ns` | nanoseconds |
+| `usec` or `us` | microseconds |
+| `msec` or `ms` | milliseconds |
+| `sec` or `s` | seconds |
+| `min` or `m` | minutes |
+| `hour` or `h` | hours |
+| `day` or `d` | days |
+| `hz` | hertz \(frequency expressed as rate per second\) |
-<table><thead><tr><th>
-
-Suffix
-
-</th><th>
-
-Time Units
-
-</th></tr></thead><tbody><tr><td>
-
-`nsec` or `ns`
-
-</td><td>
-
-nanoseconds
-
-</td></tr><tr><td>
-
-`usec` or `us`
-
-</td><td>
-
-microseconds
-
-</td></tr><tr><td>
-
-`msec` or `ms`
-
-</td><td>
-
-milliseconds
-
-</td></tr><tr><td>
-
-`sec` or `s`
-
-</td><td>
-
-seconds
-
-</td></tr><tr><td>
-
-`min` or `m`
-
-</td><td>
-
-minutes
-
-</td></tr><tr><td>
-
-`hour` or `h`
-
-</td><td>
-
-hours
-
-</td></tr><tr><td>
-
-`day` or `d`
-
-</td><td>
-
-days
-
-</td></tr><tr><td>
-
-`hz`
-
-</td><td>
-
-hertz \(frequency expressed as rate per second\)
-
-</td></tr><tbody></table>
## tick-*n* Probes <a id="dt_ref_profile-tick-n_prov">
The `tick-*n*` probes fire at fixed intervals, at a high interrupt level on only one CPU per interval.
-Unlike `profile-*n*` probes, which fire on every CPU, `tick-*n*` probes fire on only one CPU per interval and the CPU on which they fire can change over time. The units of *n* default to a frequency expressed as a rate of firing per second, but the value can also have an optional time suffix as shown in [Table 1](dtrace_providers_profile.md#dt_t1_prov), which specifies either a time interval or a frequency.
+Unlike `profile-*n*` probes, which fire on every CPU,
+`tick-*n*` probes fire on only one CPU per interval and the CPU on which they fire can change over time.
+The units of *n* default to a frequency expressed as a rate of firing per second,
+but the value can also have an optional time suffix as shown in the earlier table,
+which specifies either a time interval or a frequency.
The `tick-*n*` probes have several uses, such as providing some periodic output or taking a periodic action.
--
2.47.3
^ permalink raw reply related [flat|nested] 28+ messages in thread* Re: [DTrace-devel] [PATCH v2 15/20] doc: Clean up profile unit table
2025-10-22 3:22 ` [PATCH v2 15/20] doc: Clean up profile unit table eugene.loh
@ 2025-10-23 19:33 ` Elena Zannoni
0 siblings, 0 replies; 28+ messages in thread
From: Elena Zannoni @ 2025-10-23 19:33 UTC (permalink / raw)
To: eugene.loh, dtrace, dtrace-devel
Reviewed-by: Elena Zannoni <elena.zannoni@oracle.com>
On 10/21/25 9:22 PM, eugene.loh--- via DTrace-devel wrote:
> From: Eugene Loh <eugene.loh@oracle.com>
>
> There are two references to "Table 1" (which is not otherwise
> identified), along with links to an undefined ID. Rework these
> references.
>
> While we're at it, convert the table from HTML to Markdown and break up
> some longer lines, improving readability and maintainability of the
> Markdown source file.
>
> Signed-off-by: Eugene Loh <eugene.loh@oracle.com>
> ---
> .../reference/dtrace_providers_profile.md | 95 ++++---------------
> 1 file changed, 20 insertions(+), 75 deletions(-)
>
> diff --git a/doc/userguide/reference/dtrace_providers_profile.md b/doc/userguide/reference/dtrace_providers_profile.md
> index da83e8561..762109d02 100644
> --- a/doc/userguide/reference/dtrace_providers_profile.md
> +++ b/doc/userguide/reference/dtrace_providers_profile.md
> @@ -11,86 +11,31 @@ Such probes aren't associated with any particular point of execution, but rather
>
> The `profile-*n*` probes fire at a fixed interval, at a high-interrupt level on all active CPUs.
>
> -The units of *n* default to a frequency that's expressed as a rate of firing per second, but the value can also have an optional suffix , as shown in [Table 1](dtrace_providers_profile.md#dt_t1_prov), which specifies either a time interval or a frequency. The following table describes valid time suffixes for a `tick-` *n* probe.
> +The units of *n* default to a frequency that's expressed as a rate of firing per second,
> +but the value can also have an optional suffix, as shown in the following table,
> +which specifies either a time interval or a frequency.
> +The following table describes valid time suffixes for a `tick-` *n* probe.
> +
> +| Suffix | Time Units |
> +| :--- | :--- |
> +| `nsec` or `ns` | nanoseconds |
> +| `usec` or `us` | microseconds |
> +| `msec` or `ms` | milliseconds |
> +| `sec` or `s` | seconds |
> +| `min` or `m` | minutes |
> +| `hour` or `h` | hours |
> +| `day` or `d` | days |
> +| `hz` | hertz \(frequency expressed as rate per second\) |
>
> -<table><thead><tr><th>
> -
> -Suffix
> -
> -</th><th>
> -
> -Time Units
> -
> -</th></tr></thead><tbody><tr><td>
> -
> -`nsec` or `ns`
> -
> -</td><td>
> -
> -nanoseconds
> -
> -</td></tr><tr><td>
> -
> -`usec` or `us`
> -
> -</td><td>
> -
> -microseconds
> -
> -</td></tr><tr><td>
> -
> -`msec` or `ms`
> -
> -</td><td>
> -
> -milliseconds
> -
> -</td></tr><tr><td>
> -
> -`sec` or `s`
> -
> -</td><td>
> -
> -seconds
> -
> -</td></tr><tr><td>
> -
> -`min` or `m`
> -
> -</td><td>
> -
> -minutes
> -
> -</td></tr><tr><td>
> -
> -`hour` or `h`
> -
> -</td><td>
> -
> -hours
> -
> -</td></tr><tr><td>
> -
> -`day` or `d`
> -
> -</td><td>
> -
> -days
> -
> -</td></tr><tr><td>
> -
> -`hz`
> -
> -</td><td>
> -
> -hertz \(frequency expressed as rate per second\)
> -
> -</td></tr><tbody></table>
> ## tick-*n* Probes <a id="dt_ref_profile-tick-n_prov">
>
> The `tick-*n*` probes fire at fixed intervals, at a high interrupt level on only one CPU per interval.
>
> -Unlike `profile-*n*` probes, which fire on every CPU, `tick-*n*` probes fire on only one CPU per interval and the CPU on which they fire can change over time. The units of *n* default to a frequency expressed as a rate of firing per second, but the value can also have an optional time suffix as shown in [Table 1](dtrace_providers_profile.md#dt_t1_prov), which specifies either a time interval or a frequency.
> +Unlike `profile-*n*` probes, which fire on every CPU,
> +`tick-*n*` probes fire on only one CPU per interval and the CPU on which they fire can change over time.
> +The units of *n* default to a frequency expressed as a rate of firing per second,
> +but the value can also have an optional time suffix as shown in the earlier table,
> +which specifies either a time interval or a frequency.
>
> The `tick-*n*` probes have several uses, such as providing some periodic output or taking a periodic action.
>
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v2 16/20] doc: Clean up undefined anchor links
2025-10-22 3:22 [PATCH v2 05/20] doc: Replace duplicate id eugene.loh
` (8 preceding siblings ...)
2025-10-22 3:22 ` [PATCH v2 15/20] doc: Clean up profile unit table eugene.loh
@ 2025-10-22 3:22 ` eugene.loh
2025-10-23 19:34 ` Elena Zannoni
2025-10-22 3:22 ` [PATCH v2 17/20] doc: Add IP provider documentation eugene.loh
` (5 subsequent siblings)
15 siblings, 1 reply; 28+ messages in thread
From: eugene.loh @ 2025-10-22 3:22 UTC (permalink / raw)
To: dtrace, dtrace-devel
From: Eugene Loh <eugene.loh@oracle.com>
Signed-off-by: Eugene Loh <eugene.loh@oracle.com>
---
doc/userguide/index.md | 2 +-
.../reference/dtrace_builtin_variable_reference.md | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/doc/userguide/index.md b/doc/userguide/index.md
index abd1096db..ef1489f5e 100644
--- a/doc/userguide/index.md
+++ b/doc/userguide/index.md
@@ -7,7 +7,7 @@
- [Install DTrace on Oracle Linux 9](how-to/dtrace-howto-install-dtrace.md#install_dtrace_oracle_linux_9)
- [Install DTrace on Oracle Linux 8](how-to/dtrace-howto-install-dtrace.md#install_dtrace_oracle_linux_8)
- [Install DTrace on Oracle Linux 7](how-to/dtrace-howto-install-dtrace.md#install_dtrace_oracle_linux_7)
- - [Verify the DTrace Installation](how-to/dtrace-howto-install-_dtrace.md#verify_install)
+ - [Verify the DTrace Installation](how-to/dtrace-howto-install-dtrace.md#verify_install)
- [List and Enable Probes](how-to/dtrace-howto-list-and-enable-probes.md#list_enable_probes)
- [Create a DTrace Script](how-to/dtrace-howto-create-a-dtrace-script.md#dt_create_script)
- [Use Predicates For Control Flow](how-to/dtrace-howto-use-predicates.md#dt_preds_dlang)
diff --git a/doc/userguide/reference/dtrace_builtin_variable_reference.md b/doc/userguide/reference/dtrace_builtin_variable_reference.md
index aecd2308c..0cbfc4252 100644
--- a/doc/userguide/reference/dtrace_builtin_variable_reference.md
+++ b/doc/userguide/reference/dtrace_builtin_variable_reference.md
@@ -31,7 +31,7 @@ Macro arguments
</td><td>
-See [Macro Arguments](dtrace_builtin_variable_reference.md#macro_arguments)
+See [Macro Arguments](dtrace_builtin_variable_reference.md#dt_macroa_scrpt)
</td></tr><tr><td>
@@ -127,7 +127,7 @@ Target process ID
</td><td>
-See [Target Process ID](dtrace_builtin_variable_reference.md#target_process)
+See [Target Process ID](dtrace_builtin_variable_reference.md#targ_proc_id)
</td></tr><tr><td>
`$uid`
@@ -231,7 +231,7 @@ regardless of whether they're referenced by using the `$arg` or `$$arg` form of
If the `defaultargs` option is set,
unspecified arguments that are referenced with the `$$arg` form have the value of the empty string \(`""`\).
-### Target Process ID
+### Target Process ID <a id="targ_proc_id">
Use the `$target` macro variable to create scripts to be applied to the user process of interest that you specify with the `-p` option or that you create by using the `dtrace` command with the `-c` option. The D programs that you specify on the command line or by using the `-s` option are compiled after processes are created or grabbed, and the `$target` variable expands to the integer process ID of the first such process.
--
2.47.3
^ permalink raw reply related [flat|nested] 28+ messages in thread* Re: [PATCH v2 16/20] doc: Clean up undefined anchor links
2025-10-22 3:22 ` [PATCH v2 16/20] doc: Clean up undefined anchor links eugene.loh
@ 2025-10-23 19:34 ` Elena Zannoni
0 siblings, 0 replies; 28+ messages in thread
From: Elena Zannoni @ 2025-10-23 19:34 UTC (permalink / raw)
To: eugene.loh, dtrace, dtrace-devel
Reviewed-by: Elena Zannoni <elena.zannoni@oracle.com>
On 10/21/25 9:22 PM, eugene.loh@oracle.com wrote:
> From: Eugene Loh <eugene.loh@oracle.com>
>
> Signed-off-by: Eugene Loh <eugene.loh@oracle.com>
> ---
> doc/userguide/index.md | 2 +-
> .../reference/dtrace_builtin_variable_reference.md | 6 +++---
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/doc/userguide/index.md b/doc/userguide/index.md
> index abd1096db..ef1489f5e 100644
> --- a/doc/userguide/index.md
> +++ b/doc/userguide/index.md
> @@ -7,7 +7,7 @@
> - [Install DTrace on Oracle Linux 9](how-to/dtrace-howto-install-dtrace.md#install_dtrace_oracle_linux_9)
> - [Install DTrace on Oracle Linux 8](how-to/dtrace-howto-install-dtrace.md#install_dtrace_oracle_linux_8)
> - [Install DTrace on Oracle Linux 7](how-to/dtrace-howto-install-dtrace.md#install_dtrace_oracle_linux_7)
> - - [Verify the DTrace Installation](how-to/dtrace-howto-install-_dtrace.md#verify_install)
> + - [Verify the DTrace Installation](how-to/dtrace-howto-install-dtrace.md#verify_install)
> - [List and Enable Probes](how-to/dtrace-howto-list-and-enable-probes.md#list_enable_probes)
> - [Create a DTrace Script](how-to/dtrace-howto-create-a-dtrace-script.md#dt_create_script)
> - [Use Predicates For Control Flow](how-to/dtrace-howto-use-predicates.md#dt_preds_dlang)
> diff --git a/doc/userguide/reference/dtrace_builtin_variable_reference.md b/doc/userguide/reference/dtrace_builtin_variable_reference.md
> index aecd2308c..0cbfc4252 100644
> --- a/doc/userguide/reference/dtrace_builtin_variable_reference.md
> +++ b/doc/userguide/reference/dtrace_builtin_variable_reference.md
> @@ -31,7 +31,7 @@ Macro arguments
>
> </td><td>
>
> -See [Macro Arguments](dtrace_builtin_variable_reference.md#macro_arguments)
> +See [Macro Arguments](dtrace_builtin_variable_reference.md#dt_macroa_scrpt)
>
> </td></tr><tr><td>
>
> @@ -127,7 +127,7 @@ Target process ID
>
> </td><td>
>
> -See [Target Process ID](dtrace_builtin_variable_reference.md#target_process)
> +See [Target Process ID](dtrace_builtin_variable_reference.md#targ_proc_id)
> </td></tr><tr><td>
>
> `$uid`
> @@ -231,7 +231,7 @@ regardless of whether they're referenced by using the `$arg` or `$$arg` form of
> If the `defaultargs` option is set,
> unspecified arguments that are referenced with the `$$arg` form have the value of the empty string \(`""`\).
>
> -### Target Process ID
> +### Target Process ID <a id="targ_proc_id">
>
> Use the `$target` macro variable to create scripts to be applied to the user process of interest that you specify with the `-p` option or that you create by using the `dtrace` command with the `-c` option. The D programs that you specify on the command line or by using the `-s` option are compiled after processes are created or grabbed, and the `$target` variable expands to the integer process ID of the first such process.
>
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v2 17/20] doc: Add IP provider documentation
2025-10-22 3:22 [PATCH v2 05/20] doc: Replace duplicate id eugene.loh
` (9 preceding siblings ...)
2025-10-22 3:22 ` [PATCH v2 16/20] doc: Clean up undefined anchor links eugene.loh
@ 2025-10-22 3:22 ` eugene.loh
2025-10-22 3:22 ` [PATCH v2 18/20] doc: Add TCP " eugene.loh
` (4 subsequent siblings)
15 siblings, 0 replies; 28+ messages in thread
From: eugene.loh @ 2025-10-22 3:22 UTC (permalink / raw)
To: dtrace, dtrace-devel
From: Eugene Loh <eugene.loh@oracle.com>
Signed-off-by: Eugene Loh <eugene.loh@oracle.com>
Reviewed-by: Alan Maguire <alan.maguire@oracle.com>
---
doc/userguide/index.md | 10 +
doc/userguide/reference/dtrace_providers.md | 2 +
.../reference/dtrace_providers_ip.md | 173 ++++++++++++++++++
3 files changed, 185 insertions(+)
create mode 100644 doc/userguide/reference/dtrace_providers_ip.md
diff --git a/doc/userguide/index.md b/doc/userguide/index.md
index ef1489f5e..063881c6d 100644
--- a/doc/userguide/index.md
+++ b/doc/userguide/index.md
@@ -208,6 +208,16 @@
- [fileinfo\_t](reference/dtrace_providers_io.md#dt_ref_iofile_prov)
- [io Examples](reference/dtrace_providers_io.md#dt_ref_ioexamples_prov)
- [io Stability](reference/dtrace_providers_io.md#dt_ref_iostab_prov)
+ - [IP Provider](reference/dtrace_providers_ip.md)
+ - [ip Probes](reference/dtrace_providers_ip.md#dt_ref_ipprobes_prov)
+ - [ip Probe Arguments](reference/dtrace_providers_ip.md#dt_ref_ipargs_prov)
+ - [pktinfo\_t](reference/dtrace_providers_ip.md#dt_ref_ippkt_prov)
+ - [csinfo\_t](reference/dtrace_providers_ip.md#dt_ref_ipcs_prov)
+ - [ipinfo\_t](reference/dtrace_providers_ip.md#dt_ref_ipip_prov)
+ - [ifinfo\_t](reference/dtrace_providers_ip.md#dt_ref_ipif_prov)
+ - [ipv4info\_t](reference/dtrace_providers_ip.md#dt_ref_ipipv4_prov)
+ - [ipv6info\_t](reference/dtrace_providers_ip.md#dt_ref_ipipv6_prov)
+ - [ip Stability](reference/dtrace_providers_ip.md#dt_ref_ipstab_prov)
- [Lockstat Provider](reference/dtrace_providers_lockstat.md#dt_ref_lockstat_prov)
- [lockstat Probes](reference/dtrace_providers_lockstat.md#dt_ref_lockstatprobes_prov)
- [lockstat Probe Arguments](reference/dtrace_providers_lockstat.md#dt_ref_lockstatargs_prov)
diff --git a/doc/userguide/reference/dtrace_providers.md b/doc/userguide/reference/dtrace_providers.md
index 70fcb583f..a225f4486 100644
--- a/doc/userguide/reference/dtrace_providers.md
+++ b/doc/userguide/reference/dtrace_providers.md
@@ -11,6 +11,8 @@ The `dtrace` provider includes several probes that are specific to DTrace itself
The `fbt` \(Function Boundary Tracing\) provider includes probes that are associated with the entry to and return from most functions in the Linux kernel. Therefore, there could be tens of thousands of `fbt` probes.
- **[IO Provider](../reference/dtrace_providers_io.md)**
The `io` provider makes available probes that relate to data input and output.
+- **[IP Provider](../reference/dtrace_providers_ip.md)**
+The `ip` provider provides probes that can be used to study IP traffic.
- **[Lockstat Provider](../reference/dtrace_providers_lockstat.md)**
The `lockstat` provider provides probes that can be used to study lock usage and contention.
- **[Pid Provider](../reference/dtrace_providers_pid.md)**
diff --git a/doc/userguide/reference/dtrace_providers_ip.md b/doc/userguide/reference/dtrace_providers_ip.md
new file mode 100644
index 000000000..0630e577a
--- /dev/null
+++ b/doc/userguide/reference/dtrace_providers_ip.md
@@ -0,0 +1,173 @@
+# IP Provider
+
+The `ip` provider makes available a probe at IP send operations in the system and a probe at receive.
+
+**Parent topic:**[DTrace Provider Reference](../reference/dtrace_providers.md)
+
+## ip Probes <a id="dt_ref_ipprobes_prov">
+
+The `ip` provider provides one probe for IP sends and another for IP receives.
+The module name is always `vmlinux` and the function name is empty.
+
+## ip Probe Arguments <a id="dt_ref_ipargs_prov">
+
+The following table lists the argument types for both the `send` and `receive` probes.
+
+| arg | type |
+| :--- | :--- |
+| `args[0]` | `pktinfo_t *` |
+| `args[1]` | `csinfo_t *` |
+| `args[2]` | `ipinfo_t *` |
+| `args[3]` | `ifinfo_t *` |
+| `args[4]` | `ipv4info_t *` |
+| `args[5]` | `ipv6sinfo_t *` |
+
+### pktinfo\_t <a id="dt_ref_ippkt_prov">
+
+The `pktinfo_t` structure is an abstraction that describes a packet.
+Detailed information about this data structure can be found in
+`/usr/lib64/dtrace/*version*/ip.d` or
+`/usr/lib64/dtrace/*version*/net.d`, depending on `dtrace` version.
+The definition of `pktinfo_t` is as follows:
+
+```nocopybutton
+typedef struct pktinfo {
+ uintptr_t pkt_addr;
+} pktinfo_t;
+```
+
+**Note:**
+
+DTrace translates the members of `pktinfo_t` from the `struct sk_buff *`.
+
+### csinfo\_t <a id="dt_ref_ipcs_prov">
+
+The `csinfo_t` structure is an abstraction that describes connection state.
+Detailed information about this data structure can be found in
+`/usr/lib64/dtrace/*version*/ip.d` or
+`/usr/lib64/dtrace/*version*/net.d`, depending on `dtrace` version.
+The definition of `csinfo_t` is as follows:
+
+```nocopybutton
+typedef struct csinfo {
+ uintptr_t cs_addr;
+ uint64_t cs_cid;
+} csinfo_t;
+```
+
+**Note:**
+
+DTrace translates the members of `csinfo_t` from the `struct sock *`.
+
+### ipinfo\_t <a id="dt_ref_ipip_prov">
+
+The `ipinfo_t` structure contains common IP info for both IPv4 and IPv6.
+Detailed information about this data structure can be found in `/usr/lib64/dtrace/*version*/ip.d`.
+The definition of `ipinfo_t` is as follows:
+
+```nocopybutton
+typedef struct ipinfo {
+ uint8_t ip_ver; /* IP version (4, 6) */
+ uint32_t ip_plength; /* payload length */
+ string ip_saddr; /* source address */
+ string ip_daddr; /* destination address */
+} ipinfo_t;
+```
+
+**Note:**
+
+DTrace translates the members of `ipinfo_t` from, variously,
+`struct iphdr *`, `struct ipv6hdr *`, or `void_ip_t *`.
+
+### ifinfo\_t <a id="dt_ref_ipif_prov">
+
+The `ifinfo_t` structure contains network interface info.
+Detailed information about this data structure can be found in `/usr/lib64/dtrace/*version*/ip.d`.
+The definition of `ifinfo_t` is as follows:
+
+```nocopybutton
+typedef struct ifinfo {
+ string if_name; /* interface name */
+ int8_t if_local; /* is delivered locally */
+ netstackid_t if_ipstack; /* netns pointer on Linux */
+ uintptr_t if_addr; /* pointer to raw struct net_device */
+} ifinfo_t;
+```
+
+**Note:**
+
+DTrace translates the members of `ifinfo_t` from a `struct net_device *`.
+
+### ipv4info\_t <a id="dt_ref_ipipv4_prov">
+
+The `ipv4info_t` structure is translated version of the IPv4 header
+(with raw pointer).
+These values are NULL if the packet is not IPv4.
+Detailed information about this data structure can be found in `/usr/lib64/dtrace/*version*/ip.d`.
+The definition of `ipv4info_t` is as follows:
+
+```nocopybutton
+typedef struct ipv4info {
+ uint8_t ipv4_ver; /* IP version (4) */
+ uint8_t ipv4_ihl; /* header length, bytes */
+ uint8_t ipv4_tos; /* type of service field */
+ uint16_t ipv4_length; /* length (header + payload) */
+ uint16_t ipv4_ident; /* identification */
+ uint8_t ipv4_flags; /* IP flags */
+ uint16_t ipv4_offset; /* fragment offset */
+ uint8_t ipv4_ttl; /* time to live */
+ uint8_t ipv4_protocol; /* next level protocol */
+ string ipv4_protostr; /* next level protocol, as string */
+ uint16_t ipv4_checksum; /* header checksum */
+ ipaddr_t ipv4_src; /* source address */
+ ipaddr_t ipv4_dst; /* destination address */
+ string ipv4_saddr; /* source address, string */
+ string ipv4_daddr; /* destination address, string */
+ struct iphdr *ipv4_hdr; /* pointer to raw header */
+} ipv4info_t;
+```
+
+**Note:**
+
+DTrace translates the members of `ipv4info_t` from a `struct iphdr *`.
+
+### ipv6info\_t <a id="dt_ref_ipipv6_prov">
+
+The `ipv6info_t` structure is translated version of the IPv6 header
+(with raw pointer).
+These values are NULL if the packet is not IPv6.
+Detailed information about this data structure can be found in `/usr/lib64/dtrace/*version*/ip.d`.
+The definition of `ipv6info_t` is as follows:
+
+```nocopybutton
+typedef struct ipv6info {
+ uint8_t ipv6_ver; /* IP version (6) */
+ uint8_t ipv6_tclass; /* traffic class */
+ uint32_t ipv6_flow; /* flow label */
+ uint16_t ipv6_plen; /* payload length */
+ uint8_t ipv6_nexthdr; /* next header protocol */
+ string ipv6_nextstr; /* next header protocol, as string */
+ uint8_t ipv6_hlim; /* hop limit */
+ in6_addr_t *ipv6_src; /* source address */
+ in6_addr_t *ipv6_dst; /* destination address */
+ string ipv6_saddr; /* source address, string */
+ string ipv6_daddr; /* destination address, string */
+ struct ipv6hdr *ipv6_hdr; /* pointer to raw header */
+} ipv6info_t;
+```
+
+**Note:**
+
+DTrace translates the members of `ipv6info_t` from a `struct ipv6hdr *`.
+
+## ip Stability <a id="dt_ref_ipstab_prov">
+
+The `ip` provider uses DTrace's stability mechanism to describe its stabilities. These stability values are listed in the following table.
+
+| Element | Name Stability | Data Stability | Dependency Class |
+| :--- | :--- | :--- | :--- |
+| Provider | Evolving | Evolving | ISA |
+| Module | Private | Private | Unknown |
+| Function | Private | Private | Unknown |
+| Name | Evolving | Evolving | ISA |
+| Arguments | Evolving | Evolving | ISA |
--
2.47.3
^ permalink raw reply related [flat|nested] 28+ messages in thread* [PATCH v2 18/20] doc: Add TCP provider documentation
2025-10-22 3:22 [PATCH v2 05/20] doc: Replace duplicate id eugene.loh
` (10 preceding siblings ...)
2025-10-22 3:22 ` [PATCH v2 17/20] doc: Add IP provider documentation eugene.loh
@ 2025-10-22 3:22 ` eugene.loh
2025-10-22 3:22 ` [PATCH v2 19/20] doc: Add UDP " eugene.loh
` (3 subsequent siblings)
15 siblings, 0 replies; 28+ messages in thread
From: eugene.loh @ 2025-10-22 3:22 UTC (permalink / raw)
To: dtrace, dtrace-devel
From: Eugene Loh <eugene.loh@oracle.com>
Signed-off-by: Eugene Loh <eugene.loh@oracle.com>
---
doc/userguide/index.md | 8 +-
doc/userguide/reference/dtrace_providers.md | 2 +
.../reference/dtrace_providers_tcp.md | 127 ++++++++++++++++++
3 files changed, 136 insertions(+), 1 deletion(-)
create mode 100644 doc/userguide/reference/dtrace_providers_tcp.md
diff --git a/doc/userguide/index.md b/doc/userguide/index.md
index 063881c6d..fa9d9d021 100644
--- a/doc/userguide/index.md
+++ b/doc/userguide/index.md
@@ -259,9 +259,15 @@
- [syscall Probes](reference/dtrace_providers_syscall.md#dt_ref_syscallprobes_prov)
- [syscall Probe Arguments](reference/dtrace_providers_syscall.md#dt_ref_syscallargs_prov)
- [syscall Stability](reference/dtrace_providers_syscall.md#dt_ref_syscallstab_prov)
+ - [TCP Provider](reference/dtrace_providers_tcp.md)
+ - [tcp Probes](reference/dtrace_providers_tcp.md#dt_ref_tcpprobes_prov)
+ - [tcp Probe Arguments](reference/dtrace_providers_tcp.md#dt_ref_tcpargs_prov)
+ - [tcpinfo\_t](reference/dtrace_providers_tcp.md#dt_ref_tcptcp_prov)
+ - [tcpsinfo\_t](reference/dtrace_providers_tcp.md#dt_ref_tcptcps_prov)
+ - [tcplsinfo\_t](reference/dtrace_providers_tcp.md#dt_ref_tcptcpls_prov)
+ - [tcp Stability](reference/dtrace_providers_tcp.md#dt_ref_tcpstab_prov)
- [USDT Provider](reference/dtrace-ref-StaticallyDefinedTracingofUserApplications.md#dt_ref_usdt_prov)
- [Defining USDT Providers and Probes](reference/dtrace-ref-StaticallyDefinedTracingofUserApplications.md#dt_ref_usdtprobes_prov)
- [Adding USDT Probes to Application Code](reference/dtrace-ref-StaticallyDefinedTracingofUserApplications.md#dt_ref_usdt_probe_add_prov)
- [Building Applications With USDT Probes](reference/dtrace-ref-StaticallyDefinedTracingofUserApplications.md#dt_ref_usdt_build_prov)
- [USDT Examples](reference/dtrace-ref-StaticallyDefinedTracingofUserApplications.md#dt_ref_usdtexamples_prov)
-
diff --git a/doc/userguide/reference/dtrace_providers.md b/doc/userguide/reference/dtrace_providers.md
index a225f4486..7da634d2a 100644
--- a/doc/userguide/reference/dtrace_providers.md
+++ b/doc/userguide/reference/dtrace_providers.md
@@ -29,6 +29,8 @@ The `sched` provider makes available probes related to CPU scheduling.
The Statically Defined Tracing \(SDT\) provider \(`sdt`\) creates probes at sites that a software programmer has formally designated. Thus, the SDT provider is chiefly of interest only to developers of new providers. Most users access SDT only indirectly by using other providers.
- **[Syscall Provider](../reference/dtrace_providers_syscall.md)**
The `syscall` provider makes available a probe at the entry to and return from every system call in the system.
+- **[TCP Provider](../reference/dtrace_providers_tcp.md)**
+The `tcp` provider makes available probe at different phases of TCP processing.
- **[USDT Provider](../reference/dtrace-ref-StaticallyDefinedTracingofUserApplications.md)**
Use the USDT provider, for user space statically defined tracing, to instrument user space code with probes that are meaningful for an application.
diff --git a/doc/userguide/reference/dtrace_providers_tcp.md b/doc/userguide/reference/dtrace_providers_tcp.md
new file mode 100644
index 000000000..fefa9d629
--- /dev/null
+++ b/doc/userguide/reference/dtrace_providers_tcp.md
@@ -0,0 +1,127 @@
+# TCP Provider
+
+The `tcp` provider makes available probes that mark different
+phases of tcp processing.
+
+**Parent topic:**[DTrace Provider Reference](../reference/dtrace_providers.md)
+
+## tcp Probes <a id="dt_ref_tcpprobes_prov">
+
+`tcp` provides a probe for each of TCP accept (established or refused), connect
+(request, established, refused), send, receive, and state-change:
+
+- `accept-established`
+- `accept-refused`
+- `connect-request`
+- `connect-established`
+- `connect-refused`
+- `send`
+- `receive`
+- `state-change`
+
+The module name is always `vmlinux` and the function name is empty.
+
+## tcp Probe Arguments <a id="dt_ref_tcpargs_prov">
+
+The following table lists the argument types for `tcp` probes.
+
+| probe | `args[0]` | `args[1]` | `args[2]` | `args[3]` | `args[4]` | `args[5]` |
+| :--- | :--- | :--- | :--- | :--- | :--- | :--- |
+| `accept-established` | `pktinfo_t *` | `csinfo_t *` | `ipinfo_t *` | `tcpsinfo_t *` | `tcpinfo_t *` | `void` |
+| `accept-refused` | `pktinfo_t *` | `csinfo_t *` | `ipinfo_t *` | `tcpsinfo_t *` | `tcpinfo_t *` | `void` |
+| `connect-request` | `pktinfo_t *` | `csinfo_t *` | `ipinfo_t *` | `tcpsinfo_t *` | `tcpinfo_t *` | `void` |
+| `connect-established` | `pktinfo_t *` | `csinfo_t *` | `ipinfo_t *` | `tcpsinfo_t *` | `tcpinfo_t *` | `void` |
+| `connect-refused` | `pktinfo_t *` | `csinfo_t *` | `ipinfo_t *` | `tcpsinfo_t *` | `tcpinfo_t *` | `void` |
+| `send` | `pktinfo_t *` | `csinfo_t *` | `ipinfo_t *` | `tcpsinfo_t *` | `tcpinfo_t *` | `void` |
+| `receive` | `pktinfo_t *` | `csinfo_t *` | `ipinfo_t *` | `tcpsinfo_t *` | `tcpinfo_t *` | `void` |
+| `state-change` | `void` | `csinfo_t *` | `void` | `tcpsinfo_t *` | `void` | `tcplsinfo_t *` |
+
+The `pktinfo_t`, `csinfo_t`, and `ipinfo_t` structures are described in [IP Provider](dtrace_providers_ip.md).
+
+### tcpinfo\_t <a id="dt_ref_tcptcp_prov">
+
+The `tcpinfo_t` structure contains TCP header fields.
+Detailed information about this data structure can be found in `/usr/lib64/dtrace/*version*/tcp.d`.
+The definition of `tcpinfo_t` is as follows:
+
+```nocopybutton
+typedef struct tcpinfo {
+ uint16_t tcp_sport; /* source port */
+ uint16_t tcp_dport; /* destination port */
+ uint32_t tcp_seq; /* sequence number */
+ uint32_t tcp_ack; /* acknowledgment number */
+ uint8_t tcp_offset; /* data offset, in bytes */
+ uint8_t tcp_flags; /* flags */
+ uint16_t tcp_window; /* window size */
+ uint16_t tcp_checksum; /* checksum */
+ uint16_t tcp_urgent; /* urgent data pointer */
+ uintptr_t tcp_hdr; /* raw TCP header */
+} tcpinfo_t;
+```
+
+**Note:**
+
+DTrace translates the members of `tcpinfo_t` from a `struct tcphdr *`.
+
+### tcpsinfo\_t <a id="dt_ref_tcptcps_prov">
+
+The `tcpsinfo_t` structure contains stable TCP details from tcp_t.
+Detailed information about this data structure can be found in `/usr/lib64/dtrace/*version*/tcp.d`.
+The definition of `tcpsinfo_t` is as follows:
+
+```nocopybutton
+typedef struct tcpsinfo {
+ uintptr_t tcps_addr;
+ int tcps_local; /* is delivered locally, boolean */
+ uint16_t tcps_lport; /* local port */
+ uint16_t tcps_rport; /* remote port */
+ string tcps_laddr; /* local address, as a string */
+ string tcps_raddr; /* remote address, as a string */
+ int tcps_state; /* TCP state */
+ uint32_t tcps_iss; /* Initial sequence # sent */
+ uint32_t tcps_suna; /* sequence # sent but unacked */
+ uint32_t tcps_snxt; /* next sequence # to send */
+ uint32_t tcps_rnxt; /* next sequence # expected */
+ uint32_t tcps_swnd; /* send window size */
+ int32_t tcps_snd_ws; /* send window scaling */
+ uint32_t tcps_rwnd; /* receive window size */
+ int32_t tcps_rcv_ws; /* receive window scaling */
+ uint32_t tcps_cwnd; /* congestion window */
+ uint32_t tcps_cwnd_ssthresh; /* threshold for congestion avoidance */
+ uint32_t tcps_sack_snxt; /* next SACK seq # for retransmission */
+ uint32_t tcps_rto; /* round-trip timeout, msec */
+ uint32_t tcps_mss; /* max segment size */
+ int tcps_retransmit; /* retransmit send event, boolean */
+ uint32_t tcps_rtt; /* smoothed avg round-trip time, msec */
+ uint32_t tcps_rtt_sd; /* standard deviation of RTT */
+ uint32_t tcps_irs; /* Initial recv sequence # */
+} tcpsinfo_t;
+```
+
+**Note:**
+
+DTrace translates the members of `tcpsinfo_t` from a `struct tcp_sock *`.
+
+### tcplsinfo\_t <a id="dt_ref_tcptcpls_prov">
+
+The `tcplsinfo_t` structure has the old tcp state for state changes.
+Detailed information about this data structure can be found in `/usr/lib64/dtrace/*version*/tcp.d`.
+The definition of `tcplsinfo_t` is as follows:
+
+```nocopybutton
+typedef struct tcplsinfo {
+ int tcps_state; /* previous TCP state */
+} tcplsinfo_t;
+```
+
+## tcp Stability <a id="dt_ref_tcpstab_prov">
+
+The `tcp` provider uses DTrace's stability mechanism to describe its stabilities. These stability values are listed in the following table.
+
+| Element | Name Stability | Data Stability | Dependency Class |
+| :--- | :--- | :--- | :--- |
+| Provider | Evolving | Evolving | ISA |
+| Module | Private | Private | Unknown |
+| Function | Private | Private | Unknown |
+| Name | Evolving | Evolving | ISA |
+| Arguments | Evolving | Evolving | ISA |
--
2.47.3
^ permalink raw reply related [flat|nested] 28+ messages in thread* [PATCH v2 19/20] doc: Add UDP provider documentation
2025-10-22 3:22 [PATCH v2 05/20] doc: Replace duplicate id eugene.loh
` (11 preceding siblings ...)
2025-10-22 3:22 ` [PATCH v2 18/20] doc: Add TCP " eugene.loh
@ 2025-10-22 3:22 ` eugene.loh
2025-10-22 3:22 ` [PATCH v2 20/20] doc: Add rawfbt " eugene.loh
` (2 subsequent siblings)
15 siblings, 0 replies; 28+ messages in thread
From: eugene.loh @ 2025-10-22 3:22 UTC (permalink / raw)
To: dtrace, dtrace-devel
From: Eugene Loh <eugene.loh@oracle.com>
Signed-off-by: Eugene Loh <eugene.loh@oracle.com>
---
doc/userguide/index.md | 6 ++
doc/userguide/reference/dtrace_providers.md | 2 +
.../reference/dtrace_providers_udp.md | 76 +++++++++++++++++++
3 files changed, 84 insertions(+)
create mode 100644 doc/userguide/reference/dtrace_providers_udp.md
diff --git a/doc/userguide/index.md b/doc/userguide/index.md
index fa9d9d021..f86c8b9e5 100644
--- a/doc/userguide/index.md
+++ b/doc/userguide/index.md
@@ -266,6 +266,12 @@
- [tcpsinfo\_t](reference/dtrace_providers_tcp.md#dt_ref_tcptcps_prov)
- [tcplsinfo\_t](reference/dtrace_providers_tcp.md#dt_ref_tcptcpls_prov)
- [tcp Stability](reference/dtrace_providers_tcp.md#dt_ref_tcpstab_prov)
+ - [UDP Provider](reference/dtrace_providers_udp.md)
+ - [udp Probes](reference/dtrace_providers_udp.md#dt_ref_udpprobes_prov)
+ - [udp Probe Arguments](reference/dtrace_providers_udp.md#dt_ref_udpargs_prov)
+ - [udpsinfo\_t](reference/dtrace_providers_udp.md#dt_ref_udpudps_prov)
+ - [udpinfo\_t](reference/dtrace_providers_udp.md#dt_ref_udpudp_prov)
+ - [udp Stability](reference/dtrace_providers_udp.md#dt_ref_udpstab_prov)
- [USDT Provider](reference/dtrace-ref-StaticallyDefinedTracingofUserApplications.md#dt_ref_usdt_prov)
- [Defining USDT Providers and Probes](reference/dtrace-ref-StaticallyDefinedTracingofUserApplications.md#dt_ref_usdtprobes_prov)
- [Adding USDT Probes to Application Code](reference/dtrace-ref-StaticallyDefinedTracingofUserApplications.md#dt_ref_usdt_probe_add_prov)
diff --git a/doc/userguide/reference/dtrace_providers.md b/doc/userguide/reference/dtrace_providers.md
index 7da634d2a..f11bacb2f 100644
--- a/doc/userguide/reference/dtrace_providers.md
+++ b/doc/userguide/reference/dtrace_providers.md
@@ -31,6 +31,8 @@ The Statically Defined Tracing \(SDT\) provider \(`sdt`\) creates probes at site
The `syscall` provider makes available a probe at the entry to and return from every system call in the system.
- **[TCP Provider](../reference/dtrace_providers_tcp.md)**
The `tcp` provider makes available probe at different phases of TCP processing.
+- **[UDP Provider](../reference/dtrace_providers_udp.md)**
+The `udp` provider makes available a probe at UDP send and receive operations in the system.
- **[USDT Provider](../reference/dtrace-ref-StaticallyDefinedTracingofUserApplications.md)**
Use the USDT provider, for user space statically defined tracing, to instrument user space code with probes that are meaningful for an application.
diff --git a/doc/userguide/reference/dtrace_providers_udp.md b/doc/userguide/reference/dtrace_providers_udp.md
new file mode 100644
index 000000000..455f91e4d
--- /dev/null
+++ b/doc/userguide/reference/dtrace_providers_udp.md
@@ -0,0 +1,76 @@
+# UDP Provider
+
+The `udp` provider makes available a probe at UDP send operations in the system and a probe at receive.
+
+**Parent topic:**[DTrace Provider Reference](../reference/dtrace_providers.md)
+
+## udp Probes <a id="dt_ref_udpprobes_prov">
+
+`udp` provides a probe for UDP sends and one for UDP receives.
+The module name is always `vmlinux` and the function name is empty.
+
+## udp Probe Arguments <a id="dt_ref_udpargs_prov">
+
+The following table lists the argument types for both the `send` and `receive` probes.
+
+| arg | type |
+| :--- | :--- |
+| `args[0]` | `pktinfo_t *` |
+| `args[1]` | `csinfo_t *` |
+| `args[2]` | `ipinfo_t *` |
+| `args[3]` | `udpsinfo_t *` |
+| `args[4]` | `udpinfo_t *` |
+
+The `pktinfo_t`, `csinfo_t`, and `ipinfo_t` structures are described in [IP Provider](dtrace_providers_ip.md).
+
+### udpsinfo\_t <a id="dt_ref_udpudps_prov">
+
+The `udpsinfo_t` structure contains stable UDP details from `udp_t`.
+Detailed information about this data structure can be found in `/usr/lib64/dtrace/*version*/udp.d`.
+The definition of `udpsinfo_t` is as follows:
+
+```nocopybutton
+typedef struct udpsinfo {
+ uintptr_t udps_addr;
+ uint16_t udps_lport; /* local port */
+ uint16_t udps_rport; /* remote port */
+ string udps_laddr; /* local address, as a string */
+ string udps_raddr; /* remote address, as a string */
+} udpsinfo_t;
+```
+
+**Note:**
+
+DTrace translates the members of `udpsinfo_t` from a `struct udp_sock *`.
+
+### udpinfo\_t <a id="dt_ref_udpudp_prov">
+
+The `udpinfo_t` structure contains the UDP header fields.
+Detailed information about this data structure can be found in `/usr/lib64/dtrace/*version*/udp.d`.
+The definition of `udpinfo_t` is as follows:
+
+```nocopybutton
+typedef struct udpinfo {
+ uint16_t udp_sport; /* source port */
+ uint16_t udp_dport; /* destination port */
+ uint16_t udp_length; /* total length */
+ uint16_t udp_checksum; /* headers + data checksum */
+ struct udphdr *udp_hdr; /* raw UDP header */
+} udpinfo_t;
+```
+
+**Note:**
+
+DTrace translates the members of `udpinfo_t` from a `struct udphdr *`.
+
+## udp Stability <a id="dt_ref_udpstab_prov">
+
+The `udp` provider uses DTrace's stability mechanism to describe its stabilities. These stability values are listed in the following table.
+
+| Element | Name Stability | Data Stability | Dependency Class |
+| :--- | :--- | :--- | :--- |
+| Provider | Evolving | Evolving | ISA |
+| Module | Private | Private | Unknown |
+| Function | Private | Private | Unknown |
+| Name | Evolving | Evolving | ISA |
+| Arguments | Evolving | Evolving | ISA |
--
2.47.3
^ permalink raw reply related [flat|nested] 28+ messages in thread* [PATCH v2 20/20] doc: Add rawfbt provider documentation
2025-10-22 3:22 [PATCH v2 05/20] doc: Replace duplicate id eugene.loh
` (12 preceding siblings ...)
2025-10-22 3:22 ` [PATCH v2 19/20] doc: Add UDP " eugene.loh
@ 2025-10-22 3:22 ` eugene.loh
2025-10-22 3:22 ` [PATCH 21/20] doc: Add blank line before section head so it is recognized eugene.loh
2025-10-23 19:23 ` [PATCH v2 05/20] doc: Replace duplicate id Elena Zannoni
15 siblings, 0 replies; 28+ messages in thread
From: eugene.loh @ 2025-10-22 3:22 UTC (permalink / raw)
To: dtrace, dtrace-devel
From: Eugene Loh <eugene.loh@oracle.com>
Signed-off-by: Eugene Loh <eugene.loh@oracle.com>
---
doc/userguide/index.md | 4 ++
doc/userguide/reference/dtrace_providers.md | 2 +
.../reference/dtrace_providers_rawfbt.md | 50 +++++++++++++++++++
3 files changed, 56 insertions(+)
create mode 100644 doc/userguide/reference/dtrace_providers_rawfbt.md
diff --git a/doc/userguide/index.md b/doc/userguide/index.md
index f86c8b9e5..da9a08687 100644
--- a/doc/userguide/index.md
+++ b/doc/userguide/index.md
@@ -241,6 +241,10 @@
- [profile Probe Arguments](reference/dtrace_providers_profile.md#dt_ref_profargs_prov)
- [profile Probe Creation](reference/dtrace_providers_profile.md#dt_ref_profprobecreate_prov)
- [profile Stability](reference/dtrace_providers_profile.md#dt_ref_profstab_prov)
+ - [Raw FBT Provider](reference/dtrace_providers_rawfbt.md)
+ - [rawfbt Probes](reference/dtrace_providers_rawfbt.md#dt_ref_rawfbtprobes_prov)
+ - [rawfbt Probe Arguments](reference/dtrace_providers_rawfbt.md#dt_ref_rawfbtargs_prov)
+ - [rawfbt Stability](reference/dtrace_providers_rawfbt.md#dt_ref_rawfbtstab_prov)
- [Rawtp Provider](reference/dtrace_providers_rawtp.md#dt_ref_rawtp_prov)
- [rawtp Stability](reference/dtrace_providers_rawtp.md#dt_ref_rawtpstab_prov)
- [Sched Provider](reference/dtrace_providers_sched.md#dt_ref_sched_prov)
diff --git a/doc/userguide/reference/dtrace_providers.md b/doc/userguide/reference/dtrace_providers.md
index f11bacb2f..741a34fc8 100644
--- a/doc/userguide/reference/dtrace_providers.md
+++ b/doc/userguide/reference/dtrace_providers.md
@@ -21,6 +21,8 @@ The `pid` provider traces a user process, both function `entry` and `return`, an
The `proc` provider makes available the probes that pertain to the following activities: process creation and termination, LWP creation and termination, execution of new program images, and signal sending and handling.
- **[Profile Provider](../reference/dtrace_providers_profile.md)**
The `profile` provider includes probes that are associated with an interrupt that fires at some regular, specified time interval.
+- **[Raw FBT Provider](../reference/dtrace_providers_rawfbt.md)**
+The `rawfbt` provider is a version of the `fbt` provider based on kprobes and allowing probing of synthetic function variants generated by the compiler.
- **[Rawtp Provider](../reference/dtrace_providers_rawtp.md)**
The `rawtp` provider gives DTrace users access to the raw tracepoints exposed by the kernel tracing system, including access to the untranslated arguments of the associated tracepoint events.
- **[Sched Provider](../reference/dtrace_providers_sched.md)**
diff --git a/doc/userguide/reference/dtrace_providers_rawfbt.md b/doc/userguide/reference/dtrace_providers_rawfbt.md
new file mode 100644
index 000000000..7b1fc7723
--- /dev/null
+++ b/doc/userguide/reference/dtrace_providers_rawfbt.md
@@ -0,0 +1,50 @@
+# Raw FBT Provider
+
+The [fbt provider](../reference/dtrace_providers_fbt.md) consists of
+probes that are associated with the entry to and return from most functions
+in the Linux kernel. It does not support tracing synthetic functions,
+that is, compiler-generated functions with a . in their name.
+
+In contrast, the `rawfbt` provider implements a variant of the FBT provider
+and always uses kprobes. It does allow tracing of synthetic functions, such
+as compiler-generated optimized variants of functions with . suffixes.
+
+You can see the raw FBT probes on your system with:
+
+```
+sudo dtrace -lP rawfbt
+```
+
+As with the `fbt` provider, there could be tens of thousands of probes,
+and effective use requires knowledge of the kernel implementation.
+
+**Parent topic:**[DTrace Provider Reference](../reference/dtrace_providers.md)
+
+## rawfbt Probes <a id="dt_ref_rawfbtprobes_prov">
+
+The module name of a `rawfbt` probe is `vmlinux` for built-in modules.
+The function name is the probed function.
+The probe name is either `entry` or `return`.
+
+## rawfbt Probe Arguments <a id="dt_ref_rawfbtargs_prov">
+
+The arguments to `entry` probes are the same as the arguments to the corresponding operating system kernel function.
+These arguments can be accessed as `int64_t` values by using the `arg0`, `arg1`, `arg2`, ... variables.
+
+If the function has a return value, the return value is stored in `arg1` of the `return` probe.
+If a function doesn't have a return value, `arg1` isn't defined.
+
+There are no typed `args[]` arguments for any `rawfbt` probes.
+
+## rawfbt Stability <a id="dt_ref_rawfbtstab_prov">
+
+The `rawfbt` provider uses DTrace's stability mechanism to describe its stabilities.
+These stability values are listed in the following table.
+
+| Element | Name Stability | Data Stability | Dependency Class |
+| :--- | :--- | :--- | :--- |
+| Provider | Evolving | Evolving | Common |
+| Module | Private | Private | Unknown |
+| Function | Private | Private | ISA |
+| Name | Evolving | Evolving | Common |
+| Arguments | Private | Private | ISA |
--
2.47.3
^ permalink raw reply related [flat|nested] 28+ messages in thread* [PATCH 21/20] doc: Add blank line before section head so it is recognized
2025-10-22 3:22 [PATCH v2 05/20] doc: Replace duplicate id eugene.loh
` (13 preceding siblings ...)
2025-10-22 3:22 ` [PATCH v2 20/20] doc: Add rawfbt " eugene.loh
@ 2025-10-22 3:22 ` eugene.loh
2025-10-23 19:35 ` [DTrace-devel] " Elena Zannoni
2025-10-23 19:23 ` [PATCH v2 05/20] doc: Replace duplicate id Elena Zannoni
15 siblings, 1 reply; 28+ messages in thread
From: eugene.loh @ 2025-10-22 3:22 UTC (permalink / raw)
To: dtrace, dtrace-devel
From: Eugene Loh <eugene.loh@oracle.com>
Signed-off-by: Eugene Loh <eugene.loh@oracle.com>
---
.../reference/dtrace-ref-TypesOperatorsandExpressions.md | 1 +
doc/userguide/reference/dtrace-ref-speculation.md | 1 +
doc/userguide/reference/dtrace_providers_proc.md | 2 ++
doc/userguide/reference/dtrace_providers_sched.md | 2 ++
doc/userguide/reference/dtrace_stability_reference.md | 1 +
5 files changed, 7 insertions(+)
diff --git a/doc/userguide/reference/dtrace-ref-TypesOperatorsandExpressions.md b/doc/userguide/reference/dtrace-ref-TypesOperatorsandExpressions.md
index bb1c49949..ef0910b90 100644
--- a/doc/userguide/reference/dtrace-ref-TypesOperatorsandExpressions.md
+++ b/doc/userguide/reference/dtrace-ref-TypesOperatorsandExpressions.md
@@ -1151,6 +1151,7 @@ Dereferences a pointer to an object.
Accesses a member of a structure or union type.
</td></tr><tbody></table>
+
## Type and Constant Definitions <a id="dt_typcondef_dlang">
This section describes how to declare type aliases and named constants in D. It also discusses D type and namespace management for program and OS types and identifiers.
diff --git a/doc/userguide/reference/dtrace-ref-speculation.md b/doc/userguide/reference/dtrace-ref-speculation.md
index 30c5e6eaa..f93053275 100644
--- a/doc/userguide/reference/dtrace-ref-speculation.md
+++ b/doc/userguide/reference/dtrace-ref-speculation.md
@@ -74,6 +74,7 @@ ID
Discards the speculative buffer that's associated with ID.
</td></tr><tbody></table>
+
## How to use speculation
The following example illustrates how to use speculation. All speculation functions must be used together for speculation to work correctly.
diff --git a/doc/userguide/reference/dtrace_providers_proc.md b/doc/userguide/reference/dtrace_providers_proc.md
index cf64bc28f..d799efd72 100644
--- a/doc/userguide/reference/dtrace_providers_proc.md
+++ b/doc/userguide/reference/dtrace_providers_proc.md
@@ -357,6 +357,7 @@ Probe
—
</td></tr><tbody></table>
+
### lwpsinfo\_t <a id="dt_ref_lwpsinfoproc_prov">
Several `proc` probes have arguments of type `lwpsinfo_t`. Detailed information about this data structure can be found in `/usr/lib64/dtrace/*version*/procfs.d`. Some structure members, while still recognized for historical reasons, aren't implemented. The definition of the `lwpsinfo_t` structure is as follows:
@@ -475,6 +476,7 @@ The thread is a zombie.
The equivalent Linux task state is `EXIT_ZOMBIE`, `EXIT_DEAD`, or `TASK_DEAD`.
</td></tr><tbody></table>
+
### psinfo\_t <a id="dt_ref_procpsinfo_prov">
Several `proc` probes have an argument of type `psinfo_t`. Detailed information about this data structure can be found in `/usr/lib64/dtrace/*version*/procfs.d`. The definition of the `psinfo_t` structure, is as follows:
diff --git a/doc/userguide/reference/dtrace_providers_sched.md b/doc/userguide/reference/dtrace_providers_sched.md
index 42f318e77..652f2917c 100644
--- a/doc/userguide/reference/dtrace_providers_sched.md
+++ b/doc/userguide/reference/dtrace_providers_sched.md
@@ -76,6 +76,7 @@ Fires as a part of clock tick-based accounting. In clock tick-based accounting,
Fires immediately before the current thread wakes a thread sleeping on a synchronization object. Here, `args[0]` and `args[1]` refer to the sleeping thread, as an `lwpsinfo_t *` and `psinfo_t *`, respectively. The type and address of the synchronization object are contained in the `pr_stype` and `pr_wchan` members of the `lwpsinfo_t` of the sleeping thread. The meaning of this address is a private implementation detail, but the address value might be treated as a token unique to the synchronization object.
</td></tr><tbody></table>
+
## sched Probe Arguments <a id="dt_ref_schedargs_prov">
Many of these probes refer to a particular thread. For these probes, the thread's `lwpsinfo_t` is pointed to by `args[0]` and the `psinfo_t` of the process containing the thread by `args[1]`. A few probes refer to a particular CPU. Its `cpuinfo_t` is pointed to by `args[2]`. Only `enqueue` has an `args[3]`, and that argument is a Boolean, as described. The `argN` values are implementation specific. Instead, use `args[]` to access the probe arguments.
@@ -243,6 +244,7 @@ Probe
—
</td></tr><tbody></table>
+
### lwpsinfo\_t and psinfo\_t <a id="dt_ref_lwpsinfo_t_psinfo_t_sched_prov">
The `lwpsinfo_t` and `psinfo_t` structures are described in [Proc Provider](dtrace_providers_proc.md).
diff --git a/doc/userguide/reference/dtrace_stability_reference.md b/doc/userguide/reference/dtrace_stability_reference.md
index f90b91de3..fb3238ec4 100644
--- a/doc/userguide/reference/dtrace_stability_reference.md
+++ b/doc/userguide/reference/dtrace_stability_reference.md
@@ -146,6 +146,7 @@ Standard
The interface complies with an industry standard. The corresponding documentation for the interface describes the standard to which the interface conforms. Standards are typically controlled by a standards development organization. Changes can be made to the interface in accordance with approved changes to the standard. This stability level can also apply to interfaces that have been adopted \(without a formal standard\) by an industry convention. Availability is provided for only the specified versions of a standard; availability in later versions isn't guaranteed.
</td></tr><tbody></table>
+
## Dependency Classes
Dependency classes are used to describe architectural dependencies for interfaces in DTrace.
--
2.47.3
^ permalink raw reply related [flat|nested] 28+ messages in thread* Re: [DTrace-devel] [PATCH 21/20] doc: Add blank line before section head so it is recognized
2025-10-22 3:22 ` [PATCH 21/20] doc: Add blank line before section head so it is recognized eugene.loh
@ 2025-10-23 19:35 ` Elena Zannoni
0 siblings, 0 replies; 28+ messages in thread
From: Elena Zannoni @ 2025-10-23 19:35 UTC (permalink / raw)
To: eugene.loh, dtrace, dtrace-devel
Reviewed-by: Elena Zannoni <elena.zannoni@oracle.com>
On 10/21/25 9:22 PM, eugene.loh--- via DTrace-devel wrote:
> From: Eugene Loh <eugene.loh@oracle.com>
>
> Signed-off-by: Eugene Loh <eugene.loh@oracle.com>
> ---
> .../reference/dtrace-ref-TypesOperatorsandExpressions.md | 1 +
> doc/userguide/reference/dtrace-ref-speculation.md | 1 +
> doc/userguide/reference/dtrace_providers_proc.md | 2 ++
> doc/userguide/reference/dtrace_providers_sched.md | 2 ++
> doc/userguide/reference/dtrace_stability_reference.md | 1 +
> 5 files changed, 7 insertions(+)
>
> diff --git a/doc/userguide/reference/dtrace-ref-TypesOperatorsandExpressions.md b/doc/userguide/reference/dtrace-ref-TypesOperatorsandExpressions.md
> index bb1c49949..ef0910b90 100644
> --- a/doc/userguide/reference/dtrace-ref-TypesOperatorsandExpressions.md
> +++ b/doc/userguide/reference/dtrace-ref-TypesOperatorsandExpressions.md
> @@ -1151,6 +1151,7 @@ Dereferences a pointer to an object.
> Accesses a member of a structure or union type.
>
> </td></tr><tbody></table>
> +
> ## Type and Constant Definitions <a id="dt_typcondef_dlang">
>
> This section describes how to declare type aliases and named constants in D. It also discusses D type and namespace management for program and OS types and identifiers.
> diff --git a/doc/userguide/reference/dtrace-ref-speculation.md b/doc/userguide/reference/dtrace-ref-speculation.md
> index 30c5e6eaa..f93053275 100644
> --- a/doc/userguide/reference/dtrace-ref-speculation.md
> +++ b/doc/userguide/reference/dtrace-ref-speculation.md
> @@ -74,6 +74,7 @@ ID
> Discards the speculative buffer that's associated with ID.
>
> </td></tr><tbody></table>
> +
> ## How to use speculation
>
> The following example illustrates how to use speculation. All speculation functions must be used together for speculation to work correctly.
> diff --git a/doc/userguide/reference/dtrace_providers_proc.md b/doc/userguide/reference/dtrace_providers_proc.md
> index cf64bc28f..d799efd72 100644
> --- a/doc/userguide/reference/dtrace_providers_proc.md
> +++ b/doc/userguide/reference/dtrace_providers_proc.md
> @@ -357,6 +357,7 @@ Probe
> —
>
> </td></tr><tbody></table>
> +
> ### lwpsinfo\_t <a id="dt_ref_lwpsinfoproc_prov">
>
> Several `proc` probes have arguments of type `lwpsinfo_t`. Detailed information about this data structure can be found in `/usr/lib64/dtrace/*version*/procfs.d`. Some structure members, while still recognized for historical reasons, aren't implemented. The definition of the `lwpsinfo_t` structure is as follows:
> @@ -475,6 +476,7 @@ The thread is a zombie.
> The equivalent Linux task state is `EXIT_ZOMBIE`, `EXIT_DEAD`, or `TASK_DEAD`.
>
> </td></tr><tbody></table>
> +
> ### psinfo\_t <a id="dt_ref_procpsinfo_prov">
>
> Several `proc` probes have an argument of type `psinfo_t`. Detailed information about this data structure can be found in `/usr/lib64/dtrace/*version*/procfs.d`. The definition of the `psinfo_t` structure, is as follows:
> diff --git a/doc/userguide/reference/dtrace_providers_sched.md b/doc/userguide/reference/dtrace_providers_sched.md
> index 42f318e77..652f2917c 100644
> --- a/doc/userguide/reference/dtrace_providers_sched.md
> +++ b/doc/userguide/reference/dtrace_providers_sched.md
> @@ -76,6 +76,7 @@ Fires as a part of clock tick-based accounting. In clock tick-based accounting,
> Fires immediately before the current thread wakes a thread sleeping on a synchronization object. Here, `args[0]` and `args[1]` refer to the sleeping thread, as an `lwpsinfo_t *` and `psinfo_t *`, respectively. The type and address of the synchronization object are contained in the `pr_stype` and `pr_wchan` members of the `lwpsinfo_t` of the sleeping thread. The meaning of this address is a private implementation detail, but the address value might be treated as a token unique to the synchronization object.
>
> </td></tr><tbody></table>
> +
> ## sched Probe Arguments <a id="dt_ref_schedargs_prov">
>
> Many of these probes refer to a particular thread. For these probes, the thread's `lwpsinfo_t` is pointed to by `args[0]` and the `psinfo_t` of the process containing the thread by `args[1]`. A few probes refer to a particular CPU. Its `cpuinfo_t` is pointed to by `args[2]`. Only `enqueue` has an `args[3]`, and that argument is a Boolean, as described. The `argN` values are implementation specific. Instead, use `args[]` to access the probe arguments.
> @@ -243,6 +244,7 @@ Probe
> —
>
> </td></tr><tbody></table>
> +
> ### lwpsinfo\_t and psinfo\_t <a id="dt_ref_lwpsinfo_t_psinfo_t_sched_prov">
>
> The `lwpsinfo_t` and `psinfo_t` structures are described in [Proc Provider](dtrace_providers_proc.md).
> diff --git a/doc/userguide/reference/dtrace_stability_reference.md b/doc/userguide/reference/dtrace_stability_reference.md
> index f90b91de3..fb3238ec4 100644
> --- a/doc/userguide/reference/dtrace_stability_reference.md
> +++ b/doc/userguide/reference/dtrace_stability_reference.md
> @@ -146,6 +146,7 @@ Standard
> The interface complies with an industry standard. The corresponding documentation for the interface describes the standard to which the interface conforms. Standards are typically controlled by a standards development organization. Changes can be made to the interface in accordance with approved changes to the standard. This stability level can also apply to interfaces that have been adopted \(without a formal standard\) by an industry convention. Availability is provided for only the specified versions of a standard; availability in later versions isn't guaranteed.
>
> </td></tr><tbody></table>
> +
> ## Dependency Classes
>
> Dependency classes are used to describe architectural dependencies for interfaces in DTrace.
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v2 05/20] doc: Replace duplicate id
2025-10-22 3:22 [PATCH v2 05/20] doc: Replace duplicate id eugene.loh
` (14 preceding siblings ...)
2025-10-22 3:22 ` [PATCH 21/20] doc: Add blank line before section head so it is recognized eugene.loh
@ 2025-10-23 19:23 ` Elena Zannoni
15 siblings, 0 replies; 28+ messages in thread
From: Elena Zannoni @ 2025-10-23 19:23 UTC (permalink / raw)
To: eugene.loh, dtrace, dtrace-devel
Reviewed-by: Elena Zannoni <elena.zannoni@oracle.com>
On 10/21/25 9:22 PM, eugene.loh@oracle.com wrote:
> From: Eugene Loh <eugene.loh@oracle.com>
>
> The id has already been defined above. Replace the second definition.
>
> Signed-off-by: Eugene Loh <eugene.loh@oracle.com>
> ---
> doc/userguide/reference/dtrace_builtin_variable_reference.md | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/doc/userguide/reference/dtrace_builtin_variable_reference.md b/doc/userguide/reference/dtrace_builtin_variable_reference.md
> index c9a7dfebc..607c8f0dd 100644
> --- a/doc/userguide/reference/dtrace_builtin_variable_reference.md
> +++ b/doc/userguide/reference/dtrace_builtin_variable_reference.md
> @@ -169,7 +169,7 @@ However, in probe descriptions, macro variables are expanded and concatenated wi
>
> Macro variables are only expanded one time within each probe description field and they can't contain probe description delimiters \(`:`\).
>
> -### Macro Arguments {#dt_macrov_scrpt}
> +### Macro Arguments {#dt_macroa_scrpt}
>
> The D compiler also provides a set of macro variables corresponding to any more argument operands that are specified as part of the `dtrace` command invocation. These *macro arguments* are accessed by using the built-in names `$0`, for the name of the D program file or `dtrace` command, `$1`, for the first extra operand, `$2` for the second operand, and so on. If you use the `-s` option, `$0` expands to the value of the name of the input file that's used with this option. For D programs that are specified on the command line, `$0` expands to the value of `argv[0]`, which is used to run the `dtrace` command itself.
>
^ permalink raw reply [flat|nested] 28+ messages in thread