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 06:52:00 -0000 [thread overview]
Message-ID: <1136356104.17597.47.camel@localhost.localdomain> (raw)
In-Reply-To: <8f2776cb0601032155q10fa5597naf26a180c753e2a3@mail.gmail.com>
Hi Jim
I am not sure about removing the get_prev_frame. We need it for the
correct frame id . In case you were stepping over a recursive call and
deep inside after main had executed you would need the correct frame id
of the return frame and in the other case a null_frame_id.
Changing over breaks the behaviour of the backtrace over a recursive
call. Gives me extra failures inside break.exp .
cheers
Ramana
On Tue, 2006-01-03 at 21:55 -0800, Jim Blandy wrote:
> Hi --- thanks for revising the patch.
>
> +/* 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. */
>
> I don't think this is quite what you mean to say. The comment for a
> function should describe its behavior in terms of its arguments;
> "caller" is vague. Second, this isn't always used for "next"; it can
> get used when you "step" into a function with no debug info (if I'm
> reading right). Third, a more self-contained explanation of why the
> get_prev_frame-based approach isn't sufficient would be better.
>
> How about:
>
> /* Insert a step-resume breakpoint at the address to which
> RETURN_FRAME will return.
>
> Unlike insert_step_resume_breakpoint_at_frame (get_prev_frame (F)),
> this works even when F is the oldest frame. (Consider next-ing out
> of main when 'show backtrace past-main' is off.) */
>
> Finally --- could insert_step_resume_breakpoint_at_caller simply
> *always* use the frame_pc_unwind approach, and drop the check for
> get_prev_frame altogether? I understand that trying get_prev_frame
> first is guaranteed to give the least disturbance to the existing
> behavior, but I don't like leaving stuff like that in there unless we
> can explain why it's actually needed.
--
Ramana Radhakrishnan
GNU Tools
codito ergo sum (www.codito.com)
Ph: +91-20-26051367 (office) +91-9890040009 (mobile)
next prev parent reply other threads:[~2006-01-04 6:52 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
2006-01-04 5:55 ` Jim Blandy
2006-01-04 6:52 ` Ramana Radhakrishnan [this message]
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=1136356104.17597.47.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