Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
* [PATCH RFA] ending-run.exp
@ 2001-07-02 14:43 Michael Snyder
       [not found] ` <3B4A132E.AA2DE377@cygnus.com>
  0 siblings, 1 reply; 6+ messages in thread
From: Michael Snyder @ 2001-07-02 14:43 UTC (permalink / raw)
  To: gdb-patches

This script seems to expect that, if you step past the return from main, 
you will end up in some sort of "start" function.

Can anyone think of any reason why "Program exited normally" is not
a legitimate output to see after stepping past the return from main?
2001-07-02  Michael Snyder  <msnyder@redhat.com>

	* gdb.base/ending-run.exp: Accept "Program exited normally" as
	legitimate output from stepping out of main.

Index: ending-run.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/ending-run.exp,v
retrieving revision 1.6
diff -c -3 -p -r1.6 ending-run.exp
*** ending-run.exp	2001/05/23 19:04:13	1.6
--- ending-run.exp	2001/07/02 21:40:58
*************** if ![gdb_skip_stdio_test "Step to return
*** 140,145 ****
--- 140,146 ----
  
  set old_timeout $timeout
  set timeout 50
+ set program_exited 0
  send_gdb "next\n"
  gdb_expect {
      -re "33.*$gdb_prompt $" {
*************** gdb_expect {
*** 160,165 ****
--- 161,171 ----
  		# This is what happens on sparc64-elf ultra.
  		pass "step out of main"
  	    }
+ 	    -re ".*Program exited normally.*$gdb_prompt $" {
+ 		# This is what happens on Linux i86 (and I would expect others)
+ 		set program_exited 1
+ 		pass "step out of main"
+ 	    }
  	    -re ".*in .nope ().*$gdb_prompt $" {
  		# This is what happens on Solaris currently -sts 1999-08-25
  		pass "step out of main on Solaris"
*************** gdb_expect {
*** 185,190 ****
--- 191,201 ----
      -re ".*in.*\\\$START\\\$.*from.*dld.sl.*$gdb_prompt $"  {
          pass "step out of main 2"
      }
+     -re ".*Program exited normally.*$gdb_prompt $" {
+ 	# This is what happens on Linux i86 (and I would expect others)
+ 	set program_exited 1
+ 	pass "step out of main"
+     }
      -re ".*in.*currently asm.*$gdb_prompt $" { 
          pass "step out of main into assembler"
      }
*************** gdb_expect {
*** 196,236 ****
  }
  
  if {![target_info exists use_cygmon] || ![target_info use_cygmon]} {
!     send_gdb "n\n"
!     gdb_expect {
! 	-re "Program exited normally.*$gdb_prompt $" {
! 	    # If we actually have debug info for the start function,
! 	    # then we won't get the "Single-stepping until function
! 	    # exit" message.
! 	    pass "step to end of run 1"
! 	}
! 	-re ".*Single.*Program exited.*$gdb_prompt $" {
! 	    pass "step to end of run 1"
! 	}
! 	-re ".*Single.*in exit.*from.*dld.sl.*$gdb_prompt $" {
! 	    pass "step to end of run 2" 
! 	    gdb_test "c" ".*" "continue after exit"
! 	}
! 	timeout { fail "(timeout) step to end of run" }
      }
  
!   set timeout $old_timeout
!   
!   gdb_test "n" ".*The program is not being run.*" "don't step after run"
!   
!   set exec_output [remote_exec host "ls core"]
!   
!   
!   if [ regexp "core not found" $exec_output]  {
!     pass "No core dumped on quit"
!   } else {
!     if [ regexp "No such file or directory" $exec_output] {
!       pass "ls: core: No core dumped on quit"
      } else {
!       remote_exec build "rm -f core"
!       fail "Core dumped on quit"
      }
-   }
  }
  
  #remote_exec build "rm -f ${binfile}"
--- 207,254 ----
  }
  
  if {![target_info exists use_cygmon] || ![target_info use_cygmon]} {
!     global program_exited;
!     if {[eval expr $program_exited == 0]} {
! 	send_gdb "n\n"
! 	gdb_expect {
! 	    -re "Program exited normally.*$gdb_prompt $" {
! 		# If we actually have debug info for the start function,
! 		# then we won't get the "Single-stepping until function
! 		# exit" message.
! 		pass "step to end of run 1"
! 	    }
! 	    -re ".*Single.*Program exited.*$gdb_prompt $" {
! 		pass "step to end of run 1"
! 	    }
! 	    -re ".*Single.*in exit.*from.*dld.sl.*$gdb_prompt $" {
! 		pass "step to end of run 2" 
! 		gdb_test "c" ".*" "continue after exit"
! 	    }
! 	    -re ".*$gdb_prompt $" {
! 		fail "step to end of run"
! 	    }
! 	    timeout { 
! 		fail "(timeout) step to end of run" 
! 	    }
! 	}   
      }
+ 
+     set timeout $old_timeout
  
!     gdb_test "n" ".*The program is not being run.*" "don't step after run"
! 
!     set exec_output [remote_exec host "ls core"]
! 
!     if [ regexp "core not found" $exec_output]  {
! 	pass "No core dumped on quit"
      } else {
! 	if [ regexp "No such file or directory" $exec_output] {
! 	    pass "ls: core: No core dumped on quit"
! 	} else {
! 	    remote_exec build "rm -f core"
! 	    fail "Core dumped on quit"
! 	}
      }
  }
  
  #remote_exec build "rm -f ${binfile}"
From msnyder@cygnus.com Mon Jul 02 14:53:00 2001
From: Michael Snyder <msnyder@cygnus.com>
To: gdb-patches@sources.redhat.com
Subject: [PATCH] corefile.exp regexp fix
Date: Mon, 02 Jul 2001 14:53:00 -0000
Message-id: <3B40ED69.6C7FB4C7@cygnus.com>
X-SW-Source: 2001-07/msg00017.html
Content-length: 1140

 
2001-07-02  Michael Snyder  <msnyder@redhat.com>

	* gdb.base/corefile.exp: Quote the curly braces in regexp.

Index: corefile.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/corefile.exp,v
retrieving revision 1.3
diff -c -3 -p -r1.3 corefile.exp
*** corefile.exp	2001/03/06 08:21:50	1.3
--- corefile.exp	2001/07/02 21:51:40
*************** gdb_test "print coremaker_data" "\\\$$de
*** 189,195 ****
  gdb_test "print coremaker_bss" "\\\$$decimal = 10"
  gdb_test "print coremaker_ro" "\\\$$decimal = 201"
  
! gdb_test "print func2::coremaker_local" "\\\$$decimal = {0, 1, 2, 3, 4}"
  
  # Somehow we better test the ability to read the registers out of the core
  # file correctly.  I don't think the other tests do this.
--- 189,195 ----
  gdb_test "print coremaker_bss" "\\\$$decimal = 10"
  gdb_test "print coremaker_ro" "\\\$$decimal = 201"
  
! gdb_test "print func2::coremaker_local" "\\\$$decimal = \\{0, 1, 2, 3, 4\\}"
  
  # Somehow we better test the ability to read the registers out of the core
  # file correctly.  I don't think the other tests do this.
From kevinb@cygnus.com Mon Jul 02 14:53:00 2001
From: Kevin Buettner <kevinb@cygnus.com>
To: fnf@redhat.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] Fix auto-solib-add bug (patch revised 7/1/2001)
Date: Mon, 02 Jul 2001 14:53:00 -0000
Message-id: <1010702215326.ZM24300@ocotillo.lan>
References: <200107012207.f61M73600827@gofish.ninemoons.com> <fnf@www.ninemoons.com>
X-SW-Source: 2001-07/msg00018.html
Content-length: 1226

On Jul 1,  3:07pm, Fred Fish wrote:

> Here is the latest patch, which should apply cleanly to the sourceware
> gdb sources as of today.  I also made a couple of other minor tweaks
> and cleanups.

Fred,

Your patch is approved except for the portions which move the
declaration of auto_solib_add from symfile.h to coff-solib.h, solib.h,
and somsolib.h.  I would prefer that you submit a separate patch for
this change.  (I spoke with Jim Blandy about them and he pointed out
that the declaration of auto_solib_add ought to stay in symfile.h so
long as the definition remains in symfile.c.)  In any event, I think
that moving the declaration of auto_solib_add qualifies as a cleanup
activity and isn't necessary for the rest of your patch to work.

One of the problems with approving this patch is that it touches a lot
of files for which I am not a maintainer.  I have spoken with Michael
Snyder regarding your changes to infcmd.c and infrun.c and he has no
problem with them.  I believe that the rest of the changes are
"obvious" once the rest of your changes are accepted, but just the
same it probably wouldn't hurt to wait a couple of days before
checking them in just in case some other maintainer has issues...

Kevin


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH RFA] ending-run.exp
       [not found] ` <3B4A132E.AA2DE377@cygnus.com>
@ 2001-07-09 13:47   ` Andrew Cagney
  2001-07-12 17:09   ` Michael Snyder
  1 sibling, 0 replies; 6+ messages in thread
From: Andrew Cagney @ 2001-07-09 13:47 UTC (permalink / raw)
  To: Fernando Nasser; +Cc: Michael Snyder, gdb-patches

> Well, main() is normally called from inside crt0  from some sort of "start" function.  When you step past the return from main you should return to the frame above main, i.e., to after the call to main inside the "start" function in crt0.
> 
> If it is not stopping there it is either a bug or some new situation that did not use to exist.
> 
> I don't think we should accept "Program exited normally" until we understand a little bit more of what is actually happening when we get this message.


Ulgh, that problem.  At present GDB's behavour is poorly define 

for when it comes to what to do with the bottom (outer most) stack 
frames. For instance backtrace code sometimes includes _start but 
sometimes does not.

There needs to be a consistent story as to what is reasonable.  With 
that in mind I can image a GDB that does something like:

	(gdb)
	4: return 0;
	(gdb) list
	main ()
	{
	  printf ("Hello World\n");
	  return 0;
	}
	(gdb) step
	File has no symbols, single stepping until exit
	Program exited normally.
	(gdb)

	Andrew






^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH RFA] ending-run.exp
       [not found] ` <3B4A132E.AA2DE377@cygnus.com>
  2001-07-09 13:47   ` Andrew Cagney
@ 2001-07-12 17:09   ` Michael Snyder
  2001-07-13 12:47     ` Fernando Nasser
  1 sibling, 1 reply; 6+ messages in thread
From: Michael Snyder @ 2001-07-12 17:09 UTC (permalink / raw)
  To: Fernando Nasser; +Cc: Michael Snyder, gdb-patches

Fernando Nasser wrote:
> 
> Michael Snyder wrote:
> >
> > This script seems to expect that, if you step past the return from main,
> > you will end up in some sort of "start" function.
> >
> > Can anyone think of any reason why "Program exited normally" is not
> > a legitimate output to see after stepping past the return from main?
> >
> 
> Sorry for the delay, I was on vacation.
> 
> Well, main() is normally called from inside crt0  from some sort of "start" function.  When you step past the return from main you should return to the frame above main, i.e., to after the call to main inside the "start" function in crt0.
> 
> If it is not stopping there it is either a bug or some new situation that did not use to exist.
> 
> I don't think we should accept "Program exited normally" until we understand a little bit more of what is actually happening when we get this message.

The thing is, this is testing something outside of GDB.
GDB doesn't have any control over how main() is called.
I don't think "stopping in the caller of main" should be
part of GDB's expected behavior set.  Besides, the test
fails on native linux, so _something_ is obviously wrong
with it...


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH RFA] ending-run.exp
  2001-07-12 17:09   ` Michael Snyder
@ 2001-07-13 12:47     ` Fernando Nasser
  2001-07-25 15:42       ` Michael Snyder
  0 siblings, 1 reply; 6+ messages in thread
From: Fernando Nasser @ 2001-07-13 12:47 UTC (permalink / raw)
  To: Michael Snyder; +Cc: Michael Snyder, gdb-patches

Michael Snyder wrote:
> 
> Fernando Nasser wrote:
> >
> > Michael Snyder wrote:
> > >
> > > This script seems to expect that, if you step past the return from main,
> > > you will end up in some sort of "start" function.
> > >
> > > Can anyone think of any reason why "Program exited normally" is not
> > > a legitimate output to see after stepping past the return from main?
> > >
> >
> > Sorry for the delay, I was on vacation.
> >
> > Well, main() is normally called from inside crt0  from some sort of "start" function.  When you step past the return from main you should return to the frame above main, i.e., to after the call to main inside the "start" function in crt0.
> >
> > If it is not stopping there it is either a bug or some new situation that did not use to exist.
> >
> > I don't think we should accept "Program exited normally" until we understand a little bit more of what is actually happening when we get this message.
> 
> The thing is, this is testing something outside of GDB.
> GDB doesn't have any control over how main() is called.
> I don't think "stopping in the caller of main" should be
> part of GDB's expected behavior set.  Besides, the test
> fails on native linux, so _something_ is obviously wrong
> with it...

Humm...  we already test stopping on the caller in other places, so I am inclined to agree with you that this does not matter much here.

Nobody else has presented another reason not to do this, so lets go ahead and check your changes in.

-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH RFA] ending-run.exp
  2001-07-13 12:47     ` Fernando Nasser
@ 2001-07-25 15:42       ` Michael Snyder
  0 siblings, 0 replies; 6+ messages in thread
From: Michael Snyder @ 2001-07-25 15:42 UTC (permalink / raw)
  To: Fernando Nasser; +Cc: Michael Snyder, gdb-patches

Fernando Nasser wrote:
> 
> Michael Snyder wrote:
> >
> > Fernando Nasser wrote:
> > >
> > > Michael Snyder wrote:
> > > >
> > > > This script seems to expect that, if you step past the return from main,
> > > > you will end up in some sort of "start" function.
> > > >
> > > > Can anyone think of any reason why "Program exited normally" is not
> > > > a legitimate output to see after stepping past the return from main?
> > > >
> > >
> > > Sorry for the delay, I was on vacation.
> > >
> > > Well, main() is normally called from inside crt0  from some sort of "start" function.  When you step past the return from main you should return to the frame above main, i.e., to after the call to main inside the "start" function in crt0.
> > >
> > > If it is not stopping there it is either a bug or some new situation that did not use to exist.
> > >
> > > I don't think we should accept "Program exited normally" until we understand a little bit more of what is actually happening when we get this message.
> >
> > The thing is, this is testing something outside of GDB.
> > GDB doesn't have any control over how main() is called.
> > I don't think "stopping in the caller of main" should be
> > part of GDB's expected behavior set.  Besides, the test
> > fails on native linux, so _something_ is obviously wrong
> > with it...
> 
> Humm...  we already test stopping on the caller in other places, so I am inclined to agree with you that this does not matter much here.
> 
> Nobody else has presented another reason not to do this, so lets go ahead and check your changes in.

Committed.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH RFA] ending-run.exp
@ 2001-07-02 15:18 Michael Elizabeth Chastain
  0 siblings, 0 replies; 6+ messages in thread
From: Michael Elizabeth Chastain @ 2001-07-02 15:18 UTC (permalink / raw)
  To: gdb-patches, msnyder

Michael Snyder asks:
> Can anyone think of any reason why "Program exited normally" is not
> a legitimate output to see after stepping past the return from main?

I've seen this happen in my test runs, and I've thought about it,
and I have no objection to the gdb behavior "Program exited normally".

MichaelC


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2001-07-25 15:42 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-07-02 14:43 [PATCH RFA] ending-run.exp Michael Snyder
     [not found] ` <3B4A132E.AA2DE377@cygnus.com>
2001-07-09 13:47   ` Andrew Cagney
2001-07-12 17:09   ` Michael Snyder
2001-07-13 12:47     ` Fernando Nasser
2001-07-25 15:42       ` Michael Snyder
2001-07-02 15:18 Michael Elizabeth Chastain

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox