Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Ramana Radhakrishnan <ramana.radhakrishnan@codito.com>
To: Jim Blandy <jimb@red-bean.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: Fix for PR 1971 .
Date: Wed, 04 Jan 2006 05:07:00 -0000	[thread overview]
Message-ID: <1136350956.8215.14.camel@localhost.localdomain> (raw)
In-Reply-To: <8f2776cb0601031543g4fc5a45bj9cf367c82d6793b0@mail.gmail.com>

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

Hi Jim, 


> > > Attached is a fix for PR 1971. This inserts a breakpoint at the return
> > > address for a function that does not have a previous frame which is what
> > > you have in the case of main. This would however not stop after the
> > > return from main because the semantics of the next command would not
> > > stop the execution in any place where there is no debug information.
> > >
> > > Tested on native x86 with today's head as well as 6.4 branch with no
> > > extra regressions .
> >
> > Is this the behavior we actually want?  Where the user hasn't "set
> > backtrace past-main on", isn't it the correct behavior for GDB to
> > allow the program to exit when doing a 'next' out of main?  (I assume
> > that, if one does a 'set backtrace past-main on', then 'next' works as
> > you suggest it should.)
> 
> Oh, wait.  I might understand better now.  The current behavior is a
> segfault, as get_prev_frame returns NULL.  The code you patched is
> clearly wrong as it stands, since it doesn't account for that
> possibility.  The behavior with your patch is that 'next' from main
> causes the program to run to completion when past-main is off, as I
> suggested it ought.  Right?

Right . Thats the intended behaviour. The debuggee would run to
completion depending  on whether there exists debug info beyond main or
not. 

> I see three uses of insert_step_resume_breakpoint_at_frame
> (get_prev_frame (get_current_frame ())) in infrun.c; would it be
> reasonable to add a new function in the
> insert_step_resume_breakpoint_at_* family,
> insert_step_resume_breakpoint_at_caller (say), that sets the
> step-resume breakpoint at a sal built from the given frame's return
> address?
> 
> I think you'd want to use frame_pc_unwind in that function, and not
> gdbarch_unwind_pc.
> 

 Here's an updated patch that uses a new function
insert_step_resume_breakpoint_at_caller and frame_pc_unwind as suggested
which has been tested on x86-linux with an extra pass in
watchthreads.exp, I am still not sure why this gets fixed by this.. 

 Ok to commit ? 

2006-01-04  Ramana Radhakrishnan  <ramana.radhakrishnan@codito.com>

       PR 1971
       * infrun.c (insert_step_resume_breakpoint_at_caller):New
function.
       (handle_inferior_event):Use above.


cheers
Ramana
-- 
Ramana Radhakrishnan
GNU Tools
codito ergo sum (www.codito.com)

[-- Attachment #2: pr1971-take2 --]
[-- Type: text/x-patch, Size: 2694 bytes --]

Index: infrun.c
===================================================================
RCS file: /cvs/src/src/gdb/infrun.c,v
retrieving revision 1.208
diff -u -a -u -r1.208 infrun.c
--- infrun.c	17 Dec 2005 22:34:01 -0000	1.208
+++ infrun.c	4 Jan 2006 04:40:11 -0000
@@ -943,6 +943,7 @@
 
 static void step_into_function (struct execution_control_state *ecs);
 static void insert_step_resume_breakpoint_at_frame (struct frame_info *step_frame);
+static void insert_step_resume_breakpoint_at_caller (struct frame_info *step_frame);
 static void insert_step_resume_breakpoint_at_sal (struct symtab_and_line sr_sal,
 						  struct frame_id sr_id);
 static void stop_stepping (struct execution_control_state *ecs);
@@ -2390,7 +2391,8 @@
 	  /* We're doing a "next", set a breakpoint at callee's return
 	     address (the address at which the caller will
 	     resume).  */
-	  insert_step_resume_breakpoint_at_frame (get_prev_frame (get_current_frame ()));
+
+	  insert_step_resume_breakpoint_at_caller ( get_current_frame ());
 	  keep_going (ecs);
 	  return;
 	}
@@ -2453,7 +2455,7 @@
 
       /* Set a breakpoint at callee's return address (the address at
          which the caller will resume).  */
-      insert_step_resume_breakpoint_at_frame (get_prev_frame (get_current_frame ()));
+      insert_step_resume_breakpoint_at_caller ( get_current_frame ());
       keep_going (ecs);
       return;
     }
@@ -2522,7 +2524,7 @@
 	{
 	  /* Set a breakpoint at callee's return address (the address
 	     at which the caller will resume).  */
-	  insert_step_resume_breakpoint_at_frame (get_prev_frame (get_current_frame ()));
+	  insert_step_resume_breakpoint_at_caller ( get_current_frame ());
 	  keep_going (ecs);
 	  return;
 	}
@@ -2757,6 +2759,30 @@
   insert_step_resume_breakpoint_at_sal (sr_sal, get_frame_id (return_frame));
 }
 
+/* Insert a step resume breakpoint at the return address of the
+   caller. This is to ensure that on doing a next from before main completes
+   execution of the program without GDB dumping core. Look at PR 1971
+   for more details.  */
+
+static void 
+insert_step_resume_breakpoint_at_caller (struct frame_info *return_frame)
+{
+  if (get_prev_frame (return_frame))
+    {
+      insert_step_resume_breakpoint_at_frame (get_prev_frame (return_frame));
+    }
+  else
+    {
+      struct symtab_and_line sr_sal;
+      init_sal (&sr_sal);		/* initialize to zeros */
+      sr_sal.pc = ADDR_BITS_REMOVE (frame_pc_unwind (return_frame));
+      sr_sal.section = find_pc_overlay (sr_sal.pc);
+      insert_step_resume_breakpoint_at_sal (sr_sal, null_frame_id);
+    }   
+  
+}
+
+
 static void
 stop_stepping (struct execution_control_state *ecs)
 {

  reply	other threads:[~2006-01-04  5:07 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-03 18:41 Ramana Radhakrishnan
2006-01-03 23:34 ` Jim Blandy
2006-01-03 23:43   ` Jim Blandy
2006-01-04  5:07     ` Ramana Radhakrishnan [this message]
2006-01-04  5:55       ` Jim Blandy
2006-01-04  6:52         ` Ramana Radhakrishnan
2006-01-04  7:57           ` Jim Blandy
2006-01-04  8:27             ` Ramana Radhakrishnan
2006-01-04 13:56       ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1136350956.8215.14.camel@localhost.localdomain \
    --to=ramana.radhakrishnan@codito.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=jimb@red-bean.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox