* RFA: frame id enhancement
@ 2003-10-06 21:15 J. Johnston
2003-10-14 21:59 ` J. Johnston
2003-10-15 21:09 ` Andrew Cagney
0 siblings, 2 replies; 13+ messages in thread
From: J. Johnston @ 2003-10-06 21:15 UTC (permalink / raw)
To: gdb-patches
[-- Attachment #1: Type: text/plain, Size: 839 bytes --]
The following patch enhances the frame id support to allow an architecture
to set a special address for the frame. This enables architectures such as the
ia64 (which has a 2nd stack) to properly mark distinct frames. I added a
new routine that builds frame ids that has a special address parameter. The
current frame_id_build() has been changed to call the new routine with a default
special address of 0. This means that existing calls to frame_id_build() require
no changes.
Ok to commit to mainline?
-- Jeff J.
2003-10-06 Jeff Johnston <jjohnstn@redhat.com>
* frame.h (struct frame_id): Add new field: special_addr.
(frame_id_build_special): New prototype.
* frame.c (frame_id_build_special): New function.
(frame_id_build): Change to call frame_id_build_special().
(frame_id_eq): Change to also test special_addr field.
[-- Attachment #2: frame-special.patch --]
[-- Type: text/plain, Size: 3972 bytes --]
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 6 Oct 2003 21:07: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)
{
@@ -288,6 +297,9 @@
eq = 0;
else if (l.stack_addr != r.stack_addr)
/* If .stack addresses are different, the frames are different. */
+ eq = 0;
+ else if (l.special_addr != r.special_addr)
+ /* If .special addresses are different, the frames are different. */
eq = 0;
else if (l.code_addr == 0 || r.code_addr == 0)
/* A zero code addr is a wild card, always succeed. */
Index: frame.h
===================================================================
RCS file: /cvs/src/src/gdb/frame.h,v
retrieving revision 1.109
diff -u -r1.109 frame.h
--- frame.h 28 Sep 2003 22:32:19 -0000 1.109
+++ frame.h 6 Oct 2003 21:07:52 -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,6 +102,12 @@
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 have the same stack_addr and code_addr but are distinct
+ due to some other qualification (e.g. the ia64 uses a register
+ stack which is distinct from the memory stack). */
+ CORE_ADDR special_addr;
};
/* Methods for constructing and comparing Frame IDs.
@@ -120,9 +124,19 @@
/* 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. */
+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). */
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: RFA: frame id enhancement
2003-10-06 21:15 RFA: frame id enhancement J. Johnston
@ 2003-10-14 21:59 ` J. Johnston
2003-10-15 21:09 ` Andrew Cagney
1 sibling, 0 replies; 13+ messages in thread
From: J. Johnston @ 2003-10-14 21:59 UTC (permalink / raw)
To: J. Johnston; +Cc: gdb-patches
Ping.
J. Johnston wrote:
> The following patch enhances the frame id support to allow an architecture
> to set a special address for the frame. This enables architectures such
> as the
> ia64 (which has a 2nd stack) to properly mark distinct frames. I added a
> new routine that builds frame ids that has a special address parameter.
> The
> current frame_id_build() has been changed to call the new routine with a
> default
> special address of 0. This means that existing calls to
> frame_id_build() require
> no changes.
>
> Ok to commit to mainline?
>
> -- Jeff J.
>
> 2003-10-06 Jeff Johnston <jjohnstn@redhat.com>
>
> * frame.h (struct frame_id): Add new field: special_addr.
> (frame_id_build_special): New prototype.
> * frame.c (frame_id_build_special): New function.
> (frame_id_build): Change to call frame_id_build_special().
> (frame_id_eq): Change to also test special_addr field.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: RFA: frame id enhancement
2003-10-06 21:15 RFA: frame id enhancement J. Johnston
2003-10-14 21:59 ` J. Johnston
@ 2003-10-15 21:09 ` Andrew Cagney
2003-10-15 23:12 ` J. Johnston
1 sibling, 1 reply; 13+ messages in thread
From: Andrew Cagney @ 2003-10-15 21:09 UTC (permalink / raw)
To: J. Johnston; +Cc: gdb-patches
> @@ -288,6 +297,9 @@
> eq = 0;
> else if (l.stack_addr != r.stack_addr)
> /* If .stack addresses are different, the frames are different. */
> + eq = 0;
> + else if (l.special_addr != r.special_addr)
> + /* If .special addresses are different, the frames are different. */
> eq = 0;
> else if (l.code_addr == 0 || r.code_addr == 0)
> /* A zero code addr is a wild card, always succeed. */
Looking at the full code:
> int
> frame_id_eq (struct frame_id l, struct frame_id r)
> {
> int eq;
> if (l.stack_addr == 0 || r.stack_addr == 0)
> /* Like a NaN, if either ID is invalid, the result is false. */
> eq = 0;
> else if (l.stack_addr != r.stack_addr)
> /* If .stack addresses are different, the frames are different. */
> eq = 0;
> 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. */
> eq = 1;
> else
> /* No luck. */
> eq = 0;
> if (frame_debug)
> {
> fprintf_unfiltered (gdb_stdlog, "{ frame_id_eq (l=");
> fprint_frame_id (gdb_stdlog, l);
> fprintf_unfiltered (gdb_stdlog, ",r=");
> fprint_frame_id (gdb_stdlog, r);
> fprintf_unfiltered (gdb_stdlog, ") -> %d }\n", eq);
> }
> return eq;
> }
Is there a need to allow wild card SPECIAL_ADDRs here? The user can
specify:
(gdb) frame <frame-id-stack-addr>
and on some architectures:
(gdb) frame <frame-id.stack-addr> <frame-id.code-addr>
and have GDB jump to that frame. It relies on the wild-card mechanism
to give approx matches (otherwize the user will have to fully specify
<stack-addr>, <code-addr> and <special-addr>).
Looking at:
> int
> frame_id_inner (struct frame_id l, struct frame_id r)
> {
> int inner;
> if (l.stack_addr == 0 || r.stack_addr == 0)
> /* Like NaN, any operation involving an invalid ID always fails. */
> inner = 0;
> else
> /* 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). */
> inner = INNER_THAN (l.stack_addr, r.stack_addr);
> if (frame_debug)
> {
> fprintf_unfiltered (gdb_stdlog, "{ frame_id_inner (l=");
> fprint_frame_id (gdb_stdlog, l);
> fprintf_unfiltered (gdb_stdlog, ",r=");
> fprint_frame_id (gdb_stdlog, r);
> fprintf_unfiltered (gdb_stdlog, ") -> %d }\n", inner);
> }
> return inner;
> }
does SPECIAL_ADDR add further ordering? If it doesn't then the comment
needs to be updated (and the description in "frame.h" clarified).
Andrew
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: RFA: frame id enhancement
2003-10-15 21:09 ` Andrew Cagney
@ 2003-10-15 23:12 ` J. Johnston
2003-10-16 16:09 ` Andrew Cagney
0 siblings, 1 reply; 13+ messages in thread
From: J. Johnston @ 2003-10-15 23:12 UTC (permalink / raw)
To: Andrew Cagney; +Cc: gdb-patches
Andrew Cagney wrote:
>> @@ -288,6 +297,9 @@
>> eq = 0;
>> else if (l.stack_addr != r.stack_addr)
>> /* If .stack addresses are different, the frames are different. */
>> + eq = 0;
>> + else if (l.special_addr != r.special_addr)
>> + /* If .special addresses are different, the frames are
>> different. */
>> eq = 0;
>> else if (l.code_addr == 0 || r.code_addr == 0)
>> /* A zero code addr is a wild card, always succeed. */
>
>
> Looking at the full code:
>
>> int
>> frame_id_eq (struct frame_id l, struct frame_id r)
>> {
>> int eq;
>> if (l.stack_addr == 0 || r.stack_addr == 0)
>> /* Like a NaN, if either ID is invalid, the result is false. */
>> eq = 0;
>> else if (l.stack_addr != r.stack_addr)
>> /* If .stack addresses are different, the frames are different. */
>> eq = 0;
>> 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. */
>> eq = 1;
>> else
>> /* No luck. */
>> eq = 0;
>> if (frame_debug)
>> {
>> fprintf_unfiltered (gdb_stdlog, "{ frame_id_eq (l=");
>> fprint_frame_id (gdb_stdlog, l);
>> fprintf_unfiltered (gdb_stdlog, ",r=");
>> fprint_frame_id (gdb_stdlog, r);
>> fprintf_unfiltered (gdb_stdlog, ") -> %d }\n", eq);
>> }
>> return eq;
>> }
>
>
> Is there a need to allow wild card SPECIAL_ADDRs here? The user can
> specify:
> (gdb) frame <frame-id-stack-addr>
> and on some architectures:
> (gdb) frame <frame-id.stack-addr> <frame-id.code-addr>
> and have GDB jump to that frame. It relies on the wild-card mechanism
> to give approx matches (otherwize the user will have to fully specify
> <stack-addr>, <code-addr> and <special-addr>).
>
Hmm, good point. I see arguments for either choice. IMO, it would be best to
make it easier for the user for the most common case. The most common case will
use the stack so the stack addr is enough to distinguish the frame. If a false
match is made, the end-user still has the option to specify more information.
I will change this.
> Looking at:
>
>> int
>> frame_id_inner (struct frame_id l, struct frame_id r)
>> {
>> int inner;
>> if (l.stack_addr == 0 || r.stack_addr == 0)
>> /* Like NaN, any operation involving an invalid ID always fails. */
>> inner = 0;
>> else
>> /* 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). */
>> inner = INNER_THAN (l.stack_addr, r.stack_addr);
>> if (frame_debug)
>> {
>> fprintf_unfiltered (gdb_stdlog, "{ frame_id_inner (l=");
>> fprint_frame_id (gdb_stdlog, l);
>> fprintf_unfiltered (gdb_stdlog, ",r=");
>> fprint_frame_id (gdb_stdlog, r);
>> fprintf_unfiltered (gdb_stdlog, ") -> %d }\n", inner);
>> }
>> return inner;
>> }
>
>
> does SPECIAL_ADDR add further ordering? If it doesn't then the comment
> needs to be updated (and the description in "frame.h" clarified).
>
Another good point. Yes, it does in this case. Two frames could both not use
the stack but one will definitely move the special_addr. I need to add a
SPECIAL_INNER_THAN macro which can default to false and must be overridden by
the platform.
-- Jeff J.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: RFA: frame id enhancement
2003-10-15 23:12 ` J. Johnston
@ 2003-10-16 16:09 ` Andrew Cagney
2003-10-16 19:06 ` J. Johnston
0 siblings, 1 reply; 13+ messages in thread
From: Andrew Cagney @ 2003-10-16 16:09 UTC (permalink / raw)
To: J. Johnston; +Cc: Andrew Cagney, gdb-patches
>> int
>> frame_id_inner (struct frame_id l, struct frame_id r)
>> {
>> int inner;
>> if (l.stack_addr == 0 || r.stack_addr == 0)
>> /* Like NaN, any operation involving an invalid ID always fails. */
>> inner = 0;
>> else
>> /* 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). */
>> inner = INNER_THAN (l.stack_addr, r.stack_addr);
>> if (frame_debug)
>> {
>> fprintf_unfiltered (gdb_stdlog, "{ frame_id_inner (l=");
>> fprint_frame_id (gdb_stdlog, l);
>> fprintf_unfiltered (gdb_stdlog, ",r=");
>> fprint_frame_id (gdb_stdlog, r);
>> fprintf_unfiltered (gdb_stdlog, ") -> %d }\n", inner);
>> }
>> return inner;
>> }
>>
>>
>> does SPECIAL_ADDR add further ordering? If it doesn't then the comment needs to be updated (and the description in "frame.h" clarified).
>
>
> Another good point. Yes, it does in this case. Two frames could both not use the stack but one will definitely move the special_addr. I need to add a SPECIAL_INNER_THAN macro which can default to false and must be overridden by the platform.
Is there real value add in having SPECIAL_INNER_THAN though? It would
only be called by frame_id_inner. Looking at how that method is used:
> frame.c:354: if (frame_id_inner (id, this))
In frame_find_by_id: Its sole purpose is to act as a short circuit for
the unlikely case where the ID isn't present in the frame. A stonger
frame_id_inner has little value add.
> frame.c:1909: && frame_id_inner (get_frame_id (this_frame),
In get_prev_frame: Its a sainity check to detect what appears to be a
badly corrupt stack. Marginal value add?
> infrun.c:2094: && (frame_id_inner (get_frame_id (get_current_frame ()),
Commented out.
> infrun.c:2383: if (frame_id_inner (current_frame, step_frame_id))
Received a signal. Given that a predicate to the call is:
&& INNER_THAN (read_sp (), step_sp))
the code's assumed that a signal modifies frame_id.stack_addr, so there
is no value add. It might be useful to clarify this assumption though.
> infrun.c:2477: && frame_id_inner (step_frame_id,
It's the reverse of infrun.c:2383 where the inferior is falling out of a
singnal trampoline, I think the assumptions again hold.
> infrun.c:2641: if (!(frame_id_inner (current_frame, step_frame_id)))
"Trust me" there's no value add. While the comment reads:
/* In the case where we just stepped out of a function into the
middle of a line of the caller, continue stepping, but
step_frame_id must be modified to current frame */
The test also updates step_frame_id when switching between frameless
stackless leaf function. The extra test wouldn't fix that problem.
I'll try to remember to add some comments to that code.
Andrew
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: RFA: frame id enhancement
2003-10-16 16:09 ` Andrew Cagney
@ 2003-10-16 19:06 ` J. Johnston
2003-10-16 21:06 ` Andrew Cagney
0 siblings, 1 reply; 13+ messages in thread
From: J. Johnston @ 2003-10-16 19:06 UTC (permalink / raw)
To: Andrew Cagney; +Cc: gdb-patches
[-- Attachment #1: Type: text/plain, Size: 3232 bytes --]
Andrew Cagney wrote:
>
>>> int
>>> frame_id_inner (struct frame_id l, struct frame_id r)
>>> {
>>> int inner;
>>> if (l.stack_addr == 0 || r.stack_addr == 0)
>>> /* Like NaN, any operation involving an invalid ID always fails. */
>>> inner = 0;
>>> else
>>> /* 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). */
>>> inner = INNER_THAN (l.stack_addr, r.stack_addr);
>>> if (frame_debug)
>>> {
>>> fprintf_unfiltered (gdb_stdlog, "{ frame_id_inner (l=");
>>> fprint_frame_id (gdb_stdlog, l);
>>> fprintf_unfiltered (gdb_stdlog, ",r=");
>>> fprint_frame_id (gdb_stdlog, r);
>>> fprintf_unfiltered (gdb_stdlog, ") -> %d }\n", inner);
>>> }
>>> return inner;
>>> }
>>>
>>>
>>> does SPECIAL_ADDR add further ordering? If it doesn't then the
>>> comment needs to be updated (and the description in "frame.h"
>>> clarified).
>
>
>>
>>
>> Another good point. Yes, it does in this case. Two frames could both
>> not use the stack but one will definitely move the special_addr. I
>> need to add a SPECIAL_INNER_THAN macro which can default to false and
>> must be overridden by the platform.
>
>
> Is there real value add in having SPECIAL_INNER_THAN though? It would
> only be called by frame_id_inner. Looking at how that method is used:
>
>> frame.c:354: if (frame_id_inner (id, this))
>
> In frame_find_by_id: Its sole purpose is to act as a short circuit for
> the unlikely case where the ID isn't present in the frame. A stonger
> frame_id_inner has little value add.
>
>> frame.c:1909: && frame_id_inner (get_frame_id (this_frame),
>
> In get_prev_frame: Its a sainity check to detect what appears to be a
> badly corrupt stack. Marginal value add?
>
>> infrun.c:2094: && (frame_id_inner (get_frame_id
>> (get_current_frame ()),
>
> Commented out.
>
>> infrun.c:2383: if (frame_id_inner (current_frame, step_frame_id))
>
> Received a signal. Given that a predicate to the call is:
> && INNER_THAN (read_sp (), step_sp))
> the code's assumed that a signal modifies frame_id.stack_addr, so there
> is no value add. It might be useful to clarify this assumption though.
>
>> infrun.c:2477: && frame_id_inner (step_frame_id,
>
> It's the reverse of infrun.c:2383 where the inferior is falling out of a
> singnal trampoline, I think the assumptions again hold.
>
>> infrun.c:2641: if (!(frame_id_inner (current_frame, step_frame_id)))
>
> "Trust me" there's no value add. While the comment reads:
> /* In the case where we just stepped out of a function into the
> middle of a line of the caller, continue stepping, but
> step_frame_id must be modified to current frame */
> The test also updates step_frame_id when switching between frameless
> stackless leaf function. The extra test wouldn't fix that problem. I'll
> try to remember to add some comments to that code.
>
> Andrew
>
Ok, that simplifies things. I have included a revised patch that allows for the
wild-card scenario.
Ok?
-- Jeff J.
[-- Attachment #2: frame-special.patch --]
[-- Type: text/plain, Size: 3972 bytes --]
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 6 Oct 2003 21:07: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)
{
@@ -288,6 +297,9 @@
eq = 0;
else if (l.stack_addr != r.stack_addr)
/* If .stack addresses are different, the frames are different. */
+ eq = 0;
+ else if (l.special_addr != r.special_addr)
+ /* If .special addresses are different, the frames are different. */
eq = 0;
else if (l.code_addr == 0 || r.code_addr == 0)
/* A zero code addr is a wild card, always succeed. */
Index: frame.h
===================================================================
RCS file: /cvs/src/src/gdb/frame.h,v
retrieving revision 1.109
diff -u -r1.109 frame.h
--- frame.h 28 Sep 2003 22:32:19 -0000 1.109
+++ frame.h 6 Oct 2003 21:07:52 -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,6 +102,12 @@
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 have the same stack_addr and code_addr but are distinct
+ due to some other qualification (e.g. the ia64 uses a register
+ stack which is distinct from the memory stack). */
+ CORE_ADDR special_addr;
};
/* Methods for constructing and comparing Frame IDs.
@@ -120,9 +124,19 @@
/* 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. */
+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). */
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: RFA: frame id enhancement
2003-10-16 19:06 ` J. Johnston
@ 2003-10-16 21:06 ` Andrew Cagney
2003-10-16 21:49 ` J. Johnston
0 siblings, 1 reply; 13+ messages in thread
From: Andrew Cagney @ 2003-10-16 21:06 UTC (permalink / raw)
To: J. Johnston; +Cc: gdb-patches
>
>> It's the reverse of infrun.c:2383 where the inferior is falling out of a singnal trampoline, I think the assumptions again hold.
>>
>> infrun.c:2641: if (!(frame_id_inner (current_frame, step_frame_id)))
>>
>> "Trust me" there's no value add. While the comment reads:
>> /* In the case where we just stepped out of a function into the
>> middle of a line of the caller, continue stepping, but
>> step_frame_id must be modified to current frame */
>> The test also updates step_frame_id when switching between frameless stackless leaf function. The extra test wouldn't fix that problem. I'll try to remember to add some comments to that code.
I've done this.
> Ok, that simplifies things. I have included a revised patch that allows for the wild-card scenario.
We're going to need more comments so that the next person better
understands what is going on:
+ /* 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 have the same stack_addr and code_addr but are distinct
+ due to some other qualification (e.g. the ia64 uses a register
+ stack which is distinct from the memory stack). */
+ CORE_ADDR special_addr;
can you expand this definition to to note that the value isn't ordered,
and that zero is treated as a wild card (its mentioned further down
but I think here, at the definition, is better). For the ia64, is/can
the second area be described as a register spill area rather than a
stack? If the word "stack" can be avoided, the rationale for "special"
being un-ordered is stronger.
For:
NOTE: Given frameless 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). */
an update is needed, suggest something like:
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 stackless, they
have an identical .stack_addr value, and differ only by their
unordered .code_addr .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.
and a similar update to:
frame_id_inner (struct frame_id l, struct frame_id r)
{
int inner;
if (l.stack_addr == 0 || r.stack_addr == 0)
/* Like NaN, any operation involving an invalid ID always fails. */
inner = 0;
else
/* 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). */
inner = INNER_THAN (l.stack_addr, r.stack_addr);
I can't think of a word better than "special", so I guess special it is :-)
Andrew
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: RFA: frame id enhancement
2003-10-16 21:06 ` Andrew Cagney
@ 2003-10-16 21:49 ` J. Johnston
2003-10-16 23:32 ` J. Johnston
2003-10-17 18:11 ` Kevin Buettner
0 siblings, 2 replies; 13+ messages in thread
From: J. Johnston @ 2003-10-16 21:49 UTC (permalink / raw)
To: Andrew Cagney; +Cc: gdb-patches
Andrew Cagney wrote:
>>
>>> It's the reverse of infrun.c:2383 where the inferior is falling out
>>> of a singnal trampoline, I think the assumptions again hold.
>>>
>>> infrun.c:2641: if (!(frame_id_inner (current_frame, step_frame_id)))
>>>
>>> "Trust me" there's no value add. While the comment reads:
>>> /* In the case where we just stepped out of a function into the
>>> middle of a line of the caller, continue stepping, but
>>> step_frame_id must be modified to current frame */
>>> The test also updates step_frame_id when switching between frameless
>>> stackless leaf function. The extra test wouldn't fix that problem.
>>> I'll try to remember to add some comments to that code.
>
>
> I've done this.
>
>> Ok, that simplifies things. I have included a revised patch that
>> allows for the wild-card scenario.
>
>
> We're going to need more comments so that the next person better
> understands what is going on:
>
> + /* 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 have the same stack_addr and code_addr but are distinct
> + due to some other qualification (e.g. the ia64 uses a register
> + stack which is distinct from the memory stack). */
> + CORE_ADDR special_addr;
>
> can you expand this definition to to note that the value isn't ordered,
> and that zero is treated as a wild card (its mentioned further down but
> I think here, at the definition, is better). For the ia64, is/can the
> second area be described as a register spill area rather than a stack?
> If the word "stack" can be avoided, the rationale for "special" being
> un-ordered is stronger.
>
It "is" a register stack on the ia64. Registers r32 - r127 for any frame all
come from this area. It gets bumped up by a special alloc() instruction. I'm
not sure I would call it unordered. It may be better to say that it is treated
as unordered. That would make the comments below much simpler - i.e. the
special_addr field is treated as unordered so it is never used to determine
order when comparing frames.
I can easily add the zero/wildcard comment.
> For:
>
> NOTE: Given frameless 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). */
>
> an update is needed, suggest something like:
>
> 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 stackless, they
> have an identical .stack_addr value, and differ only by their
> unordered .code_addr .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.
>
>
> and a similar update to:
>
> frame_id_inner (struct frame_id l, struct frame_id r)
> {
> int inner;
> if (l.stack_addr == 0 || r.stack_addr == 0)
> /* Like NaN, any operation involving an invalid ID always fails. */
> inner = 0;
> else
> /* 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). */
> inner = INNER_THAN (l.stack_addr, r.stack_addr);
>
> I can't think of a word better than "special", so I guess special it is :-)
>
> Andrew
>
>
>
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: RFA: frame id enhancement
2003-10-16 21:49 ` J. Johnston
@ 2003-10-16 23:32 ` J. Johnston
2003-10-17 13:30 ` Andrew Cagney
2003-10-17 18:11 ` Kevin Buettner
1 sibling, 1 reply; 13+ messages in thread
From: J. Johnston @ 2003-10-16 23:32 UTC (permalink / raw)
To: J. Johnston; +Cc: Andrew Cagney, gdb-patches
[-- Attachment #1: Type: text/plain, Size: 4207 bytes --]
J. Johnston wrote:
> Andrew Cagney wrote:
>
>>>
>>>> It's the reverse of infrun.c:2383 where the inferior is falling out
>>>> of a singnal trampoline, I think the assumptions again hold.
>>>>
>>>> infrun.c:2641: if (!(frame_id_inner (current_frame, step_frame_id)))
>>>>
>>>> "Trust me" there's no value add. While the comment reads:
>>>> /* In the case where we just stepped out of a function into the
>>>> middle of a line of the caller, continue stepping, but
>>>> step_frame_id must be modified to current frame */
>>>> The test also updates step_frame_id when switching between frameless
>>>> stackless leaf function. The extra test wouldn't fix that problem.
>>>> I'll try to remember to add some comments to that code.
>>
>>
>>
>> I've done this.
>>
>>> Ok, that simplifies things. I have included a revised patch that
>>> allows for the wild-card scenario.
>>
>>
>>
>> We're going to need more comments so that the next person better
>> understands what is going on:
>>
>> + /* 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 have the same stack_addr and code_addr but are distinct
>> + due to some other qualification (e.g. the ia64 uses a register
>> + stack which is distinct from the memory stack). */
>> + CORE_ADDR special_addr;
>>
>> can you expand this definition to to note that the value isn't
>> ordered, and that zero is treated as a wild card (its mentioned
>> further down but I think here, at the definition, is better). For the
>> ia64, is/can the second area be described as a register spill area
>> rather than a stack? If the word "stack" can be avoided, the rationale
>> for "special" being un-ordered is stronger.
>>
>
> It "is" a register stack on the ia64. Registers r32 - r127 for any
> frame all come from this area. It gets bumped up by a special alloc()
> instruction. I'm not sure I would call it unordered. It may be better
> to say that it is treated as unordered. That would make the comments
> below much simpler - i.e. the special_addr field is treated as unordered
> so it is never used to determine order when comparing frames.
>
> I can easily add the zero/wildcard comment.
>
>> For:
>>
>> NOTE: Given frameless 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). */
>>
>> an update is needed, suggest something like:
>>
>> 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 stackless, they
>> have an identical .stack_addr value, and differ only by their
>> unordered .code_addr .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.
>>
>>
>> and a similar update to:
>>
>> frame_id_inner (struct frame_id l, struct frame_id r)
>> {
>> int inner;
>> if (l.stack_addr == 0 || r.stack_addr == 0)
>> /* Like NaN, any operation involving an invalid ID always fails. */
>> inner = 0;
>> else
>> /* 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). */
>> inner = INNER_THAN (l.stack_addr, r.stack_addr);
>>
>> I can't think of a word better than "special", so I guess special it
>> is :-)
>>
Is the revised attached patch ok?
-- Jeff J.
[-- Attachment #2: frame_special.patch --]
[-- Type: text/plain, Size: 6014 bytes --]
Index: 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)
{
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: RFA: frame id enhancement
2003-10-16 23:32 ` J. Johnston
@ 2003-10-17 13:30 ` Andrew Cagney
2003-10-17 16:32 ` J. Johnston
0 siblings, 1 reply; 13+ messages in thread
From: Andrew Cagney @ 2003-10-17 13:30 UTC (permalink / raw)
To: J. Johnston; +Cc: gdb-patches
> 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)
> {
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: RFA: frame id enhancement
2003-10-17 13:30 ` Andrew Cagney
@ 2003-10-17 16:32 ` J. Johnston
0 siblings, 0 replies; 13+ messages in thread
From: J. Johnston @ 2003-10-17 16:32 UTC (permalink / raw)
To: Andrew Cagney; +Cc: gdb-patches
Patch checked into mainline. Thanks.
-- Jeff J.
Andrew Cagney wrote:
>
>> 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)
>> {
>
>
>
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: RFA: frame id enhancement
2003-10-16 21:49 ` J. Johnston
2003-10-16 23:32 ` J. Johnston
@ 2003-10-17 18:11 ` Kevin Buettner
2003-10-17 19:34 ` J. Johnston
1 sibling, 1 reply; 13+ messages in thread
From: Kevin Buettner @ 2003-10-17 18:11 UTC (permalink / raw)
To: J. Johnston, Andrew Cagney; +Cc: gdb-patches
On Oct 16, 5:49pm, J. Johnston wrote:
> It "is" a register stack on the ia64. Registers r32 - r127 for any frame all
> come from this area. It gets bumped up by a special alloc() instruction. I'm
> not sure I would call it unordered. It may be better to say that it is treated
> as unordered. That would make the comments below much simpler - i.e. the
> special_addr field is treated as unordered so it is never used to determine
> order when comparing frames.
For IA-64, the backing store most certainly is ordered. It is quite
possible to have a bunch of consecutive frames which all have the same
"sp" value. For these frames, older frames will have smaller bsp values
than newer frames. (I.e, the backing store stack grows from lower
addresses toward higher addresses.)
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: RFA: frame id enhancement
2003-10-17 18:11 ` Kevin Buettner
@ 2003-10-17 19:34 ` J. Johnston
0 siblings, 0 replies; 13+ messages in thread
From: J. Johnston @ 2003-10-17 19:34 UTC (permalink / raw)
To: Kevin Buettner; +Cc: Andrew Cagney, gdb-patches
Kevin Buettner wrote:
> On Oct 16, 5:49pm, J. Johnston wrote:
>
>
>>It "is" a register stack on the ia64. Registers r32 - r127 for any frame all
>>come from this area. It gets bumped up by a special alloc() instruction. I'm
>>not sure I would call it unordered. It may be better to say that it is treated
>>as unordered. That would make the comments below much simpler - i.e. the
>>special_addr field is treated as unordered so it is never used to determine
>>order when comparing frames.
>
>
> For IA-64, the backing store most certainly is ordered. It is quite
> possible to have a bunch of consecutive frames which all have the same
> "sp" value. For these frames, older frames will have smaller bsp values
> than newer frames. (I.e, the backing store stack grows from lower
> addresses toward higher addresses.)
>
Just to clarify, I was referring to two different "it"s above. What I meant to
say was "I wouldn't call the special field unordered". Sorry for the confusion.
The special field may or may not be an ordered value, but generically, it
should be treated as unordered which is why I made the clarification in the comment.
-- Jeff J.
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2003-10-17 19:34 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-10-06 21:15 RFA: frame id enhancement 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
2003-10-17 16:32 ` J. Johnston
2003-10-17 18:11 ` Kevin Buettner
2003-10-17 19:34 ` J. Johnston
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox