Re: RFA: frame id enhancement

[Andrew Cagney <ac131313@redhat.com>]

> 
>> 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