| Message ID | 1426130037-17956-14-git-send-email-scottwood@freescale.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
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. James -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2015-03-12 8:11 AM, 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. __builtin_return_address(0) returns the return address in the calling procedure ignoring import/export stubs. There are no function descriptors for return addresses. Thus, it can't return a function pointer. There are no function descriptors in 32-bit parisc when the -mfast-indirect-calls compiler option is used. This option used to be used for 64-bit kernel builds but this broke when the -mfast-indirect-calls was fixed for user space (gcl uses it). I worked a bit on trying to eliminate function descriptors from the 64-bit kernel for performance but I don't have a working change. Dave
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 *). -Scott -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Thu, Mar 12, 2015 at 02:04:41PM -0400, James Bottomley wrote: > 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. It's dead code behind #ifdef DEBUG_SUPERIO_INIT. A. -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/parisc/superio.c b/drivers/parisc/superio.c index 8be2096..38c5440 100644 --- a/drivers/parisc/superio.c +++ b/drivers/parisc/superio.c @@ -348,7 +348,7 @@ int superio_fixup_irq(struct pci_dev *pcidev) BUG(); return -1; } - printk("superio_fixup_irq(%s) ven 0x%x dev 0x%x from %pf\n", + printk("superio_fixup_irq(%s) ven 0x%x dev 0x%x from %ps\n", pci_name(pcidev), pcidev->vendor, pcidev->device, __builtin_return_address(0));
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. Signed-off-by: Scott Wood <scottwood@freescale.com> Cc: linux-parisc@vger.kernel.org --- drivers/parisc/superio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)