Message-ID: <55AECF03.80407@windriver.com>
Date:	Wed, 22 Jul 2015 07:00:19 +0800
From:	czm <zumeng.chen@...driver.com>
To:	Michael Ellerman <mpe@...erman.id.au>
CC:	Zumeng Chen <zumeng.chen@...il.com>,
	<linux-kernel@...r.kernel.org>, <paulus@...ba.org>,
	<imunsie@....ibm.com>, <linuxppc-dev@...ts.ozlabs.org>,
	<romeo.cane.ext@...iant.com>, Anton Blanchard <anton@...ba.org>
Subject: Re: BUG: perf error on syscalls for powerpc64.

在 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@...-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 <asm/systbl.h>
>
> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists