This is the mail archive of the
mailing list for the GDB project.
Re: Command to break before exiting stack frame?
- From: Justin Paston-Cooper <paston dot cooper at gmail dot com>
- To: Simon Marchi <simon dot marchi at polymtl dot ca>
- Cc: gdb at sourceware dot org
- Date: Sun, 17 Mar 2019 13:58:48 +0000
- Subject: Re: Command to break before exiting stack frame?
- References: <CAEndGgToidTsVOhwvV=9RFf=nYWwK+3_qWheYJ8JtoNez3Pq8w@mail.gmail.com> <firstname.lastname@example.org> <email@example.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
static int f (int x);
f (int x)
if (x == 0)
return f(x - 1);
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 <firstname.lastname@example.org> wrote:
> On 2019-03-16 20:00, Andreas Schwab wrote:
> > On Mär 16 2019, Justin Paston-Cooper <email@example.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?