Re: [PATCH] common/symbols: Drop '+0/<len>' when printing function pointer symbols.

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 04/10/13 11:15, Jan Beulich wrote:
>>>> On 04.10.13 at 12:02, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> Introduce print_function() with the same semantics as print_symbol().  The
>> underlying __print_symbol() now takes an extra boolean indicating whether we
>> are expecting to print a function pointer.   In the case that we are 
>> expecting
>> a function pointer, and the offset is 0, drop the offset and length.
>>
>> The requirement for offset being 0 is for the (hopefully never, but we 
>> really
>> want to know if it does happen) case where a Xen function pointer is not
>> actually pointing at the start of a function.
>>
>> The relevent print_symbol() functions are updated to print_function()
> There's no reason why the same couldn't apply to data symbols.
> Rather than doing it this way (and with a mis-named function), I'd
> much prefer going the printk() format string extensions route that
> Linux went. This would at once allow re-combining the broken up
> printing when symbols are involved into single invocations of printk().
> This has been on my (mental) to-do list for quite some time, but
> hasn't been important enough for me to ever get to it.
>
> Jan
>

Right - that is two very quick recommendations for %pS and %pF.  I will
see what I can do in my next bit of free time.  (FWIW, this patch came
about from frustration during my HPET interrupt debugging work, and I
was looking for a momentary break from the HPET code itself)

~Andrew