Re: [PATCH] Fix the multithread program core thread message error

[Amerigo Wang <xiyou.wangcong@gmail.com>]

On Wed, Jul 01, 2009 at 12:05:19PM -0700, Andrew Morton wrote:
>On Wed, 1 Jul 2009 14:21:37 +0800
>Hui Zhu <teawater@gmail.com> wrote:
>
>> Thanks for your help, Amerigo.
>> 
>> Hui
>> 
>> Fix the multithread program core thread message error.
>> This issue just affect arch 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 a arch doesn't define ELF_CORE_COPY_TASK_REGS, The function
>> 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:
>>
>> ...
>>
>> 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.
>

Thanks for taking this.


>I'm trying to work out if we should backport this fix into earlier
>kernels (2.6.30.x, 2.6.29.x, etc).
>
>I'd have though that having gdb produce crap for all the threads would
>be fairly irritating to ARM developers and hence we should backport
>this.  But perhaps it doens't affect many people, dunno.
>
>What do poeple think?

This doesn't affect many platforms, only the platforms which has
_neither_ CORE_DUMP_USE_REGSET nor ELF_CORE_COPY_TASK_REGS.

I haven't checked all, just x86 and arm, x86 doesn't, arm does.