PATCH: Fix MI stack frame output for synthetic frames

PATCH: Fix MI stack frame output for synthetic frames

[Jason Molenda]

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

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.

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

PS- Jeff, I saw you doing some tuple/list cleanup recently.  The
one place I fixed on the Apple but the FSF doesn't have correct is
the CHILDREN list from -var-list-children; it should be a list,
but it's currently output as a tuple.  I'd be willing to submit a
patch to the code and the testsuite if you're interested.

PPS- I should add that this test causes no regressions and doesn't
change the CLI output.  I wrote a test file to explicitly cover
these synthesized frames in CLI and MI modes, but it would take a
little reworking to handle the FSF style MI output.




static void
print_frame_info_base (struct frame_info *fi, int level, int source, int args)
{
  struct symtab_and_line sal;
  int source_print;
  int location_print;
  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>");
      ui_out_text (uiout, "\n");
      annotate_frame_end ();
      do_cleanups (uiout_cleanup);
      return;
    }
  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: 3102 bytes --]

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.

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	8 Nov 2002 22:02:49 -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,29 @@ print_frame_info_base (struct frame_info
           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 ();
-      printf_filtered ("<function called from gdb>\n");
+      ui_out_field_string (uiout, "func", "<function called from gdb>");
+      ui_out_text (uiout, "\n");
       annotate_frame_end ();
+      do_cleanups (uiout_cleanup);
       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)
-        {
-          ui_out_text (uiout, "#");
-          ui_out_field_fmt_int (uiout, 2, ui_left, "level", level);
-        }
       annotate_signal_handler_caller ();
-      printf_filtered ("<signal handler called>\n");
+      ui_out_field_string (uiout, "func", "<signal handler called>");
+      ui_out_text (uiout, "\n");
       annotate_frame_end ();
+      do_cleanups (uiout_cleanup);
       return;
     }
 

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: Fix MI stack frame output for synthetic frames

[Jason Molenda]

[-- Attachment #1: Type: text/plain, Size: 677 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, I'll write up an MI test case for this and re-post the whole
patch a bit later (off to help a user just now :-).  I can also 
test the signal handler frame one a la gdb.base/signals.exp easily
enough.  

For the tests I added to the Apple gdb, I use the following C file
to test various cases (the function bar() I used for verifying
unwindonsignal was working correctly) in MI and CLI mode.

Thanks,

J

[-- Attachment #2: inf-call-interrupt.c --]
[-- Type: text/plain, Size: 577 bytes --]

#include <signal.h>
#include <unistd.h>
#include <stdlib.h>

void foo (void);
void bar (void);

void subroutine (int);

void handler (int);


main ()
{
  puts ("Starting up");

  foo ();

  puts ("Waiting to get a signal");

  signal (SIGALRM, handler);
  alarm (1);
  sleep (2);

  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++;
}

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

[Andrew Cagney]

> 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, I'll write up an MI test case for this and re-post the whole
> patch a bit later (off to help a user just now :-).  I can also 
> test the signal handler frame one a la gdb.base/signals.exp easily
> enough.  

Thanks.

Just note that, unlike all that older code, you can now assume:

- the message always appears (if it doesn't its a bug in that 
architecture not using dummy-frames :-)
- the unwind stops at main (if it doesn't for your target yell and 
someone will fix it :-)

Much easier!
Andrew


> For the tests I added to the Apple gdb, I use the following C file
> to test various cases (the function bar() I used for verifying
> unwindonsignal was working correctly) in MI and CLI mode.

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

[Jason Molenda]

On Sat, Nov 09, 2002 at 12:47:23AM -0800, Jason Molenda wrote:

> [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.


Incidentally, I suppose I should duplicate the .exp file for an
mi1 version.  They'll be nearly identical at this point, but as
mi2 changes there may be differences, and anyone specifically
targetting mi1 (oh say Apple :-) would want to keep testing this
stuff even in mi1 mode.

Ping on two MI patches

[Jason Molenda]

It hasn't been an especially long time (I sent them just last
weekend), but these two patches seem rather uncontroversial...

Fixing MI frame tuple output when there is a call dummy or signal frame
on the stack, includes test cases for new output:
	http://sources.redhat.com/ml/gdb-patches/2002-11/msg00274.html

Fixing var-list-children's response so CHILDREN is a list instead of
a tuple, includes updates to testsuite and doc fix (already approved
by Eli):
	http://sources.redhat.com/ml/gdb-patches/2002-11/msg00287.html

Thanks,

Jason

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

[Mark Kettenis]

Andrew Cagney <ac131313@redhat.com> writes:

> > [gdb/ChangeLog]
> > 2002-11-09  Jason Molenda  (jason-cl@molenda.com)
> > 
> >         * stack.c (print_frame_info_base): Output complete FRAME tuple
> >         for synthesized frames.

> 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.

Something must've gone wrong with your testing :-(.  The stack.c
change lost us a "frame-begin" annotation when printing a DUMMY_FRAME
or a SIGTRAMP_FRAME.  The latter provoked a

   FAIL: gdb.base/annota1.exp: backtrace @ signal handler

on my system.

Anyway, I propose the attached fix.  OK to check that in?

Index: ChangeLog
from  Mark Kettenis  <kettenis@gnu.org>

	* stack.c (print_frame_info): Restore call to annotate_frame_begin
	lost in the previous patch.

Index: stack.c
===================================================================
RCS file: /cvs/src/src/gdb/stack.c,v
retrieving revision 1.64
diff -u -p -r1.64 stack.c
--- stack.c 2 Feb 2003 05:51:08 -0000 1.64
+++ stack.c 2 Feb 2003 17:37:44 -0000
@@ -203,6 +203,8 @@ print_frame_info (struct frame_info *fi,
       struct cleanup *uiout_cleanup
 	= make_cleanup_ui_out_tuple_begin_end (uiout, "frame");
 
+      annotate_frame_begin (level == -1 ? 0 : level, get_frame_pc (fi));
+
       /* Do this regardless of SOURCE because we don't have any source
          to list for this frame.  */
       if (level >= 0)
@@ -216,7 +218,7 @@ print_frame_info (struct frame_info *fi,
           ui_out_field_core_addr (uiout, "addr", fi->pc);
           annotate_frame_address_end ();
         }
-      
+
       if (get_frame_type (fi) == DUMMY_FRAME)
         {
           annotate_function_call ();

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

[Andrew Cagney]

> Anyway, I propose the attached fix.  OK to check that in?

Ulgh. Yes, thanks.

> Index: ChangeLog
> from  Mark Kettenis  <kettenis@gnu.org>
> 
> 	* stack.c (print_frame_info): Restore call to annotate_frame_begin
> 	lost in the previous patch.
> 
> Index: stack.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/stack.c,v
> retrieving revision 1.64
> diff -u -p -r1.64 stack.c
> --- stack.c 2 Feb 2003 05:51:08 -0000 1.64
> +++ stack.c 2 Feb 2003 17:37:44 -0000
> @@ -203,6 +203,8 @@ print_frame_info (struct frame_info *fi,
>        struct cleanup *uiout_cleanup
>  	= make_cleanup_ui_out_tuple_begin_end (uiout, "frame");
>  
> +      annotate_frame_begin (level == -1 ? 0 : level, get_frame_pc (fi));
> +
>        /* Do this regardless of SOURCE because we don't have any source
>           to list for this frame.  */
>        if (level >= 0)
> @@ -216,7 +218,7 @@ print_frame_info (struct frame_info *fi,
>            ui_out_field_core_addr (uiout, "addr", fi->pc);
>            annotate_frame_address_end ();
>          }
> -      
> +
>        if (get_frame_type (fi) == DUMMY_FRAME)
>          {
>            annotate_function_call ();
> 

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

[Mark Kettenis]

   Date: Sun, 02 Feb 2003 13:23:23 -0500
   From: Andrew Cagney <ac131313@redhat.com>

   > Anyway, I propose the attached fix.  OK to check that in?

   Ulgh. Yes, thanks.

Done.

   > Index: ChangeLog
   > from  Mark Kettenis  <kettenis@gnu.org>
   > 
   > 	* stack.c (print_frame_info): Restore call to annotate_frame_begin
   > 	lost in the previous patch.

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)
 {

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