--- /dev/null
+Creative Commons Attribution 4.0 International
+
+ Creative Commons Corporation (“Creative Commons”) is not a law firm and does not provide legal services or legal advice. Distribution of Creative Commons public licenses does not create a lawyer-client or other relationship. Creative Commons makes its licenses and related information available on an “as-is” basis. Creative Commons gives no warranties regarding its licenses, any material licensed under their terms and conditions, or any related information. Creative Commons disclaims all liability for damages resulting from their use to the fullest extent possible.
+
+Using Creative Commons Public Licenses
+
+Creative Commons public licenses provide a standard set of terms and conditions that creators and other rights holders may use to share original works of authorship and other material subject to copyright and certain other rights specified in the public license below. The following considerations are for informational purposes only, are not exhaustive, and do not form part of our licenses.
+
+Considerations for licensors: Our public licenses are intended for use by those authorized to give the public permission to use material in ways otherwise restricted by copyright and certain other rights. Our licenses are irrevocable. Licensors should read and understand the terms and conditions of the license they choose before applying it. Licensors should also secure all rights necessary before applying our licenses so that the public can reuse the material as expected. Licensors should clearly mark any material not subject to the license. This includes other CC-licensed material, or material used under an exception or limitation to copyright. More considerations for licensors.
+
+Considerations for the public: By using one of our public licenses, a licensor grants the public permission to use the licensed material under specified terms and conditions. If the licensor’s permission is not necessary for any reason–for example, because of any applicable exception or limitation to copyright–then that use is not regulated by the license. Our licenses grant only permissions under copyright and certain other rights that a licensor has authority to grant. Use of the licensed material may still be restricted for other reasons, including because others have copyright or other rights in the material. A licensor may make special requests, such as asking that all changes be marked or described. Although not required by our licenses, you are encouraged to respect those requests where reasonable. More considerations for the public.
+
+Creative Commons Attribution 4.0 International Public License
+
+By exercising the Licensed Rights (defined below), You accept and agree to be bound by the terms and conditions of this Creative Commons Attribution 4.0 International Public License ("Public License"). To the extent this Public License may be interpreted as a contract, You are granted the Licensed Rights in consideration of Your acceptance of these terms and conditions, and the Licensor grants You such rights in consideration of benefits the Licensor receives from making the Licensed Material available under these terms and conditions.
+
+Section 1 – Definitions.
+
+ a. Adapted Material means material subject to Copyright and Similar Rights that is derived from or based upon the Licensed Material and in which the Licensed Material is translated, altered, arranged, transformed, or otherwise modified in a manner requiring permission under the Copyright and Similar Rights held by the Licensor. For purposes of this Public License, where the Licensed Material is a musical work, performance, or sound recording, Adapted Material is always produced where the Licensed Material is synched in timed relation with a moving image.
+
+ b. Adapter's License means the license You apply to Your Copyright and Similar Rights in Your contributions to Adapted Material in accordance with the terms and conditions of this Public License.
+
+ c. Copyright and Similar Rights means copyright and/or similar rights closely related to copyright including, without limitation, performance, broadcast, sound recording, and Sui Generis Database Rights, without regard to how the rights are labeled or categorized. For purposes of this Public License, the rights specified in Section 2(b)(1)-(2) are not Copyright and Similar Rights.
+
+ d. Effective Technological Measures means those measures that, in the absence of proper authority, may not be circumvented under laws fulfilling obligations under Article 11 of the WIPO Copyright Treaty adopted on December 20, 1996, and/or similar international agreements.
+
+ e. Exceptions and Limitations means fair use, fair dealing, and/or any other exception or limitation to Copyright and Similar Rights that applies to Your use of the Licensed Material.
+
+ f. Licensed Material means the artistic or literary work, database, or other material to which the Licensor applied this Public License.
+
+ g. Licensed Rights means the rights granted to You subject to the terms and conditions of this Public License, which are limited to all Copyright and Similar Rights that apply to Your use of the Licensed Material and that the Licensor has authority to license.
+
+ h. Licensor means the individual(s) or entity(ies) granting rights under this Public License.
+
+ i. Share means to provide material to the public by any means or process that requires permission under the Licensed Rights, such as reproduction, public display, public performance, distribution, dissemination, communication, or importation, and to make material available to the public including in ways that members of the public may access the material from a place and at a time individually chosen by them.
+
+ j. Sui Generis Database Rights means rights other than copyright resulting from Directive 96/9/EC of the European Parliament and of the Council of 11 March 1996 on the legal protection of databases, as amended and/or succeeded, as well as other essentially equivalent rights anywhere in the world.
+
+ k. You means the individual or entity exercising the Licensed Rights under this Public License. Your has a corresponding meaning.
+
+Section 2 – Scope.
+
+ a. License grant.
+
+ 1. Subject to the terms and conditions of this Public License, the Licensor hereby grants You a worldwide, royalty-free, non-sublicensable, non-exclusive, irrevocable license to exercise the Licensed Rights in the Licensed Material to:
+
+ A. reproduce and Share the Licensed Material, in whole or in part; and
+
+ B. produce, reproduce, and Share Adapted Material.
+
+ 2. Exceptions and Limitations. For the avoidance of doubt, where Exceptions and Limitations apply to Your use, this Public License does not apply, and You do not need to comply with its terms and conditions.
+
+ 3. Term. The term of this Public License is specified in Section 6(a).
+
+ 4. Media and formats; technical modifications allowed. The Licensor authorizes You to exercise the Licensed Rights in all media and formats whether now known or hereafter created, and to make technical modifications necessary to do so. The Licensor waives and/or agrees not to assert any right or authority to forbid You from making technical modifications necessary to exercise the Licensed Rights, including technical modifications necessary to circumvent Effective Technological Measures. For purposes of this Public License, simply making modifications authorized by this Section 2(a)(4) never produces Adapted Material.
+
+ 5. Downstream recipients.
+
+ A. Offer from the Licensor – Licensed Material. Every recipient of the Licensed Material automatically receives an offer from the Licensor to exercise the Licensed Rights under the terms and conditions of this Public License.
+
+ B. No downstream restrictions. You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, the Licensed Material if doing so restricts exercise of the Licensed Rights by any recipient of the Licensed Material.
+
+ 6. No endorsement. Nothing in this Public License constitutes or may be construed as permission to assert or imply that You are, or that Your use of the Licensed Material is, connected with, or sponsored, endorsed, or granted official status by, the Licensor or others designated to receive attribution as provided in Section 3(a)(1)(A)(i).
+
+b. Other rights.
+
+ 1. Moral rights, such as the right of integrity, are not licensed under this Public License, nor are publicity, privacy, and/or other similar personality rights; however, to the extent possible, the Licensor waives and/or agrees not to assert any such rights held by the Licensor to the limited extent necessary to allow You to exercise the Licensed Rights, but not otherwise.
+
+ 2. Patent and trademark rights are not licensed under this Public License.
+
+ 3. To the extent possible, the Licensor waives any right to collect royalties from You for the exercise of the Licensed Rights, whether directly or through a collecting society under any voluntary or waivable statutory or compulsory licensing scheme. In all other cases the Licensor expressly reserves any right to collect such royalties.
+
+Section 3 – License Conditions.
+
+Your exercise of the Licensed Rights is expressly made subject to the following conditions.
+
+ a. Attribution.
+
+ 1. If You Share the Licensed Material (including in modified form), You must:
+
+ A. retain the following if it is supplied by the Licensor with the Licensed Material:
+
+ i. identification of the creator(s) of the Licensed Material and any others designated to receive attribution, in any reasonable manner requested by the Licensor (including by pseudonym if designated);
+
+ ii. a copyright notice;
+
+ iii. a notice that refers to this Public License;
+
+ iv. a notice that refers to the disclaimer of warranties;
+
+ v. a URI or hyperlink to the Licensed Material to the extent reasonably practicable;
+
+ B. indicate if You modified the Licensed Material and retain an indication of any previous modifications; and
+
+ C. indicate the Licensed Material is licensed under this Public License, and include the text of, or the URI or hyperlink to, this Public License.
+
+ 2. You may satisfy the conditions in Section 3(a)(1) in any reasonable manner based on the medium, means, and context in which You Share the Licensed Material. For example, it may be reasonable to satisfy the conditions by providing a URI or hyperlink to a resource that includes the required information.
+
+ 3. If requested by the Licensor, You must remove any of the information required by Section 3(a)(1)(A) to the extent reasonably practicable.
+
+ 4. If You Share Adapted Material You produce, the Adapter's License You apply must not prevent recipients of the Adapted Material from complying with this Public License.
+
+Section 4 – Sui Generis Database Rights.
+
+Where the Licensed Rights include Sui Generis Database Rights that apply to Your use of the Licensed Material:
+
+ a. for the avoidance of doubt, Section 2(a)(1) grants You the right to extract, reuse, reproduce, and Share all or a substantial portion of the contents of the database;
+
+ b. if You include all or a substantial portion of the database contents in a database in which You have Sui Generis Database Rights, then the database in which You have Sui Generis Database Rights (but not its individual contents) is Adapted Material; and
+
+ c. You must comply with the conditions in Section 3(a) if You Share all or a substantial portion of the contents of the database.
+For the avoidance of doubt, this Section 4 supplements and does not replace Your obligations under this Public License where the Licensed Rights include other Copyright and Similar Rights.
+
+Section 5 – Disclaimer of Warranties and Limitation of Liability.
+
+ a. Unless otherwise separately undertaken by the Licensor, to the extent possible, the Licensor offers the Licensed Material as-is and as-available, and makes no representations or warranties of any kind concerning the Licensed Material, whether express, implied, statutory, or other. This includes, without limitation, warranties of title, merchantability, fitness for a particular purpose, non-infringement, absence of latent or other defects, accuracy, or the presence or absence of errors, whether or not known or discoverable. Where disclaimers of warranties are not allowed in full or in part, this disclaimer may not apply to You.
+
+ b. To the extent possible, in no event will the Licensor be liable to You on any legal theory (including, without limitation, negligence) or otherwise for any direct, special, indirect, incidental, consequential, punitive, exemplary, or other losses, costs, expenses, or damages arising out of this Public License or use of the Licensed Material, even if the Licensor has been advised of the possibility of such losses, costs, expenses, or damages. Where a limitation of liability is not allowed in full or in part, this limitation may not apply to You.
+
+ c. The disclaimer of warranties and limitation of liability provided above shall be interpreted in a manner that, to the extent possible, most closely approximates an absolute disclaimer and waiver of all liability.
+
+Section 6 – Term and Termination.
+
+ a. This Public License applies for the term of the Copyright and Similar Rights licensed here. However, if You fail to comply with this Public License, then Your rights under this Public License terminate automatically.
+
+ b. Where Your right to use the Licensed Material has terminated under Section 6(a), it reinstates:
+
+ 1. automatically as of the date the violation is cured, provided it is cured within 30 days of Your discovery of the violation; or
+
+ 2. upon express reinstatement by the Licensor.
+
+ c. For the avoidance of doubt, this Section 6(b) does not affect any right the Licensor may have to seek remedies for Your violations of this Public License.
+
+ d. For the avoidance of doubt, the Licensor may also offer the Licensed Material under separate terms or conditions or stop distributing the Licensed Material at any time; however, doing so will not terminate this Public License.
+
+ e. Sections 1, 5, 6, 7, and 8 survive termination of this Public License.
+
+Section 7 – Other Terms and Conditions.
+
+ a. The Licensor shall not be bound by any additional or different terms or conditions communicated by You unless expressly agreed.
+
+ b. Any arrangements, understandings, or agreements regarding the Licensed Material not stated herein are separate from and independent of the terms and conditions of this Public License.
+
+Section 8 – Interpretation.
+
+ a. For the avoidance of doubt, this Public License does not, and shall not be interpreted to, reduce, limit, restrict, or impose conditions on any use of the Licensed Material that could lawfully be made without permission under this Public License.
+
+ b. To the extent possible, if any provision of this Public License is deemed unenforceable, it shall be automatically reformed to the minimum extent necessary to make it enforceable. If the provision cannot be reformed, it shall be severed from this Public License without affecting the enforceability of the remaining terms and conditions.
+
+ c. No term or condition of this Public License will be waived and no failure to comply consented to unless expressly agreed to by the Licensor.
+
+ d. Nothing in this Public License constitutes or may be interpreted as a limitation upon, or waiver of, any privileges and immunities that apply to the Licensor or You, including from the legal processes of any jurisdiction or authority.
+
+Creative Commons is not a party to its public licenses. Notwithstanding, Creative Commons may elect to apply one of its public licenses to material it publishes and in those instances will be considered the “Licensor.” Except for the limited purpose of indicating that material is shared under a Creative Commons public license or as otherwise permitted by the Creative Commons policies published at creativecommons.org/policies, Creative Commons does not authorize the use of the trademark “Creative Commons” or any other trademark or logo of Creative Commons without its prior written consent including, without limitation, in connection with any unauthorized modifications to any of its public licenses or any other arrangements, understandings, or agreements concerning use of licensed material. For the avoidance of doubt, this paragraph does not form part of the public licenses.
+
+Creative Commons may be contacted at creativecommons.org.
LICENSE \
LICENSES/Autoconf-exception-2.0.txt \
LICENSES/BSD-2-Clause.txt \
+ LICENSES/CC-BY-4.0.txt \
LICENSES/FSFAP.txt \
LICENSES/GPL-2.0-or-later.txt \
LICENSES/GPL-3.0-or-later.txt \
# SPDX-License-Identifier: MIT
# SPDX-FileCopyrightText: 2024 EfficiOS Inc.
-EXTRA_DIST = rfc-side-abi.txt
-dist_doc_DATA = rfc-side-abi.txt
+EXTRA_DIST = rfc-side-abi.md
+dist_doc_DATA = rfc-side-abi.md
--- /dev/null
+<!--
+SPDX-FileCopyrightText: 2024 Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
+
+SPDX-License-Identifier: CC-BY-4.0
+-->
+
+# RFC - SIDE ABI
+
+*This document is under heavy construction. Please beware of the
+ potholes as you wander through it.*
+
+## Introduction
+
+The purpose of the SIDE ABI is to allow kernel and user-space tracers to
+attach to static and dynamic instrumentation of user-space applications.
+
+The SIDE ABI key characteristics:
+
+- runtime and language agnostic,
+- supports multiple concurrent tracers,
+- instrumentation is not specific to a tracer, so there is no need
+ to rebuild applications if using a different tracer,
+- instrumentation can be either static or dynamic,
+- supports complex and nested types,
+- supports both static and dynamic types.
+
+The SIDE ABI expresses the instrumentation description as data (no
+generated code). Instrumentation arguments are passed on the stack as an
+array of typed items, along with a reference to the instrumentation
+description.
+
+The following ABIs are introduced to let applications declare their
+instrumentation and insert instrumentation calls:
+
+- an event description ABI,
+- a type description ABI,
+- an event and type attribute ABI, which allows associating key-value
+ tuples to events and types,
+- an ABI defining how applications provide arguments to instrumentation
+ calls.
+
+The combination of the type description and type argument ABIs is later
+refered to as the SIDE type system.
+
+The ABI exposed to kernel and user-space tracers allow them to list
+and connect to the instrumentation, and conditionally enables
+instrumentation when at least one tracer is using it.
+
+The type description and type argument ABIs include support for
+statically known types and dynamic types. Nested structures, arrays, and
+variable-length arrays are supported.
+
+The libside C API is a reference implementation of the SIDE ABI for
+instrumentation of C/C++ applications by user-space tracers following
+the default calling convention (System V ELF ABI on Linux, MS ABI on
+Windows) and eventually by Linux kernel tracers through the User Events
+ABI.
+
+A set of macros is provided with the libside C API for convenience of
+C/C++ application instrumentation.
+
+
+## Genesis
+
+The SIDE ABI and libside library learn from the user feedback about
+experience with LTTng-UST and Linux kernel tracepoints, and therefore
+they introduce significant changes (and vast simplifications) to the way
+instrumentation is done compared to LTTng-UST and Linux kernel
+tracepoints.
+
+- Linux kernel User Events ABI
+ - Exposes a stable ABI allowing applications to register their event
+ names/field types to the kernel,
+ - Can be expected to have a large effect on application instrumentation,
+ - My concerns:
+ – Should be co-designed with a userspace instrumentation API/ABI rather than only
+ focusing on the kernel ABI,
+ – Should allow purely userspace tracers to use the same instrumentation as userspace
+ tracers implemented within the Linux kernel,
+ – Tracers can target their specific use-cases, but infrastructure should be shared,
+ – Limit fragmentation of the instrumentation ecosystem.
+
+- Improvements over tracepoints:
+ - Improve compiler error reporting vs tracepoints
+ - API uses standard header inclusion practices
+ - share ABI across runtimes (no need to reimplement tracepoints for
+ each language, or to use string only payloads)
+
+- Improvements over SDT: allow expressing additional event semantic
+ (e.g. user attributes, versioning, nested and compound data types)
+ - libside has less impact on control flow when disabled (no stack setup)
+ - SDT ABI is focused on architecture calling conventions, libside ABI
+ is easier to use from runtime environments which have an ABI
+ different from the native architecture (golang, rust, python, java).
+ libside instrumentation ABI calls a small fixed set of functions.
+
+- Comparison with ETW
+ - similar to libside in terms of array of arguments,
+ - does not support pre-registration of events (static typing)
+ - type information received at runtime from the instrumentation
+ callsite.
+
+
+## Desiderata
+
+- Common instrumentation for kernel and purely userspace tracers,
+ - Instrumentation is self-described,
+ - Support compound and nested types,
+ - Support pre-registration of events,
+ - Do not rely on compiled event-specific code,
+ - Independent from ELF,
+ - Simple ABI for instrumented code, kernel, and user-space tracers,
+ - Support concurrent tracers,
+ - Expose API to allow dynamic instrumentation libraries to register
+ their events/payloads.
+
+- Support statically typed instrumentation
+
+- Support dynamically typed instrumentation
+ - Natively cover dynamically-typed languages
+ - The support for events with dynamic fields allows lessening the number
+ of statically declared events in situation where an application
+ possesses seldom-used events with a large variety of parameter types.
+ - The support for mixed static and dynamic event fields allows
+ implementation of post-processing string formatting along with a
+ variadic payload, while keeping trace data in a structured format.
+
+- Performance considerations for userspace tracers.
+ - Maintain performance characteristics comparable to existing
+ userspace tracers.
+ - Low overhead, good scalability when used by userspace tracers.
+
+- Allows tracing user-space through a kernel tracer. Even through it is
+ an approach that adds more overhead, it has the benefit of not
+ requiring agent threads to be deployed into applications, which is
+ useful to trace locked-down processes.
+
+- Instrumentation registration APIs
+ - Instrumentation can be generated at runtime
+ - dynamic patching,
+ - JIT
+ - Instrumentation can be declared statically (static instrumentation)
+ - Instrumentation can be enabled dynamically.
+ - Very low overhead when not in use.
+
+- libside must be extensible in the future.
+ - Extension scheme should allow adding new types in the future without
+ requiring complex logic to future-proof tracers.
+ - Exposed types are invariant,
+ - libside ABI and API can be extended by adding new types.
+
+- the side ABI should allow multiple instances and versions within
+ a process (e.g. libside for C/C++, Java side ABI, Python side ABI...).
+
+- Both event description and payload are data (no generated text).
+ - It allows tracers to directly interpret the event payload from their
+ description, removing the need for code generation. This lessens the
+ instruction cache pollution compared to code generation approaches.
+ - Tracer interpreter for filtering and field capture can directly use
+ the instrumentation data, without need for setting up a structured
+ argument layout on the stack within the tracer.
+
+- Validation of argument vs event description coherence.
+
+- Passing arguments to events should be:
+ - Conveniently express application data structures to be expected as
+ instrumentation input.
+ - Flexible,
+ - Efficient,
+ - If all are not possible combined, specialize types for each purpose.
+
+- Allow tracers to passively collect application state transitions.
+
+- Allow tracers to actively sample the current state of an application.
+
+- Error messages generated when misusing the API should be easy to
+ comprehend and resolve.
+
+- Allow expressing additional custom semantic augmenting events and
+ types.
+
+
+## Design / Architecture
+
+- Compiler error messages are easy to understand because it is a simple
+ header file without any repeated inclusion tricks.
+
+- Variadic events.
+
+- Instrumentation API/ABI:
+ – Type system,
+ - Type visitor callbacks
+ - (perfetto)
+ - Stack-copy types
+ - Data-gathering types
+ - Dynamic types.
+ – Helper macros for C/C++,
+ – Express instrumentation description as data,
+ – Instrumentation arguments are passed on the stack as a data array
+ (similar to iovec) along with a reference to instrumentation
+ description,
+ – Instrumentation is conditionally enabled when at least one tracer is
+ registered to it.
+
+- Tracer-agnostic API/ABI:
+ – Available events notifications,
+ – Conditionally enabling instrumentation,
+ – Synchronize registered user-space tracer callbacks with RCU,
+ – Co-designed to interact with User Events.
+
+- Application state dump
+ - How are applications/libraries meant to provide state information ?
+ - How are tracers meant to interact with state dump ?
+ - statedump mode polling
+ - statedump mode agent thread
+
+- RCU to synchronize userspace tracers registration vs invocation
+
+- How tracers are meant to interact with libside ?
+
+- How is C/C++ language instrumentation is meant to be used ?
+
+- How are dynamic instrumentation facilities meant to interact with
+ libside ?
+
+- How is a kernel tracer meant to interact with libside ?
+
+- How is gdb (ptrace) meant to interact with libside ?
+
+- Validation that instrumentation arguments match event description
+ fields cannot be done by the compiler, requires either:
+ - run time check,
+ - static checker (only for static instrumentation).
+
+- Event attributes.
+
+- Type attributes.
+++ /dev/null
-
-RFC - SIDE ABI
-
-[ This document is under heavy construction. Please beware of the
- potholes as you wander through it. ]
-
-* Introduction
-
-The purpose of the SIDE ABI is to allow kernel and user-space tracers to
-attach to static and dynamic instrumentation of user-space applications.
-
-The SIDE ABI key characteristics:
-
-- runtime and language agnostic,
-- supports multiple concurrent tracers,
-- instrumentation is not specific to a tracer, so there is no need
- to rebuild applications if using a different tracer,
-- instrumentation can be either static or dynamic,
-- supports complex and nested types,
-- supports both static and dynamic types.
-
-The SIDE ABI expresses the instrumentation description as data (no
-generated code). Instrumentation arguments are passed on the stack as an
-array of typed items, along with a reference to the instrumentation
-description.
-
-The following ABIs are introduced to let applications declare their
-instrumentation and insert instrumentation calls:
-
-- an event description ABI,
-- a type description ABI,
-- an event and type attribute ABI, which allows associating key-value
- tuples to events and types,
-- an ABI defining how applications provide arguments to instrumentation
- calls.
-
-The combination of the type description and type argument ABIs is later
-refered to as the SIDE type system.
-
-The ABI exposed to kernel and user-space tracers allow them to list
-and connect to the instrumentation, and conditionally enables
-instrumentation when at least one tracer is using it.
-
-The type description and type argument ABIs include support for
-statically known types and dynamic types. Nested structures, arrays, and
-variable-length arrays are supported.
-
-The libside C API is a reference implementation of the SIDE ABI for
-instrumentation of C/C++ applications by user-space tracers following
-the default calling convention (System V ELF ABI on Linux, MS ABI on
-Windows) and eventually by Linux kernel tracers through the User Events
-ABI.
-
-A set of macros is provided with the libside C API for convenience of
-C/C++ application instrumentation.
-
-
-* Genesis
-
-The SIDE ABI and libside library learn from the user feedback about
-experience with LTTng-UST and Linux kernel tracepoints, and therefore
-they introduce significant changes (and vast simplifications) to the way
-instrumentation is done compared to LTTng-UST and Linux kernel
-tracepoints.
-
-- Linux kernel User Events ABI
- - Exposes a stable ABI allowing applications to register their event
- names/field types to the kernel,
- - Can be expected to have a large effect on application instrumentation,
- - My concerns:
- – Should be co-designed with a userspace instrumentation API/ABI rather than only
- focusing on the kernel ABI,
- – Should allow purely userspace tracers to use the same instrumentation as userspace
- tracers implemented within the Linux kernel,
- – Tracers can target their specific use-cases, but infrastructure should be shared,
- – Limit fragmentation of the instrumentation ecosystem.
-
-- Improvements over tracepoints:
- - Improve compiler error reporting vs tracepoints
- - API uses standard header inclusion practices
- - share ABI across runtimes (no need to reimplement tracepoints for
- each language, or to use string only payloads)
-
-- Improvements over SDT: allow expressing additional event semantic
- (e.g. user attributes, versioning, nested and compound data types)
- - libside has less impact on control flow when disabled (no stack setup)
- - SDT ABI is focused on architecture calling conventions, libside ABI
- is easier to use from runtime environments which have an ABI
- different from the native architecture (golang, rust, python, java).
- libside instrumentation ABI calls a small fixed set of functions.
-
-- Comparison with ETW
- - similar to libside in terms of array of arguments,
- - does not support pre-registration of events (static typing)
- - type information received at runtime from the instrumentation
- callsite.
-
-
-* Desiderata
-
-- Common instrumentation for kernel and purely userspace tracers,
- - Instrumentation is self-described,
- - Support compound and nested types,
- - Support pre-registration of events,
- - Do not rely on compiled event-specific code,
- - Independent from ELF,
- - Simple ABI for instrumented code, kernel, and user-space tracers,
- - Support concurrent tracers,
- - Expose API to allow dynamic instrumentation libraries to register
- their events/payloads.
-
-- Support statically typed instrumentation
-
-- Support dynamically typed instrumentation
- - Natively cover dynamically-typed languages
- - The support for events with dynamic fields allows lessening the number
- of statically declared events in situation where an application
- possesses seldom-used events with a large variety of parameter types.
- - The support for mixed static and dynamic event fields allows
- implementation of post-processing string formatting along with a
- variadic payload, while keeping trace data in a structured format.
-
-- Performance considerations for userspace tracers.
- - Maintain performance characteristics comparable to existing
- userspace tracers.
- - Low overhead, good scalability when used by userspace tracers.
-
-- Allows tracing user-space through a kernel tracer. Even through it is
- an approach that adds more overhead, it has the benefit of not
- requiring agent threads to be deployed into applications, which is
- useful to trace locked-down processes.
-
-- Instrumentation registration APIs
- - Instrumentation can be generated at runtime
- - dynamic patching,
- - JIT
- - Instrumentation can be declared statically (static instrumentation)
- - Instrumentation can be enabled dynamically.
- - Very low overhead when not in use.
-
-- libside must be extensible in the future.
- - Extension scheme should allow adding new types in the future without
- requiring complex logic to future-proof tracers.
- - Exposed types are invariant,
- - libside ABI and API can be extended by adding new types.
-
-- the side ABI should allow multiple instances and versions within
- a process (e.g. libside for C/C++, Java side ABI, Python side ABI...).
-
-- Both event description and payload are data (no generated text).
- - It allows tracers to directly interpret the event payload from their
- description, removing the need for code generation. This lessens the
- instruction cache pollution compared to code generation approaches.
- - Tracer interpreter for filtering and field capture can directly use
- the instrumentation data, without need for setting up a structured
- argument layout on the stack within the tracer.
-
-- Validation of argument vs event description coherence.
-
-- Passing arguments to events should be:
- - Conveniently express application data structures to be expected as
- instrumentation input.
- - Flexible,
- - Efficient,
- - If all are not possible combined, specialize types for each purpose.
-
-- Allow tracers to passively collect application state transitions.
-
-- Allow tracers to actively sample the current state of an application.
-
-- Error messages generated when misusing the API should be easy to
- comprehend and resolve.
-
-- Allow expressing additional custom semantic augmenting events and
- types.
-
-
-* Design / Architecture
-
-- Compiler error messages are easy to understand because it is a simple
- header file without any repeated inclusion tricks.
-
-- Variadic events.
-
-- Instrumentation API/ABI:
- – Type system,
- - Type visitor callbacks
- - (perfetto)
- - Stack-copy types
- - Data-gathering types
- - Dynamic types.
- – Helper macros for C/C++,
- – Express instrumentation description as data,
- – Instrumentation arguments are passed on the stack as a data array
- (similar to iovec) along with a reference to instrumentation
- description,
- – Instrumentation is conditionally enabled when at least one tracer is
- registered to it.
-
-- Tracer-agnostic API/ABI:
- – Available events notifications,
- – Conditionally enabling instrumentation,
- – Synchronize registered user-space tracer callbacks with RCU,
- – Co-designed to interact with User Events.
-
-- Application state dump
- - How are applications/libraries meant to provide state information ?
- - How are tracers meant to interact with state dump ?
- - statedump mode polling
- - statedump mode agent thread
-
-- RCU to synchronize userspace tracers registration vs invocation
-
-- How tracers are meant to interact with libside ?
-
-- How is C/C++ language instrumentation is meant to be used ?
-
-- How are dynamic instrumentation facilities meant to interact with
- libside ?
-
-- How is a kernel tracer meant to interact with libside ?
-
-- How is gdb (ptrace) meant to interact with libside ?
-
-- Validation that instrumentation arguments match event description
- fields cannot be done by the compiler, requires either:
- - run time check,
- - static checker (only for static instrumentation).
-
-- Event attributes.
-
-- Type attributes.
+// SPDX-FileCopyrightText: 2024 Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
+//
+// SPDX-License-Identifier: MIT
+
#include <side/trace.h>
side_static_event(my_provider_event, "myprovider", "myevent", SIDE_LOGLEVEL_DEBUG,
+// SPDX-FileCopyrightText: 2024 Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
+//
+// SPDX-License-Identifier: MIT
+
#include <side/trace.h>
static
projects / libside.git / commitdiff
