Hello,

We need to make a decision. We have a failed-assertion on x86-linux,
and it is a regression compared to gdb-6.8.  We have decided that
we had to fix this issue before starting the gdb-7.0 release.

This failed assertion is one symptom of the same issue that manifests
itself in several ways (I think we have at least a couple of PRs for
that).  Daniel sent a patch as an RFC, because it implements a temporary
solution to a larger design shortcoming:

> The magic outer frame ID is, IMO, a workaround.  What we really want
> is to have frame IDs wherever we can.  Either "stack address
> uncertain, but function known" or even "stack address and function
> known, but outerness detected".  This requires changes to the
> unwinding interface, and additional changes to each affected unwinder
> to build the best IDs we can and to mark the outer frame some other
> way.

The issue with the current patch is summarized:

> The obvious pitfall is that the outer frame isn't a single consistent
> frame.  So there's an ugly bit in infrun that says if we set the stack
> pointer while inside an outer frame, and suddenly we're in a frame we
> think we can unwind from (mostly incorrectly at this point), then
> we've not changed functions.  Otherwise stepping through _start will
> blow up on some platforms I tried.

The "ugly" piece in infrun.c is the following hunk:

  +  /* The outer_frame_id check is a heuristic to detect stepping
  +     through startup code.  If we step over an instruction which
  +     sets the stack pointer from an invalid value to a valid value,
  +     we may detect that as a subroutine call from the mythical
  +     "outermost" function.  This could be fixed by marking
  +     outermost frames as !stack_p,code_p,special_p.  Then the
  +     initial outermost frame, before sp was valid, would
  +     have code_addr == &_start.  See the commend in frame_id_eq
  +     for more.  */
     if (!frame_id_eq (get_stack_frame_id (frame),
                      ecs->event_thread->step_stack_frame_id)
  -      && frame_id_eq (frame_unwind_caller_id (frame),
  -                     ecs->event_thread->step_stack_frame_id))
  +      && (frame_id_eq (frame_unwind_caller_id (get_current_frame ()),
  +                      ecs->event_thread->step_stack_frame_id)
  +         && (!frame_id_eq (ecs->event_thread->step_stack_frame_id,
  +                           outer_frame_id)
  +             || step_start_function != find_pc_function (stop_pc))))

Maybe the patch is not perfect, but we're a little under pressure
if we want to release soon, and the patch itself is fairly localized.

If we want to only fix the PR that blocks us, we can try the patch that
I am attaching, which guards "info frame" against null frame IDs. It's
not very invasive, but it is at least as ugly as Daniel finds his patch
ugly, and only fixes the "info frame" command. However, if there are
objections to Daniel's patch, then my hack allows us to get going for
the relase without a major delay.

Any objection to Daniel's patch? I'm going to be aggressive here,
and apply on Friday unless someone objects. I am attaching Daniel's
patch for easier reference. Mine is attached next.

-- 
Joel