Re: RFA: frame id enhancement

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

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.