Re: Fix committed for mi-syn-frames fails (was: Re: PATCH RFA: Fix MI stack frame output for synthetic frames)

Re: Fix committed for mi-syn-frames fails (was: Re: PATCH RFA: Fix MI stack frame output for synthetic frames)

[Michael Elizabeth Chastain]

> I've commited this.  mi-syn-frames.exp passes with gcc 3.2 and
> gcc 2.96 with stabs and DWARF 2.

It's all PASS all the time in my test bed now.  Good job.

Michael C

Re: PATCH: Fix MI stack frame output for synthetic frames

[Andrew Cagney]

> Hi all,
> 
> We've recently found a little problem with the current gdb in MI
> mode with synthesized frames on the stack (a gdb call dummy or a
> stack handler).  Until last month, print_frame_info_base() would
> print information about these frames to stdout via printf_unfiltered;
> the reply to -stack-list-frames would have a FRAME tuple for level
> 0, skip level 1 (assuming that's the synthesized frame), then a
> FRAME tuple for level 2 and so on.

It should be possible to test the "<function called from gdb>" case. 
All the more main-stream architectures now use dummy-frames so any one 
of them can be used for the test.

Can you do that?

Andrew


> With Jeff's change a month ago -
> http://sources.redhat.com/ml/gdb-patches/2002-09/msg00777.html
> 
> a LEVEL field is being output, but no other parts of the FRAME tuple.
> (the FRAME tuple is a named tuple ("frame") with fields ADDR, FUNC,
> ARGS, and LINE if those are all available).  The output now looks like
> 
> ~"<signal handler called>\n"
> stack=[frame={level="0",addr=...,func=...},level="1",frame={level="2",addr=...},...]
> 
> I've attached a patch to emit a TUPLE with a func name of "<signal
> handler called>" or "<function called from gdb>" and to include
> the ADDR field.  I also took the opportunity to remove some code that'd
> been #if 0'ed since the original import on to sources.redhat.com in 1999.
> It's probably easier to read the new code than the patch -- I'll list the
> new code below and attach the patch.
> 
> 2002-11-08  Jason Molenda  (jmolenda@apple.com)
>       
>         * stack.c (print_frame_info_base): Emit full FRAME tuple for
>         gdb call dummy and signal handler synthetic stack frames; send
>         stack frame name through UI instead of stdout.
> 
> Jason

Re: PATCH RFA: Fix MI stack frame output for synthetic frames

[Jason Molenda]

[-- Attachment #1: Type: text/plain, Size: 2129 bytes --]

On Fri, Nov 08, 2002 at 05:38:38PM -0500, Andrew Cagney wrote:

> It should be possible to test the "<function called from gdb>" case. 
> All the more main-stream architectures now use dummy-frames so any one 
> of them can be used for the test.
> 
> Can you do that?


OK, how's this look?  I don't care about the names of the files or
anything like that.

[gdb/ChangeLog]
2002-11-09  Jason Molenda  (jason-cl@molenda.com)

        * stack.c (print_frame_info_base): Output complete FRAME tuple
        for synthesized frames.

[gdb/testsuite/ChangeLog]
2002-11-09  Jason Molenda  (jason-cl@molenda.com)

        * gdb.mi/mi-syn-frame.exp: New tests for synthetic frames in
        stack backtraces.
        * gdb.mi/inferior-mischief.c: Part of same.

It's probably not necessary, but I'll include the final plain text
of print_frame_info_base that I settled on for this patch so no
one needs to do unidiff decompression in their heads.  This change
introduces no new testsuite regressions.


  struct cleanup *uiout_cleanup;

  if (frame_in_dummy (fi) || fi->signal_handler_caller)
    {
      annotate_frame_begin (level == -1 ? 0 : level, fi->pc);
      uiout_cleanup = make_cleanup_ui_out_tuple_begin_end (uiout, "frame");

      /* Do this regardless of SOURCE because we don't have any source
         to list for this frame.  */
      if (level >= 0)
        {
          ui_out_text (uiout, "#");
          ui_out_field_fmt_int (uiout, 2, ui_left, "level", level);
        }
      if (ui_out_is_mi_like_p (uiout))
        {
          annotate_frame_address ();
          ui_out_field_core_addr (uiout, "addr", fi->pc);
          annotate_frame_address_end ();
        }
      if (frame_in_dummy (fi))
        {
          annotate_function_call ();
          ui_out_field_string (uiout, "func", "<function called from gdb>");
	}
      else if (fi->signal_handler_caller)
        {
	  annotate_signal_handler_caller ();
          ui_out_field_string (uiout, "func", "<signal handler called>");
        }
      ui_out_text (uiout, "\n");
      annotate_frame_end ();

      do_cleanups (uiout_cleanup);
      return;
    }

[-- Attachment #2: pa.txt --]
[-- Type: text/plain, Size: 12031 bytes --]

[gdb/ChangeLog]
2002-11-09  Jason Molenda  (jason-cl@molenda.com)

	* stack.c (print_frame_info_base): Output complete FRAME tuple
	for synthesized frames.

[gdb/testsuite/ChangeLog]
2002-11-09  Jason Molenda  (jason-cl@molenda.com)

	* gdb.mi/mi-syn-frame.exp: New tests for synthetic frames in
	stack backtraces.
	* gdb.mi/inferior-mischief.c: Part of same.


Index: stack.c
===================================================================
RCS file: /cvs/src/src/gdb/stack.c,v
retrieving revision 1.46
diff -u -p -r1.46 stack.c
--- stack.c	3 Oct 2002 22:34:58 -0000	1.46
+++ stack.c	9 Nov 2002 08:38:34 -0000
@@ -332,28 +332,12 @@ print_frame_info_base (struct frame_info
   struct symtab_and_line sal;
   int source_print;
   int location_print;
+  struct cleanup *uiout_cleanup;
 
-#if 0
-  char buf[MAX_REGISTER_RAW_SIZE];
-  CORE_ADDR sp;
-
-  /* On the 68k, this spends too much time in m68k_find_saved_regs.  */
-
-  /* Get the value of SP_REGNUM relative to the frame.  */
-  get_saved_register (buf, (int *) NULL, (CORE_ADDR *) NULL,
-		    FRAME_INFO_ID (fi), SP_REGNUM, (enum lval_type *) NULL);
-  sp = extract_address (buf, REGISTER_RAW_SIZE (SP_REGNUM));
-
-  /* This is not a perfect test, because if a function alloca's some
-     memory, puts some code there, and then jumps into it, then the test
-     will succeed even though there is no call dummy.  Probably best is
-     to check for a bp_call_dummy breakpoint.  */
-  if (PC_IN_CALL_DUMMY (fi->pc, sp, fi->frame))
-#else
-  if (frame_in_dummy (fi))
-#endif
+  if (frame_in_dummy (fi) || fi->signal_handler_caller)
     {
       annotate_frame_begin (level == -1 ? 0 : level, fi->pc);
+      uiout_cleanup = make_cleanup_ui_out_tuple_begin_end (uiout, "frame");
 
       /* Do this regardless of SOURCE because we don't have any source
          to list for this frame.  */
@@ -362,25 +346,26 @@ print_frame_info_base (struct frame_info
           ui_out_text (uiout, "#");
           ui_out_field_fmt_int (uiout, 2, ui_left, "level", level);
         }
-      annotate_function_call ();
-      printf_filtered ("<function called from gdb>\n");
-      annotate_frame_end ();
-      return;
-    }
-  if (fi->signal_handler_caller)
-    {
-      annotate_frame_begin (level == -1 ? 0 : level, fi->pc);
-
-      /* Do this regardless of SOURCE because we don't have any source
-         to list for this frame.  */
-      if (level >= 0)
+      if (ui_out_is_mi_like_p (uiout))
         {
-          ui_out_text (uiout, "#");
-          ui_out_field_fmt_int (uiout, 2, ui_left, "level", level);
+          annotate_frame_address ();
+          ui_out_field_core_addr (uiout, "addr", fi->pc);
+          annotate_frame_address_end ();
         }
-      annotate_signal_handler_caller ();
-      printf_filtered ("<signal handler called>\n");
+      if (frame_in_dummy (fi))
+        {
+          annotate_function_call ();
+          ui_out_field_string (uiout, "func", "<function called from gdb>");
+	}
+      else if (fi->signal_handler_caller)
+        {
+	  annotate_signal_handler_caller ();
+          ui_out_field_string (uiout, "func", "<signal handler called>");
+        }
+      ui_out_text (uiout, "\n");
       annotate_frame_end ();
+
+      do_cleanups (uiout_cleanup);
       return;
     }
 
Index: testsuite/gdb.mi/inferior-mischief.c
===================================================================
RCS file: testsuite/gdb.mi/inferior-mischief.c
diff -N testsuite/gdb.mi/inferior-mischief.c
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ testsuite/gdb.mi/inferior-mischief.c	9 Nov 2002 08:38:44 -0000
@@ -0,0 +1,61 @@
+#include <signal.h>
+#include <unistd.h>
+#include <stdlib.h>
+
+void foo (void);
+void bar (void);
+
+void subroutine (int);
+void handler (int);
+void have_a_very_merry_interrupt (void);
+
+main ()
+{
+  puts ("Starting up");
+
+  foo ();   /* Put a breakpoint on foo() and call it to see a dummy frame */
+
+
+  have_a_very_merry_interrupt ();
+
+  puts ("Shutting down");
+}
+
+void
+foo (void)
+{
+  puts ("hi in foo");
+}
+
+void 
+bar (void)
+{
+  char *nuller = 0;
+
+  puts ("hi in bar");
+
+  *nuller = 'a';      /* try to cause a segfault */
+}
+
+void
+handler (int sig)
+{
+  subroutine (sig);
+}
+
+void
+subroutine (int in)
+{
+  while (in < 100)
+    in++;
+}
+
+void
+have_a_very_merry_interrupt (void)
+{
+  puts ("Waiting to get a signal");
+  signal (SIGALRM, handler);
+  alarm (1);
+  sleep (2);  /* We'll receive that signal while sleeping */
+}
+
Index: testsuite/gdb.mi/mi-syn-frame.exp
===================================================================
RCS file: testsuite/gdb.mi/mi-syn-frame.exp
diff -N testsuite/gdb.mi/mi-syn-frame.exp
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ mi-syn-frame.exp	9 Nov 2002 08:41:01 -0000
@@ -0,0 +1,106 @@
+# Copyright 2002 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+# 
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+# 
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  
+
+# Please email any bugs, comments, and/or additions to this file to:
+# bug-gdb@prep.ai.mit.edu
+
+# Test MI output with synthetic frames on the stack (call dummies,
+# signal handlers).
+
+load_lib mi-support.exp
+set MIFLAGS "-i=mi"
+
+set testfile "inferior-mischief"
+set srcfile ${testfile}.c
+set binfile ${objdir}/${subdir}/${testfile}
+if  { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug additional_flags=-DFAKEARGV}] != "" } {
+     gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail."
+}
+
+set my_mi_gdb_prompt "\\(gdb\\)\[ \]*\[\r\n\]*"
+
+mi_gdb_exit
+mi_gdb_start
+mi_delete_breakpoints
+mi_gdb_reinitialize_dir $srcdir/$subdir
+mi_gdb_load ${binfile}
+mi_run_to_main
+
+mi_gdb_test "400-break-insert foo" "400\\^done,bkpt=\{number=\"2\",type=\"breakpoint\",disp=\"keep\",enabled=\"y\",addr=\"$hex\",func=\"foo\",file=\".*inferior-mischief.c\",line=\"$decimal\",times=\"0\"\}"
+
+
+#
+# Call foo() by hand, where we'll hit a breakpoint.
+#
+
+mi_gdb_test "401-data-evaluate-expression foo()" "\\&\"The program being debugged stopped while in a function called from GDB.\\\\n\"\[\r\n\]+\\&\"When the function \\(foo\\) is done executing, GDB will silently\\\\n\"\[\r\n\]+\\&\"stop \\(instead of continuing to evaluate the expression containing\\\\n\"\[\r\n\]+\\&\"the function call\\).\\\\n\"\[\r\n\]+401\\^error,msg=\"The program being debugged stopped while in a function called from GDB.*\"" "call inferior's function with a breakpoint set in it"
+
+mi_gdb_test "402-stack-list-frames" "402\\^done,reason=\"breakpoint-hit\",bkptno=\"2\",thread-id=\"$decimal\",frame=\{addr=\"$hex\",func=\"foo\",args=\\\[\\\],file=\".*inferior-mischief.c\",line=\"$decimal\"\},stack=\\\[frame=\{level=\"0\",addr=\"$hex\",func=\"foo\",file=\".*inferior-mischief.c\",line=\"$decimal\"\},frame=\{level=\"1\",addr=\"$hex\",func=\"<function called from gdb>\"\},frame=\{level=\"2\",addr=\"$hex\",func=\"main\",file=\".*inferior-mischief.c\",line=\"$decimal\"\}.*\\\]" "backtrace from inferior function stopped at bp, showing gdb dummy frame"
+
+#
+# Continue back to main()
+#
+
+send_gdb "403-exec-continue\n"
+gdb_expect {
+  -re "403\\^running\[\r\n\]+${my_mi_gdb_prompt}hi in foo\[\r\n\]+403\\\*stopped\[\r\n\]+${my_mi_gdb_prompt}$" {
+    pass "403-exec-continue"
+  }
+  timeout {
+    fail "403-exec-continue"
+  }
+}
+
+mi_gdb_test "404-stack-list-frames 0 0" "404\\^done,stack=\\\[frame=\{level=\"0\",addr=\"$hex\",func=\"main\",file=\".*inferior-mischief.c\",line=\"$decimal\"\}.*\\\]"
+
+
+#
+# Call have_a_very_merry_interrupt() which will eventually raise a signal
+# that's caught by handler() which calls subroutine().
+
+mi_gdb_test "405-break-insert subroutine" "405\\^done,bkpt=\{number=\"3\",type=\"breakpoint\",disp=\"keep\",enabled=\"y\",addr=\"$hex\",func=\"subroutine\",file=\".*inferior-mischief.c\",line=\"$decimal\",times=\"0\"\}"
+
+mi_gdb_test "406-data-evaluate-expression have_a_very_merry_interrupt()" "Waiting to get a signal\[\r\n\]+\\&\"The program being debugged stopped while in a function called from GDB.\\\\n\"\[\r\n\]+\\&\"When the function \\(have_a_very_merry_interrupt\\) is done executing, GDB will silently\\\\n\"\[\r\n\]+\\&\"stop \\(instead of continuing to evaluate the expression containing\\\\n\"\[\r\n\]+\\&\"the function call\\).\\\\n\"\[\r\n\]+406\\^error,msg=\"The program being debugged stopped while in a function called from GDB.\\\\nWhen the function \\(have_a_very_merry_interrupt\\) is done executing, GDB will silently\\\\nstop \\(instead of continuing to evaluate the expression containing\\\\nthe function call\\).\""
+
+# We should have both a signal handler and a call dummy frame
+# in this next output.
+
+mi_gdb_test "407-stack-list-frames" "407\\^done,reason=\"breakpoint-hit\",bkptno=\"3\",thread-id=\"$decimal\",frame=\{addr=\"$hex\",func=\"subroutine\",args=\\\[\{name=\"in\",value=\"$decimal\"\}\\\],file=\".*inferior-mischief.c\",line=\"$decimal\"\},stack=\\\[frame=\{level=\"0\",addr=\"$hex\",func=\"subroutine\",file=\".*inferior-mischief.c\",line=\"$decimal\"\},frame=\{level=\"1\",addr=\"$hex\",func=\"handler\",file=\".*inferior-mischief.c\",line=\"$decimal\"\},frame=\{level=\"2\",addr=\"$hex\",func=\"<signal handler called>\"\},.*frame=\{level=\"$decimal\",addr=\"$hex\",func=\"have_a_very_merry_interrupt\",file=\".*inferior-mischief.c\",line=\"$decimal\"\},frame=\{level=\"$decimal\",addr=\"$hex\",func=\"<function called from gdb>\"\},frame=\{level=\"$decimal\",addr=\"$hex\",func=\"main\",file=\".*inferior-mischief.c\",line=\"$decimal\"\}.*\\\]"
+
+
+send_gdb "408-exec-continue\n"
+gdb_expect {
+  -re "408\\^running\[\r\n\]+${my_mi_gdb_prompt}408\\\*stopped\[\r\n\]+${my_mi_gdb_prompt}$" {
+    pass "408-exec-continue"
+  }
+  timeout {
+    fail "408-exec-continue"
+  }
+}
+
+mi_gdb_test "409-stack-list-frames 0 0" "409\\^done,stack=\\\[frame=\{level=\"0\",addr=\"$hex\",func=\"main\",file=\".*inferior-mischief.c\",line=\"$decimal\"\}.*\\\]"
+
+#
+# Call bar() by hand, which should get an exception while running.
+# 
+
+mi_gdb_test "410-data-evaluate-expression bar()" "hi in bar\[\r\n\]+\\&\"The program being debugged was signaled while in a function called from GDB.\\\\n\"\[\r\n\]+\\&\"GDB remains in the frame where the signal was received.\\\\n\"\[\r\n\]+\\&\"To change this behavior use \\\\\"set unwindonsignal on\\\\\"\\\\n\"\[\r\n\]+\\&\"Evaluation of the expression containing the function \\(bar\\) will be abandoned.\\\\n\"\[\r\n\]+410\\^error,msg=\"The program being debugged was signaled while in a function called from GDB.\\\\nGDB remains in the frame where the signal was received.\\\\nTo change this behavior use \\\\\"set unwindonsignal on\\\\\"\\\\nEvaluation of the expression containing the function \\(bar\\) will be abandoned.\"" "call inferior function which raises exception"
+
+mi_gdb_test "411-stack-list-frames" "411\\^done,reason=\"signal-received\",signal-name=\".*\",signal-meaning=\".*\",thread-id=\"$decimal\",frame=\{addr=\"$hex\",func=\"bar\",args=\\\[\\\],file=\".*inferior-mischief.c\",line=\"$decimal\"\},stack=\\\[frame=\{level=\"0\",addr=\"$hex\",func=\"bar\",file=\".*inferior-mischief.c\",line=\"$decimal\"},frame=\{level=\"1\",addr=\"$hex\",func=\"<function called from gdb>\"\},frame=\{level=\"2\",addr=\"$hex\",func=\"main\",file=\".*inferior-mischief.c\",line=\"$decimal\"}.*\\\]" "backtrace from inferior function at exception"
+
+mi_gdb_exit
+
+return 0

Re: PATCH RFA: Fix MI stack frame output for synthetic frames

[Andrew Cagney]

> [gdb/ChangeLog]
> 2002-11-09  Jason Molenda  (jason-cl@molenda.com)
> 
>         * stack.c (print_frame_info_base): Output complete FRAME tuple
>         for synthesized frames.
> 
> [gdb/testsuite/ChangeLog]
> 2002-11-09  Jason Molenda  (jason-cl@molenda.com)
> 
>         * gdb.mi/mi-syn-frame.exp: New tests for synthetic frames in
>         stack backtraces.
>         * gdb.mi/inferior-mischief.c: Part of same.
> 
I've (finally ...) tested it and checked it in.  (renamed 
inferior-mischief.c to mi-syn-frame.c though - booring).

Passes fine on x86.  I suspect other targets won't be so lucky.

Andrew

Re: PATCH RFA: Fix MI stack frame output for synthetic frames

[David Carlton]

On Sun, 02 Feb 2003 00:52:24 -0500, Andrew Cagney <ac131313@redhat.com> said:
>> [gdb/ChangeLog]
>> 2002-11-09  Jason Molenda  (jason-cl@molenda.com)
>> * stack.c (print_frame_info_base): Output complete FRAME tuple

>> for synthesized frames.
>> [gdb/testsuite/ChangeLog]

>> 2002-11-09  Jason Molenda  (jason-cl@molenda.com)
>> * gdb.mi/mi-syn-frame.exp: New tests for synthetic frames in

>> stack backtraces.
>> * gdb.mi/inferior-mischief.c: Part of same.
>> 

> I've (finally ...) tested it and checked it in.  (renamed
> inferior-mischief.c to mi-syn-frame.c though - booring).

> Passes fine on x86.  I suspect other targets won't be so lucky.

On i686-pc-linux-gnu/GCC3.1/DWARF2, I get the following:

Running ./gdb.mi/mi-syn-frame.exp ...
PASS: gdb.mi/mi-syn-frame.exp: breakpoint at main
PASS: gdb.mi/mi-syn-frame.exp: mi runto main
PASS: gdb.mi/mi-syn-frame.exp: 400-break-insert foo
PASS: gdb.mi/mi-syn-frame.exp: call inferior's function with a breakpoint set in it
PASS: gdb.mi/mi-syn-frame.exp: backtrace from inferior function stopped at bp, showing gdb dummy frame
PASS: gdb.mi/mi-syn-frame.exp: 403-exec-continue
PASS: gdb.mi/mi-syn-frame.exp: 404-stack-list-frames 0 0
PASS: gdb.mi/mi-syn-frame.exp: 405-break-insert subroutine
PASS: gdb.mi/mi-syn-frame.exp: 406-data-evaluate-expression have_a_very_merry_interrupt()
PASS: gdb.mi/mi-syn-frame.exp: 407-stack-list-frames
FAIL: gdb.mi/mi-syn-frame.exp: 408-exec-continue
FAIL: gdb.mi/mi-syn-frame.exp: 409-stack-list-frames 0 0
FAIL: gdb.mi/mi-syn-frame.exp: call inferior function which raises exception
FAIL: gdb.mi/mi-syn-frame.exp: backtrace from inferior function at exception

I haven't investigated the failures at all.

David Carlton
carlton@math.stanford.edu

Re: PATCH RFA: Fix MI stack frame output for synthetic frames

[Jason Molenda]

On Mon, Feb 03, 2003 at 10:15:20AM -0800, David Carlton wrote:

> 
> On i686-pc-linux-gnu/GCC3.1/DWARF2, I get the following:
> 

> PASS: gdb.mi/mi-syn-frame.exp: 407-stack-list-frames
> FAIL: gdb.mi/mi-syn-frame.exp: 408-exec-continue
> FAIL: gdb.mi/mi-syn-frame.exp: 409-stack-list-frames 0 0
> FAIL: gdb.mi/mi-syn-frame.exp: call inferior function which raises exception
> FAIL: gdb.mi/mi-syn-frame.exp: backtrace from inferior function at exception

I'll look at these late tonight unless someone else does it first.

J

Re: PATCH RFA: Fix MI stack frame output for synthetic frames

[Daniel Jacobowitz]

On Mon, Feb 03, 2003 at 10:27:48AM -0800, Jason Molenda wrote:
> On Mon, Feb 03, 2003 at 10:15:20AM -0800, David Carlton wrote:
> 
> > 
> > On i686-pc-linux-gnu/GCC3.1/DWARF2, I get the following:
> > 
> 
> > PASS: gdb.mi/mi-syn-frame.exp: 407-stack-list-frames
> > FAIL: gdb.mi/mi-syn-frame.exp: 408-exec-continue
> > FAIL: gdb.mi/mi-syn-frame.exp: 409-stack-list-frames 0 0
> > FAIL: gdb.mi/mi-syn-frame.exp: call inferior function which raises exception
> > FAIL: gdb.mi/mi-syn-frame.exp: backtrace from inferior function at exception
> 
> I'll look at these late tonight unless someone else does it first.

The exec-continue failure seems to be a bad regular expression - it's
expecting "*stopped[\r\n]+", not any of the things which follow
*stopped.  I'm not sure without looking at te test whether
stack-list-frames is a legitimate failure or not; it's reporting a
different function than expected.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: PATCH RFA: Fix MI stack frame output for synthetic frames

[Jason Molenda]

On Mon, Feb 03, 2003 at 01:34:41PM -0500, Daniel Jacobowitz wrote:
> On Mon, Feb 03, 2003 at 10:27:48AM -0800, Jason Molenda wrote:
> > On Mon, Feb 03, 2003 at 10:15:20AM -0800, David Carlton wrote:
> > 
> > > 
> > > On i686-pc-linux-gnu/GCC3.1/DWARF2, I get the following:
> > > 
> > 
> > > PASS: gdb.mi/mi-syn-frame.exp: 407-stack-list-frames
> > > FAIL: gdb.mi/mi-syn-frame.exp: 408-exec-continue

> The exec-continue failure seems to be a bad regular expression - it's
> expecting "*stopped[\r\n]+", not any of the things which follow
> *stopped.  

The problem is that a breakpoint on this function:

void
subroutine (int in)
{
  while (in < 100)
    in++;
}

will be triggered each time in the loop.  e.g.

[jason@little-green-moose gdb.mi]$ ../../gdb -q ./mi-syn-frame
(gdb) b main
Breakpoint 1 at 0x8048408: file ../../../src/gdb/testsuite/gdb.mi/mi-syn-frame.c, line 14.
(gdb) run
Starting program: /home/jason/sware/gdb/b/gdb/testsuite/gdb.mi/mi-syn-frame

Breakpoint 1, main () at ../../../src/gdb/testsuite/gdb.mi/mi-syn-frame.c:14
14        puts ("Starting up");
(gdb) b subroutine
Breakpoint 2 at 0x8048530: file ../../../src/gdb/testsuite/gdb.mi/mi-syn-frame.c, line 49.
(gdb) call subroutine(5)

Breakpoint 2, subroutine (in=5)
    at ../../../src/gdb/testsuite/gdb.mi/mi-syn-frame.c:49
49        while (in < 100)
The program being debugged stopped while in a function called from GDB.
When the function (subroutine) is done executing, GDB will silently
stop (instead of continuing to evaluate the expression containing
the function call).
(gdb) cont
Continuing.

Breakpoint 2, subroutine (in=6)
    at ../../../src/gdb/testsuite/gdb.mi/mi-syn-frame.c:49
49        while (in < 100)
(gdb) cont
Continuing.
[etc]

It's failing for both stabs and for DWARF with gcc 3.2 (the one
included in RH 8).  In both cases, gdb is putting the breakpoint
on the cmpl at subroutine+4 so it's hit each time we iterate the loop:

(gdb) x/10i subroutine
0x804852c <subroutine>: push   %ebp
0x804852d <subroutine+1>:       mov    %esp,%ebp
0x804852f <subroutine+3>:       nop
0x8048530 <subroutine+4>:       cmpl   $0x63,0x8(%ebp)
0x8048534 <subroutine+8>:       jle    0x8048538 <subroutine+12>
0x8048536 <subroutine+10>:      jmp    0x8048540 <subroutine+20>
0x8048538 <subroutine+12>:      incl   0x8(%ebp)
0x804853b <subroutine+15>:      jmp    0x8048530 <subroutine+4>
0x804853d <subroutine+17>:      lea    0x0(%esi),%esi
0x8048540 <subroutine+20>:      pop    %ebp

But when I compile the same test program with gcc 2.96, gdb is
putting the breakpoint on subroutine+3 - the nop - and things
work as expected.


My promise to fix this this evening assumed it was a dumb little
testsuite regexp problem - this is novel enough (read: Not My Fault :) 
that I'm instead going to bed as it's about bedtime...  I'll look
back into this tomorrow night when I get home if no one else
recognizes why this problem might be coming up.

Jason

Re: PATCH RFA: Fix MI stack frame output for synthetic frames

[Jason Molenda]

On Tue, Feb 04, 2003 at 12:09:36AM -0800, Jason Molenda wrote:
> On Mon, Feb 03, 2003 at 01:34:41PM -0500, Daniel Jacobowitz wrote:
> > On Mon, Feb 03, 2003 at 10:27:48AM -0800, Jason Molenda wrote:
> > > On Mon, Feb 03, 2003 at 10:15:20AM -0800, David Carlton wrote:
> > > 
> > > > 
> > > > On i686-pc-linux-gnu/GCC3.1/DWARF2, I get the following:
> > > > 
> > > 
> > > > PASS: gdb.mi/mi-syn-frame.exp: 407-stack-list-frames
> > > > FAIL: gdb.mi/mi-syn-frame.exp: 408-exec-continue
> 
> > The exec-continue failure seems to be a bad regular expression - it's
> > expecting "*stopped[\r\n]+", not any of the things which follow
> > *stopped.  


It's not really a compiler bug and not really a debugger bug.  
For this function -

> void
> subroutine (int in)
> {
>   while (in < 100)
>     in++;
> }

gcc 3.2 is outputting debug info like this -

        .stabs  "subroutine:F(9,7)",36,0,0,subroutine
        .stabs  "in:p(0,1)",160,0,0,8
.globl subroutine
        .type   subroutine,@function
subroutine:
        .stabn 68,0,48,.LM18-subroutine
.LM18:
        pushl   %ebp
        movl    %esp, %ebp
        nop
        .stabn 68,0,49,.LM19-subroutine    ; line #49 is the while (...)
.LM19:
.L6:
        cmpl    $99, 8(%ebp)
        jle     .L8
        jmp     .L5
.L8:

The compiler is correct to put the line stab there (it does the
equivalent for DWARF2), and gdb is correct in putting the breakpoint
on the cmpl insn, but the unfortunate end result of these two is that
a user putting a breakpoint on the subroutine will have a breakpoint
that's tripped each iteration of the loop.

Given all that, I'll check in a change to mi-syn-frames.c so this
function reads

void
subroutine (int in)
{
  int count = in;
  while (count < 100)
    count++;
}

The assignment gives us two assembly instructions after the end of the
prologue for a breakpoint that won't be hit at each iteration.  It's
stupid, I know.

I'll make that change and run it through the testsuites tomorrow
night.  If I get approval for the change before then (hint hint :)
I'll check it in, else I'll post a patch.

J

Re: PATCH RFA: Fix MI stack frame output for synthetic frames

[Daniel Jacobowitz]

On Wed, Feb 05, 2003 at 12:24:16AM -0800, Jason Molenda wrote:
> gcc 3.2 is outputting debug info like this -
> 
>         .stabs  "subroutine:F(9,7)",36,0,0,subroutine
>         .stabs  "in:p(0,1)",160,0,0,8
> .globl subroutine
>         .type   subroutine,@function
> subroutine:
>         .stabn 68,0,48,.LM18-subroutine
> .LM18:
>         pushl   %ebp
>         movl    %esp, %ebp
>         nop
>         .stabn 68,0,49,.LM19-subroutine    ; line #49 is the while (...)
> .LM19:
> .L6:
>         cmpl    $99, 8(%ebp)
>         jle     .L8
>         jmp     .L5
> .L8:
> 
> The compiler is correct to put the line stab there (it does the
> equivalent for DWARF2), and gdb is correct in putting the breakpoint
> on the cmpl insn, but the unfortunate end result of these two is that
> a user putting a breakpoint on the subroutine will have a breakpoint
> that's tripped each iteration of the loop.
> 
> Given all that, I'll check in a change to mi-syn-frames.c so this
> function reads
> 
> void
> subroutine (int in)
> {
>   int count = in;
>   while (count < 100)
>     count++;
> }
> 
> The assignment gives us two assembly instructions after the end of the
> prologue for a breakpoint that won't be hit at each iteration.  It's
> stupid, I know.
> 
> I'll make that change and run it through the testsuites tomorrow
> night.  If I get approval for the change before then (hint hint :)
> I'll check it in, else I'll post a patch.

Pre-approved as an obvious fix to the test.  Thanks for following up. 
I think there are a few other failures; I'll check again after you've
fixed this one.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: PATCH RFA: Fix MI stack frame output for synthetic frames

[Elena Zannoni]

Daniel Jacobowitz writes:
 > On Wed, Feb 05, 2003 at 12:24:16AM -0800, Jason Molenda wrote:
 > > gcc 3.2 is outputting debug info like this -
 > > 
 > >         .stabs  "subroutine:F(9,7)",36,0,0,subroutine
 > >         .stabs  "in:p(0,1)",160,0,0,8
 > > .globl subroutine
 > >         .type   subroutine,@function
 > > subroutine:
 > >         .stabn 68,0,48,.LM18-subroutine
 > > .LM18:
 > >         pushl   %ebp
 > >         movl    %esp, %ebp
 > >         nop
 > >         .stabn 68,0,49,.LM19-subroutine    ; line #49 is the while (...)
 > > .LM19:
 > > .L6:
 > >         cmpl    $99, 8(%ebp)
 > >         jle     .L8
 > >         jmp     .L5
 > > .L8:
 > > 
 > > The compiler is correct to put the line stab there (it does the
 > > equivalent for DWARF2), and gdb is correct in putting the breakpoint
 > > on the cmpl insn, but the unfortunate end result of these two is that
 > > a user putting a breakpoint on the subroutine will have a breakpoint
 > > that's tripped each iteration of the loop.
 > > 
 > > Given all that, I'll check in a change to mi-syn-frames.c so this
 > > function reads
 > > 
 > > void
 > > subroutine (int in)
 > > {
 > >   int count = in;
 > >   while (count < 100)
 > >     count++;
 > > }
 > > 
 > > The assignment gives us two assembly instructions after the end of the
 > > prologue for a breakpoint that won't be hit at each iteration.  It's
 > > stupid, I know.
 > > 
 > > I'll make that change and run it through the testsuites tomorrow
 > > night.  If I get approval for the change before then (hint hint :)
 > > I'll check it in, else I'll post a patch.
 > 
 > Pre-approved as an obvious fix to the test.  Thanks for following up. 
 > I think there are a few other failures; I'll check again after you've
 > fixed this one.

As one of the MI testsuite maintainers, I'll approve the patch, but, Jason
can you post when you do the check in?

elena

 > 
 > -- 
 > Daniel Jacobowitz
 > MontaVista Software                         Debian GNU/Linux Developer

Fix committed for mi-syn-frames fails (was: Re: PATCH RFA: Fix MI stack frame output for synthetic frames)

[Jason Molenda]

I've commited this.  mi-syn-frames.exp passes with gcc 3.2 and
gcc 2.96 with stabs and DWARF 2.


2003-02-05  Jason Molenda  (jason-cl@molenda.com)

	* gdb.mi/mi-syn-frames.c (subroutine): Add an extra statement
	at the beginning so the breakpoint doesn't get set on the loop.

Index: gdb.mi/mi-syn-frame.c
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi-syn-frame.c,v
retrieving revision 1.1
diff -u -p -r1.1 mi-syn-frame.c
--- gdb.mi/mi-syn-frame.c	2 Feb 2003 05:51:09 -0000	1.1
+++ gdb.mi/mi-syn-frame.c	6 Feb 2003 06:26:01 -0000
@@ -46,8 +46,9 @@ handler (int sig)
 void
 subroutine (int in)
 {
-  while (in < 100)
-    in++;
+  int count = in;
+  while (count < 100)
+    count++;
 }
 
 void

Re: Fix committed for mi-syn-frames fails (was: Re: PATCH RFA: Fix MI stack frame output for synthetic frames)

[Jason Molenda]

(Yes yes, I fixed the ChangeLog -- deep in my heart I know this file
should be called "mi-syn-frames", not "mi-syn-frame". :-)

On Wed, Feb 05, 2003 at 10:28:35PM -0800, Jason Molenda wrote:
> I've commited this.  mi-syn-frames.exp passes with gcc 3.2 and
> gcc 2.96 with stabs and DWARF 2.
> 
> 
> 2003-02-05  Jason Molenda  (jason-cl@molenda.com)
> 
> 	* gdb.mi/mi-syn-frames.c (subroutine): Add an extra statement
> 	at the beginning so the breakpoint doesn't get set on the loop.
> 
> Index: gdb.mi/mi-syn-frame.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi-syn-frame.c,v
> retrieving revision 1.1
> diff -u -p -r1.1 mi-syn-frame.c
> --- gdb.mi/mi-syn-frame.c	2 Feb 2003 05:51:09 -0000	1.1
> +++ gdb.mi/mi-syn-frame.c	6 Feb 2003 06:26:01 -0000
> @@ -46,8 +46,9 @@ handler (int sig)
>  void
>  subroutine (int in)
>  {
> -  while (in < 100)
> -    in++;
> +  int count = in;
> +  while (count < 100)
> +    count++;
>  }
>  
>  void

Re: Fix committed for mi-syn-frames fails (was: Re: PATCH RFA: Fix MI stack frame output for synthetic frames)

[David Carlton]

On Wed, 5 Feb 2003 22:28:35 -0800, Jason Molenda <jason-swarelist@molenda.com> said:

> I've commited this.  mi-syn-frames.exp passes with gcc 3.2 and
> gcc 2.96 with stabs and DWARF 2.

Thanks, it works for me, too.

David Carlton
carlton@math.stanford.edu

Re: Fix committed for mi-syn-frames fails (was: Re: PATCH RFA: Fix MI stack frame output for synthetic frames)

[Andrew Cagney]

> -  while (in < 100)
> -    in++;
> +  int count = in;
> +  while (count < 100)
> +    count++;

Pss, add a comment explaining why the code is written that way :-)

Andrew

Re: Fix committed for mi-syn-frames fails (was: Re: PATCH RFA: Fix MI stack frame output for synthetic frames)

[Jason Molenda]

On Thu, Feb 06, 2003 at 01:21:00PM -0500, Andrew Cagney wrote:

> 
> Pss, add a comment explaining why the code is written that way :-)
> 

I don't think anyone looks to the testsuite source code for brevity
and logical expression, but I don't have any real preference.
Patch below committed.


2003-02-06  Jason Molenda  (jason-cl@molenda.com)

	* gdb.mi/mi-syn-frame.c (subroutine): Add a comment explaining
	why the code is written that way.

Index: gdb.mi/mi-syn-frame.c
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.mi/mi-syn-frame.c,v
retrieving revision 1.2
diff -u -p -r1.2 mi-syn-frame.c
--- gdb.mi/mi-syn-frame.c	6 Feb 2003 06:27:01 -0000	1.2
+++ gdb.mi/mi-syn-frame.c	6 Feb 2003 18:25:01 -0000
@@ -43,6 +43,10 @@ handler (int sig)
   subroutine (sig);
 }
 
+/* The first statement in subroutine () is a place for a breakpoint.  
+   Without it, the breakpoint is put on the while comparison and will
+   be hit at each iteration. */
+
 void
 subroutine (int in)
 {