Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1186360 > unrolled thread

Re: BUG: perf error on syscalls for powerpc64.

Started byZumeng Chen <zumeng.chen@gmail.com>
First post2015-07-17 03:30 +0200
Last post2015-07-21 08:50 +0200
Articles 6 — 4 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: BUG: perf error on syscalls for powerpc64. Zumeng Chen <zumeng.chen@gmail.com> - 2015-07-17 03:30 +0200
    Re: BUG: perf error on syscalls for powerpc64. Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> - 2015-07-17 04:00 +0200
      Re: BUG: perf error on syscalls for powerpc64. Zumeng Chen <zumeng.chen@windriver.com> - 2015-07-17 07:40 +0200
    Re: BUG: perf error on syscalls for powerpc64. Michael Ellerman <mpe@ellerman.id.au> - 2015-07-17 06:10 +0200
      Re: BUG: perf error on syscalls for powerpc64. Zumeng Chen <zumeng.chen@windriver.com> - 2015-07-17 07:40 +0200
        Re: BUG: perf error on syscalls for powerpc64. Michael Ellerman <mpe@ellerman.id.au> - 2015-07-21 08:50 +0200

#1186360 — Re: BUG: perf error on syscalls for powerpc64.

FromZumeng Chen <zumeng.chen@gmail.com>
Date2015-07-17 03:30 +0200
SubjectRe: BUG: perf error on syscalls for powerpc64.
Message-ID<pN2Do-7lA-15@gated-at.bofh.it>
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,

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.

     arch/powerpc/kernel/systbl.S
     47 .globl sys_call_table   <--- see here
     48 sys_call_table:

     So if you want to exclaim sys_call_table as array, then I think
it's very
     clear what we'll get when we do sys_call_table[i].

2. Disassemble codes difference of arch_syscall_addr with or without
1028ccf5
================================================

     *) With 1028ccf5
       ---------------------
Dump of assembler code for function arch_syscall_addr:
522    {
523        return (unsigned long)sys_call_table[nr];
    0xc000000000df53d4 <+0>:    addis   r10,r2,-13
    0xc000000000df53d8 <+4>:    addi    r9,r10,3488
    0xc000000000df53dc <+8>:    rldicr  r3,r3,3,60
524    }
    0xc000000000df53e0 <+12>:    ldx     r3,r9,r3
    0xc000000000df53e4 <+16>:    blr


     *) Without 1028ccf5
     ---------------------------
Dump of assembler code for function arch_syscall_addr:
522    {
523        return (unsigned long)sys_call_table[nr];
    0xc000000000df53d0 <+0>:    addis   r10,r2,-13
    0xc000000000df53d4 <+4>:    addi    r9,r10,3488
    0xc000000000df53d8 <+8>:    rldicr  r3,r3,3,60
    0xc000000000df53dc <+12>:    ld      r9,0(r9) <------only this is
different
524    }
    0xc000000000df53e0 <+16>:    ldx     r3,r9,r3
    0xc000000000df53e4 <+20>:    blr
End of assembler dump.

3. What I have seen in 3.14.x kernel,
======================
And so far, no more difference to 4.x kernel from me about this part if
I'm right.

*) With 1028ccf5

perf list|grep -i syscall got me nothing.


*) Without 1028ccf5
root@localhost:~# perf list|grep -i syscall
   syscalls:sys_enter_socket                          [Tracepoint event]
   syscalls:sys_exit_socket                           [Tracepoint event]
   syscalls:sys_enter_socketpair                      [Tracepoint event]
   syscalls:sys_exit_socketpair                       [Tracepoint event]
   syscalls:sys_enter_bind                            [Tracepoint event]
   syscalls:sys_exit_bind                             [Tracepoint event]
   syscalls:sys_enter_listen                          [Tracepoint event]
   syscalls:sys_exit_listen                           [Tracepoint event]
   ... ...

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/

[toc] | [next] | [standalone]

#1186372

FromSukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Date2015-07-17 04:00 +0200
Message-ID<pN36p-7Ts-5@gated-at.bofh.it>
In reply to#1186360
Zumeng Chen [zumeng.chen@gmail.com] wrote:
| 3. What I have seen in 3.14.x kernel,
| ======================
| And so far, no more difference to 4.x kernel from me about this part if
| I'm right.
| 
| *) With 1028ccf5
| 
| perf list|grep -i syscall got me nothing.
| 
| 
| *) Without 1028ccf5
| root@localhost:~# perf list|grep -i syscall
|    syscalls:sys_enter_socket                          [Tracepoint event]
|    syscalls:sys_exit_socket                           [Tracepoint event]
|    syscalls:sys_enter_socketpair                      [Tracepoint event]
|    syscalls:sys_exit_socketpair                       [Tracepoint event]
|    syscalls:sys_enter_bind                            [Tracepoint event]
|    syscalls:sys_exit_bind                             [Tracepoint event]
|    syscalls:sys_enter_listen                          [Tracepoint event]
|    syscalls:sys_exit_listen                           [Tracepoint event]
|    ... ...

Are you seeing this on big-endian or little-endian system?

IIRC, I saw the opposite behavior on an LE system a few months ago.
i.e. without 1028ccf5, 'perf listf|grep syscall' failed.

Applying 1028ccf5, seemed to fix it.

Sukadev

--
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/

[toc] | [prev] | [next] | [standalone]

#1186476

FromZumeng Chen <zumeng.chen@windriver.com>
Date2015-07-17 07:40 +0200
Message-ID<pN6xj-4zZ-5@gated-at.bofh.it>
In reply to#1186372
On 2015年07月17日 09:51, Sukadev Bhattiprolu wrote:
> Zumeng Chen [zumeng.chen@gmail.com] wrote:
> | 3. What I have seen in 3.14.x kernel,
> | ======================
> | And so far, no more difference to 4.x kernel from me about this part if
> | I'm right.
> |
> | *) With 1028ccf5
> |
> | perf list|grep -i syscall got me nothing.
> |
> |
> | *) Without 1028ccf5
> | root@localhost:~# perf list|grep -i syscall
> |    syscalls:sys_enter_socket                          [Tracepoint event]
> |    syscalls:sys_exit_socket                           [Tracepoint event]
> |    syscalls:sys_enter_socketpair                      [Tracepoint event]
> |    syscalls:sys_exit_socketpair                       [Tracepoint event]
> |    syscalls:sys_enter_bind                            [Tracepoint event]
> |    syscalls:sys_exit_bind                             [Tracepoint event]
> |    syscalls:sys_enter_listen                          [Tracepoint event]
> |    syscalls:sys_exit_listen                           [Tracepoint event]
> |    ... ...
>
> Are you seeing this on big-endian or little-endian system?

Big one.

>
> IIRC, I saw the opposite behavior on an LE system a few months ago.
> i.e. without 1028ccf5, 'perf listf|grep syscall' failed.

I wonder if this has anything to do with the bug.

Cheers,
Zumeng

>
> Applying 1028ccf5, seemed to fix it.
>
> Sukadev
>

--
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/

[toc] | [prev] | [next] | [standalone]

#1186417

FromMichael Ellerman <mpe@ellerman.id.au>
Date2015-07-17 06:10 +0200
Message-ID<pN58d-2Dm-5@gated-at.bofh.it>
In reply to#1186360
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.

A pointer is a location in memory that contains the address of another location
in memory.

>      arch/powerpc/kernel/systbl.S
>      47 .globl sys_call_table   <--- see here
>      48 sys_call_table:

Which gives us a .o that looks like:

  0000000000000000 <sys_call_table>:
                   0: R_PPC64_ADDR64       sys_restart_syscall
                   8: R_PPC64_ADDR64       sys_restart_syscall
                   10: R_PPC64_ADDR64      sys_exit
                   18: R_PPC64_ADDR64      sys_exit

ie. at the location in memory called sys_call_table we have *the contents of
the syscall table*.

We do not have *the address* of the syscall table.

You can also see in the System.map:

  c000000000bb0798 R sys_call_table
  c000000000bb1e58 r cache_type_info

ie. sys_call_table occupies 5824 bytes. If it was a pointer it would only
occupy 8 bytes.

Compare to SYS_CALL_TABLE, which *is* a pointer.

  c000000001172bf8 d SYS_CALL_TABLE
  c000000001172c00 d exception_marker

Note, 8 bytes.


Finally if you look at a running system using xmon:

  0:mon> d $sys_call_table
  c0000000008f0798 c0000000000a85a0 c0000000000a85a0  |................|
  c0000000008f07a8 c000000000099b40 c000000000099b40  |.......@.......@|

  0:mon> la c0000000000a85a0
  c0000000000a85a0: .sys_restart_syscall+0x0/0x40
  0:mon> la c000000000099b40
  c000000000099b40: .SyS_exit+0x0/0x20

  0:mon> d $SYS_CALL_TABLE
  c000000000ec68f8 c0000000008f0798 7265677368657265  |........regshere|
                   ^
  		 this is the address of sys_call_table


As another example, see hcall_real_table, which is basically identical, and is
also declared as an array in C.


> 3. What I have seen in 3.14.x kernel,
> ======================
> And so far, no more difference to 4.x kernel from me about this part if
> I'm right.
> 
> *) With 1028ccf5
> 
> perf list|grep -i syscall got me nothing.
> 
> 
> *) Without 1028ccf5
> root@localhost:~# perf list|grep -i syscall
>    syscalls:sys_enter_socket                          [Tracepoint event]
>    syscalls:sys_exit_socket                           [Tracepoint event]
>    syscalls:sys_enter_socketpair                      [Tracepoint event]
>    syscalls:sys_exit_socketpair                       [Tracepoint event]
>    syscalls:sys_enter_bind                            [Tracepoint event]
>    syscalls:sys_exit_bind                             [Tracepoint event]
>    syscalls:sys_enter_listen                          [Tracepoint event]
>    syscalls:sys_exit_listen                           [Tracepoint event]
>    ... ...

I don't know why that's happening.

Please just test 4.2-rc2 for now, so that there are not too many variables.

Assuming you have CONFIG_FTRACE_SYSCALLS=y, you can see the tracepoints in
debugfs with:

  $ ls -la /sys/kernel/debug/tracing/events/syscalls
  total 0
  drwxr-xr-x 596 root root 0 Jul 17 13:11 .
  drwxr-xr-x  45 root root 0 Jul 17 13:11 ..
  -rw-r--r--   1 root root 0 Jul 17 13:33 enable
  -rw-r--r--   1 root root 0 Jul 17 13:11 filter
  drwxr-xr-x   2 root root 0 Jul 17 13:11 sys_enter_accept
  drwxr-xr-x   2 root root 0 Jul 17 13:11 sys_enter_accept4
  drwxr-xr-x   2 root root 0 Jul 17 13:11 sys_enter_access
  drwxr-xr-x   2 root root 0 Jul 17 13:11 sys_enter_add_key
  ...


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/

[toc] | [prev] | [next] | [standalone]

#1186474

FromZumeng Chen <zumeng.chen@windriver.com>
Date2015-07-17 07:40 +0200
Message-ID<pN6xj-4zZ-1@gated-at.bofh.it>
In reply to#1186417
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:

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

>
> A pointer is a location in memory that contains the address of another location
> in memory.

Yeah, this definition is right.

>
>>       arch/powerpc/kernel/systbl.S
>>       47 .globl sys_call_table   <--- see here
>>       48 sys_call_table:
> Which gives us a .o that looks like:
>
>    0000000000000000 <sys_call_table>:
>                     0: R_PPC64_ADDR64       sys_restart_syscall
>                     8: R_PPC64_ADDR64       sys_restart_syscall
>                     10: R_PPC64_ADDR64      sys_exit
>                     18: R_PPC64_ADDR64      sys_exit
>
> ie. at the location in memory called sys_call_table we have *the contents of
> the syscall table*.
>
> We do not have *the address* of the syscall table.
>
> You can also see in the System.map:
>
>    c000000000bb0798 R sys_call_table
>    c000000000bb1e58 r cache_type_info

Please refer to `cat  System.map` above

>
> ie. sys_call_table occupies 5824 bytes. If it was a pointer it would only
> occupy 8 bytes.
>
> Compare to SYS_CALL_TABLE, which *is* a pointer.
>
>    c000000001172bf8 d SYS_CALL_TABLE
>    c000000001172c00 d exception_marker
>
> Note, 8 bytes.
>
>
> Finally if you look at a running system using xmon:
>
>    0:mon> d $sys_call_table
>    c0000000008f0798 c0000000000a85a0 c0000000000a85a0  |................|
>    c0000000008f07a8 c000000000099b40 c000000000099b40  |.......@.......@|

This is right sys_call_table. but not what I'm talking about. What I'm 
talking about
is that the definition of sys_call_table by that commit will incur the 
following result:

sys_call_table[0]= 0xc0000000014e1b48[0] = c000000000009590 <----Only 
this one is right the head address of sys_call_table
sys_call_table[1]= 0xc0000000014e1b48[1] = c0000000015b0da8
sys_call_table[2]= 0xc0000000014e1b48[2] = 0
sys_call_table[3]= 0xc0000000014e1b48[3] = c000000000de0984
sys_call_table[4]= 0xc0000000014e1b48[4] = c0000000015b0da8
sys_call_table[5]= 0xc0000000014e1b48[5] = 0

This is definitely not what we want, is that right?


>
>    0:mon> la c0000000000a85a0
>    c0000000000a85a0: .sys_restart_syscall+0x0/0x40
>    0:mon> la c000000000099b40
>    c000000000099b40: .SyS_exit+0x0/0x20
>
>    0:mon> d $SYS_CALL_TABLE
>    c000000000ec68f8 c0000000008f0798 7265677368657265  |........regshere|
>                     ^
>    		 this is the address of sys_call_table
>
>
> As another example, see hcall_real_table, which is basically identical, and is
> also declared as an array in C.
>
>
>> 3. What I have seen in 3.14.x kernel,
>> ======================
>> And so far, no more difference to 4.x kernel from me about this part if
>> I'm right.
>>
>> *) With 1028ccf5
>>
>> perf list|grep -i syscall got me nothing.
>>
>>
>> *) Without 1028ccf5
>> root@localhost:~# perf list|grep -i syscall
>>     syscalls:sys_enter_socket                          [Tracepoint event]
>>     syscalls:sys_exit_socket                           [Tracepoint event]
>>     syscalls:sys_enter_socketpair                      [Tracepoint event]
>>     syscalls:sys_exit_socketpair                       [Tracepoint event]
>>     syscalls:sys_enter_bind                            [Tracepoint event]
>>     syscalls:sys_exit_bind                             [Tracepoint event]
>>     syscalls:sys_enter_listen                          [Tracepoint event]
>>     syscalls:sys_exit_listen                           [Tracepoint event]
>>     ... ...
> I don't know why that's happening.
>
> Please just test 4.2-rc2 for now, so that there are not too many variables.

Yeah, maybe right.

>
> Assuming you have CONFIG_FTRACE_SYSCALLS=y, you can see the tracepoints in

Absolutely

Cheers,
Zumeng

> debugfs with:
>
>    $ ls -la /sys/kernel/debug/tracing/events/syscalls
>    total 0
>    drwxr-xr-x 596 root root 0 Jul 17 13:11 .
>    drwxr-xr-x  45 root root 0 Jul 17 13:11 ..
>    -rw-r--r--   1 root root 0 Jul 17 13:33 enable
>    -rw-r--r--   1 root root 0 Jul 17 13:11 filter
>    drwxr-xr-x   2 root root 0 Jul 17 13:11 sys_enter_accept
>    drwxr-xr-x   2 root root 0 Jul 17 13:11 sys_enter_accept4
>    drwxr-xr-x   2 root root 0 Jul 17 13:11 sys_enter_access
>    drwxr-xr-x   2 root root 0 Jul 17 13:11 sys_enter_add_key
>    ...
>
>
> cheers
>
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev

--
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/

[toc] | [prev] | [next] | [standalone]

#1188704

FromMichael Ellerman <mpe@ellerman.id.au>
Date2015-07-21 08:50 +0200
Message-ID<pOzxf-y4-3@gated-at.bofh.it>
In reply to#1186474
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.

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/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web