Messages in this thread | | | Date | Wed, 23 Dec 1998 14:15:22 -0500 (EST) | From | Kenneth Albanowski <> | Subject | Re: /proc/sys/kernel/corename |
| |
On Wed, 23 Dec 1998, Tigran Aivazian wrote:
> Good idea, but which terminal are you going to run the debugger on, > if the process did not have a ctty in the first place? > Even if it had one it is better to not touch it as it may be in > insane (anything other than canonical) state. > > Perhaps one could choose a spare vc (like X does when it starts up) > and start gdb there?
I wouldn't expect a naieve implementation at all (one that is hardwired to some specific thing). Since this would probably be a fairly unusual debugging procedure, the default should still be a core dump (as limited by ulimit), but if the user has requested a debug session (either via a ptrace call within or without the task, or some more general notification that all tasks of a certain sort should be debugged), then a debug stub would be started. That stub, in turn, might be connected to an automatically launched debugging process (if the user has specified a VT or X session to be used in that manner) or would simply remain in the background, waiting for an interactive (perhaps remote) connection from a debugger.
Obviously some decisions need to be made about how many tasks are allowed to stay "debuggable" in the background, how many debuggers can be fired up at once, etc. But again, this is relatively simple work for a user-space daemon.
The only additions that seem to be necessary for this are:
1) some way for a fatal signal to trigger a self-ptrace, a "pause" of some sort, and a notification of another task.
2) some way to tell the kernel what processes and signals #1 applies to.
3) some way of telling a process that you are ptracing to dump to a specified corefile (or perhaps dump core to a buffer).
4) and just perhaps, some way of resuming the process after having bypassed or returned from the fatal signal trigger.
The rest can be accomplished entirely in user space, using existing technology. The master daemon would deal with the notifications, and fork stubs to talk to debuggable tasks, and those stubs would talk to gdb via the existing remote target mechanism. The daemon or a separate debugq program could worry about forking debuggers to connect up to the stubs.
For what it's worth, this mechanism would be extremely attractive for working in an embedded system, where connecting to a downed task can be more feasible then writing out a core file.
(Equally, some way of overriding the core mechanism so that I could, for example, dump core to a remote machine, would be valuable.)
-- Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |