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)
{
next prev parent 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