From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id 3D1EE3858C74 for ; Tue, 20 Sep 2022 15:05:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3D1EE3858C74 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: from tarox.wildebeest.org (83-87-18-245.cable.dynamic.v4.ziggo.nl [83.87.18.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 12E183000648; Tue, 20 Sep 2022 17:05:14 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 5F1CA40007B5; Tue, 20 Sep 2022 17:05:13 +0200 (CEST) Message-ID: <6ab5b70c95e4c3169ac4ad678e5011baef52f05e.camel@klomp.org> Subject: Re: libabigail 2.1 trunk testing where are we? From: Mark Wielaard To: Dodji Seketeli Cc: Ben Woodard , Ben Woodard via Libabigail Date: Tue, 20 Sep 2022 17:05:13 +0200 In-Reply-To: <87y1ue5t5i.fsf@seketeli.org> References: <5BA0C098-9E22-4604-8C13-1D0624B2489F@redhat.com> <87y1ue5t5i.fsf@seketeli.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-10.el7) Mime-Version: 1.0 X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Dodji, On Tue, 2022-09-20 at 10:47 +0200, Dodji Seketeli wrote: > Okay, so I have just applied this to master. Thanks! > Mark, by the, way, just for my own education, would it have been ok to > just use gelf_getshdr all the time, rather than using looking at the > sh_entsize property of the section header that can be wrong sometimes? >=20 > I am guessing the reason why you chose to keep looking at the later has > to do with potential performance concerns? I am sure I fully understand your question. Do you mean if we could have used gelf_fsize (elf, ELF_T_DYN, 1, EV_CURRENT) all the time? Yes, we could have simply done that. I didn't do that in the patch because that would have changed the existing code more. But maybe I should have done that and ignored the shdr completely to simplify things. Cheers, Mark