lkml.org 
[lkml]   [1998]   [Dec]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: /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/

\
 
 \ /
  Last update: 2005-03-22 13:46    [W:0.042 / U:0.848 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site