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

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.


  reply	other threads:[~2006-01-04  5:55 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 [this message]
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=8f2776cb0601032155q10fa5597naf26a180c753e2a3@mail.gmail.com \
    --to=jimb@red-bean.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=ramana.radhakrishnan@codito.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