This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Support gzip compressed exec and core files in gdb
- From: Gary Benson <gbenson at redhat dot com>
- To: Doug Evans <dje at google dot com>
- Cc: Michael Eager <eager at eagerm dot com>, "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>, binutils <binutils at sourceware dot org>
- Date: Wed, 11 Mar 2015 18:21:11 +0000
- Subject: Re: [PATCH] Support gzip compressed exec and core files in gdb
- Authentication-results: sourceware.org; auth=none
- References: <54FF77D6 dot 7010400 at eagerm dot com> <20150311100702 dot GA3698 at blade dot nx> <5500580C dot 6090400 at eagerm dot com> <20150311174236 dot GA13850 at blade dot nx> <CADPb22T8A4p6Mj2sWVrk3OCROiwrdMBR+tXk45xdHPEMs5PLRg at mail dot gmail dot com>
Doug Evans wrote:
> On Wed, Mar 11, 2015 at 10:42 AM, Gary Benson <gbenson@redhat.com> wrote:
> > Michael Eager wrote:
> > > On 03/11/15 03:07, Gary Benson wrote:
> > > >Michael Eager wrote:
> > > > > Add support to automatically unzip compressed executable and
> > > > > core files. Files will be uncompressed into temporary
> > > > > directory (/tmp or $TMPDIR) and are deleted when GDB exits.
> > > > > This should be transparent to users, except for disk space
> > > > > requirements. The name of the uncompressed file is
> > > > > mentioned, but all references to the file in GDB messages is
> > > > > to the file which the user specified.
> > > >...
> > > > > diff --git a/gdb/common/filestuff.c b/gdb/common/filestuff.c
> > > > > index 14d6324..b2c31fd 100644
> > > > > --- a/gdb/common/filestuff.c
> > > > > +++ b/gdb/common/filestuff.c
> > > >...
> > > > > +#ifndef GDBSERVER
> > > >
> > > > Please do not add GDBSERVER conditionals to gdb/common, I spent
> > > > half a year removing them all.
> > > >
> > > > It looks like this code is only used by GDB, not gdbserver, so
> > > > the fix is simple, just put the code somewhere GDB-specific.
> > >
> > > Sure. Any suggestions? gdb_bfd.c seems like the wrong place.
> >
> > gdb/utils.c maybe?
>
> Fine by me.
> Though, OTOH, there's nothing intrinsic in what's being done there
> that gdbserver (or anything else that might want to use common)
> couldn't use it tomorrow.
> I'd be ok with common/compression.c or some such.
Do we really want to be putting things in common speculatively?
Cheers,
Gary
--
http://gbenson.net/