Re: Robustify frame_unwind_address_in_block heuristic?

[Frederic RISS <frederic dot riss at st dot com>]

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.