From 280ef1e68789ef7ef82048b8a772a57203750495 Mon Sep 17 00:00:00 2001 From: Denys Vlasenko Date: Mon, 1 Feb 2010 15:46:18 +0100 Subject: CCpp: explain why we give "file BINRY_NAME" to gdb. Signed-off-by: Denys Vlasenko --- lib/Plugins/CCpp.cpp | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) (limited to 'lib/Plugins') diff --git a/lib/Plugins/CCpp.cpp b/lib/Plugins/CCpp.cpp index 5838bc45..b6305a23 100644 --- a/lib/Plugins/CCpp.cpp +++ b/lib/Plugins/CCpp.cpp @@ -287,12 +287,25 @@ static void GetBacktrace(const char *pDebugDumpDir, } args[3] = (char*)dfd.c_str(); - /* + /* "file BINARY_FILE" is needed, without it gdb cannot properly + * unwind the stack. Currently the unwind information is located + * in .eh_frame which is stored only in binary, not in coredump + * or debuginfo. + * + * Fedora GDB does not strictly need it, it will find the binary + * by its build-id. But for binaries either without build-id + * (=built on non-Fedora GCC) or which do not have + * their debuginfo rpm installed gdb would not find BINARY_FILE + * so it is still makes sense to supply "file BINARY_FILE". + * * Unfortunately, "file BINARY_FILE" doesn't work well if BINARY_FILE * was deleted (as often happens during system updates): * gdb uses specified BINARY_FILE * even if it is completely unrelated to the coredump * See https://bugzilla.redhat.com/show_bug.cgi?id=525721 + * + * TODO: check mtimes on COREFILE and BINARY_FILE and not supply + * BINARY_FILE if it is newer (to at least avoid gdb complaining). */ args[4] = (char*)"-ex"; string file = ssprintf("file %s", executable.c_str()); -- cgit