From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH] common/symbols: Drop '+0/' when printing function pointer symbols. Date: Fri, 4 Oct 2013 11:18:08 +0100 Message-ID: <524E95E0.6070603@citrix.com> References: <1380880953-20453-1-git-send-email-andrew.cooper3@citrix.com> <524EB14F02000078000F8D18@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VS2Sc-000243-68 for xen-devel@lists.xenproject.org; Fri, 04 Oct 2013 10:18:14 +0000 In-Reply-To: <524EB14F02000078000F8D18@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: xen-devel , Keir Fraser List-Id: xen-devel@lists.xenproject.org On 04/10/13 11:15, Jan Beulich wrote: >>>> On 04.10.13 at 12:02, Andrew Cooper 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