This is the mail archive of the
mailing list for the GDB project.
RE: [patch v4 18/24] record-btrace: extend unwinder
- From: "Metzger, Markus T" <markus dot t dot metzger at intel dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Mon, 16 Sep 2013 11:21:29 +0000
- Subject: RE: [patch v4 18/24] record-btrace: extend unwinder
- Authentication-results: sourceware.org; auth=none
- References: <1372842874-28951-1-git-send-email-markus dot t dot metzger at intel dot com> <1372842874-28951-19-git-send-email-markus dot t dot metzger at intel dot com> <20130818190842 dot GN24153 at host2 dot jankratochvil dot net>
> -----Original Message-----
> From: Jan Kratochvil [mailto:firstname.lastname@example.org]
> Sent: Sunday, August 18, 2013 9:09 PM
> > An assertion in get_frame_id at frame.c:340 requires that a frame
> > provides a stack address. The record-btrace unwinder can't provide
> > this since the trace does not contain data. I incorrectly set
> > stack_addr_p to 1 to avoid the assertion.
> Primarily record-btrace can provide the stack address. You know $sp at the
> end of the recoding and you can query .eh_frame/.debug_frame at any PC
> address what is the difference between $sp and caller's $sp at that exact PC.
> This assumes either all the involved binaries were built with -fasynchronous-
> unwind-tables (for .eh_frame) or that debug info (for .debug_frame) is
> present. The former is true in Fedora / Red Hat distros, unaware how others.
This would only hold for functions that have not yet returned to their caller.
If we go back far enough, the branch trace will also contain functions that
have already returned to their caller for which we do not have any information.
I would even argue that this is the majority of functions in the branch trace.
> The current method of constant STACK_ADDR may have some problems with
> frame_id_inner() but I did not investigate it more.
By looking at the code, frame_id_inner () should always fail since all btrace
frames have stack_addr == 0.
On the other hand, frame_id_inner is only called for frames of type
NORMAL_FRAME, whereas btrace frames have type BTRACE_FRAME.
> > When evaluating arguments for printing the stack back trace, there's
> > an ugly error displayed: "error reading variable: can't compute CFA for this
> > The error is correct, we can't compute the CFA since we don't have the
> > stack at that time, but it is rather annoying at this place and makes
> > the back trace difficult to read.
This has meanwhile been resolved. This had been a side-effect of throwing
an error in to_fetch_registers. When I just return, function arguments are
correctly displayed as unavailable and the "can't compute CFA for this frame"
message is gone.
> > + if (bfun == NULL)
> > + return "<none>";
I replaced this with ??.
> > +
> > + msym = bfun->msym;
> > + sym = bfun->sym;
> > +
> > + if (sym != NULL)
> > + return SYMBOL_PRINT_NAME (sym);
> > + else if (msym != NULL)
> > + return SYMBOL_PRINT_NAME (msym);
> > + else
> > + return "<unknown>";
I replaced this with ??.
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