From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11464 invoked by alias); 29 Jul 2019 14:24:33 -0000 Mailing-List: contact elfutils-devel-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: elfutils-devel-owner@sourceware.org Received: (qmail 11423 invoked by uid 89); 29 Jul 2019 14:24:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.3 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-10.9 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy= X-Spam-Status: No, score=-10.9 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on sourceware.org X-Spam-Level: X-HELO: gnu.wildebeest.org Received: from wildebeest.demon.nl (HELO gnu.wildebeest.org) (212.238.236.112) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 29 Jul 2019 14:24:24 +0000 Received: from librem.wildebeest.org (host81-133-75-206.in-addr.btopenworld.com [81.133.75.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id E4E7D30014BB; Mon, 29 Jul 2019 16:24:21 +0200 (CEST) Received: by librem.wildebeest.org (Postfix, from userid 1000) id 441BEC01C0; Mon, 29 Jul 2019 16:24:19 +0200 (CEST) Date: Mon, 29 Jul 2019 14:24:00 -0000 From: Mark Wielaard To: Florian Weimer Cc: elfutils-devel@sourceware.org, Panu Matilainen Subject: Re: [PATCH] elfclassify tool Message-ID: <20190729142419.GB2881@wildebeest.org> References: <87k1fz8c9q.fsf@oldenburg2.str.redhat.com> <2e6a27c552ae5e365db54ca6b432c77c9ad5b041.camel@klomp.org> <871s22yybt.fsf@oldenburg2.str.redhat.com> <8736mfzhob.fsf@oldenburg2.str.redhat.com> <87k1cadpym.fsf@oldenburg2.str.redhat.com> <20190726221124.GA39429@wildebeest.org> <87ef296xir.fsf@oldenburg2.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ef296xir.fsf@oldenburg2.str.redhat.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Flag: NO X-IsSubscribed: yes X-SW-Source: 2019-q3/txt/msg00090.txt.bz2 On Mon, Jul 29, 2019 at 10:43:56AM +0200, Florian Weimer wrote: > * Mark Wielaard: > > > + if (elf == NULL) > > + { > > + /* This likely means it just isn't an ELF file, probably not a > > + real issue, but warn if verbose reporting. */ > > + if (verbose > 0) > > + fprintf (stderr, "warning: %s: %s\n", current_path, elf_errmsg (-1)); > > + return false; > > + } > > Is it possible to distinguish the error from a memory allocation error? > It would be wrong to mis-classify a file just because the system is low > on memory. You are right this is not the proper way to report the issue. Normally, when just using elf_begin, a NULL return should be reported through elf_issue (which will set the issues flag). But, because I added -z, we are using either elf_begin or dwelf_elf_begin. dwelf_elf_begin will return NULL (instead of a an empty (ELF_K_NONE) Elf descriptor when there is an issue, or the (decompressed) file wasn't an ELF file. So we should split the error reporting. If we called elf_begin and get NULL we should call elf_issue to report the proper issue. If we called dwefl_elf_begin and we get NULL, I am not sure yet what the proper way is to detect whether it is a real issue, or "just" not a (decompressed) ELF file. I am afraid the current handling is the best we can do. Maybe we can fix dwelf_elf_begin to return an empty (ELF_K_NONE) Elf descriptor if there was no issue, but the (decompressed) file wasn't an ELF file. Cheers, Mark