From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5847 invoked by alias); 4 Jun 2014 08:54:35 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 5822 invoked by uid 89); 4 Jun 2014 08:54:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: smtp-relay.CeBiTec.Uni-Bielefeld.DE Received: from snape.CeBiTec.Uni-Bielefeld.DE (HELO smtp-relay.CeBiTec.Uni-Bielefeld.DE) (129.70.160.84) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 04 Jun 2014 08:54:32 +0000 Received: from localhost (localhost.CeBiTec.Uni-Bielefeld.DE [127.0.0.1]) by smtp-relay.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTP id 924EE2B8; Wed, 4 Jun 2014 10:54:29 +0200 (CEST) Received: from smtp-relay.CeBiTec.Uni-Bielefeld.DE ([127.0.0.1]) by localhost (malfoy.CeBiTec.Uni-Bielefeld.DE [127.0.0.1]) (amavisd-new, port 10024) with LMTP id fS8ai72Bd6S8; Wed, 4 Jun 2014 10:54:27 +0200 (CEST) Received: from lokon.CeBiTec.Uni-Bielefeld.DE (lokon.CeBiTec.Uni-Bielefeld.DE [129.70.161.110]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-relay.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTPS id 27B7C2B7; Wed, 4 Jun 2014 10:54:27 +0200 (CEST) Received: (from ro@localhost) by lokon.CeBiTec.Uni-Bielefeld.DE (8.14.7+Sun/8.14.7/Submit) id s548sPmi021094; Wed, 4 Jun 2014 10:54:25 +0200 (MEST) From: Rainer Orth To: Mike Stump Cc: "Joseph S. Myers" , gcc-patches@gcc.gnu.org, Paolo Bonzini , DJ Delorie , Nathanael Nerode , Alexandre Oliva , Gerald Pfeifer Subject: Re: [build, driver] RFC: Support compressed debug sections References: Date: Wed, 04 Jun 2014 08:54:00 -0000 In-Reply-To: (Mike Stump's message of "Tue, 3 Jun 2014 09:19:56 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2014-06/txt/msg00317.txt.bz2 Mike Stump writes: > On Jun 3, 2014, at 3:40 AM, Rainer Orth wro= te: >> It's been another week, and I still need approval for the build, doc, >> and Darwin changes: > > So, the darwin bits look trivial enough, if the entire scheme is what > people want to do. My question would be, why do we want an option for > this? If the scheme works, why not just turn it on unconditionally? If = it > doesn=A1=AFt work, why add it? If it isn=A1=AFt good, why add it? If it= is good, > why not do it? It works in very specific circumstances, like assembler and linker versions. > If it is just to reach compatibility with the debugger, then I=A1=AFd rat= her > either just mandate a certain debugger or autoconf for what the current > debugger supports. As of late people seem to just break the debugging > experience with non-updated gdbs and assume that a newer gdb is used. You cannot do that: unlike the assembler and linker used, which are often hardcoded into gcc, the debugger can easily be changed below the compiler's feet, so to speak. Besides, on several platforms, you have more than one debugger available (like gdb and dbx, or others), so this isn't an option. Apart from that, the debugging experience when e.g. emitting very recent DWARF extensions and trying to use them with a gdb that doesn't understand them usually leads to some debug info missing. In this case, emitting compressed debug with a debugger that cannot read it leads to the debugger claiming (correctly, from its point of view) that there's no debugging info present. I don't want to tell users who come complaining `I compiled with -g, but my debugger tells me there's no debug info present': `look, your debugger lies, it is present, but it cannot read it'. That's a lot worse than the DWARF extensions scenario above. On top of all that, compressed debug is a tradeoff: in some cases it may be worth it to save space on debug info if disk space is at a premium for some reason (e.g. for release builds), but in others you want to compile as fast as possible, but assembling and linking compressed debug takes more CPU time. Otherwise we could just as well default to -Os, telling our users it's better for them since it generates faster and smaller code, not minding the compile time cost and worse debugging experience. I at least don't wont to patronize our users like this. Rainer --=20 ---------------------------------------------------------------------------= -- Rainer Orth, Center for Biotechnology, Bielefeld University