Re: [PATCH v2] perf docs: Correct JIT_CODE_UNWINDING_INFO specification

[Namhyung Kim <namhyung@kernel.org>]

Hello,

Sorry for the late reply.

On Sat, Oct 31, 2026 at 02:12:22PM +0800, Letian Jiang wrote:
> The JIT_CODE_UNWINDING_INFO description places the EH Frame Header before
> the EH Frame. However, jit_add_eh_frame_info() uses the beginning of the
> unwinding data for .eh_frame and the trailing eh_frame_hdr_size bytes for
> .eh_frame_hdr.
> 
> Correct the unwinding_data description and the eh_frame_hdr_size field
> description to match the layout consumed by perf.
> 
> Also document that an unwinding record precedes and applies to the next
> JIT_CODE_LOAD record. perf caches the unwinding data and uses it when
> processing that load record.
> 
> Revise the mapped_size note to describe frame-pointer-based unwinding as
> a possibility depending on the backend and valid frame pointers in the
> generated code.
> 
> The libunwind-specific use case still matters: its EH Frame Header fields
> through fde_count are read directly from the ELF file, while lookup-table
> and EH Frame accesses require a mapping covering those addresses. An
> empty lookup table can trigger frame-pointer-based unwinding fallback
> without mapping the unwinding data. This does not impose the same access
> requirements on other unwinding backends.

Thanks for working on this.  It's been a while since I took a look at it
last time.  I don't remember why it has EH Frame Header at the end.
It'd be simplier if we have it before.

> 
> Signed-off-by: Letian Jiang <letian.jiang@outlook.com>
> ---
> Changes in v2:
> - Revise rather than remove the mapped_size note's frame-pointer use
>   case, making it conditional on backend support and valid frame pointers.
> - Explain the libunwind empty lookup table use case in the commit
>   description while keeping the specification backend-neutral.
> - Keep the record-ordering paragraph on one line to match the existing
>   specification style.
> 
> v1: https://lore.kernel.org/linux-perf-users/CYXPR84MB347620A9EC3D829B4279F138826D2@CYXPR84MB3476.NAMPRD84.PROD.OUTLOOK.COM/
> 
>  tools/perf/Documentation/jitdump-specification.txt | 8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/perf/Documentation/jitdump-specification.txt b/tools/perf/Documentation/jitdump-specification.txt
> index 7993635..ab43aa8 100644
> --- a/tools/perf/Documentation/jitdump-specification.txt
> +++ b/tools/perf/Documentation/jitdump-specification.txt
> @@ -153,12 +153,14 @@ The record type is optional.
>  
>  The record is used to describe the unwinding information for a jitted function.
>  
> +The record must precede the corresponding JIT_CODE_LOAD record. It applies to the next JIT_CODE_LOAD record in the file.
> +
>  The record has the following fields following the fixed-size record header in order:
>  
>  uint64_t unwind_data_size   : the size in bytes of the unwinding data table at the end of the record

Does this mean the size of EH Frames only or including the header?  I
think it's better to clarify it here.

Thanks,
Namhyung


> -uint64_t eh_frame_hdr_size  : the size in bytes of the DWARF EH Frame Header at the start of the unwinding data table at the end of the record
> +uint64_t eh_frame_hdr_size  : the size in bytes of the DWARF EH Frame Header at the end of the unwinding data table
>  uint64_t mapped_size        : the size of the unwinding data mapped in memory
> -const char unwinding_data[n]: an array of unwinding data, consisting of the EH Frame Header, followed by the actual EH Frame
> +const char unwinding_data[n]: an array of unwinding data, consisting of the EH Frame, followed by the EH Frame Header
>  
>  
>  The EH Frame header follows the Linux Standard Base (LSB) specification as described in the document at https://refspecs.linuxfoundation.org/LSB_1.3.0/gLSB/gLSB/ehframehdr.html
> @@ -167,4 +169,4 @@ The EH Frame header follows the Linux Standard Base (LSB) specification as descr
>  The EH Frame follows the LSB specification as described in the document at https://refspecs.linuxbase.org/LSB_3.0.0/LSB-PDA/LSB-PDA/ehframechpt.html
>  
>  
> -NOTE: The mapped_size is generally either the same as unwind_data_size (if the unwinding data was mapped in memory by the running process) or zero (if the unwinding data is not mapped by the process). If the unwinding data was not mapped, then only the EH Frame Header will be read, which can be used to specify FP based unwinding for a function which does not have unwinding information.
> +NOTE: The mapped_size is generally either the same as unwind_data_size (if the unwinding data was mapped in memory by the running process) or zero (if the unwinding data is not mapped by the process). If the unwinding data was not mapped, frame-pointer-based unwinding may still be possible, depending on the unwinding backend and whether the generated code maintains valid frame pointers.