From: Andrew Cagney <ac131313@redhat.com>
To: Andrew Cagney <ac131313@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [patch rfc] Add the frame's type to the unwinder
Date: Sat, 05 Apr 2003 03:56:00 -0000 [thread overview]
Message-ID: <3E8E53EB.4030201@redhat.com> (raw)
In-Reply-To: <3E8B5905.1000704@redhat.com>
> Hello,
>
> The attached patch, moves the frame's type into `struct frame_unwind' and in doing so makes it possible to combine the sequence:
>
> prev->type = frame_type_from_pc()
> prev->unwind = frame_unwind_find_by_pc()
>
> into a single:
>
> prev->unwind = frame_unwind_find_by_pc();
> // prev->type == prev->unwind->type;
>
> and hence eliminate the the call to frame_type_from_pc().
>
>
> Fine print:
>
> While the above is true for new code, old code continues to use the same confused combination of frame_type_from_pc(), frame_unwind_find_by_pc(), deprecated_set_frame_type(), and legacy_get_prev_frame(). A legacy frame's type is initialized to UNKNOWN_FRAME, and then zero or more of those functions will override it. get_frame_type() mapping an UNKNOWN_FRAME onto a NORMAL_FRAME.
>
> Importantly, if a legacy frame's unwinder returns a known frame type (!UNKNOWN_FRAME) then that will be used in preference to any other value. This should make it possible for old architectures to incrementally implement new unwinders.
>
>
> Tested on d10v, ppc, and i386. I'll commit in a few days,
I've checked this in.
Andrew
> 2003-04-02 Andrew Cagney <cagney@redhat.com>
>
> * frame.c (get_prev_frame): Do not call frame_type_from_pc. Set
> the frame's type from the unwinder.
> (get_frame_type): Map UNKNOWN_FRAME onto NORMAL_FRAME.
> (create_new_frame, legacy_get_prev_frame): When the unwinder's
> type isn't UNKNOWN_FRAME, initalize "type" from the unwinder.
> (get_frame_base_address): Use get_frame_type.
> (get_frame_locals_address, get_frame_args_address): Ditto.
> (legacy_saved_regs_unwinder): Set the type to UNKNOWN_TYPE.
> * frame.h (enum frame_type): Add UNKNOWN_FRAME.
> (struct frame_info): Add comment explaining why the frame contains
> a "type" field.
> * dummy-frame.c (dummy_frame_unwind): Set the type to DUMMY_FRAME.
> * d10v-tdep.c (d10v_frame_unwind): Set the type to NORMAL_FRAME.
> * sentinel-frame.c (sentinel_frame_unwinder): Set the type to
> NORMAL_FRAME.
> * frame-unwind.h: Include "frame.h".
> (struct frame_unwind): Add "type" field.
> * Makefile.in (frame_unwind_h): Add $(frame_h).
>
> Inde
prev parent reply other threads:[~2003-04-05 3:56 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-02 21:41 Andrew Cagney
2003-04-02 21:53 ` Andrew Cagney
2003-04-05 3:56 ` Andrew Cagney [this message]
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=3E8E53EB.4030201@redhat.com \
--to=ac131313@redhat.com \
--cc=gdb-patches@sources.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