Re: RFA: frame id enhancement

["J. Johnston" <jjohnstn@redhat.com>]

[-- 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).  */