From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4291 invoked by alias); 2 Apr 2008 00:07:16 -0000 Received: (qmail 4162 invoked by uid 22791); 2 Apr 2008 00:07:15 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 02 Apr 2008 00:06:58 +0000 Received: from zps78.corp.google.com (zps78.corp.google.com [172.25.146.78]) by smtp-out.google.com with ESMTP id m3206eTO008764; Wed, 2 Apr 2008 01:06:41 +0100 Received: from localhost (meta.corp.google.com [172.22.108.53]) by zps78.corp.google.com with ESMTP id m3206ciq013348; Tue, 1 Apr 2008 17:06:38 -0700 Received: by localhost (Postfix, from userid 500) id 1BD1B3F25EF; Tue, 1 Apr 2008 17:06:38 -0700 (PDT) To: drow@false.org CC: bauerman@br.ibm.com, gdb-patches@sourceware.org In-reply-to: <20080401140953.GD12753@caradoc.them.org> (message from Daniel Jacobowitz on Tue, 1 Apr 2008 10:09:53 -0400) Subject: Re: Patch to handle compressed sections References: <20080325230440.BF0623F25D6@localhost> <1206547779.29533.43.camel@localhost.localdomain> <20080326173918.E6D063F25E8@localhost> <20080326180132.GB10127@caradoc.them.org> <20080326183538.346243F25E8@localhost> <20080401140953.GD12753@caradoc.them.org> Message-Id: <20080402000638.1BD1B3F25EF@localhost> Date: Wed, 02 Apr 2008 00:38:00 -0000 From: csilvers@google.com (Craig Silverstein) 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-04/txt/msg00033.txt.bz2 } I think we have to do this. It's unfriendly to consumers to have } the section have an unpredictable name Yeah, that's a fair point. OK, I'll rewrite it. It's a bit of a pain to change formats -- especially with gold already released to support the old format -- so I'd like to pass the new format by you guys before I implement it. My plan is to name the new sections .zdebug_foo. They will start with a 5-byte header that indicates what compression format is being used, and what version of the format. For now, only ZLIB1 will be supported. Following the ZLIB1 header-field will be an 8-byte length header-field, in big-endian order -- I know DWARF mostly uses leb128, but I don't want to add the complexity for people who just want to parse the header (which, technically, isn't part of dwarf :-) ). Plus, we don't care much about the space used here. Following the length will come the content, which is just a blob of data compressed by zlib. gdb will be changed to look for .zdebug_foo as an alternate to .debug_foo, and the section-reading code will decompress such sections at read-time. Does this sound like a reasonable plan? If so, I'll try to get a new patch later this week. craig