Robustify frame_unwind_address_in_block heuristic?

[Frederic RISS <frederic.riss@st.com>]

Hi,

frame_unwind_address_in_block contains the following code:

  /* If THIS frame is not inner most (i.e., NEXT isn't the sentinel),
     and NEXT is `normal' (i.e., not a sigtramp, dummy, ....) THIS
     frame's PC ends up pointing at the instruction fallowing the
     "call".  Adjust that PC value so that it falls on the call
     instruction (which, hopefully, falls within THIS frame's code
     block).  So far it's proved to be a very good approximation.  See
     get_frame_type() for why ->type can't be used.  */
  if (next_frame->level >= 0
      && get_frame_type (next_frame) == NORMAL_FRAME)
    --pc;

and indeed, this has proved to be a very good and useful approximation. 

However, I'm facing a little issue with this. I've developed a custom
frame unwinder for some project. It unwinds over some asm stubs which do
branch to regular C code, but which also set the link register
(containing the return address) to the entry of some other asm that
finishes the stub's work (let's call that ret_stub).

During a debug session, the dwarf2 unwinder finds the ret_stub return
address and my custom unwinder kicks in to unwind to the following
frame... which all seems right except for one little glitch: when
printing the ret_stub frame, the above heuristic decrements the return
address and points to a symbol that has no other relevance in the
backtrace than being the one that happens to be linked just before
ret_stub. Quite confusing for the user.

I have to admit that the above is a convoluted case which shouldn't show
up in a 'standard' debug session. It's also not the first time I wish
that frame unwinders were more flexible/modular, but it's the first time
that I wasn't able to work around the issue without patching GDB's core
functionality. Would it be acceptable to add a check to the above
function that checks whether pc-1 points into the same function as pc?
Or maybe someone sees another way to prevent that issue?

Thanks,
Fred.