This is the mail archive of the
mailing list for the GDB project.
Re: Patch to handle compressed sections
- From: csilvers at google dot com (Craig Silverstein)
- To: drow at false dot org
- Cc: bauerman at br dot ibm dot com, gdb-patches at sourceware dot org
- Date: Tue, 1 Apr 2008 17:06:38 -0700 (PDT)
- Subject: Re: Patch to handle compressed sections
- References: <20080325230440.BF0623F25D6@localhost> <firstname.lastname@example.org> <20080326173918.E6D063F25E8@localhost> <20080326180132.GB10127@caradoc.them.org> <20080326183538.346243F25E8@localhost> <20080401140953.GD12753@caradoc.them.org>
} 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
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
Does this sound like a reasonable plan? If so, I'll try to get a new
patch later this week.