Skip to content
  • Hui Zhu's avatar
    elf: fix multithreaded program core dumping on arm · a65e7bfc
    Hui Zhu authored
    
    
    Fix the multithread program core thread message error.
    
    This issue affects arches with neither has CORE_DUMP_USE_REGSET nor
    ELF_CORE_COPY_TASK_REGS, ARM is one of them.
    
    The thread message of core file is generated in elf_dump_thread_status.
    The register values is set by elf_core_copy_task_regs in this function.
    
    If an arch doesn't define ELF_CORE_COPY_TASK_REGS,
    elf_core_copy_task_regs() will do nothing.  Then the core file will not
    have the register message of thread.
    
    So add elf_core_copy_regs to set regiser values if ELF_CORE_COPY_TASK_REGS
    doesn't define.
    
    The following is how to reproduce this issue:
    
    cat 1.c
    #include <stdio.h>
    #include <pthread.h>
    #include <assert.h>
    
    void td1(void * i)
    {
           while (1)
           {
                   printf ("1\n");
                   sleep (1);
           }
    
           return;
    }
    
    void td2(void * i)
    {
           while (1)
           {
                   printf ("2\n");
                   sleep (1);
           }
    
           return;
    }
    
    int
    main(int argc,char *argv[],char *envp[])
    {
           pthread_t       t1,t2;
    
           pthread_create(&t1, NULL, (void*)td1, NULL);
           pthread_create(&t2, NULL, (void*)td2, NULL);
    
           sleep (10);
    
           assert(0);
    
           return (0);
    }
    arm-xxx-gcc -g -lpthread 1.c -o 1
    copy 1.c and 1 to a arm board.
    Goto this board.
    ulimit -c 1800000
    ./1
    # ./1
    1
    2
    1
    ...
    ...
    1
    1: 1.c:37: main: Assertion `0' failed.
    Aborted (core dumped)
    Then you can get a core file.
    gdb 1 core.xxx
    Without the patch:
    (gdb) info threads
     3 process 909  0x00000000 in ?? ()
     2 process 908  0x00000000 in ?? ()
    * 1 process 907  0x4a6e2238 in raise () from /lib/libc.so.6
    You can found that the pc of 909 and 908 is 0x00000000.
    With the patch:
    (gdb) info threads
     3 process 885  0x4a749974 in nanosleep () from /lib/libc.so.6
     2 process 884  0x4a749974 in nanosleep () from /lib/libc.so.6
    * 1 process 883  0x4a6e2238 in raise () from /lib/libc.so.6
    The pc of 885 and 884 is right.
    
    Signed-off-by: default avatarHui Zhu <teawater@gmail.com>
    Cc: Amerigo Wang <xiyou.wangcong@gmail.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: David Howells <dhowells@redhat.com>
    Cc: Roland McGrath <roland@redhat.com>
    Cc: Jakub Jelinek <jakub@redhat.com>
    Cc: Russell King <rmk@arm.linux.org.uk>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    a65e7bfc