Multithreaded core dump for 2.5.10-ia64 kernel.

This is a version of the tcore multi-threaded core dump patch that supports both i386 and ia64 architectures.

Its been smoke tested on a 2 way IPF box, it doesn't seem to crash ;)

I'm new to the stack unwinding thing WRT ia64 and would love to get some feed back on my tweaks to process.c that collect the register state data for the thread processes in the crashing thread group.

This multithread core dump is very similar to the patches I've been tossing up to the LKML, only this one supports ia64 core dumps as well as i386.

This patch applies cleanly to the 2.5.10+ia64 kernel.
It has a off by 2 line offset warnings in binfmt_elf.c for the stock 2.5.10 kernel due to some include lines added to binfmt_elf.c by the ia64 patch. I build this patch against the ia64 kernel. Regardless, it works for both architectures.

To use this patch you need to "echo 1 > /proc/sys/kernel/core_dumps_threads" to enable the tcore code path. Then when a multi-threaded application dumps core, it will crate a core file with the data for all the processes in the thread group.

This code works by "suspending" the other thread group processes, and then adding extra note sections to the core file with the user register state data. GDB 5.x knows how to work with these core files with one caveat. You may need to "strip libpthread*" before loading up the core file and crashing application into gdb. GDB 5.x; x < 2, seems to have a problem loading symbols for libpthread in this type of use.

The process suspend design does a number of interesting things that are worth pointing out.
1) it creates an extra run queue that has no cpu, the phantom cpu.
2) it uses process migration to migrate the processes of the thread group to the phantom run queue.
3) it removes the down_write from elf_dump_core, to avoid any possibility of deadlocking with one of the suspended thread processes. This is safe to do as the other thread process are suspended and cannot free pages while they aren't getting any CPU time.

One last note, I would have made this patch against the 2.5.18-ia64, but I was missing a header file (perfmon_itanium.h) and had some problems building it.

--mgross

(W) 503-712-8218
MS: JF1-05
2111 N.E. 25th Ave.
Hillsboro, OR 97124

Mark> I'm new to the stack unwinding thing WRT ia64 and would love Mark> to get some feed back on my tweaks to process.c that collect Mark> the register state data for the thread processes in the Mark> crashing thread group.

It looks fine to me. One suggestion, however: it might be a good idea to add a BUG_ON(task != current) statement to the dump_task_regs() and dump_task_fpu() routines. This will stop folks from accidentally trying to use unw_init_from_blocked_task() for the currently running task.

	--david

Good idea, I'll put the BUG_ON in.

I'll re-base to the updated 2.5.18 ia64 patches, that include perfmon_itanium.h, and add the BUG_ON logic later today.

Thanks,

--mgross

(W) 503-712-8218
MS: JF1-05
2111 N.E. 25th Ave.
Hillsboro, OR 97124

Mark> Good idea, I'll put the BUG_ON in. I'll re-base to the Mark> updated 2.5.18 ia64 patches, that include perfmon_itanium.h, Mark> and add the BUG_ON logic later today.

Note that for 2.5.18, you'll also have to create an empty include/asm-ia64/suspend.h, as Peter pointed out yesterday. Sorry for the glitches. Will try to do better next time.

	--david