Re: "break main; run" test

Re: "break main; run" test

[Michael Elizabeth Chastain]

> When people refer to the test of starting gdb on a program, setting a
> breakpoint on "main", and running to that point, is there a particular
> standard test program in mind? "Hello world"? The GDB binary itself?

You are right; it is ambiguous.

To me, it usually means "the gdb binary itself", since the gdb binary is
a large program and it's guaranteed to exist.  Sometimes it means
"hello world", and sometimes it means "any random program".

Michael C

Re: "break main; run" test

[Eli Zaretskii]

> Date: Thu,  8 Jan 2004 22:16:21 -0500 (EST)
> From: mec.gnu@mindspring.com (Michael Elizabeth Chastain)
> 
> > When people refer to the test of starting gdb on a program, setting a
> > breakpoint on "main", and running to that point, is there a particular
> > standard test program in mind? "Hello world"? The GDB binary itself?
> 
> You are right; it is ambiguous.

Seconded.  Perhaps we should replace that language with something less
ambiguous.

> To me, it usually means "the gdb binary itself", since the gdb binary is
> a large program and it's guaranteed to exist.  Sometimes it means
> "hello world", and sometimes it means "any random program".

It should IMHO preferably be some non-trivially large program, as some
subtle problems don't get expiosed unless GDB needs to deal with
complex debug info structures.  It certainly cannot be a program with
no debug info, since then it's not guaranteed that GDB will know where
to find the symbol `main'.

Re: "break main; run" test

[Andrew Cagney]

FYI, the release process recommends the following smoke test:

>  15.7.2 Sanity check the tar ball
> 
> Pick a popular machine (Solaris/PPC?) and try the build on that.
> 
>  
> 
> $  bunzip2 < gdb-5.2.tar.bz2 | tar xpf -
> $  cd gdb-5.2
> $  ./configure 
> $  make
> ...
> $  ./gdb/gdb ./gdb/gdb
> GNU gdb 5.2
> ...
> (gdb)  b main
> Breakpoint 1 at 0x80732bc: file main.c, line 734.
> (gdb)  run
> Starting program: /tmp/gdb-5.2/gdb/gdb 
> 
> Breakpoint 1, main (argc=1, argv=0xbffff8b4) at main.c:734
> 734       catch_errors (captured_main, &args, "", RETURN_MASK_ALL);
> (gdb)  print args
> $1 = {argc = 136426532, argv = 0x821b7f0}
> (gdb)

Should note that I intend tweaking the doco so that "backtrace", instead 
of "print args" is used.  I suspect that "backtrace" is GDB's second 
most popular user command (the first is "run") :-)

Andrew


>> Date: Thu,  8 Jan 2004 22:16:21 -0500 (EST)
>> From: mec.gnu@mindspring.com (Michael Elizabeth Chastain)
>> 
> 
>> > When people refer to the test of starting gdb on a program, setting a
>> > breakpoint on "main", and running to that point, is there a particular
>> > standard test program in mind? "Hello world"? The GDB binary itself?
> 
>> 
>> You are right; it is ambiguous.
> 
> 
> Seconded.  Perhaps we should replace that language with something less
> ambiguous.
> 
> 
>> To me, it usually means "the gdb binary itself", since the gdb binary is
>> a large program and it's guaranteed to exist.  Sometimes it means
>> "hello world", and sometimes it means "any random program".
> 
> 
> It should IMHO preferably be some non-trivially large program, as some
> subtle problems don't get expiosed unless GDB needs to deal with
> complex debug info structures.  It certainly cannot be a program with
> no debug info, since then it's not guaranteed that GDB will know where
> to find the symbol `main'.
> 

Re: "break main; run" test

[Eli Zaretskii]

> Date: Fri, 09 Jan 2004 11:56:06 -0500
> From: Andrew Cagney <cagney@gnu.org>
> 
> Should note that I intend tweaking the doco so that "backtrace", instead 
> of "print args" is used.  I suspect that "backtrace" is GDB's second 
> most popular user command

How about doing both bt and p?  I think they are both very central to
any debugging, no matter what user polls (if we have them) say.

Re: "break main; run" test

[Andrew Cagney]

>> Date: Fri, 09 Jan 2004 11:56:06 -0500
>> From: Andrew Cagney <cagney@gnu.org>
>> 
>> Should note that I intend tweaking the doco so that "backtrace", instead 
>> of "print args" is used.  I suspect that "backtrace" is GDB's second 
>> most popular user command
> 
> 
> How about doing both bt and p?  I think they are both very central to
> any debugging, no matter what user polls (if we have them) say.

M'kay, and perhaps break in something other than main - a backtrace when 
in main isn't very interesting :-)

Andrew

Re: "break main; run" test

[Michael Elizabeth Chastain]

> I challenge you to find a Solaris/PPC machine, yet alone one that GDB 
> works on :-)

Ha!  I override operator/ !

  bool gnu_triple operator/ (os_t os, cpu_t cpu)
  {
    // normal people use '&&' but i am special
    return os == this->os_ || cpu == this->cpu_ ;
  }

Re: "break main; run" test

[Michael Elizabeth Chastain]

doco> Pick a popular machine (Solaris/PPC?) and try the build on that.

BTW, on an unrelated minor point, I think it's GNU policy to use Free
Software whenever it's available.  So the example should be Linux or
FreeBSD or Hurd, not Solaris.

But Hurd will ship before we pick all the Solaris examples out.  :)

Michael C

Re: "break main; run" test

[Andrew Cagney]

> doco> Pick a popular machine (Solaris/PPC?) and try the build on that.
> 
> BTW, on an unrelated minor point, I think it's GNU policy to use Free
> Software whenever it's available.  So the example should be Linux or
> FreeBSD or Hurd, not Solaris.
> 
> But Hurd will ship before we pick all the Solaris examples out.  :)

I challenge you to find a Solaris/PPC machine, yet alone one that GDB 
works on :-)

Andrew

"break main; run" test

[Nathan J. Williams]

When people refer to the test of starting gdb on a program, setting a
breakpoint on "main", and running to that point, is there a particular
standard test program in mind? "Hello world"? The GDB binary itself?
Or just whatever happens to be lying around and compiled with debug
information (or even not with debug information)?

        - Nathan