Just-in-time debugging

Just-in-time debugging

[Robin Rowe]

Hi. Can I configure gdb so that it will launch automatically in response to
a core dump?

Thanks,

Robin
---------------------------------------------------------------------------
www.OpenSourceProgrammers.org
www.LinuxMovies.org

Re: Just-in-time debugging

[Christopher Faylor]

On Fri, Jun 07, 2002 at 05:24:29PM -0700, Robin Rowe wrote:
>Hi. Can I configure gdb so that it will launch automatically in response to
>a core dump?

On what system?  On windows you'd do:

set cygwin=error_start=x:/path/to/gdb.exe

I don't know if it's possible to do on unix or not.

cgf

Re: Just-in-time debugging

[Eli Zaretskii]

On Sat, 8 Jun 2002, Christopher Faylor wrote:

> On windows you'd do:
> 
> set cygwin=error_start=x:/path/to/gdb.exe

Shouldn't this be in the manual?

Re: Just-in-time debugging

[Christopher Faylor]

On Sun, Jun 09, 2002 at 08:46:15AM +0300, Eli Zaretskii wrote:
>
>On Sat, 8 Jun 2002, Christopher Faylor wrote:
>
>> On windows you'd do:
>> 
>> set cygwin=error_start=x:/path/to/gdb.exe
>
>Shouldn't this be in the manual?

Does the gdb manual document quirks of individual "operating systems"?

cgf

Re: Just-in-time debugging

[Eli Zaretskii]

> Date: Sun, 9 Jun 2002 12:31:00 -0400
> From: Christopher Faylor <cgf@redhat.com>
> >> 
> >> set cygwin=error_start=x:/path/to/gdb.exe
> >
> >Shouldn't this be in the manual?
> 
> Does the gdb manual document quirks of individual "operating systems"?

Yes.  See the chapter "Configurations" which describes, under
"Native", commands specific to the DJGPP and other ports.

Re: Just-in-time debugging

[Christopher Faylor]

On Sun, Jun 09, 2002 at 08:10:57PM +0300, Eli Zaretskii wrote:
>> Date: Sun, 9 Jun 2002 12:31:00 -0400
>> From: Christopher Faylor <cgf@redhat.com>
>> >> 
>> >> set cygwin=error_start=x:/path/to/gdb.exe
>> >
>> >Shouldn't this be in the manual?
>> 
>> Does the gdb manual document quirks of individual "operating systems"?
>
>Yes.  See the chapter "Configurations" which describes, under
>"Native", commands specific to the DJGPP and other ports.

These all seem to be GDB commands.  The command that I gave above is for
the windows command shell.  It instructs cygwin to invoke a program when
a fatal signal is encountered.

Unless we want to start documenting things like "How to use ulimit" in
the gdb manual, I don't think it is necessarily appropriate for us
to mention the setting of environment variables for cygwin.

cgf

Re: Just-in-time debugging

[Eli Zaretskii]

On Sun, 9 Jun 2002, Christopher Faylor wrote:

> Unless we want to start documenting things like "How to use ulimit" in
> the gdb manual, I don't think it is necessarily appropriate for us
> to mention the setting of environment variables for cygwin.

The variable is related to GDB, so it sounds appropriate.

Re: Just-in-time debugging

[Andrew Cagney]

> On Sun, 9 Jun 2002, Christopher Faylor wrote:
> 
> 
>> Unless we want to start documenting things like "How to use ulimit" in
>> the gdb manual, I don't think it is necessarily appropriate for us
>> to mention the setting of environment variables for cygwin.
> 
> 
> The variable is related to GDB, so it sounds appropriate.

Yes.  While not the internal user interface, it definitly very useful 
and makes someone using GDB's life easier.

Similar to this is knowing how to use GDB to create a stack backtrace.

Andrew

Re: Just-in-time debugging

[Christopher Faylor]

On Mon, Jun 10, 2002 at 11:17:07AM -0400, Andrew Cagney wrote:
>>On Sun, 9 Jun 2002, Christopher Faylor wrote:
>>>Unless we want to start documenting things like "How to use ulimit" in
>>>the gdb manual, I don't think it is necessarily appropriate for us
>>>to mention the setting of environment variables for cygwin.
>>
>>The variable is related to GDB, so it sounds appropriate.
>
>Yes.  While not the internal user interface, it definitly very useful 
>and makes someone using GDB's life easier.
>
>Similar to this is knowing how to use GDB to create a stack backtrace.

As I'd mentioned, I think a better example is the unix ulimit command.
A grep of 'ulimit' does not unearth anything in the gdb documentation
directory.  Certainly, if a user wants to create a core file (and why
would you create a core file except for debugging?) they'd need to know
about this.

If you want to start populating the gdb documentation with OS-specific
hints, then I think you should start with linux.

In the meantime, I'm not going to be providing documentation for this.
I don't want to have to worry about modifying the information in two
places when/if we change the CYGWIN environment variable.

cgf

Re: Just-in-time debugging

[Eli Zaretskii]

> Date: Mon, 10 Jun 2002 11:38:37 -0400
> From: Christopher Faylor <cgf@redhat.com>
> 
> In the meantime, I'm not going to be providing documentation for this.
> I don't want to have to worry about modifying the information in two
> places when/if we change the CYGWIN environment variable.

How about a pointer to the other place where this is mentioned in the
Cygwin docs?

Re: Just-in-time debugging on Linux

[Robin Rowe]

Christopher,

> On windows you'd do:
>
> set cygwin=error_start=x:/path/to/gdb.exe

Thanks lots, but I meant Linux. Does anyone know the trick to launch gdb
automatically there?

Robin
---------------------------------------------------------------------------
www.OpenSourceProgrammers.org
www.LinuxMovies.org

# Re: Just-in-time debugging on Linux

[Michael Veksler]

/References/: <007a01c20e82$daf93e20$0301a8c0@rowboat 
<http://sources.redhat.com/ml/gdb/2002-06/msg00063.html>> 
<20020608172614.GA16912@redhat.com 
<http://sources.redhat.com/ml/gdb/2002-06/msg00064.html>>

 > Christopher,
 >
 > > On windows you'd do:
 > >
 > > set cygwin=error_start=x:/path/to/gdb.exe
 >
 > Thanks lots, but I meant Linux. Does anyone know the trick to launch gdb
 > automatically there?
 >
 > Robin

Try the following code:

#include <stdlib.h>
#include <unistd.h>
#include <sys/wait.h>
#include <signal.h>
#include <stdio.h>

static char* exec_name="";

static void crash_handler(int sig)
{
   int status=0;
   int pid;
   char * gdb_array[]={"gdb", exec_name, "PID", NULL};
   char pid_str[40];

   sprintf(pid_str, "%d%c", getpid(), '\0');
   gdb_array[2]= pid_str;

   pid= fork();

   if (pid < 0)    /* error */
     abort();
   else if (pid)   /* parent */
   {
     sleep(60);   /* Give GDB time to attach */
     _exit(1);     /* you can skip this line by telling gdb to "return" */
   }
   else            /* child */
     execvp("gdb", gdb_array);
}
void register_gdb()
{
   signal(SIGQUIT, crash_handler);  /* Normally got from Ctrl-\ */
   signal(SIGILL,  crash_handler);
   signal(SIGTRAP, crash_handler);
   signal(SIGABRT, crash_handler);
   signal(SIGFPE,  crash_handler);
   signal(SIGBUS,  crash_handler);
   signal(SIGSEGV, crash_handler);  /* This is the most common crash */
   signal(SIGSYS,  crash_handler);
}

void crash_segv()
{
   int *p=0;
   *p=1;
}

int main(int argc, char *argv[])
{
   exec_name=argv[0];
   register_gdb();
   crash_segv();
   return 0;
}

Re: Just-in-time debugging on Linux

[Robin Rowe]

Michael,

>    signal(SIGSEGV, crash_handler);  /* This is the most common crash */

This is an interesting approach, but I want to trap unmodified programs.

Thanks,

Robin
---------------------------------------------------------------------------
www.OpenSourceProgrammers.org
www.LinuxMovies.org

Re: Just-in-time debugging on Linux

[phi]

Robin Rowe wrote:
> 
> Michael,
> 
> >    signal(SIGSEGV, crash_handler);  /* This is the most common crash */
> 
> This is an interesting approach, but I want to trap unmodified programs.
> 


Then wrap them up in a script 

rename prog xyz into xyz.ori  this doesn't modify the prog?

then implement the script xyz that does

xyz::
#! your shell
gdb xyz.ori $@

and have you gdbinit (or other ways) to catch the signal you want.

At xyz invocation we start gdb wich start xyz.ori wich will catch the signal
and let you see.


==================

If you really don't want to rename xyz.ori then have the script xyz earlier in
your PATH and make the script invoke the xyz from its original path

Phi

Re: Just-in-time debugging on Linux

[Tom Tromey]

>>>>> "phi" == phi  <phi@hpfrcu81.france.hp.com> writes:

phi> Then wrap them up in a script 
phi> rename prog xyz into xyz.ori  this doesn't modify the prog?
phi> then implement the script xyz that does

phi> xyz::
phi> #! your shell
phi> gdb xyz.ori $@

This doesn't really work.  One problem is that the inferior won't
start running automatically.  The other problem is that I/O
redirections get hosed (I think).

I do think this would be a useful feature for gdb.  I've wanted it for
a number of years now, but haven't had the time to implement it.

Incidentally your script is missing a `--args'.

Tom