From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755315AbbCLSEq (ORCPT ); Thu, 12 Mar 2015 14:04:46 -0400 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:43665 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755016AbbCLSEn (ORCPT ); Thu, 12 Mar 2015 14:04:43 -0400 Message-ID: <1426183481.2146.80.camel@HansenPartnership.com> Subject: Re: [PATCH 14/22] parisc: %pF is only for function pointers From: James Bottomley To: Scott Wood Cc: trivial@kernel.org, linux-kernel@vger.kernel.org, linux-parisc@vger.kernel.org Date: Thu, 12 Mar 2015 14:04:41 -0400 In-Reply-To: <1426176869.30327.113.camel@freescale.com> References: <1426130037-17956-1-git-send-email-scottwood@freescale.com> <1426130037-17956-14-git-send-email-scottwood@freescale.com> <1426162282.2146.77.camel@HansenPartnership.com> <1426176869.30327.113.camel@freescale.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.9 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2015-03-12 at 11:14 -0500, Scott Wood wrote: > On Thu, 2015-03-12 at 08:11 -0400, James Bottomley wrote: > > On Wed, 2015-03-11 at 22:13 -0500, Scott Wood wrote: > > > Use %pS for actual addresses, otherwise you'll get bad output > > > on arches like ppc64 where %pF expects a function descriptor. Even on > > > other architectures, refrain from setting a bad example that people > > > copy. > > > > Are you sure about this? Parisc64 is a function description > > architecture. There may be a misunderstanding about what > > __builtin_return_address(0) is supposed to return, but I'm certain the > > person who added the code thought it returned a function pointer, which > > on parisc64 would be a descriptor. > > I wasn't aware that parisc64 used descriptors, but I don't see how you'd > get one out of __builtin_return_address(0) since it's not usually a > function entry point (plus, GCC documents it as returning void *). I was more thinking that this message is printed for every boot with a superio chip (which is a lot of our boxes). How come no-one has complained on parisc64 if it's doing the wrong thing. James