RE: [patch v4 24/24] record-btrace: skip tail calls in back trace

["Metzger, Markus T" <markus dot t dot metzger at intel dot com>]

> -----Original Message-----
> From: gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] On Behalf Of Jan Kratochvil


> > The branch trace represents the caller/callee relationship of tail
> > calls.  The caller of a tail call is shown in the back trace and in
> > the function-call history.
> >
> > This is not consistent with GDB's normal behavior, where the tail
> > caller is not shown in the back trace.
> 
> This depends on the compiler and its options.  With recent GCCs and -O2 -g
> compilation tail calls are shown.  They are even tested for (full) reverse
> execution:
> Running ./gdb.reverse/amd64-tailcall-reverse.exp ...
> Running ./gdb.arch/amd64-tailcall-ret.exp ...
> Running ./gdb.arch/amd64-tailcall-cxx.exp ...
> Running ./gdb.arch/amd64-tailcall-noret.exp ...
> 
> In the -O0 -g mode they are not shown just because of the lack of debug
> info.
> AFAIK it is too expensive for GCC to produce it while -O0 -g compilation
> should be fast.
> 
> Surprisingly this gives in some cases -O2 -g compilation better debugging
> experience than -O0 -g compilation.

>From this perspective, this would actually be a feature that we have tail
calls available also in the call stack for reverse/replay even if we did not
have them for live debugging due to limited debug information.


> Still when I revert this GDB code patch then gdb.btrace/rn-dl-bind.exp does
> not reverse-next properly - what is the reason?
> 
> reverse-next^M
> __GI_____strtoul_l_internal (nptr=<unavailable>, endptr=<unavailable>,
> base=<optimized out>, group=<optimized out>, loc=<optimized out>) at
> ../stdlib/strtol_l.c:531^M
> 531     }^M
> (gdb) FAIL: gdb.btrace/rn-dl-bind.exp: rn-dl-bind, 2.3 bt^M
> #0  __GI_____strtoul_l_internal (nptr=<unavailable>, endptr=<unavailable>,
> base=<optimized out>, group=<optimized out>, loc=<optimized out>) at
> ../stdlib/strtol_l.c:531^M
> #1  0x00007ffff7228f8d in __GI_strtoul (nptr=<error reading variable:
> Registers are not available in btrace record history>, endptr=<error reading
> variable: Registers are not available in btrace record history>, base=<error
> reading variable: Registers are not available in btrace record history>) at
> ../stdlib/strtol.c:108^M
> #2  _dl_runtime_resolve () at ../sysdeps/x86_64/dl-trampoline.S:56^M
> #3  0x00000000004004c6 in ?? ()^M
> #4  0x00000000004004fb in strtoul@plt ()^M
> #5  0x000000000040060c in test () at ./gdb.btrace/rn-dl-bind.c:26^M
> #6  0x0000000000400621 in main () at ./gdb.btrace/rn-dl-bind.c:35^M
> Backtrace stopped: not enough registers or memory available to unwind
> further^M

I need to investigate this.

At some point, get_frame_func () returns 0, which is then used for the
code in the BTRACE_FRAME id.  This doesn't look OK at first glance.


> > It further causes the finish command to fail for tail calls.
> >
> > This patch skips tail calls when computing the back trace during
> > replay.  The finish command now works also for tail calls.

There were also some fails around finish.  I did not investigate those
after I realized that stepping behaves differently for live debugging
and replay.  The fails went away once I skipped tail calls.


Regards,
Markus.

Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052