From: Doug Evans <dje@google.com>
To: gdb-patches@sourceware.org
Subject: Re: [RFA] dummy frame handling cleanup, plus inferior fun call signal handling improvement
Date: Wed, 19 Nov 2008 14:07:00 -0000 [thread overview]
Message-ID: <e394668d0811181643n2c2b5f13u37d8242d0447c23a@mail.gmail.com> (raw)
In-Reply-To: <20081118125838.0613C412301@localhost>
On Tue, Nov 18, 2008 at 4:58 AM, Doug Evans <dje@google.com> wrote:
> Hi. This patch was in progress when I wrote
> http://sourceware.org/ml/gdb-patches/2008-11/msg00391.html
> This patch subsumes that one.
>
> There are two things this patch does:
> 1) properly pop dummy frames more often
> 2) make the inferior resumable after an inferior function call gets a
> signal without having to remember to do "signal 0"
>
> 1) properly pop dummy frames more often
>
> Ulrich asked:
>> I agree that it would be better if call_function_by_hand were to call
>> dummy_frame_pop in this case. However, why exactly is this a bug?
>
> It's a bug because it's confusing to not pop the frame in the places
> where one is able to. Plus it's, well, unclean.
> I recognize that the dummy frame stack can't be precisely managed because
> the user can do things like:
>
> set $orig_pc = $pc
> set $orig_sp = $sp
> break my_fun
> call my_fun()
> set $pc = $orig_pc
> set $sp = $orig_sp
> continue
>
> [This doesn't always work, but you get the idea.]
> At the "continue", the inferior function call no longer exists and
> gdb's mechanisms for removing the dummy frame from dummy_frame_stack
> will never trigger (until the program is resumed and cleanup_dummy_frames
> is called). But we can still keep things clean
> and unconfusing for the common case.
For completeness' sake,
To catch cases like these one could do things like compare $sp with
$dummy_frame_stack.*.regcache.sp every time execution stops.
next prev parent reply other threads:[~2008-11-19 0:44 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-18 21:01 Doug Evans
2008-11-19 14:07 ` Doug Evans [this message]
2008-11-20 15:02 ` Doug Evans
2008-11-20 15:06 ` Doug Evans
2008-12-01 20:52 ` Doug Evans
2008-12-01 21:22 ` Pedro Alves
2008-12-02 1:20 ` Doug Evans
2008-12-03 6:04 ` Doug Evans
2008-12-04 15:32 ` Ulrich Weigand
2008-12-04 15:54 ` Pedro Alves
2008-12-04 22:32 ` Doug Evans
2008-12-04 22:42 ` Pedro Alves
2008-12-05 0:18 ` Ulrich Weigand
2008-12-05 0:37 ` Pedro Alves
2008-12-05 1:16 ` Get rid of stop_pc (was: [RFA] dummy frame handling cleanup, plus inferior fun call signal handling improvement) Pedro Alves
2008-12-05 1:50 ` Doug Evans
2008-12-05 2:14 ` Pedro Alves
2008-12-05 2:46 ` Pedro Alves
2008-12-05 18:43 ` Ulrich Weigand
2008-12-05 19:07 ` Pedro Alves
2008-12-05 0:30 ` [RFA] dummy frame handling cleanup, plus inferior fun call signal handling improvement Ulrich Weigand
2008-11-26 19:17 ` Doug Evans
2009-01-07 6:52 Doug Evans
2009-01-07 16:36 ` Doug Evans
2009-01-14 15:07 ` Ulrich Weigand
2009-01-07 17:02 ` Pedro Alves
2009-01-14 15:07 ` Ulrich Weigand
2009-01-19 7:24 ` Doug Evans
2009-01-19 14:40 ` Ulrich Weigand
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=e394668d0811181643n2c2b5f13u37d8242d0447c23a@mail.gmail.com \
--to=dje@google.com \
--cc=gdb-patches@sourceware.org \
/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