Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933768AbbGUXBF (ORCPT ); Tue, 21 Jul 2015 19:01:05 -0400 Received: from mail1.windriver.com ([147.11.146.13]:38438 "EHLO mail1.windriver.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933239AbbGUXBB (ORCPT ); Tue, 21 Jul 2015 19:01:01 -0400 Message-ID: <55AECF03.80407@windriver.com> Date: Wed, 22 Jul 2015 07:00:19 +0800 From: czm User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Michael Ellerman CC: Zumeng Chen , , , , , , Anton Blanchard Subject: Re: BUG: perf error on syscalls for powerpc64. References: <1437037461.15828.2.camel@ellerman.id.au> <1437106043.29389.5.camel@ellerman.id.au> <55A89280.8090705@windriver.com> <1437460821.30722.11.camel@ellerman.id.au> In-Reply-To: <1437460821.30722.11.camel@ellerman.id.au> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3273 Lines: 91 在 2015年07月21日 14:40, Michael Ellerman 写道: > On Fri, 2015-07-17 at 13:28 +0800, Zumeng Chen wrote: >> On 2015年07月17日 12:07, Michael Ellerman wrote: >>> On Fri, 2015-07-17 at 09:27 +0800, Zumeng Chen wrote: >>>> On 2015年07月16日 17:04, Michael Ellerman wrote: >>>>> On Thu, 2015-07-16 at 13:57 +0800, Zumeng Chen wrote: >>>>>> Hi All, >>>>>> >>>>>> 1028ccf5 did a change for sys_call_table from a pointer to an array of >>>>>> unsigned long, I think it's not proper, here is my reason: >>>>>> >>>>>> sys_call_table defined as a label in assembler should be pointer array >>>>>> rather than an array as described in 1028ccf5. If we defined it as an >>>>>> array, then arch_syscall_addr will return the address of sys_call_table[], >>>>>> actually the content of sys_call_table[] is demanded by arch_syscall_addr. >>>>>> so 'perf list' will ignore all syscalls since find_syscall_meta will >>>>>> return null >>>>>> in init_ftrace_syscalls because of the wrong arch_syscall_addr. >>>>>> >>>>>> Did I miss something, or Gcc compiler has done something newer ? >>>>> Hi Zumeng, >>>>> >>>>> It works for me with the code as it is in mainline. >>>>> >>>>> I don't quite follow your explanation, so if you're seeing a bug please send >>>>> some information about what you're actually seeing. And include the disassembly >>>>> of arch_syscall_addr() and your compiler version etc. >>>> Hi Michael, >>> Hi Zumeng, >>> >>>> Yeah, it seems it was not a good explanation, I'll explain more this time: >>>> >>>> 1. Whatever we exclaim sys_call_table in C level, actually it is a pointer >>>> to sys_call_table rather than sys_call_table self in assemble level. >>> No it's not a pointer. >> Then what is the second one in the following: > It's a function descriptor. > >> zchen@pek-yocto-build2:$ cat System.map |grep sys_call_table >> c000000000009590 T .sys_call_table <-----this is a real sys_call_table. >> c0000000014e1b48 D sys_call_table <-----this should be referred by >> arch_syscall_addr >> >> The c0000000014e1b48[0] = c000000000009590 > That is from 3.14 isn't it? > > In 3.14 we had in systbl.S: > > 46 _GLOBAL(sys_call_table) > 47 #include > > And _GLOBAL was: > > 46 #define _GLOBAL(name) \ > 47 .type name,@function; \ > 48 .globl name; \ > 49 name: > > > Which means sys_call_table was being declared as a function, which is > completely wrong. > > On big endian when you declare a function "foo" you get two symbols, ".foo" at > the address you declare the symbol and "foo" which is somewhere else and > contains three pointers, the first of which is to ".foo". > > So at address "foo" you have a pointer to ".foo", which happens to be what > you'd expect if "foo" was a pointer to ".foo". > > Anton fixed this in 3.16: > > https://git.kernel.org/torvalds/c/c857c43b34ec > > > But that had the side-effect of breaking the usage of sys_call_table in C. Yeah, good to know, thanks Michael again. Cheers, Zumeng > > cheers > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/