On (09/21/17 01:29), Sergey Senozhatsky wrote:
[..]
> + %pS versatile_init+0x0/0x110
> + %ps versatile_init
> %pF versatile_init+0x0/0x110
> %pf versatile_init
> - %pS versatile_init+0x0/0x110
> %pSR versatile_init+0x9/0x110
> (with __builtin_extract_return_addr() translation)
> - %ps versatile_init
> %pB prev_fn_of_versatile_init+0x88/0x88
>
> -The ``F`` and ``f`` specifiers are for printing function pointers,
> -for example, f->func, &gettimeofday. They have the same result as
> -``S`` and ``s`` specifiers. But they do an extra conversion on
> -ia64, ppc64 and parisc64 architectures where the function pointers
> -are actually function descriptors.
> -
> The ``S`` and ``s`` specifiers can be used for printing symbols
> from direct addresses, for example, __builtin_return_address(0),
> (void *)regs->ip. They result in the symbol name with (``S``) or
> without (``s``) offsets. If KALLSYMS are disabled then the symbol
> address is printed instead.
>
> +Note, that the ``F`` and ``f`` specifiers are identical to ``S`` (``s``)
> +and thus deprecated.
JFI,
I have updated this part. it's probably too early to completely
wipe out pF/pf info.
the updated Doc goes like this:
+Note, that the ``F`` and ``f`` specifiers are identical to ``S`` (``s``)
+and thus deprecated. We have ``F`` and ``f`` because on ia64, ppc64 and
+parisc64 function pointers are indirect and, in fact, are function
+descriptors, which require additional dereferencing before we can lookup
+the symbol. As of now, ``S`` and ``s`` perform dereferencing on those
+platforms (when needed), so ``F`` and ``f`` exist for compatibility
+reasons only.
-ss
