From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9857 invoked by alias); 20 Sep 2011 20:22:19 -0000 Received: (qmail 9849 invoked by uid 22791); 20 Sep 2011 20:22:18 -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; Tue, 20 Sep 2011 20:22:05 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p8KKM5nn020617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 20 Sep 2011 16:22:05 -0400 Received: from host1.jankratochvil.net (ovpn-116-24.ams2.redhat.com [10.36.116.24]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p8KKM3Mj019506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Sep 2011 16:22:04 -0400 Received: from host1.jankratochvil.net (localhost [127.0.0.1]) by host1.jankratochvil.net (8.14.4/8.14.4) with ESMTP id p8KKM2of018461; Tue, 20 Sep 2011 22:22:02 +0200 Received: (from jkratoch@localhost) by host1.jankratochvil.net (8.14.4/8.14.4/Submit) id p8KKM1ta018460; Tue, 20 Sep 2011 22:22:01 +0200 Date: Tue, 20 Sep 2011 20:22: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: <20110920202201.GA14894@host1.jankratochvil.net> References: <20110915123230.GA4048@dhcp-25-199.brq.redhat.com> <20110915174831.GA30247@host1.jankratochvil.net> <20110920135116.GA11537@dhcp-25-199.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110920135116.GA11537@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/msg00074.txt.bz2 On Tue, 20 Sep 2011 15:51:17 +0200, Martin Milata wrote: > On Thu, Sep 15, 2011 at 19:48:31 +0200, Jan Kratochvil wrote: > > > (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. > > Great, this is so far the most important component in the signature Be aware you have to disassemble the function, relocations are for the .plt section, functions call PC-relatively the functions in .plt without any further relocations. > This unfortunately means that lot of functions that do not call anything > through .plt have the same fingerprint. Can you think of some other > properties that we could use in those functions? As you already have to do the disassembly analysis very similar to the .plt functions calls you can find references to exported variables due to the .got section references. > > > * 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. > > But we can test if the code contains either of the jX and jnX > instructions, right? jX vs. jnX will change depending on the -fprofile-* feedback file and you probably cannot find out which of the two code paths match which of the former code paths. Try yourself -fprofile-generate build, give it two different external data input for more positive/negative conditional and how you can match the resulting two -fprofile-use generated executables. BTW have fun porting the disassemblt analysis to all arches. [gdbserver] > Also, if I > understand correctly, the connection has to be initiated from the host > machine which might be a problem if there are NATs/firewalls on the way. The direction of the connection is not relevant IMO, it needs to be tunnelled for some encryption anyway which can change the way how the connection is initiated.. Thanks, Jan