Re: [PATCHv2 1/2] gdb: prevent an assertion when computing the frame_id for an inline frame

[Simon Marchi <simon.marchi@polymtl.ca>]

On 2021-07-05 7:39 a.m., Pedro Alves wrote:
> Hi Andrew,
> 
> I've read this, and I think you came up with a reasonable solution.

I discussed this with Andrew on IRC, and my bad, I didn't post the
summary of our discussions here.

I suggested that this was confusing because get_prev_frame_if_no_cycle
now becomes get_prev_frame_if_no_cycle_except_in_some_cases, and it
makes get_prev_frame_if_no_cycle alter its behavior based on what it
thinks its caller is doing.  And it causes the inline frame's this_id
method to "lie" if it can't successfully compute the frame id, instead
of properly reporting failure.  The problem, in my opinion, is that:

 - inline_frame_this_id is currently not allowed to fail (return
   null_frame_id)
 - inline_frame_this_id uses get_prev_frame_if_no_cycle, which is
   allowed to fail (return nullptr)

So the question, in my opinion, is: how to propagate the
get_prev_frame_if_no_cycle failure up the stack.  I suggested that the
this_id method could throw a "FRAME_CYCLE_ERROR" in that case, caught
by the get_prev_frame_if_no_cycle call up the stack.  It would then
set the last physical frame's stop reason to UNWIND_SAME_ID.

I made a prototype here, which passes Andrew's test:

  https://review.lttng.org/c/binutils-gdb/+/6122

I prefer this option because it avoids adding special cases.  If the id
can't be computed, this_id throws and that's it, the caller decides what
to do with it.  But if people prefer the original solution, I don't
mind :).

Simon