在 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
