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.