Re: [PATCH v2] gdb/arm: Stop unwinding on error, but do not assert

[Luis Machado <luis.machado@arm.com>]

On 10/13/22 12:21, Pedro Alves wrote:
> On 2022-10-13 10:17 a.m., Torbjörn SVENSSON via Gdb-patches wrote:
> 
>> +  /* Unwind of this frame is not possible.  Return outer_frame_id to stop the
>> +     unwinding.  */
>> +  if (cache == NULL)
>> +    {
>> +      *this_id = outer_frame_id;
>> +      return;
>> +    }
> 
> Please let's not add more uses of outer_frame_id if we can avoid it.  We're getting
> close to eliminating it.  Can a cache object still be returned, and then a frame id
> be successfully computed?

Sorry, is that deprecation of outer_frame_id documented somewhere? I haven't seen any warnings or
comments stating it is not supposed to be used.

It was even made more explicit with this commit:

commit 84154d166a1a4592c70e2a8296d5df0ad7f89be9
Author: Simon Marchi <simon.marchi@efficios.com>
Date:   Mon Aug 31 13:23:12 2020 -0400

     gdb: introduce explicit outer frame id kind


So this is a bit confusing.

> 
> You can stop the unwinding in some other way.  For example, arm_m_exception_cache has a few
> of these:
> 
> 	      /* Terminate any further stack unwinding by referring to self.  */
> 	      arm_cache_set_active_sp_value (cache, tdep, sp);
> 	      return cache;
> 
> (Not sure exactly how that works.)

It probably works by creating a cycle that will be detected by the unwinding machinery.

> 
> Alternatively, you can implement a frame_unwind::stop_reason callback and return
> UNWIND_OUTERMOST, which is already done in arm-tdep.c in other scenarios too.

Maybe we should clarify these uses. It is nice to be able to stop unwinding gracefully, as opposed
to issuing a warning like "previous frame inner to this frame (corrupt stack?)".

It seems UNWIND_OUTERMOST might be able to do that.