From bf240d1accb960cecad1c3d79fbdf799c79aed20 Mon Sep 17 00:00:00 2001 From: Andrew Brown Date: Mon, 4 Dec 2023 09:46:08 -0800 Subject: [PATCH 1/2] rust: remind users how to regenerate bindings --- rust/ittapi-sys/tests/bindgen-up-to-date.rs | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/rust/ittapi-sys/tests/bindgen-up-to-date.rs b/rust/ittapi-sys/tests/bindgen-up-to-date.rs index 8d8bcde..f16680e 100644 --- a/rust/ittapi-sys/tests/bindgen-up-to-date.rs +++ b/rust/ittapi-sys/tests/bindgen-up-to-date.rs @@ -55,7 +55,7 @@ fn test_ittnotify_bindings_up_to_date() { diff::Result::Right(s) => println!("+{}", s), } } - panic!("differences found, need to regenerate ittnotify bindings"); + panic!("differences found, need to regenerate ittnotify bindings (`BLESS=1 cargo test`)"); } } @@ -86,7 +86,9 @@ fn test_jitprofiling_bindings_up_to_date() { diff::Result::Right(s) => println!("+{}", s), } } - panic!("differences found, need to regenerate jitprofiling bindings"); + panic!( + "differences found, need to regenerate jitprofiling bindings (`BLESS=1 cargo test`)" + ); } } From cdc784286e14cc28766660ed19ec4fb494088c49 Mon Sep 17 00:00:00 2001 From: Andrew Brown Date: Mon, 4 Dec 2023 09:53:00 -0800 Subject: [PATCH 2/2] rust: regenerate bindings with VTune name changes --- .../src/linux/jitprofiling_bindings.rs | 22 +++++++++---------- .../src/macos/jitprofiling_bindings.rs | 22 +++++++++---------- .../src/windows/jitprofiling_bindings.rs | 22 +++++++++---------- 3 files changed, 33 insertions(+), 33 deletions(-) diff --git a/rust/ittapi-sys/src/linux/jitprofiling_bindings.rs b/rust/ittapi-sys/src/linux/jitprofiling_bindings.rs index 428296c..29927bd 100644 --- a/rust/ittapi-sys/src/linux/jitprofiling_bindings.rs +++ b/rust/ittapi-sys/src/linux/jitprofiling_bindings.rs @@ -28,7 +28,7 @@ pub const _iJIT_IsProfilingActiveFlags_iJIT_SAMPLING_ON: _iJIT_IsProfilingActive pub type _iJIT_IsProfilingActiveFlags = ::std::os::raw::c_uint; #[doc = " @brief Enumerator for the agent's mode"] pub use self::_iJIT_IsProfilingActiveFlags as iJIT_IsProfilingActiveFlags; -#[doc = " @brief Description of a single entry in the line number information of a code region.\n @details A table of line number entries gives information about how the reported code region\n is mapped to source file.\n Intel(R) VTune(TM) Amplifier uses line number information to attribute\n the samples (virtual address) to a line number. \\n\n It is acceptable to report different code addresses for the same source line:\n @code\n Offset LineNumber\n 1 2\n 12 4\n 15 2\n 18 1\n 21 30\n\n VTune Amplifier constructs the following table using the client data\n\n Code subrange Line number\n 0-1 2\n 1-12 4\n 12-15 2\n 15-18 1\n 18-21 30\n @endcode"] +#[doc = " @brief Description of a single entry in the line number information of a code region.\n @details A table of line number entries gives information about how the reported code region\n is mapped to source file.\n Intel(R) VTune(TM) Profiler uses line number information to attribute\n the samples (virtual address) to a line number. \\n\n It is acceptable to report different code addresses for the same source line:\n @code\n Offset LineNumber\n 1 2\n 12 4\n 15 2\n 18 1\n 21 30\n\n VTune Profiler constructs the following table using the client data\n\n Code subrange Line number\n 0-1 2\n 1-12 4\n 12-15 2\n 15-18 1\n 18-21 30\n @endcode"] #[repr(C)] #[derive(Debug, Copy, Clone)] pub struct _LineNumberInfo { @@ -72,9 +72,9 @@ fn bindgen_test_layout__LineNumberInfo() { ) ); } -#[doc = " @brief Description of a single entry in the line number information of a code region.\n @details A table of line number entries gives information about how the reported code region\n is mapped to source file.\n Intel(R) VTune(TM) Amplifier uses line number information to attribute\n the samples (virtual address) to a line number. \\n\n It is acceptable to report different code addresses for the same source line:\n @code\n Offset LineNumber\n 1 2\n 12 4\n 15 2\n 18 1\n 21 30\n\n VTune Amplifier constructs the following table using the client data\n\n Code subrange Line number\n 0-1 2\n 1-12 4\n 12-15 2\n 15-18 1\n 18-21 30\n @endcode"] +#[doc = " @brief Description of a single entry in the line number information of a code region.\n @details A table of line number entries gives information about how the reported code region\n is mapped to source file.\n Intel(R) VTune(TM) Profiler uses line number information to attribute\n the samples (virtual address) to a line number. \\n\n It is acceptable to report different code addresses for the same source line:\n @code\n Offset LineNumber\n 1 2\n 12 4\n 15 2\n 18 1\n 21 30\n\n VTune Profiler constructs the following table using the client data\n\n Code subrange Line number\n 0-1 2\n 1-12 4\n 12-15 2\n 15-18 1\n 18-21 30\n @endcode"] pub type pLineNumberInfo = *mut _LineNumberInfo; -#[doc = " @brief Description of a single entry in the line number information of a code region.\n @details A table of line number entries gives information about how the reported code region\n is mapped to source file.\n Intel(R) VTune(TM) Amplifier uses line number information to attribute\n the samples (virtual address) to a line number. \\n\n It is acceptable to report different code addresses for the same source line:\n @code\n Offset LineNumber\n 1 2\n 12 4\n 15 2\n 18 1\n 21 30\n\n VTune Amplifier constructs the following table using the client data\n\n Code subrange Line number\n 0-1 2\n 1-12 4\n 12-15 2\n 15-18 1\n 18-21 30\n @endcode"] +#[doc = " @brief Description of a single entry in the line number information of a code region.\n @details A table of line number entries gives information about how the reported code region\n is mapped to source file.\n Intel(R) VTune(TM) Profiler uses line number information to attribute\n the samples (virtual address) to a line number. \\n\n It is acceptable to report different code addresses for the same source line:\n @code\n Offset LineNumber\n 1 2\n 12 4\n 15 2\n 18 1\n 21 30\n\n VTune Profiler constructs the following table using the client data\n\n Code subrange Line number\n 0-1 2\n 1-12 4\n 12-15 2\n 15-18 1\n 18-21 30\n @endcode"] pub type LineNumberInfo = _LineNumberInfo; #[doc = "<\\brief Native to the process architecture that is calling it."] pub const _iJIT_CodeArchitecture_iJIT_CA_NATIVE: _iJIT_CodeArchitecture = 0; @@ -238,7 +238,7 @@ pub struct _iJIT_Method_Load_V2 { pub class_file_name: *mut ::std::os::raw::c_char, #[doc = "<\\brief Source file name. Can be NULL."] pub source_file_name: *mut ::std::os::raw::c_char, - #[doc = "<\\brief Module name. Can be NULL.\nThe module name can be useful for distinguishing among\ndifferent JIT engines. VTune Amplifier will display\nreported methods grouped by specific module."] + #[doc = "<\\brief Module name. Can be NULL.\nThe module name can be useful for distinguishing among\ndifferent JIT engines. VTune Profiler will display\nreported methods grouped by specific module."] pub module_name: *mut ::std::os::raw::c_char, } #[test] @@ -370,9 +370,9 @@ pub struct _iJIT_Method_Load_V3 { pub class_file_name: *mut ::std::os::raw::c_char, #[doc = "<\\brief Source file name. Can be NULL."] pub source_file_name: *mut ::std::os::raw::c_char, - #[doc = "<\\brief Module name. Can be NULL.\n The module name can be useful for distinguishing among\n different JIT engines. VTune Amplifier will display\n reported methods grouped by specific module."] + #[doc = "<\\brief Module name. Can be NULL.\n The module name can be useful for distinguishing among\n different JIT engines. VTune Profiler will display\n reported methods grouped by specific module."] pub module_name: *mut ::std::os::raw::c_char, - #[doc = "<\\brief Architecture of the method's code region.\n By default, it is the same as the process\n architecture that is calling it.\n For example, you can use it if your 32-bit JIT\n engine generates 64-bit code.\n\n If JIT engine reports both 32-bit and 64-bit types\n of methods then VTune Amplifier splits the methods\n with the same module name but with different\n architectures in two different modules. VTune Amplifier\n modifies the original name provided with a 64-bit method\n version by ending it with '(64)'"] + #[doc = "<\\brief Architecture of the method's code region.\n By default, it is the same as the process\n architecture that is calling it.\n For example, you can use it if your 32-bit JIT\n engine generates 64-bit code.\n\n If JIT engine reports both 32-bit and 64-bit types\n of methods then VTune Profiler splits the methods\n with the same module name but with different\n architectures in two different modules. VTune Profiler\n modifies the original name provided with a 64-bit method\n version by ending it with '(64)'"] pub module_arch: iJIT_CodeArchitecture, } #[test] @@ -629,7 +629,7 @@ pub type iJIT_Method_Inline_Load = _iJIT_Method_Inline_Load; pub const _iJIT_SegmentType_iJIT_CT_UNKNOWN: _iJIT_SegmentType = 0; #[doc = "<\\brief Executable code."] pub const _iJIT_SegmentType_iJIT_CT_CODE: _iJIT_SegmentType = 1; -#[doc = "<\\brief Data (not executable code).\n VTune Amplifier uses the format string\n (see iJIT_Method_Update) to represent\n this data in the VTune Amplifier GUI"] +#[doc = "<\\brief Data (not executable code).\n VTune Profiler uses the format string\n (see iJIT_Method_Update) to represent\n this data in the VTune Profiler GUI"] pub const _iJIT_SegmentType_iJIT_CT_DATA: _iJIT_SegmentType = 2; #[doc = "<\\brief Use the previous markup for the trace.\n Can be used for the following\n iJVM_EVENT_TYPE_METHOD_UPDATE_V2 events,\n if the type of the previously reported segment\n type is the same."] pub const _iJIT_SegmentType_iJIT_CT_KEEP: _iJIT_SegmentType = 3; @@ -638,7 +638,7 @@ pub const _iJIT_SegmentType_iJIT_CT_EOF: _iJIT_SegmentType = 4; pub type _iJIT_SegmentType = ::std::os::raw::c_uint; #[doc = " @cond exclude_from_documentation */\n/**\n @brief Description of a segment type\n @details Use the segment type to specify a type of data supplied\n with the iJVM_EVENT_TYPE_METHOD_UPDATE_V2 event to be applied to\n a certain code trace."] pub use self::_iJIT_SegmentType as iJIT_SegmentType; -#[doc = " @brief Description of a dynamic update of the content within JIT-compiled method\n @details The JIT engine may generate the methods that are updated at runtime\n partially by mixed (data + executable code) content. When you use the iJIT_Method_Update\n structure to describe the update of the content within a JIT-compiled method,\n use iJVM_EVENT_TYPE_METHOD_UPDATE_V2 as an event type to report it.\n\n On the first Update event, VTune Amplifier copies the original code range reported by\n the iJVM_EVENT_TYPE_METHOD_LOAD event, then modifies it with the supplied bytes and\n adds the modified range to the original method. For next update events, VTune Amplifier\n does the same but it uses the latest modified version of a code region for update.\n Eventually, VTune Amplifier GUI displays multiple code ranges for the method reported by\n the iJVM_EVENT_TYPE_METHOD_LOAD event.\n Notes:\n - Multiple update events with different types for the same trace are allowed\n but they must be reported for the same code ranges.\n Example,\n @code\n [-- data---] Allowed\n [-- code --] Allowed\n [code] Ignored\n [-- data---] Allowed\n [-- code --] Allowed\n [------------ trace ---------]\n @endcode\n - The types of previously reported events can be changed but they must be reported\n for the same code ranges.\n Example,\n @code\n [-- data---] Allowed\n [-- code --] Allowed\n [-- data---] Allowed\n [-- code --] Allowed\n [------------ trace ---------]\n @endcode"] +#[doc = " @brief Description of a dynamic update of the content within JIT-compiled method\n @details The JIT engine may generate the methods that are updated at runtime\n partially by mixed (data + executable code) content. When you use the iJIT_Method_Update\n structure to describe the update of the content within a JIT-compiled method,\n use iJVM_EVENT_TYPE_METHOD_UPDATE_V2 as an event type to report it.\n\n On the first Update event, VTune Profiler copies the original code range reported by\n the iJVM_EVENT_TYPE_METHOD_LOAD event, then modifies it with the supplied bytes and\n adds the modified range to the original method. For next update events, VTune Profiler\n does the same but it uses the latest modified version of a code region for update.\n Eventually, VTune Profiler GUI displays multiple code ranges for the method reported by\n the iJVM_EVENT_TYPE_METHOD_LOAD event.\n Notes:\n - Multiple update events with different types for the same trace are allowed\n but they must be reported for the same code ranges.\n Example,\n @code\n [-- data---] Allowed\n [-- code --] Allowed\n [code] Ignored\n [-- data---] Allowed\n [-- code --] Allowed\n [------------ trace ---------]\n @endcode\n - The types of previously reported events can be changed but they must be reported\n for the same code ranges.\n Example,\n @code\n [-- data---] Allowed\n [-- code --] Allowed\n [-- data---] Allowed\n [-- code --] Allowed\n [------------ trace ---------]\n @endcode"] #[repr(C)] #[derive(Debug, Copy, Clone)] pub struct _iJIT_Method_Update { @@ -706,9 +706,9 @@ fn bindgen_test_layout__iJIT_Method_Update() { ) ); } -#[doc = " @brief Description of a dynamic update of the content within JIT-compiled method\n @details The JIT engine may generate the methods that are updated at runtime\n partially by mixed (data + executable code) content. When you use the iJIT_Method_Update\n structure to describe the update of the content within a JIT-compiled method,\n use iJVM_EVENT_TYPE_METHOD_UPDATE_V2 as an event type to report it.\n\n On the first Update event, VTune Amplifier copies the original code range reported by\n the iJVM_EVENT_TYPE_METHOD_LOAD event, then modifies it with the supplied bytes and\n adds the modified range to the original method. For next update events, VTune Amplifier\n does the same but it uses the latest modified version of a code region for update.\n Eventually, VTune Amplifier GUI displays multiple code ranges for the method reported by\n the iJVM_EVENT_TYPE_METHOD_LOAD event.\n Notes:\n - Multiple update events with different types for the same trace are allowed\n but they must be reported for the same code ranges.\n Example,\n @code\n [-- data---] Allowed\n [-- code --] Allowed\n [code] Ignored\n [-- data---] Allowed\n [-- code --] Allowed\n [------------ trace ---------]\n @endcode\n - The types of previously reported events can be changed but they must be reported\n for the same code ranges.\n Example,\n @code\n [-- data---] Allowed\n [-- code --] Allowed\n [-- data---] Allowed\n [-- code --] Allowed\n [------------ trace ---------]\n @endcode"] +#[doc = " @brief Description of a dynamic update of the content within JIT-compiled method\n @details The JIT engine may generate the methods that are updated at runtime\n partially by mixed (data + executable code) content. When you use the iJIT_Method_Update\n structure to describe the update of the content within a JIT-compiled method,\n use iJVM_EVENT_TYPE_METHOD_UPDATE_V2 as an event type to report it.\n\n On the first Update event, VTune Profiler copies the original code range reported by\n the iJVM_EVENT_TYPE_METHOD_LOAD event, then modifies it with the supplied bytes and\n adds the modified range to the original method. For next update events, VTune Profiler\n does the same but it uses the latest modified version of a code region for update.\n Eventually, VTune Profiler GUI displays multiple code ranges for the method reported by\n the iJVM_EVENT_TYPE_METHOD_LOAD event.\n Notes:\n - Multiple update events with different types for the same trace are allowed\n but they must be reported for the same code ranges.\n Example,\n @code\n [-- data---] Allowed\n [-- code --] Allowed\n [code] Ignored\n [-- data---] Allowed\n [-- code --] Allowed\n [------------ trace ---------]\n @endcode\n - The types of previously reported events can be changed but they must be reported\n for the same code ranges.\n Example,\n @code\n [-- data---] Allowed\n [-- code --] Allowed\n [-- data---] Allowed\n [-- code --] Allowed\n [------------ trace ---------]\n @endcode"] pub type piJIT_Method_Update = *mut _iJIT_Method_Update; -#[doc = " @brief Description of a dynamic update of the content within JIT-compiled method\n @details The JIT engine may generate the methods that are updated at runtime\n partially by mixed (data + executable code) content. When you use the iJIT_Method_Update\n structure to describe the update of the content within a JIT-compiled method,\n use iJVM_EVENT_TYPE_METHOD_UPDATE_V2 as an event type to report it.\n\n On the first Update event, VTune Amplifier copies the original code range reported by\n the iJVM_EVENT_TYPE_METHOD_LOAD event, then modifies it with the supplied bytes and\n adds the modified range to the original method. For next update events, VTune Amplifier\n does the same but it uses the latest modified version of a code region for update.\n Eventually, VTune Amplifier GUI displays multiple code ranges for the method reported by\n the iJVM_EVENT_TYPE_METHOD_LOAD event.\n Notes:\n - Multiple update events with different types for the same trace are allowed\n but they must be reported for the same code ranges.\n Example,\n @code\n [-- data---] Allowed\n [-- code --] Allowed\n [code] Ignored\n [-- data---] Allowed\n [-- code --] Allowed\n [------------ trace ---------]\n @endcode\n - The types of previously reported events can be changed but they must be reported\n for the same code ranges.\n Example,\n @code\n [-- data---] Allowed\n [-- code --] Allowed\n [-- data---] Allowed\n [-- code --] Allowed\n [------------ trace ---------]\n @endcode"] +#[doc = " @brief Description of a dynamic update of the content within JIT-compiled method\n @details The JIT engine may generate the methods that are updated at runtime\n partially by mixed (data + executable code) content. When you use the iJIT_Method_Update\n structure to describe the update of the content within a JIT-compiled method,\n use iJVM_EVENT_TYPE_METHOD_UPDATE_V2 as an event type to report it.\n\n On the first Update event, VTune Profiler copies the original code range reported by\n the iJVM_EVENT_TYPE_METHOD_LOAD event, then modifies it with the supplied bytes and\n adds the modified range to the original method. For next update events, VTune Profiler\n does the same but it uses the latest modified version of a code region for update.\n Eventually, VTune Profiler GUI displays multiple code ranges for the method reported by\n the iJVM_EVENT_TYPE_METHOD_LOAD event.\n Notes:\n - Multiple update events with different types for the same trace are allowed\n but they must be reported for the same code ranges.\n Example,\n @code\n [-- data---] Allowed\n [-- code --] Allowed\n [code] Ignored\n [-- data---] Allowed\n [-- code --] Allowed\n [------------ trace ---------]\n @endcode\n - The types of previously reported events can be changed but they must be reported\n for the same code ranges.\n Example,\n @code\n [-- data---] Allowed\n [-- code --] Allowed\n [-- data---] Allowed\n [-- code --] Allowed\n [------------ trace ---------]\n @endcode"] pub type iJIT_Method_Update = _iJIT_Method_Update; extern "C" { #[doc = " @brief Generates a new unique method ID.\n\n You must use this API to obtain unique and valid method IDs for methods or\n traces reported to the agent if you don't have your own mechanism to generate\n unique method IDs.\n\n @return a new unique method ID. When out of unique method IDs, this API\n returns 0, which is not an accepted value."] @@ -719,7 +719,7 @@ extern "C" { pub fn iJIT_IsProfilingActive() -> iJIT_IsProfilingActiveFlags; } extern "C" { - #[doc = " @brief Reports infomation about JIT-compiled code to the agent.\n\n The reported information is used to attribute samples obtained from any\n Intel(R) VTune(TM) Amplifier collector. This API needs to be called\n after JIT compilation and before the first entry into the JIT-compiled\n code.\n\n @param[in] event_type - type of the data sent to the agent\n @param[in] EventSpecificData - pointer to event-specific data\n\n @returns 1 on success, otherwise 0."] + #[doc = " @brief Reports infomation about JIT-compiled code to the agent.\n\n The reported information is used to attribute samples obtained from any\n Intel(R) VTune(TM) Profiler collector. This API needs to be called\n after JIT compilation and before the first entry into the JIT-compiled\n code.\n\n @param[in] event_type - type of the data sent to the agent\n @param[in] EventSpecificData - pointer to event-specific data\n\n @returns 1 on success, otherwise 0."] pub fn iJIT_NotifyEvent( event_type: iJIT_JVM_EVENT, EventSpecificData: *mut ::std::os::raw::c_void, diff --git a/rust/ittapi-sys/src/macos/jitprofiling_bindings.rs b/rust/ittapi-sys/src/macos/jitprofiling_bindings.rs index 428296c..29927bd 100644 --- a/rust/ittapi-sys/src/macos/jitprofiling_bindings.rs +++ b/rust/ittapi-sys/src/macos/jitprofiling_bindings.rs @@ -28,7 +28,7 @@ pub const _iJIT_IsProfilingActiveFlags_iJIT_SAMPLING_ON: _iJIT_IsProfilingActive pub type _iJIT_IsProfilingActiveFlags = ::std::os::raw::c_uint; #[doc = " @brief Enumerator for the agent's mode"] pub use self::_iJIT_IsProfilingActiveFlags as iJIT_IsProfilingActiveFlags; -#[doc = " @brief Description of a single entry in the line number information of a code region.\n @details A table of line number entries gives information about how the reported code region\n is mapped to source file.\n Intel(R) VTune(TM) Amplifier uses line number information to attribute\n the samples (virtual address) to a line number. \\n\n It is acceptable to report different code addresses for the same source line:\n @code\n Offset LineNumber\n 1 2\n 12 4\n 15 2\n 18 1\n 21 30\n\n VTune Amplifier constructs the following table using the client data\n\n Code subrange Line number\n 0-1 2\n 1-12 4\n 12-15 2\n 15-18 1\n 18-21 30\n @endcode"] +#[doc = " @brief Description of a single entry in the line number information of a code region.\n @details A table of line number entries gives information about how the reported code region\n is mapped to source file.\n Intel(R) VTune(TM) Profiler uses line number information to attribute\n the samples (virtual address) to a line number. \\n\n It is acceptable to report different code addresses for the same source line:\n @code\n Offset LineNumber\n 1 2\n 12 4\n 15 2\n 18 1\n 21 30\n\n VTune Profiler constructs the following table using the client data\n\n Code subrange Line number\n 0-1 2\n 1-12 4\n 12-15 2\n 15-18 1\n 18-21 30\n @endcode"] #[repr(C)] #[derive(Debug, Copy, Clone)] pub struct _LineNumberInfo { @@ -72,9 +72,9 @@ fn bindgen_test_layout__LineNumberInfo() { ) ); } -#[doc = " @brief Description of a single entry in the line number information of a code region.\n @details A table of line number entries gives information about how the reported code region\n is mapped to source file.\n Intel(R) VTune(TM) Amplifier uses line number information to attribute\n the samples (virtual address) to a line number. \\n\n It is acceptable to report different code addresses for the same source line:\n @code\n Offset LineNumber\n 1 2\n 12 4\n 15 2\n 18 1\n 21 30\n\n VTune Amplifier constructs the following table using the client data\n\n Code subrange Line number\n 0-1 2\n 1-12 4\n 12-15 2\n 15-18 1\n 18-21 30\n @endcode"] +#[doc = " @brief Description of a single entry in the line number information of a code region.\n @details A table of line number entries gives information about how the reported code region\n is mapped to source file.\n Intel(R) VTune(TM) Profiler uses line number information to attribute\n the samples (virtual address) to a line number. \\n\n It is acceptable to report different code addresses for the same source line:\n @code\n Offset LineNumber\n 1 2\n 12 4\n 15 2\n 18 1\n 21 30\n\n VTune Profiler constructs the following table using the client data\n\n Code subrange Line number\n 0-1 2\n 1-12 4\n 12-15 2\n 15-18 1\n 18-21 30\n @endcode"] pub type pLineNumberInfo = *mut _LineNumberInfo; -#[doc = " @brief Description of a single entry in the line number information of a code region.\n @details A table of line number entries gives information about how the reported code region\n is mapped to source file.\n Intel(R) VTune(TM) Amplifier uses line number information to attribute\n the samples (virtual address) to a line number. \\n\n It is acceptable to report different code addresses for the same source line:\n @code\n Offset LineNumber\n 1 2\n 12 4\n 15 2\n 18 1\n 21 30\n\n VTune Amplifier constructs the following table using the client data\n\n Code subrange Line number\n 0-1 2\n 1-12 4\n 12-15 2\n 15-18 1\n 18-21 30\n @endcode"] +#[doc = " @brief Description of a single entry in the line number information of a code region.\n @details A table of line number entries gives information about how the reported code region\n is mapped to source file.\n Intel(R) VTune(TM) Profiler uses line number information to attribute\n the samples (virtual address) to a line number. \\n\n It is acceptable to report different code addresses for the same source line:\n @code\n Offset LineNumber\n 1 2\n 12 4\n 15 2\n 18 1\n 21 30\n\n VTune Profiler constructs the following table using the client data\n\n Code subrange Line number\n 0-1 2\n 1-12 4\n 12-15 2\n 15-18 1\n 18-21 30\n @endcode"] pub type LineNumberInfo = _LineNumberInfo; #[doc = "<\\brief Native to the process architecture that is calling it."] pub const _iJIT_CodeArchitecture_iJIT_CA_NATIVE: _iJIT_CodeArchitecture = 0; @@ -238,7 +238,7 @@ pub struct _iJIT_Method_Load_V2 { pub class_file_name: *mut ::std::os::raw::c_char, #[doc = "<\\brief Source file name. Can be NULL."] pub source_file_name: *mut ::std::os::raw::c_char, - #[doc = "<\\brief Module name. Can be NULL.\nThe module name can be useful for distinguishing among\ndifferent JIT engines. VTune Amplifier will display\nreported methods grouped by specific module."] + #[doc = "<\\brief Module name. Can be NULL.\nThe module name can be useful for distinguishing among\ndifferent JIT engines. VTune Profiler will display\nreported methods grouped by specific module."] pub module_name: *mut ::std::os::raw::c_char, } #[test] @@ -370,9 +370,9 @@ pub struct _iJIT_Method_Load_V3 { pub class_file_name: *mut ::std::os::raw::c_char, #[doc = "<\\brief Source file name. Can be NULL."] pub source_file_name: *mut ::std::os::raw::c_char, - #[doc = "<\\brief Module name. Can be NULL.\n The module name can be useful for distinguishing among\n different JIT engines. VTune Amplifier will display\n reported methods grouped by specific module."] + #[doc = "<\\brief Module name. Can be NULL.\n The module name can be useful for distinguishing among\n different JIT engines. VTune Profiler will display\n reported methods grouped by specific module."] pub module_name: *mut ::std::os::raw::c_char, - #[doc = "<\\brief Architecture of the method's code region.\n By default, it is the same as the process\n architecture that is calling it.\n For example, you can use it if your 32-bit JIT\n engine generates 64-bit code.\n\n If JIT engine reports both 32-bit and 64-bit types\n of methods then VTune Amplifier splits the methods\n with the same module name but with different\n architectures in two different modules. VTune Amplifier\n modifies the original name provided with a 64-bit method\n version by ending it with '(64)'"] + #[doc = "<\\brief Architecture of the method's code region.\n By default, it is the same as the process\n architecture that is calling it.\n For example, you can use it if your 32-bit JIT\n engine generates 64-bit code.\n\n If JIT engine reports both 32-bit and 64-bit types\n of methods then VTune Profiler splits the methods\n with the same module name but with different\n architectures in two different modules. VTune Profiler\n modifies the original name provided with a 64-bit method\n version by ending it with '(64)'"] pub module_arch: iJIT_CodeArchitecture, } #[test] @@ -629,7 +629,7 @@ pub type iJIT_Method_Inline_Load = _iJIT_Method_Inline_Load; pub const _iJIT_SegmentType_iJIT_CT_UNKNOWN: _iJIT_SegmentType = 0; #[doc = "<\\brief Executable code."] pub const _iJIT_SegmentType_iJIT_CT_CODE: _iJIT_SegmentType = 1; -#[doc = "<\\brief Data (not executable code).\n VTune Amplifier uses the format string\n (see iJIT_Method_Update) to represent\n this data in the VTune Amplifier GUI"] +#[doc = "<\\brief Data (not executable code).\n VTune Profiler uses the format string\n (see iJIT_Method_Update) to represent\n this data in the VTune Profiler GUI"] pub const _iJIT_SegmentType_iJIT_CT_DATA: _iJIT_SegmentType = 2; #[doc = "<\\brief Use the previous markup for the trace.\n Can be used for the following\n iJVM_EVENT_TYPE_METHOD_UPDATE_V2 events,\n if the type of the previously reported segment\n type is the same."] pub const _iJIT_SegmentType_iJIT_CT_KEEP: _iJIT_SegmentType = 3; @@ -638,7 +638,7 @@ pub const _iJIT_SegmentType_iJIT_CT_EOF: _iJIT_SegmentType = 4; pub type _iJIT_SegmentType = ::std::os::raw::c_uint; #[doc = " @cond exclude_from_documentation */\n/**\n @brief Description of a segment type\n @details Use the segment type to specify a type of data supplied\n with the iJVM_EVENT_TYPE_METHOD_UPDATE_V2 event to be applied to\n a certain code trace."] pub use self::_iJIT_SegmentType as iJIT_SegmentType; -#[doc = " @brief Description of a dynamic update of the content within JIT-compiled method\n @details The JIT engine may generate the methods that are updated at runtime\n partially by mixed (data + executable code) content. When you use the iJIT_Method_Update\n structure to describe the update of the content within a JIT-compiled method,\n use iJVM_EVENT_TYPE_METHOD_UPDATE_V2 as an event type to report it.\n\n On the first Update event, VTune Amplifier copies the original code range reported by\n the iJVM_EVENT_TYPE_METHOD_LOAD event, then modifies it with the supplied bytes and\n adds the modified range to the original method. For next update events, VTune Amplifier\n does the same but it uses the latest modified version of a code region for update.\n Eventually, VTune Amplifier GUI displays multiple code ranges for the method reported by\n the iJVM_EVENT_TYPE_METHOD_LOAD event.\n Notes:\n - Multiple update events with different types for the same trace are allowed\n but they must be reported for the same code ranges.\n Example,\n @code\n [-- data---] Allowed\n [-- code --] Allowed\n [code] Ignored\n [-- data---] Allowed\n [-- code --] Allowed\n [------------ trace ---------]\n @endcode\n - The types of previously reported events can be changed but they must be reported\n for the same code ranges.\n Example,\n @code\n [-- data---] Allowed\n [-- code --] Allowed\n [-- data---] Allowed\n [-- code --] Allowed\n [------------ trace ---------]\n @endcode"] +#[doc = " @brief Description of a dynamic update of the content within JIT-compiled method\n @details The JIT engine may generate the methods that are updated at runtime\n partially by mixed (data + executable code) content. When you use the iJIT_Method_Update\n structure to describe the update of the content within a JIT-compiled method,\n use iJVM_EVENT_TYPE_METHOD_UPDATE_V2 as an event type to report it.\n\n On the first Update event, VTune Profiler copies the original code range reported by\n the iJVM_EVENT_TYPE_METHOD_LOAD event, then modifies it with the supplied bytes and\n adds the modified range to the original method. For next update events, VTune Profiler\n does the same but it uses the latest modified version of a code region for update.\n Eventually, VTune Profiler GUI displays multiple code ranges for the method reported by\n the iJVM_EVENT_TYPE_METHOD_LOAD event.\n Notes:\n - Multiple update events with different types for the same trace are allowed\n but they must be reported for the same code ranges.\n Example,\n @code\n [-- data---] Allowed\n [-- code --] Allowed\n [code] Ignored\n [-- data---] Allowed\n [-- code --] Allowed\n [------------ trace ---------]\n @endcode\n - The types of previously reported events can be changed but they must be reported\n for the same code ranges.\n Example,\n @code\n [-- data---] Allowed\n [-- code --] Allowed\n [-- data---] Allowed\n [-- code --] Allowed\n [------------ trace ---------]\n @endcode"] #[repr(C)] #[derive(Debug, Copy, Clone)] pub struct _iJIT_Method_Update { @@ -706,9 +706,9 @@ fn bindgen_test_layout__iJIT_Method_Update() { ) ); } -#[doc = " @brief Description of a dynamic update of the content within JIT-compiled method\n @details The JIT engine may generate the methods that are updated at runtime\n partially by mixed (data + executable code) content. When you use the iJIT_Method_Update\n structure to describe the update of the content within a JIT-compiled method,\n use iJVM_EVENT_TYPE_METHOD_UPDATE_V2 as an event type to report it.\n\n On the first Update event, VTune Amplifier copies the original code range reported by\n the iJVM_EVENT_TYPE_METHOD_LOAD event, then modifies it with the supplied bytes and\n adds the modified range to the original method. For next update events, VTune Amplifier\n does the same but it uses the latest modified version of a code region for update.\n Eventually, VTune Amplifier GUI displays multiple code ranges for the method reported by\n the iJVM_EVENT_TYPE_METHOD_LOAD event.\n Notes:\n - Multiple update events with different types for the same trace are allowed\n but they must be reported for the same code ranges.\n Example,\n @code\n [-- data---] Allowed\n [-- code --] Allowed\n [code] Ignored\n [-- data---] Allowed\n [-- code --] Allowed\n [------------ trace ---------]\n @endcode\n - The types of previously reported events can be changed but they must be reported\n for the same code ranges.\n Example,\n @code\n [-- data---] Allowed\n [-- code --] Allowed\n [-- data---] Allowed\n [-- code --] Allowed\n [------------ trace ---------]\n @endcode"] +#[doc = " @brief Description of a dynamic update of the content within JIT-compiled method\n @details The JIT engine may generate the methods that are updated at runtime\n partially by mixed (data + executable code) content. When you use the iJIT_Method_Update\n structure to describe the update of the content within a JIT-compiled method,\n use iJVM_EVENT_TYPE_METHOD_UPDATE_V2 as an event type to report it.\n\n On the first Update event, VTune Profiler copies the original code range reported by\n the iJVM_EVENT_TYPE_METHOD_LOAD event, then modifies it with the supplied bytes and\n adds the modified range to the original method. For next update events, VTune Profiler\n does the same but it uses the latest modified version of a code region for update.\n Eventually, VTune Profiler GUI displays multiple code ranges for the method reported by\n the iJVM_EVENT_TYPE_METHOD_LOAD event.\n Notes:\n - Multiple update events with different types for the same trace are allowed\n but they must be reported for the same code ranges.\n Example,\n @code\n [-- data---] Allowed\n [-- code --] Allowed\n [code] Ignored\n [-- data---] Allowed\n [-- code --] Allowed\n [------------ trace ---------]\n @endcode\n - The types of previously reported events can be changed but they must be reported\n for the same code ranges.\n Example,\n @code\n [-- data---] Allowed\n [-- code --] Allowed\n [-- data---] Allowed\n [-- code --] Allowed\n [------------ trace ---------]\n @endcode"] pub type piJIT_Method_Update = *mut _iJIT_Method_Update; -#[doc = " @brief Description of a dynamic update of the content within JIT-compiled method\n @details The JIT engine may generate the methods that are updated at runtime\n partially by mixed (data + executable code) content. When you use the iJIT_Method_Update\n structure to describe the update of the content within a JIT-compiled method,\n use iJVM_EVENT_TYPE_METHOD_UPDATE_V2 as an event type to report it.\n\n On the first Update event, VTune Amplifier copies the original code range reported by\n the iJVM_EVENT_TYPE_METHOD_LOAD event, then modifies it with the supplied bytes and\n adds the modified range to the original method. For next update events, VTune Amplifier\n does the same but it uses the latest modified version of a code region for update.\n Eventually, VTune Amplifier GUI displays multiple code ranges for the method reported by\n the iJVM_EVENT_TYPE_METHOD_LOAD event.\n Notes:\n - Multiple update events with different types for the same trace are allowed\n but they must be reported for the same code ranges.\n Example,\n @code\n [-- data---] Allowed\n [-- code --] Allowed\n [code] Ignored\n [-- data---] Allowed\n [-- code --] Allowed\n [------------ trace ---------]\n @endcode\n - The types of previously reported events can be changed but they must be reported\n for the same code ranges.\n Example,\n @code\n [-- data---] Allowed\n [-- code --] Allowed\n [-- data---] Allowed\n [-- code --] Allowed\n [------------ trace ---------]\n @endcode"] +#[doc = " @brief Description of a dynamic update of the content within JIT-compiled method\n @details The JIT engine may generate the methods that are updated at runtime\n partially by mixed (data + executable code) content. When you use the iJIT_Method_Update\n structure to describe the update of the content within a JIT-compiled method,\n use iJVM_EVENT_TYPE_METHOD_UPDATE_V2 as an event type to report it.\n\n On the first Update event, VTune Profiler copies the original code range reported by\n the iJVM_EVENT_TYPE_METHOD_LOAD event, then modifies it with the supplied bytes and\n adds the modified range to the original method. For next update events, VTune Profiler\n does the same but it uses the latest modified version of a code region for update.\n Eventually, VTune Profiler GUI displays multiple code ranges for the method reported by\n the iJVM_EVENT_TYPE_METHOD_LOAD event.\n Notes:\n - Multiple update events with different types for the same trace are allowed\n but they must be reported for the same code ranges.\n Example,\n @code\n [-- data---] Allowed\n [-- code --] Allowed\n [code] Ignored\n [-- data---] Allowed\n [-- code --] Allowed\n [------------ trace ---------]\n @endcode\n - The types of previously reported events can be changed but they must be reported\n for the same code ranges.\n Example,\n @code\n [-- data---] Allowed\n [-- code --] Allowed\n [-- data---] Allowed\n [-- code --] Allowed\n [------------ trace ---------]\n @endcode"] pub type iJIT_Method_Update = _iJIT_Method_Update; extern "C" { #[doc = " @brief Generates a new unique method ID.\n\n You must use this API to obtain unique and valid method IDs for methods or\n traces reported to the agent if you don't have your own mechanism to generate\n unique method IDs.\n\n @return a new unique method ID. When out of unique method IDs, this API\n returns 0, which is not an accepted value."] @@ -719,7 +719,7 @@ extern "C" { pub fn iJIT_IsProfilingActive() -> iJIT_IsProfilingActiveFlags; } extern "C" { - #[doc = " @brief Reports infomation about JIT-compiled code to the agent.\n\n The reported information is used to attribute samples obtained from any\n Intel(R) VTune(TM) Amplifier collector. This API needs to be called\n after JIT compilation and before the first entry into the JIT-compiled\n code.\n\n @param[in] event_type - type of the data sent to the agent\n @param[in] EventSpecificData - pointer to event-specific data\n\n @returns 1 on success, otherwise 0."] + #[doc = " @brief Reports infomation about JIT-compiled code to the agent.\n\n The reported information is used to attribute samples obtained from any\n Intel(R) VTune(TM) Profiler collector. This API needs to be called\n after JIT compilation and before the first entry into the JIT-compiled\n code.\n\n @param[in] event_type - type of the data sent to the agent\n @param[in] EventSpecificData - pointer to event-specific data\n\n @returns 1 on success, otherwise 0."] pub fn iJIT_NotifyEvent( event_type: iJIT_JVM_EVENT, EventSpecificData: *mut ::std::os::raw::c_void, diff --git a/rust/ittapi-sys/src/windows/jitprofiling_bindings.rs b/rust/ittapi-sys/src/windows/jitprofiling_bindings.rs index 9243de7..17ce844 100644 --- a/rust/ittapi-sys/src/windows/jitprofiling_bindings.rs +++ b/rust/ittapi-sys/src/windows/jitprofiling_bindings.rs @@ -28,7 +28,7 @@ pub const _iJIT_IsProfilingActiveFlags_iJIT_SAMPLING_ON: _iJIT_IsProfilingActive pub type _iJIT_IsProfilingActiveFlags = ::std::os::raw::c_int; #[doc = " @brief Enumerator for the agent's mode"] pub use self::_iJIT_IsProfilingActiveFlags as iJIT_IsProfilingActiveFlags; -#[doc = " @brief Description of a single entry in the line number information of a code region.\n @details A table of line number entries gives information about how the reported code region\n is mapped to source file.\n Intel(R) VTune(TM) Amplifier uses line number information to attribute\n the samples (virtual address) to a line number. \\n\n It is acceptable to report different code addresses for the same source line:\n @code\n Offset LineNumber\n 1 2\n 12 4\n 15 2\n 18 1\n 21 30\n\n VTune Amplifier constructs the following table using the client data\n\n Code subrange Line number\n 0-1 2\n 1-12 4\n 12-15 2\n 15-18 1\n 18-21 30\n @endcode"] +#[doc = " @brief Description of a single entry in the line number information of a code region.\n @details A table of line number entries gives information about how the reported code region\n is mapped to source file.\n Intel(R) VTune(TM) Profiler uses line number information to attribute\n the samples (virtual address) to a line number. \\n\n It is acceptable to report different code addresses for the same source line:\n @code\n Offset LineNumber\n 1 2\n 12 4\n 15 2\n 18 1\n 21 30\n\n VTune Profiler constructs the following table using the client data\n\n Code subrange Line number\n 0-1 2\n 1-12 4\n 12-15 2\n 15-18 1\n 18-21 30\n @endcode"] #[repr(C)] #[derive(Debug, Copy, Clone)] pub struct _LineNumberInfo { @@ -72,9 +72,9 @@ fn bindgen_test_layout__LineNumberInfo() { ) ); } -#[doc = " @brief Description of a single entry in the line number information of a code region.\n @details A table of line number entries gives information about how the reported code region\n is mapped to source file.\n Intel(R) VTune(TM) Amplifier uses line number information to attribute\n the samples (virtual address) to a line number. \\n\n It is acceptable to report different code addresses for the same source line:\n @code\n Offset LineNumber\n 1 2\n 12 4\n 15 2\n 18 1\n 21 30\n\n VTune Amplifier constructs the following table using the client data\n\n Code subrange Line number\n 0-1 2\n 1-12 4\n 12-15 2\n 15-18 1\n 18-21 30\n @endcode"] +#[doc = " @brief Description of a single entry in the line number information of a code region.\n @details A table of line number entries gives information about how the reported code region\n is mapped to source file.\n Intel(R) VTune(TM) Profiler uses line number information to attribute\n the samples (virtual address) to a line number. \\n\n It is acceptable to report different code addresses for the same source line:\n @code\n Offset LineNumber\n 1 2\n 12 4\n 15 2\n 18 1\n 21 30\n\n VTune Profiler constructs the following table using the client data\n\n Code subrange Line number\n 0-1 2\n 1-12 4\n 12-15 2\n 15-18 1\n 18-21 30\n @endcode"] pub type pLineNumberInfo = *mut _LineNumberInfo; -#[doc = " @brief Description of a single entry in the line number information of a code region.\n @details A table of line number entries gives information about how the reported code region\n is mapped to source file.\n Intel(R) VTune(TM) Amplifier uses line number information to attribute\n the samples (virtual address) to a line number. \\n\n It is acceptable to report different code addresses for the same source line:\n @code\n Offset LineNumber\n 1 2\n 12 4\n 15 2\n 18 1\n 21 30\n\n VTune Amplifier constructs the following table using the client data\n\n Code subrange Line number\n 0-1 2\n 1-12 4\n 12-15 2\n 15-18 1\n 18-21 30\n @endcode"] +#[doc = " @brief Description of a single entry in the line number information of a code region.\n @details A table of line number entries gives information about how the reported code region\n is mapped to source file.\n Intel(R) VTune(TM) Profiler uses line number information to attribute\n the samples (virtual address) to a line number. \\n\n It is acceptable to report different code addresses for the same source line:\n @code\n Offset LineNumber\n 1 2\n 12 4\n 15 2\n 18 1\n 21 30\n\n VTune Profiler constructs the following table using the client data\n\n Code subrange Line number\n 0-1 2\n 1-12 4\n 12-15 2\n 15-18 1\n 18-21 30\n @endcode"] pub type LineNumberInfo = _LineNumberInfo; #[doc = "<\\brief Native to the process architecture that is calling it."] pub const _iJIT_CodeArchitecture_iJIT_CA_NATIVE: _iJIT_CodeArchitecture = 0; @@ -238,7 +238,7 @@ pub struct _iJIT_Method_Load_V2 { pub class_file_name: *mut ::std::os::raw::c_char, #[doc = "<\\brief Source file name. Can be NULL."] pub source_file_name: *mut ::std::os::raw::c_char, - #[doc = "<\\brief Module name. Can be NULL.\nThe module name can be useful for distinguishing among\ndifferent JIT engines. VTune Amplifier will display\nreported methods grouped by specific module."] + #[doc = "<\\brief Module name. Can be NULL.\nThe module name can be useful for distinguishing among\ndifferent JIT engines. VTune Profiler will display\nreported methods grouped by specific module."] pub module_name: *mut ::std::os::raw::c_char, } #[test] @@ -370,9 +370,9 @@ pub struct _iJIT_Method_Load_V3 { pub class_file_name: *mut ::std::os::raw::c_char, #[doc = "<\\brief Source file name. Can be NULL."] pub source_file_name: *mut ::std::os::raw::c_char, - #[doc = "<\\brief Module name. Can be NULL.\n The module name can be useful for distinguishing among\n different JIT engines. VTune Amplifier will display\n reported methods grouped by specific module."] + #[doc = "<\\brief Module name. Can be NULL.\n The module name can be useful for distinguishing among\n different JIT engines. VTune Profiler will display\n reported methods grouped by specific module."] pub module_name: *mut ::std::os::raw::c_char, - #[doc = "<\\brief Architecture of the method's code region.\n By default, it is the same as the process\n architecture that is calling it.\n For example, you can use it if your 32-bit JIT\n engine generates 64-bit code.\n\n If JIT engine reports both 32-bit and 64-bit types\n of methods then VTune Amplifier splits the methods\n with the same module name but with different\n architectures in two different modules. VTune Amplifier\n modifies the original name provided with a 64-bit method\n version by ending it with '(64)'"] + #[doc = "<\\brief Architecture of the method's code region.\n By default, it is the same as the process\n architecture that is calling it.\n For example, you can use it if your 32-bit JIT\n engine generates 64-bit code.\n\n If JIT engine reports both 32-bit and 64-bit types\n of methods then VTune Profiler splits the methods\n with the same module name but with different\n architectures in two different modules. VTune Profiler\n modifies the original name provided with a 64-bit method\n version by ending it with '(64)'"] pub module_arch: iJIT_CodeArchitecture, } #[test] @@ -629,7 +629,7 @@ pub type iJIT_Method_Inline_Load = _iJIT_Method_Inline_Load; pub const _iJIT_SegmentType_iJIT_CT_UNKNOWN: _iJIT_SegmentType = 0; #[doc = "<\\brief Executable code."] pub const _iJIT_SegmentType_iJIT_CT_CODE: _iJIT_SegmentType = 1; -#[doc = "<\\brief Data (not executable code).\n VTune Amplifier uses the format string\n (see iJIT_Method_Update) to represent\n this data in the VTune Amplifier GUI"] +#[doc = "<\\brief Data (not executable code).\n VTune Profiler uses the format string\n (see iJIT_Method_Update) to represent\n this data in the VTune Profiler GUI"] pub const _iJIT_SegmentType_iJIT_CT_DATA: _iJIT_SegmentType = 2; #[doc = "<\\brief Use the previous markup for the trace.\n Can be used for the following\n iJVM_EVENT_TYPE_METHOD_UPDATE_V2 events,\n if the type of the previously reported segment\n type is the same."] pub const _iJIT_SegmentType_iJIT_CT_KEEP: _iJIT_SegmentType = 3; @@ -638,7 +638,7 @@ pub const _iJIT_SegmentType_iJIT_CT_EOF: _iJIT_SegmentType = 4; pub type _iJIT_SegmentType = ::std::os::raw::c_int; #[doc = " @cond exclude_from_documentation */\n/**\n @brief Description of a segment type\n @details Use the segment type to specify a type of data supplied\n with the iJVM_EVENT_TYPE_METHOD_UPDATE_V2 event to be applied to\n a certain code trace."] pub use self::_iJIT_SegmentType as iJIT_SegmentType; -#[doc = " @brief Description of a dynamic update of the content within JIT-compiled method\n @details The JIT engine may generate the methods that are updated at runtime\n partially by mixed (data + executable code) content. When you use the iJIT_Method_Update\n structure to describe the update of the content within a JIT-compiled method,\n use iJVM_EVENT_TYPE_METHOD_UPDATE_V2 as an event type to report it.\n\n On the first Update event, VTune Amplifier copies the original code range reported by\n the iJVM_EVENT_TYPE_METHOD_LOAD event, then modifies it with the supplied bytes and\n adds the modified range to the original method. For next update events, VTune Amplifier\n does the same but it uses the latest modified version of a code region for update.\n Eventually, VTune Amplifier GUI displays multiple code ranges for the method reported by\n the iJVM_EVENT_TYPE_METHOD_LOAD event.\n Notes:\n - Multiple update events with different types for the same trace are allowed\n but they must be reported for the same code ranges.\n Example,\n @code\n [-- data---] Allowed\n [-- code --] Allowed\n [code] Ignored\n [-- data---] Allowed\n [-- code --] Allowed\n [------------ trace ---------]\n @endcode\n - The types of previously reported events can be changed but they must be reported\n for the same code ranges.\n Example,\n @code\n [-- data---] Allowed\n [-- code --] Allowed\n [-- data---] Allowed\n [-- code --] Allowed\n [------------ trace ---------]\n @endcode"] +#[doc = " @brief Description of a dynamic update of the content within JIT-compiled method\n @details The JIT engine may generate the methods that are updated at runtime\n partially by mixed (data + executable code) content. When you use the iJIT_Method_Update\n structure to describe the update of the content within a JIT-compiled method,\n use iJVM_EVENT_TYPE_METHOD_UPDATE_V2 as an event type to report it.\n\n On the first Update event, VTune Profiler copies the original code range reported by\n the iJVM_EVENT_TYPE_METHOD_LOAD event, then modifies it with the supplied bytes and\n adds the modified range to the original method. For next update events, VTune Profiler\n does the same but it uses the latest modified version of a code region for update.\n Eventually, VTune Profiler GUI displays multiple code ranges for the method reported by\n the iJVM_EVENT_TYPE_METHOD_LOAD event.\n Notes:\n - Multiple update events with different types for the same trace are allowed\n but they must be reported for the same code ranges.\n Example,\n @code\n [-- data---] Allowed\n [-- code --] Allowed\n [code] Ignored\n [-- data---] Allowed\n [-- code --] Allowed\n [------------ trace ---------]\n @endcode\n - The types of previously reported events can be changed but they must be reported\n for the same code ranges.\n Example,\n @code\n [-- data---] Allowed\n [-- code --] Allowed\n [-- data---] Allowed\n [-- code --] Allowed\n [------------ trace ---------]\n @endcode"] #[repr(C)] #[derive(Debug, Copy, Clone)] pub struct _iJIT_Method_Update { @@ -706,9 +706,9 @@ fn bindgen_test_layout__iJIT_Method_Update() { ) ); } -#[doc = " @brief Description of a dynamic update of the content within JIT-compiled method\n @details The JIT engine may generate the methods that are updated at runtime\n partially by mixed (data + executable code) content. When you use the iJIT_Method_Update\n structure to describe the update of the content within a JIT-compiled method,\n use iJVM_EVENT_TYPE_METHOD_UPDATE_V2 as an event type to report it.\n\n On the first Update event, VTune Amplifier copies the original code range reported by\n the iJVM_EVENT_TYPE_METHOD_LOAD event, then modifies it with the supplied bytes and\n adds the modified range to the original method. For next update events, VTune Amplifier\n does the same but it uses the latest modified version of a code region for update.\n Eventually, VTune Amplifier GUI displays multiple code ranges for the method reported by\n the iJVM_EVENT_TYPE_METHOD_LOAD event.\n Notes:\n - Multiple update events with different types for the same trace are allowed\n but they must be reported for the same code ranges.\n Example,\n @code\n [-- data---] Allowed\n [-- code --] Allowed\n [code] Ignored\n [-- data---] Allowed\n [-- code --] Allowed\n [------------ trace ---------]\n @endcode\n - The types of previously reported events can be changed but they must be reported\n for the same code ranges.\n Example,\n @code\n [-- data---] Allowed\n [-- code --] Allowed\n [-- data---] Allowed\n [-- code --] Allowed\n [------------ trace ---------]\n @endcode"] +#[doc = " @brief Description of a dynamic update of the content within JIT-compiled method\n @details The JIT engine may generate the methods that are updated at runtime\n partially by mixed (data + executable code) content. When you use the iJIT_Method_Update\n structure to describe the update of the content within a JIT-compiled method,\n use iJVM_EVENT_TYPE_METHOD_UPDATE_V2 as an event type to report it.\n\n On the first Update event, VTune Profiler copies the original code range reported by\n the iJVM_EVENT_TYPE_METHOD_LOAD event, then modifies it with the supplied bytes and\n adds the modified range to the original method. For next update events, VTune Profiler\n does the same but it uses the latest modified version of a code region for update.\n Eventually, VTune Profiler GUI displays multiple code ranges for the method reported by\n the iJVM_EVENT_TYPE_METHOD_LOAD event.\n Notes:\n - Multiple update events with different types for the same trace are allowed\n but they must be reported for the same code ranges.\n Example,\n @code\n [-- data---] Allowed\n [-- code --] Allowed\n [code] Ignored\n [-- data---] Allowed\n [-- code --] Allowed\n [------------ trace ---------]\n @endcode\n - The types of previously reported events can be changed but they must be reported\n for the same code ranges.\n Example,\n @code\n [-- data---] Allowed\n [-- code --] Allowed\n [-- data---] Allowed\n [-- code --] Allowed\n [------------ trace ---------]\n @endcode"] pub type piJIT_Method_Update = *mut _iJIT_Method_Update; -#[doc = " @brief Description of a dynamic update of the content within JIT-compiled method\n @details The JIT engine may generate the methods that are updated at runtime\n partially by mixed (data + executable code) content. When you use the iJIT_Method_Update\n structure to describe the update of the content within a JIT-compiled method,\n use iJVM_EVENT_TYPE_METHOD_UPDATE_V2 as an event type to report it.\n\n On the first Update event, VTune Amplifier copies the original code range reported by\n the iJVM_EVENT_TYPE_METHOD_LOAD event, then modifies it with the supplied bytes and\n adds the modified range to the original method. For next update events, VTune Amplifier\n does the same but it uses the latest modified version of a code region for update.\n Eventually, VTune Amplifier GUI displays multiple code ranges for the method reported by\n the iJVM_EVENT_TYPE_METHOD_LOAD event.\n Notes:\n - Multiple update events with different types for the same trace are allowed\n but they must be reported for the same code ranges.\n Example,\n @code\n [-- data---] Allowed\n [-- code --] Allowed\n [code] Ignored\n [-- data---] Allowed\n [-- code --] Allowed\n [------------ trace ---------]\n @endcode\n - The types of previously reported events can be changed but they must be reported\n for the same code ranges.\n Example,\n @code\n [-- data---] Allowed\n [-- code --] Allowed\n [-- data---] Allowed\n [-- code --] Allowed\n [------------ trace ---------]\n @endcode"] +#[doc = " @brief Description of a dynamic update of the content within JIT-compiled method\n @details The JIT engine may generate the methods that are updated at runtime\n partially by mixed (data + executable code) content. When you use the iJIT_Method_Update\n structure to describe the update of the content within a JIT-compiled method,\n use iJVM_EVENT_TYPE_METHOD_UPDATE_V2 as an event type to report it.\n\n On the first Update event, VTune Profiler copies the original code range reported by\n the iJVM_EVENT_TYPE_METHOD_LOAD event, then modifies it with the supplied bytes and\n adds the modified range to the original method. For next update events, VTune Profiler\n does the same but it uses the latest modified version of a code region for update.\n Eventually, VTune Profiler GUI displays multiple code ranges for the method reported by\n the iJVM_EVENT_TYPE_METHOD_LOAD event.\n Notes:\n - Multiple update events with different types for the same trace are allowed\n but they must be reported for the same code ranges.\n Example,\n @code\n [-- data---] Allowed\n [-- code --] Allowed\n [code] Ignored\n [-- data---] Allowed\n [-- code --] Allowed\n [------------ trace ---------]\n @endcode\n - The types of previously reported events can be changed but they must be reported\n for the same code ranges.\n Example,\n @code\n [-- data---] Allowed\n [-- code --] Allowed\n [-- data---] Allowed\n [-- code --] Allowed\n [------------ trace ---------]\n @endcode"] pub type iJIT_Method_Update = _iJIT_Method_Update; extern "C" { #[doc = " @brief Generates a new unique method ID.\n\n You must use this API to obtain unique and valid method IDs for methods or\n traces reported to the agent if you don't have your own mechanism to generate\n unique method IDs.\n\n @return a new unique method ID. When out of unique method IDs, this API\n returns 0, which is not an accepted value."] @@ -719,7 +719,7 @@ extern "C" { pub fn iJIT_IsProfilingActive() -> iJIT_IsProfilingActiveFlags; } extern "C" { - #[doc = " @brief Reports infomation about JIT-compiled code to the agent.\n\n The reported information is used to attribute samples obtained from any\n Intel(R) VTune(TM) Amplifier collector. This API needs to be called\n after JIT compilation and before the first entry into the JIT-compiled\n code.\n\n @param[in] event_type - type of the data sent to the agent\n @param[in] EventSpecificData - pointer to event-specific data\n\n @returns 1 on success, otherwise 0."] + #[doc = " @brief Reports infomation about JIT-compiled code to the agent.\n\n The reported information is used to attribute samples obtained from any\n Intel(R) VTune(TM) Profiler collector. This API needs to be called\n after JIT compilation and before the first entry into the JIT-compiled\n code.\n\n @param[in] event_type - type of the data sent to the agent\n @param[in] EventSpecificData - pointer to event-specific data\n\n @returns 1 on success, otherwise 0."] pub fn iJIT_NotifyEvent( event_type: iJIT_JVM_EVENT, EventSpecificData: *mut ::std::os::raw::c_void,