From: Andrew Cagney <ac131313@redhat.com>
To: "J. Johnston" <jjohnstn@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: RFA: frame id enhancement
Date: Fri, 17 Oct 2003 13:30:00 -0000 [thread overview]
Message-ID: <3F8FEF0B.7000104@redhat.com> (raw)
In-Reply-To: <3F8F2A96.1070708@redhat.com>
> Is the revised attached patch ok?
Yep, now I understand it. Thanks.
Andrew
ex: frame.h
> ===================================================================
> RCS file: /cvs/src/src/gdb/frame.h,v
> retrieving revision 1.110
> diff -u -r1.110 frame.h
> --- frame.h 10 Oct 2003 00:32:04 -0000 1.110
> +++ frame.h 16 Oct 2003 23:30:50 -0000
> @@ -95,8 +95,6 @@
> is used. Watch out for all the legacy targets that still use the
> function pointer register or stack pointer register. They are
> wrong. */
> - /* NOTE: cagney/2002-11-16: The ia64 has two stacks and hence two
> - frame bases. This will need to be expanded to accomodate that. */
> CORE_ADDR stack_addr;
> /* The frame's code address. This shall be constant through out the
> lifetime of the frame. While the PC (a.k.a. resume address)
> @@ -104,15 +102,33 @@
> Typically, it is set to the address of the entry point of the
> frame's function (as returned by frame_func_unwind(). */
> CORE_ADDR code_addr;
> + /* The frame's special address. This shall be constant through out the
> + lifetime of the frame. This is used for architectures that may have
> + frames that do not change the stack but are still distinct and have
> + some form of distinct identifier (e.g. the ia64 which uses a 2nd
> + stack for registers). This field is treated as unordered - i.e. will
> + not be used in frame ordering comparisons such as frame_id_inner().
> + A zero in this field will be treated as a wild-card when comparing
> + frames for equality. */
> + CORE_ADDR special_addr;
> };
>
> /* Methods for constructing and comparing Frame IDs.
>
> - NOTE: Given frameless functions A and B, where A calls B (and hence
> + NOTE: Given stackless functions A and B, where A calls B (and hence
> B is inner-to A). The relationships: !eq(A,B); !eq(B,A);
> - !inner(A,B); !inner(B,A); all hold. This is because, while B is
> - inner to A, B is not strictly inner to A (being frameless, they
> - have the same .base value). */
> + !inner(A,B); !inner(B,A); all hold.
> +
> + This is because, while B is inner-to A, B is not strictly inner-to A.
> + Being stackless, they have an identical .stack_addr value, and differ
> + only by their unordered .code_addr and/or .special_addr values.
> +
> + Because frame_id_inner is only used as a safety net (e.g.,
> + detect a corrupt stack) the lack of strictness is not a problem.
> + Code needing to determine an exact relationship between two frames
> + must instead use frame_id_eq and frame_id_unwind. For instance,
> + in the above, to determine that A stepped-into B, the equation
> + "A.id != B.id && A.id == id_unwind (B)" can be used. */
>
> /* For convenience. All fields are zero. */
> extern const struct frame_id null_frame_id;
> @@ -120,9 +136,20 @@
> /* Construct a frame ID. The first parameter is the frame's constant
> stack address (typically the outer-bound), and the second the
> frame's constant code address (typically the entry point) (or zero,
> - to indicate a wild card). */
> + to indicate a wild card). The special identifier address is
> + defaulted to zero. */
> extern struct frame_id frame_id_build (CORE_ADDR stack_addr,
> CORE_ADDR code_addr);
> +
> +/* Construct a special frame ID. The first parameter is the frame's constant
> + stack address (typically the outer-bound), the second is the
> + frame's constant code address (typically the entry point) (or zero,
> + to indicate a wild card), and the third parameter is the frame's
> + special identifier address (or zero to indicate a wild card or
> + unused default). */
> +extern struct frame_id frame_id_build_special (CORE_ADDR stack_addr,
> + CORE_ADDR code_addr,
> + CORE_ADDR special_addr);
>
> /* Returns non-zero when L is a valid frame (a valid frame has a
> non-zero .base). */
> Index: frame.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/frame.c,v
> retrieving revision 1.145
> diff -u -r1.145 frame.c
> --- frame.c 2 Oct 2003 20:28:29 -0000 1.145
> +++ frame.c 16 Oct 2003 23:30:51 -0000
> @@ -144,9 +144,10 @@
> void
> fprint_frame_id (struct ui_file *file, struct frame_id id)
> {
> - fprintf_unfiltered (file, "{stack=0x%s,code=0x%s}",
> + fprintf_unfiltered (file, "{stack=0x%s,code=0x%s,special=0x%s}",
> paddr_nz (id.stack_addr),
> - paddr_nz (id.code_addr));
> + paddr_nz (id.code_addr),
> + paddr_nz (id.special_addr));
> }
>
> static void
> @@ -256,14 +257,22 @@
> const struct frame_id null_frame_id; /* All zeros. */
>
> struct frame_id
> -frame_id_build (CORE_ADDR stack_addr, CORE_ADDR code_addr)
> +frame_id_build_special (CORE_ADDR stack_addr, CORE_ADDR code_addr,
> + CORE_ADDR special_addr)
> {
> struct frame_id id;
> id.stack_addr = stack_addr;
> id.code_addr = code_addr;
> + id.special_addr = special_addr;
> return id;
> }
>
> +struct frame_id
> +frame_id_build (CORE_ADDR stack_addr, CORE_ADDR code_addr)
> +{
> + return frame_id_build_special (stack_addr, code_addr, 0);
> +}
> +
> int
> frame_id_p (struct frame_id l)
> {
> @@ -292,8 +301,14 @@
> else if (l.code_addr == 0 || r.code_addr == 0)
> /* A zero code addr is a wild card, always succeed. */
> eq = 1;
> - else if (l.code_addr == r.code_addr)
> - /* The .stack and .code are identical, the ID's are identical. */
> + else if (l.code_addr != r.code_addr)
> + /* If .code addresses are different, the frames are different. */
> + eq = 0;
> + else if (l.special_addr == 0 || r.special_addr == 0)
> + /* A zero special addr is a wild card (or unused), always succeed. */
> + eq = 1;
> + else if (l.special_addr == r.special_addr)
> + /* Frames are equal. */
> eq = 1;
> else
> /* No luck. */
> @@ -320,7 +335,7 @@
> /* Only return non-zero when strictly inner than. Note that, per
> comment in "frame.h", there is some fuzz here. Frameless
> functions are not strictly inner than (same .stack but
> - different .code). */
> + different .code and/or .special address). */
> inner = INNER_THAN (l.stack_addr, r.stack_addr);
> if (frame_debug)
> {
next prev parent reply other threads:[~2003-10-17 13:30 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-06 21:15 J. Johnston
2003-10-14 21:59 ` J. Johnston
2003-10-15 21:09 ` Andrew Cagney
2003-10-15 23:12 ` J. Johnston
2003-10-16 16:09 ` Andrew Cagney
2003-10-16 19:06 ` J. Johnston
2003-10-16 21:06 ` Andrew Cagney
2003-10-16 21:49 ` J. Johnston
2003-10-16 23:32 ` J. Johnston
2003-10-17 13:30 ` Andrew Cagney [this message]
2003-10-17 16:32 ` J. Johnston
2003-10-17 18:11 ` Kevin Buettner
2003-10-17 19:34 ` J. Johnston
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=3F8FEF0B.7000104@redhat.com \
--to=ac131313@redhat.com \
--cc=gdb-patches@sources.redhat.com \
--cc=jjohnstn@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