From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH 4/7] x86: Replace print_symbol() with new %ps/%pS format Date: Tue, 5 Nov 2013 10:52:29 +0000 Message-ID: <5278CDED.1000604@citrix.com> References: <1383600624-6345-1-git-send-email-andrew.cooper3@citrix.com> <1383600624-6345-5-git-send-email-andrew.cooper3@citrix.com> <5278DAB402000078000FF74C@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VdeFN-0000KV-9U for xen-devel@lists.xenproject.org; Tue, 05 Nov 2013 10:52:33 +0000 In-Reply-To: <5278DAB402000078000FF74C@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 05/11/13 10:47, Jan Beulich wrote: >>>> On 04.11.13 at 22:30, Andrew Cooper wrote: >> --- a/xen/arch/x86/time.c >> +++ b/xen/arch/x86/time.c >> @@ -1475,8 +1475,7 @@ static int >> _disable_pit_irq(void(*hpet_broadcast_setup)(void)) >> { >> if ( xen_cpuidle > 0 ) >> { >> - print_symbol("%s() failed, turning to PIT broadcast\n", >> - (unsigned long)hpet_broadcast_setup); >> + printk("hpet_broadcast_setup() failed, turning to PIT broadcast\n"); > You're losing information here - hpet_broadcast_setup is a pointer > to a function. So I am. > >> --- a/xen/common/timer.c >> +++ b/xen/common/timer.c >> @@ -511,9 +511,9 @@ s_time_t align_timer(s_time_t firsttick, uint64_t period) >> >> static void dump_timer(struct timer *t, s_time_t now) >> { >> - printk(" ex=%8"PRId64"us timer=%p cb=%p(%p)", >> - (t->expires - now) / 1000, t, t->function, t->data); >> - print_symbol(" %s\n", (unsigned long)t->function); >> + printk(" ex=%8"PRId64"us timer=%p cb=%p(%p) %ps()\n", >> + (t->expires - now) / 1000, t, t->function, t->data, >> + _p(t->function)); > Do you really think printing t->function as raw _and_ as symbolic > is worthwhile? Probably not, especially given the new fallback behaviour upon failing to find a symbol name > > Also, this isn't really x86 code... > > Jan > So it isn't. I shall split it into a patch on its own. ~Andrew