[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] common/symbols: Drop '+0/<len>' when printing function pointer symbols.
On 04/10/13 11:15, Jan Beulich wrote: >>>> On 04.10.13 at 12:02, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |