From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by sourceware.org (Postfix) with ESMTPS id 0D0E93858D39 for ; Fri, 26 Nov 2021 10:02:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0D0E93858D39 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=seketeli.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=seketeli.org Received: (Authenticated sender: dodji@seketeli.org) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id CB9BBE0013; Fri, 26 Nov 2021 10:02:18 +0000 (UTC) Received: by localhost (Postfix, from userid 1000) id 1564A5802B4; Fri, 26 Nov 2021 11:02:17 +0100 (CET) From: Dodji Seketeli To: Guillermo Martinez Cc: Guillermo Martinez via Libabigail , Jose Marchesi Subject: Re: [PATCH v2] Add regression tests for ctf reading Organization: Me, myself and I References: <20211118041625.622972-1-guillermo.e.martinez@oracle.com> <1748826.RoRjW6BIRr@sali> <87a6hstt5u.fsf@seketeli.org> <4076345.HvgH2z2rxB@sali> X-Operating-System: Fedora 36 X-URL: http://www.seketeli.net/~dodji Date: Fri, 26 Nov 2021 11:02:17 +0100 In-Reply-To: <4076345.HvgH2z2rxB@sali> (Guillermo Martinez's message of "Thu, 25 Nov 2021 21:03:19 +0000") Message-ID: <8735njtety.fsf@seketeli.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libabigail@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mailing list of the Libabigail project List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Nov 2021 10:02:23 -0000 Hey, Dodji Seketeli a =C3=A9crit: >> Actually, this won't be a false negative. It's a true negative. because >> what we want to see with abidw --abidiff is that the abixml file that is >> emitted has the same *ABI* as the incoming ELF file. In other words, we >> want to see if the DWARF/CTF, the in-memory IR, and the abixml are all >> coherent, so to speak. The exact output details of the XML itself >> (things like spaces or order of type definitions etc) don't matter to us >> at that point. We want those insignificant details of the abixml format >> to be able to fluctuate without having the fundamentals of ABI >> compatibility in general to be impacted. Guillermo Martinez a =C3=A9crit: > hmm, in order to probe my assumption of the use of abidw --abidiff in tes= t-read-* > to protect against false negatives I've commented in src/abg-dwarf-reader= .cc > the call to ctxt.load_elf_properties, simulating a broken feature(no elf-= needed node > in abixml) in dwarf_reader::read_corpus_from_elf so the /tmp/abixml hasn'= t=20 > elf-needed node: > > > > > .... > > after that, as we already know this /tmp/abixml is used to built the seco= nd corpus used > by compute_diff function, and as you can guess: no differences will be fo= und. So regressions could > not be detected, because we don't used the expected abixml file: test0.ab= i, is there where the elf-needed > node was written for example: in a previous version of libabigail. > > > > > > > I don't think your experiment invalidates what I was trying to say. Sorry if was not clear :-( In your experiment above, the ELF/DWARF reader doesn't load these elf-needed properties. So the resulting in-memory IR won't represent those properties. So the serialization of that IR into abixml won't represent those properties either. So comparing the ABI of the serialized abixml against the ABI of the input binary (none of which have the elf-needed properties) won't show any ABI change. That is expected. On the contrary, you are showing that the in-memory IR resulting from the reading of the ELF/DWARF matches the in-memory IR resulting from the abixml. And that is precisely what "abidw --abidiff" is designed to ensure. Said otherwise, the intent of the "abidw --abidiff" command is to verify that the in-memory IR built from the input binary is congruent with the in-memory IR built from its serialized abixml form. In other words, if we 'abidiff' the in-memory representation of the DWARF against the in-memory representation of the abixml coming from the DWARF, we should get the empty set. We are trying to ensure that there is no "unintended information loss" between WHAT WE SEE from the ELF binary and what we see from the abixml representation. I hope this helps. But if I am still missing something, please do not hesitate to educate me. Thanks! [...] Cheers, --=20 Dodji