From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 100792 invoked by alias); 19 Jun 2017 12:26:34 -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 100414 invoked by uid 89); 19 Jun 2017 12:26:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=terrible 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, 19 Jun 2017 12:26:32 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6E9EDC04B92D; Mon, 19 Jun 2017 12:26:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 6E9EDC04B92D Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jan.kratochvil@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 6E9EDC04B92D Received: from host1.jankratochvil.net (ovpn-116-67.ams2.redhat.com [10.36.116.67]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7273889C51; Mon, 19 Jun 2017 12:26:35 +0000 (UTC) Date: Mon, 19 Jun 2017 12:26:00 -0000 From: Jan Kratochvil To: Yao Qi Cc: Pedro Alves , gdb-patches@sourceware.org Subject: Re: Regression: Re: [PATCH 2/6] Code cleanup: dwarf2read.c: Eliminate ::file_write Message-ID: <20170619122631.GA15324@host1.jankratochvil.net> References: <8efc0742-1014-4fe0-6948-f40a9c5c4975@redhat.com> <1497284051-13795-2-git-send-email-palves@redhat.com> <20170618183603.GA1834@host1.jankratochvil.net> <0d3d940c-c6d6-02df-69a0-defdd300f92f@redhat.com> <20170619093927.GA24763@host1.jankratochvil.net> <20170619100302.GA25357@host1.jankratochvil.net> <86y3sonpuq.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86y3sonpuq.fsf@gmail.com> User-Agent: Mutt/1.8.0 (2017-02-23) X-SW-Source: 2017-06/txt/msg00507.txt.bz2 On Mon, 19 Jun 2017 14:06:53 +0200, Yao Qi wrote: > Do you have some examples or bugs? GDB performance improvement is one > of my todo, so if you have some examples, or bugs, that would be quite > helpful. Any backtraces take up to a minute. That is because GDB expands only whole CUs (and not specific DIEs) and one CU can be pretty huge in C++ programs, moreover GDB has to expand tens of CUs to expand just one CU due to some interdependencies between CUs enforced by dwarf2read.c. Less serious but another existing problem may be that dwz DW_TAG_imported_unit is implemented only in DWARF reader and not in inferior symbol/type system of GDB, therefore all DW_TAG_imported_unit units get duplicated/multiplicated inside GDB, being expanded each time again. Occasional print of an expression takes a minute which may be due to: gdb's performance is so terrible that it is unusable https://bugzilla.redhat.com/show_bug.cgi?id=1401091 Then conditions of breakpoints get evaluated by GDB and not in inferior which is commonly unusable to wait for hours until the wished even happens and one has to rather put an "if" statement into a recompiled debuggee. Then there is the inability of execute C++ statements which should get fixed by the 'compile' project but then it will be at least 2 times slower than needed due to the use of gcc instead of clang. Jan