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 -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
