Re: Command to break before exiting stack frame?

[Justin Paston-Cooper <paston dot cooper at gmail dot com>]

I accidentally replied to Andreas's email without CCing the list.
Simon has addressed the jump issue. Does gcc emit jump tables when
optimisation options are not enabled anyway?

 On tail calls: I tested the behaviour of the "finish" command with a
tail-recursive function in following code, with the following gdb
commands:

------------------------------

static int f (int x);

int
main(void)
{
  f(5);
}

static int
f (int x)
{
  if (x == 0)
    {
      return 0;
    }
  else
    {
      return f(x - 1);
    }
}

------------------------------

break f
commands
finish
end

------------------------------

Given its documentation, I would have expected the "finish" command to
print the returned value at each tail call. It turns out that it
prints the returned value only for the f(0) call. I would similarly
expect a "break on exit" command to break on the exit of the frame in
which it is called even if a tail-recursion occurs. Is there a reason
that it doesn't? My first thought would be tail-call optimisation, but
in any case breaks on tail-calls of the function still work fine, and
when I disassembled the function, I saw that no tail-call optimisation
occurred in my case.

On the actual implementation of this command: Is the implementation of
such a feature feasible? If so, how much work would it take? I would
certainly be interested in helping, although I don't yet have any
experience with working on compilers/debuggers.


On Sun, 17 Mar 2019 at 00:23, Simon Marchi <simon.marchi@polymtl.ca> wrote:
>
> On 2019-03-16 20:00, Andreas Schwab wrote:
> > On Mär 16 2019, Justin Paston-Cooper <paston.cooper@gmail.com> wrote:
> >
> >> I can't imagine that I am the first person to suggest or request this.
> >> Are
> >> there any architectural or practical reasons as to why this is might
> >> be
> >> difficult?
> >
> > There may not even be a place where the frame is exited in the current
> > function due to tail call.  Also, inline literal pools or jump tables
> > can result in false positives when searching for return insns.
> >
> > Andreas.
>
> I suppose that the list of all function exit points (regardless of
> whether it is a jump or real return) is an information that the compiler
> could theoretically produce and encode in the DWARF information?
>
> Simon