Hi--
On 1/14/25 1:48 AM, Jiayuan Chen wrote:
> The dumpstack.c file has undergone many modifications, and the
> print_context_stack() function was removed or rewritten a long time ago,
> so it's better to remove the incorrect guidance. Additionally, no new
> functions will be added to the documentation, as it may be modified again
> in the future. Using 'question mark' and 'dumpstack' is sufficient to
> index this document.
>
> Signed-off-by: Jiayuan Chen <mrpre@xxxxxxx>
> ---
> Documentation/arch/x86/kernel-stacks.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/arch/x86/kernel-stacks.rst b/Documentation/arch/x86/kernel-stacks.rst
> index 738671a4070b..2d355e78008e 100644
> --- a/Documentation/arch/x86/kernel-stacks.rst
> +++ b/Documentation/arch/x86/kernel-stacks.rst
> @@ -113,7 +113,7 @@ Printing backtraces on x86
>
> The question about the '?' preceding function names in an x86 stacktrace
> keeps popping up, here's an indepth explanation. It helps if the reader
> -stares at print_context_stack() and the whole machinery in and around
stares at printk_stack_address() and its callers
and pay special attention to the 'reliable' parameter ('?' basically
means that the address is unreliable)
Also see the comment from dumpstack.c:
/*
* Scan the stack, printing any text addresses we find. At the
* same time, follow proper stack frames with the unwinder.
*
* Addresses found during the scan which are not reported by
* the unwinder are considered to be additional clues which are
* sometimes useful for debugging and are prefixed with '?'.
* This also serves as a failsafe option in case the unwinder
* goes off in the weeds.
*/
> +stares at 'question mark' and the whole machinery in and around
> arch/x86/kernel/dumpstack.c.
>
> Adapted from Ingo's mail, Message-ID: <20150521101614.GA10889@xxxxxxxxx>:
--
~Randy
