This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Compressed exec and core files
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Michael Eager <eager at eagerm dot com>
- Cc: Binutils <binutils at sourceware dot org>
- Date: Fri, 23 Jan 2015 12:37:53 -0800
- Subject: Re: Compressed exec and core files
- Authentication-results: sourceware.org; auth=none
- References: <54C2A8BE dot 2020807 at eagerm dot com> <CAMe9rOruoc6sN6ukfgYKv6BY3YjFUFuUX7QCgRnQ_p2VmHTcVg at mail dot gmail dot com> <54C2AF81 dot 8050309 at eagerm dot com>
On Fri, Jan 23, 2015 at 12:30 PM, Michael Eager <eager@eagerm.com> wrote:
> On 01/23/15 12:19, H.J. Lu wrote:
>>
>> On Fri, Jan 23, 2015 at 12:02 PM, Michael Eager <eager@eagerm.com> wrote:
>>>
>>> I'm working on a patch to BFD to support opening compressed
>>> exec and core files transparently. When bfd_fopen is called
>>> to open a compressed file, the file would be decompressed into
>>> a temporary file, and the bfd for the temp returned. Compression
>>> with gzip and bzip2 would be supported (others can be added later).
>>>
>>> This seems pretty straight-forward. Any thoughts or comments?
>>
>>
>> Are you going to fork/exec gzip/bzip2 for this or call zlib/bzip2-libs?
>
>
> Could do either. Exec is simpler. libz.so is currently a dependency,
> adding libbzip2.so wouldn't be a big deal, but this might be a slippery
> slope, where each added compression results in another library dependency.
>
> Using exec means that the decompress program needs to be on the path, but
> the failure mode if it is not found is pretty transparent.
>
I really don't like fork/exec. I strongly prefer zlib/bzip2-libs. You can
use dlopen to load compression library on demand.
--
H.J.