From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29409 invoked by alias); 13 Jun 2010 10:40:18 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 29394 invoked by uid 22791); 13 Jun 2010 10:40:17 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=AWL,BAYES_50,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: tromey@redhat.com Cc: Project Archer , Jakub Jelinek Subject: Re: Fedora 14 debug proposal In-Reply-To: Tom Tromey's message of Tuesday, 8 June 2010 14:38:19 -0600 References: Message-Id: <20100613104010.6D1174077C@magilla.sf.frob.com> Date: Sun, 13 Jun 2010 10:40:00 -0000 X-SW-Source: 2010-q2/txt/msg00049.txt.bz2 > 1. Generate index files for the separate .debug files. This involves > running gdb to dump the index, something like: Is this a magical gdb-internal format, or something that will really be specified as a known file format? Since the plan as stated is to distribute this format in distro packages that will be around forever, the format details become interesting from a long-term compatibility point of view, not just as a gdb feature of today. > I don't know where the debuginfo stripping is done right now, but > that seems like the best place to run this script. See /usr/lib/rpm/find-debuginfo.sh. If DWARF compression ever gets finished, its tools will probably replace most or all of that script. > 2. Change GCC so that it no longer emits .debug_aranges, > .debug_pubnames, and .debug_pubtypes. Please do not lump .debug_aranges in with .debug_pub*. They are qualitatively different cases. .debug_aranges is a direct low-level derivative of the CU DIEs. The others are made with language-specific high-level knowledge. > From what I can tell, no program uses these sections. They just > waste space. libdw uses .debug_aranges and does not fall back to linear search of CUs. Removing it breaks all existing users that do any kind of lookups by PC address. > I think .debug_pub* are pretty useless. [...] I don't doubt that. > I can write the gcc patch for this. For Fedora purposes, dropping .debug_pub* sections could just as well be done in the stripping stage. And, I don't think they really cost much space in the grand scheme of things. So there is little real motivation to fiddle gcc at all until after we have completed basically everything else in the related realms. (There also isn't really any reason I know of not to drop .debug_pub* from gcc yesterday if anyone really wants to.) > 3. If we are shipping GCC 4.5 in F14, I think we should enable the > .debug_types stuff by default. This will shrink debuginfo and it > makes gdb use less memory. libdw does not yet handle .debug_types. It of course will, but I wouldn't like to have a gcc defaults change on any queue until we are quite concrete with getting all the support in line. > This one is optional, in particular I assume it will be subsumed by > the other DWARF compression work. It should be, yes. I don't see any reason that .debug_types and DW_FORM_ref_sig8 need to survive final linking. The normal reference forms are more efficient for consumers to use. Replacing ref_sig8 forms with direct ref_addr forms requires that the targets be in .debug_info rather than .debug_types. So I'd been imagining that DW_TAG_type_unit would morph into DW_TAG_compile_unit anyway. It's still possible that emitting .debug_types during compilation could speed up the build process, if plain ld COMDAT handling reduces a lot of duplication before the brute-force DWARF duplicate-subtree finder has to run. Thanks, Roland