From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14705 invoked by alias); 15 Sep 2011 17:49:07 -0000 Received: (qmail 14678 invoked by uid 22791); 15 Sep 2011 17:49:03 -0000 X-SWARE-Spam-Status: No, hits=-6.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 15 Sep 2011 17:48:35 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p8FHmYFb026081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 15 Sep 2011 13:48:35 -0400 Received: from host1.jankratochvil.net (ovpn-116-38.ams2.redhat.com [10.36.116.38]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p8FHmWM4023033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Sep 2011 13:48:34 -0400 Received: from host1.jankratochvil.net (localhost [127.0.0.1]) by host1.jankratochvil.net (8.14.4/8.14.4) with ESMTP id p8FHmVHK031951; Thu, 15 Sep 2011 19:48:31 +0200 Received: (from jkratoch@localhost) by host1.jankratochvil.net (8.14.4/8.14.4/Submit) id p8FHmVsv031948; Thu, 15 Sep 2011 19:48:31 +0200 Date: Thu, 15 Sep 2011 17:49:00 -0000 From: Jan Kratochvil To: Martin Milata Cc: Tom Tromey , gdb@sourceware.org, Karel Klic Subject: Re: Function fingerprinting for useful backtraces in absence of debuginfo Message-ID: <20110915174831.GA30247@host1.jankratochvil.net> References: <20110915123230.GA4048@dhcp-25-199.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110915123230.GA4048@dhcp-25-199.brq.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2011-09/txt/msg00056.txt.bz2 Hi Martin, I see this was more directed at gcc people but I hope I can reply some. On Thu, 15 Sep 2011 14:32:31 +0200, Martin Milata wrote: > * The name of the function, if the corresponding binary is compiled > with function symbols (as is the case with the libraries) together > with offset into the function. This is not true for static functions in the libraries: ==> 26.c <== extern void f (void (*) (void)); static void i (void) {} int main (void) { f (i); return 0; } ==> 26l.c <== static void g (void (*h) (void)) { h (); } void f (void (*h) (void)) { g (h); } gcc -o 26l.so 26l.c -Wall -shared -fPIC -s; gcc -o 26 26.c -Wall -g ./26l.so; gdb -nx ./26 -ex 'b i' -ex r -ex bt #0 i () at 26.c:2 #1 0x00007ffff7dfc53e in ?? () from ./26l.so ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ #2 0x00007ffff7dfc558 in f () from ./26l.so #3 0x00000000004005c8 in main () at 26.c:3 glibc in Fedora packaging is probably the only exception; it has the .symtab section in the main rpm. All the other libraries have .symtab only in the debuginfo rpm. > (Call graph properties) > * List of the library functions called. That is the functions called via .plt section - either from different libraries or within the same library (if it does not use direct calls like glibc does). Hopefully this should not change, I agree. > * Whether the function calls some other functions in the file. Various functions get inlined during various optimizations levels and compiler changes, it also changes with gcc -flto. > * Whether the function calls itself. > (Presence of types of instructions) Tail call optimizations (call+ret -> jump) change this so -O0 vs. -O2 code will be definitely different; But -O2 compilation of slightly different code hopefully should have the same signature. > * Conditional jumps based on equality test/signed comparison/unsigned > comparison. This is the exact target of the gcc -fprofile-* optimizations; AFAIK SuSE uses it a lot (I had some negative results trying to apply it for gdb packaging). That is to invert the jump conditional and reshuffle the code around so that in >50% cases it does not jump depending on "random" benchmark data during each >build. > So the question is: How to improve this function fingerprinting > scheme? Is there a better approach for coredump duplicate detection? I am a bit skeptical against such function content comparison but sure it does not have to be perfect. There may be soon cheap enough to run gdbserver on the local core file with the recent optimization by Paul Pluzhnikov to be finished: Re: [patch] Implement qXfer:libraries for Linux/gdbserver http://sourceware.org/ml/gdb-patches/2011-08/msg00291.html But I do not have any benchmark numbers now to support it. Thanks, Jan