Robustify frame_unwind_address_in_block heuristic?

Robustify frame_unwind_address_in_block heuristic?

[Frederic RISS]

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.

Re: Robustify frame_unwind_address_in_block heuristic?

[Daniel Jacobowitz]

On Wed, Oct 01, 2008 at 04:41:42PM +0200, Frederic RISS wrote:
> 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?

No.  That's exactly the issue this code was written to handle :-)

> Or maybe someone sees another way to prevent that issue?

I don't see how to generically handle this case unless you can
distinguish it from this example:

my_function:
	do_stuff
	call noreturn_function
unrelated_function:
	do_unrelated_stuff

But there's rarely anything to handle the special kind of call in your
'returned-to' function, so from what's on the stack, I don't know how
we can tell.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Robustify frame_unwind_address_in_block heuristic?

[Frederic RISS]

Le mercredi 01 octobre 2008 à 10:47 -0400, Daniel Jacobowitz a écrit :
> On Wed, Oct 01, 2008 at 04:41:42PM +0200, Frederic RISS wrote:
> > 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?
> 
> No.  That's exactly the issue this code was written to handle :-)

Really? I always thought the main motivation was showing the call site
in the backtrace rather than the return site (when they are different).
But yes, I hadn't thought about the handling of noreturn functions which
are rather more common than my stubs :-)

> > Or maybe someone sees another way to prevent that issue?
> 
> I don't see how to generically handle this case unless you can
> distinguish it from this example:
> 
> my_function:
> 	do_stuff
> 	call noreturn_function
> unrelated_function:
> 	do_unrelated_stuff
> 
> But there's rarely anything to handle the special kind of call in your
> 'returned-to' function, so from what's on the stack, I don't know how
> we can tell.

Of course we can't :-(, at least not in a generic way. I know the
exceptions to the rule in my application, but unfortunately there's no
way to feed this information into the frame unwinding machinery.

Well, I guess I need to stick with my ugly patch to frame.c. 

Thanks for the fast answer!
Fred.

Re: Robustify frame_unwind_address_in_block heuristic?

[Joel Brobecker]

> But there's rarely anything to handle the special kind of call in your
> 'returned-to' function, so from what's on the stack, I don't know how
> we can tell.

Perhaps there is some information either in the ret_stub or the called
function that would allow get_frame_pc () to detect it, and thus massage
the returned value by adding 1 so that get_frame_address_in_block
returns the address at the start of the stub.  Seems pretty hacky,
but might work.

That being said, the backtrace must be strange, because instead of
seeing the real caller in the backtrace, you see the ret_stub?

-- 
Joel

Re: Robustify frame_unwind_address_in_block heuristic?

[Frederic RISS]

Le mercredi 01 octobre 2008 à 08:28 -0700, Joel Brobecker a écrit :
> > But there's rarely anything to handle the special kind of call in your
> > 'returned-to' function, so from what's on the stack, I don't know how
> > we can tell.
> 
> Perhaps there is some information either in the ret_stub or the called
> function that would allow get_frame_pc () to detect it, and thus massage
> the returned value by adding 1 so that get_frame_address_in_block
> returns the address at the start of the stub.  Seems pretty hacky,
> but might work.

Yeah, I might throw another unwinder in the game that 'proxies' the
dwarf frame and returns ret_stub+1 as PC. Not really nice but it might
work.

> That being said, the backtrace must be strange, because instead of
> seeing the real caller in the backtrace, you see the ret_stub?

Well, when the user sees ret_from_irq_stub in the backtrace, she can
understand something... when she sees frobnicate_with_my_bits (or some
other unrelated stuff with a not-so-funny name) she's totally lost.

Fred