From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5337 invoked by alias); 26 Mar 2008 18:36:19 -0000 Received: (qmail 5326 invoked by uid 22791); 26 Mar 2008 18:36:19 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.45.13) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 26 Mar 2008 18:35:53 +0000 Received: from zps36.corp.google.com (zps36.corp.google.com [172.25.146.36]) by smtp-out.google.com with ESMTP id m2QIZhu7004938; Wed, 26 Mar 2008 11:35:43 -0700 Received: from localhost (meta.corp.google.com [172.22.108.53]) by zps36.corp.google.com with ESMTP id m2QIZc0b028520; Wed, 26 Mar 2008 11:35:38 -0700 Received: by localhost (Postfix, from userid 500) id 346243F25E8; Wed, 26 Mar 2008 11:35:38 -0700 (PDT) To: drow@false.org CC: bauerman@br.ibm.com, gdb-patches@sourceware.org In-reply-to: <20080326180132.GB10127@caradoc.them.org> (message from Daniel Jacobowitz on Wed, 26 Mar 2008 14:01:32 -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> Message-Id: <20080326183538.346243F25E8@localhost> Date: Wed, 26 Mar 2008 18:36: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-03/txt/msg00407.txt.bz2 } Or in the beginning of .debug_info.zlib? (.zdebug_info?) I thought of that too, but again I didn't see much benefit. On the other hand, there is a cost (albeit small): now you have a "format" for compressed data, with a header section and data to follow, so you need to codify and document the header format, and deal with issues like 4-byte vs 8-byte and endianness, and then you'll probably want a version, and things just get very complicated. I like the simplicity of saying the section is just a blob of compressed data. I feel if we start needing more data stored with a compressed section than just its uncompressed length, then we can move to .debug_info.zlib and write a header format to encompass all that data, at that time. But it's not really necessary to do that now. (And, honestly, I'd like to make it difficult to go that route, since again it adds complexity to what currently seems like a pretty simple design.) } I've been looking at this and wondering if block compression makes } more sense; that would let an optimized consumer keep less than the } whole decompressed contents in memory. The current algorithm supports block compression -- if the section consists of several compressed blocks appended together, it will recognize that and correctly decompress. It's true that right now we always decompress all the blocks when we read a section, but one could imagine that instead we keep track of this info on a per-block basis, and only decompress a given block at need. I think that would complicate the logic significantly, though, and don't think it's warranted for this version 1.0 patch. The important thing, I think, is that this patch doesn't close off making such an optimization in the future. craig