[lkml]   [2017]   [Sep]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC][PATCH v2 6/7] symbol lookup: use new kernel and module dereference functions
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.


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.


 \ /
  Last update: 2017-09-21 19:29    [W:0.194 / U:0.760 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site