Messages in this thread | | | Date | Wed, 22 Jul 2015 07:00:19 +0800 | From | czm <> | 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@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 <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 > >
| |