From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3352 invoked by alias); 26 Mar 2008 16:10:13 -0000 Received: (qmail 3343 invoked by uid 22791); 26 Mar 2008 16:10:12 -0000 X-Spam-Check-By: sourceware.org Received: from igw2.br.ibm.com (HELO igw2.br.ibm.com) (32.104.18.25) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 26 Mar 2008 16:09:43 +0000 Received: from mailhub1.br.ibm.com (mailhub1 [9.18.232.109]) by igw2.br.ibm.com (Postfix) with ESMTP id AFBCC17F4B4 for ; Wed, 26 Mar 2008 13:00:59 -0300 (BRST) Received: from d24av01.br.ibm.com (d24av01.br.ibm.com [9.18.232.46]) by mailhub1.br.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m2QG9edf3952794 for ; Wed, 26 Mar 2008 13:09:40 -0300 Received: from d24av01.br.ibm.com (loopback [127.0.0.1]) by d24av01.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m2QG9dgm028441 for ; Wed, 26 Mar 2008 13:09:39 -0300 Received: from [9.18.238.95] ([9.18.238.95]) by d24av01.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m2QG9dtF028437; Wed, 26 Mar 2008 13:09:39 -0300 Subject: Re: Patch to handle compressed sections From: Thiago Jung Bauermann To: Craig Silverstein Cc: gdb-patches@sourceware.org In-Reply-To: <20080325230440.BF0623F25D6@localhost> References: <20080325230440.BF0623F25D6@localhost> Content-Type: text/plain Date: Wed, 26 Mar 2008 16:10:00 -0000 Message-Id: <1206547779.29533.43.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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 X-SW-Source: 2008-03/txt/msg00402.txt.bz2 On Tue, 2008-03-25 at 16:04 -0700, Craig Silverstein wrote: > This patch adds support for reading compressed debug sections, as are > produced by the new gold linker when it's run with > --compress-debug-sections=zlib. Neat. Out of curiosity, does this approach work well in practice? If you need to compress debug info, it means you are dealing with a very large amount of it. Isn't it cumbersome for GDB to deal with it later? I imagine it must be slow to wait for GDB to uncompress and interpret it all, and it must use a very big amount of memory. It's a trade-off where you ease the burden on the computer where the program runs, and permits you to have debuginfo around where you probably couldn't before, but on the other hand you need a lot of resources to actually be able to work with that debuginfo in a debug environment, right? > +/* Note that if the debugging section has been compressed, it might > + have a name like .debug_info.zlib.nnnn (where nnn is the > + uncompressed size). */ I am not as fluent in ELF and DWARF representation as I would like, so take this for what it's worth: Encoding this information in the section name looks strange to me. Isn't it possible to define a new flag in the section's sh_flags to signal that the section is compressed and then use the first few bytes of the section contents for the information above? Or alternatively, create a note section for that? This route might be easier in that it doesn't raise compatibility concerns, and there's no immediate need to actually extend the ELF standard. > + /* Handle the case of a section compressed using zlib. */ > + if (strncmp (compression_type, ".zlib.", sizeof(".zlib.")-1) == 0) > + { > +#ifndef HAVE_ZLIB_H > + error (_("Dwarf Error: Can't uncompress zlib-compressed DWARF data " > + "in '%s'"), > + bfd_get_filename (abfd)); > +#else I think it's better for this error message to say something along the lines of "Support for compressed DWARF data is disabled in this copy of GDB". -- []'s Thiago Jung Bauermann Software Engineer IBM Linux Technology Center