From: Andrew Cagney <cagney@gnu.org>
To: Kevin Buettner <kevinb@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFC] infrun.c: Fix infinite loop caused by breakpoint adjustment
Date: Sun, 11 Jan 2004 21:03:00 -0000 [thread overview]
Message-ID: <4001BA24.6090005@gnu.org> (raw)
In-Reply-To: <1031218195400.ZM17244@localhost.localdomain>
> Any comments on the patch below?
Can this paragraph (or something like it) should be included in the code
change? That way the reader will better understand exactly what goes
wrong and for which architecture.
> It fixes an infinite loop caused by attempting to run to a location
> to which it's architecturally impossible to set a breakpoint at. (It's
> quite easy to reproduce this problem on FR-V. Just step into some
> library code which has been compiled with optimization.)
enjoy,
Andrew
> Since it touches infrun.c, and since a lot of developers are on
> holiday at this time of year, I'll wait until January 15 to commit it.
> Hopefully, that'll give everyone who'd like to comment on this patch
> a chance to look at it.
>
> Kevin
>
> * infrun.c (step_into_function): Account for possible breakpoint
> adjustment when computing ``stop_func_start''.
>
> Index: infrun.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/infrun.c,v
> retrieving revision 1.122
> diff -u -p -r1.122 infrun.c
> --- infrun.c 25 Nov 2003 16:01:36 -0000 1.122
> +++ infrun.c 18 Dec 2003 19:34:53 -0000
> @@ -2762,6 +2762,18 @@ step_into_function (struct execution_con
> && ecs->sal.end < ecs->stop_func_end)
> ecs->stop_func_start = ecs->sal.end;
>
> + /* Architectures which require breakpoint adjustment might not be able
> + to place a breakpoint at the computed address. If so, the test
> + ``ecs->stop_func_start == stop_pc'' will never succeed. Adjust
> + ecs->stop_func_start to an address at which a breakpoint may be
> + legitimately placed. */
> + if (gdbarch_adjust_breakpoint_address_p (current_gdbarch))
> + {
> + ecs->stop_func_start
> + = gdbarch_adjust_breakpoint_address (current_gdbarch,
> + ecs->stop_func_start);
> + }
> +
> if (ecs->stop_func_start == stop_pc)
> {
> /* We are already there: stop now. */
>
>
next prev parent reply other threads:[~2004-01-11 21:03 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-12-18 19:54 Kevin Buettner
2004-01-11 21:03 ` Andrew Cagney [this message]
2004-01-19 17:35 ` Kevin Buettner
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=4001BA24.6090005@gnu.org \
--to=cagney@gnu.org \
--cc=gdb-patches@sources.redhat.com \
--cc=kevinb@redhat.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