From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20950 invoked by alias); 24 Mar 2014 08:37:32 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 20939 invoked by uid 89); 24 Mar 2014 08:37:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 24 Mar 2014 08:37:19 +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 s2O8bEjt024303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 24 Mar 2014 04:37:15 -0400 Received: from host2.jankratochvil.net (ovpn-116-22.ams2.redhat.com [10.36.116.22]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s2O8bAPI009661 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 Mar 2014 04:37:13 -0400 Date: Mon, 24 Mar 2014 08:37:00 -0000 From: Jan Kratochvil To: "Metzger, Markus T" Cc: "gdb-patches@sourceware.org" , "Pedro Alves (palves@redhat.com)" Subject: Re: [PATCH 2/2] btrace: avoid symbol lookup Message-ID: <20140324083710.GA3317@host2.jankratochvil.net> References: <1394182665-14164-1-git-send-email-markus.t.metzger@intel.com> <1394182665-14164-3-git-send-email-markus.t.metzger@intel.com> <20140310214252.GA3105@host2.jankratochvil.net> <20140321172215.GA15215@host2.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2014-03/txt/msg00570.txt.bz2 On Mon, 24 Mar 2014 08:55:33 +0100, Metzger, Markus T wrote: > > I do not think providing incorrect behavior for performance reasons is a valid > > tradeoff. The right way would be to fix the DWARF lookups to be fast > > enough. [...] > The only actual change in functionality I was able to observe was missing > parens for the main function, I agree in 99.9% of usecases it will work the same. This still does not prove it is correct. I believe I can create a reproducer with two overlapping functions: 0..1: a() 2..3: b() 4..6: a() 7..8: b() properly describe by DW_AT_ranges which will work with former GDB but which will no longer work with patched GDB. This may definitely happen for some user .S code with hand-coded DWARF. I do not say it necessarilly happens with any real world compiler output. This may happen for gdb.dwarf2/dw2-objfile-overlap.exp which comes from a real world case of Linux kernel modules mapping. But maybe I miss something and I would fail to create the reproducer, if you do not agree I can create a .S with hand coded DWARF I can try to create one. Corner cases are the ones most difficult to debug and it is a pity when debugger provides incorrect output in such corner cases. As I said maybe this compromise is acceptable as it may not be hit in real world usage cases but I do not want to make this decision. > I think the compromise is rather between a nice, general solution that > benefits everybody and a local solution that only benefits btrace This is the second reason why I did not agree with the patch. GDB needs to be faster and if this PC->functionname mapping can be accelerated such way then it should be done globally. Regards, Jan