This is the mail archive of the gdb-patches@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: GDB needs a --cmdline option


   Date: Mon, 08 May 2000 13:39:51 -0400
   From: Fernando Nasser <fnasser@cygnus.com>

This is getting a bit off topic, but I couldn't resist to respond :-)

   Michael Meissner wrote:
   > 
   > Just as a note, when I was at DG many years ago, the debugger
   > group there added a feature where a program could invoke the
   > debugger as a child whenever it wanted to be debugged (usually in
   > the case for long live processes, especially daemons).  I recall
   > some people adding such a call to AOS/VS's equivalent of a signal
   > handler, so you could just hit ^C to start up the debugger.
   > 

   If you modify abort() do that it will try to activate the debugger
   if a certain environment variable is set we could work like MS
   stuff (if the idea of mimicking MS offends you, just remember they
   probably copied it from someone else, it may have even been from
   some Unix variant).

We have something like that on the Hurd :-).  When a program gets a
fatal signal (for example as a result of calling abort()), it contacts
a special crash server.  This crash server is supposed to do whatever
is appropriate like producing a core dump, but that's not implemented
right now.  Instead we suspend the process such that you can attach
GDB to it.  The nice thing is that this means that the process is
still mostly intact, including its communication channels with other
processes.

It would be a piece of cake to write a crash server that fires up GDB
for you.  The nice thing is that the user can specify what crash
server should be used by using an environment variable.  So you don't
need to be the system administrator to change it.

   This would only make sense for foreground jobs though.  Daemons are
   probably restricted to core files (which is not that bad -- with
   the right log facility and a core file one has a great chance to
   reproduce the problem on a subsequent debugger controlled run).

The current crash server allows you to specify different actions for
orphaned processes.

However, this doesn't make the command line option unnecessary.  If
the process crashed, it may be hard to reconstruct exactly why it
crashed (I have some experience with debugging a broken calloc()
implementation :-().

Mark

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]