From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::222]) by sourceware.org (Postfix) with ESMTPS id 364D43858D1E for ; Fri, 17 Nov 2023 23:06:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 364D43858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=seketeli.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=seketeli.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 364D43858D1E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:4b98:dc4:8::222 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700262386; cv=none; b=oxJTiiSXigU4TRB+GFJbQCQ0hisT0i/2c0G4JmghCPEKFwWphP9OH1wvvSVIpYMGGBwYrQzCga+WbIJcnAWa6i2RdjCJJKhs57cCozap4sQV0JQZ4e1KQRtMG3oqK5kuGwct+Jpk71m05Q0j5B3FOtLlFYgUoReIpBsxrSkX19w= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700262386; c=relaxed/simple; bh=3EO3hNafnv/R71nOtaNBqArUh/3BUSMOnE6bS4t/4cM=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=N2YCv08qZ8w25Rbs1bzg/JcVujNXYgATBoOj1KCf3S6IpVT2F/GDbWEKxSXwZvyGDCDgmI1oakrNiivie4Hx2aMj/02M4SOtJsSTgg6rklwMj8ENd4CI448IqFEumC9crJXi822MGQg9d7r37MSyCD3Z+tjwFRxKnqRdE8z+5bc= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail.gandi.net (Postfix) with ESMTPSA id 5C6C440003; Fri, 17 Nov 2023 23:06:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seketeli.org; s=gm1; t=1700262381; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=k5KBwDjqy9zVaksdzCNt+2tR5GteNRttaKWWMRDegUE=; b=D6otjcRBl0FTe4TU5ltPmahoZdLwxFz/sg70jldN9MGwFY7J9GT0qY7uGD4SkVVaMZEoGm hoAHqLswa2s9x/AntYH+665gzZ+tMMe7EIaSMzZxoG+tE7J2H3LW91PthAhM+aV5NfCnKZ fIwtEYNtwL3tEr2z2R6wpVyDssSgFbuXdf+aplV64hFWGrtObtsCWzjSSOR7KvRCowW8WL ScWaFKbOYZYXejSR0CWHKR70y25MoBOul6GmbPYkGOdY5ybhyxa9Bu6vFNit9dbh+AlVx3 4Zt/PLBwFe4SYjzTPTrJK63sme/s/QlhWSl5xrl2WSofTqTS2722yYk98QOcPg== Received: by localhost (Postfix, from userid 1000) id 7AE465077C71; Sat, 18 Nov 2023 00:06:19 +0100 (CET) From: Dodji Seketeli To: fche@redhat.com (Frank Ch. Eigler) Cc: libabigail@sourceware.org, woodard@redhat.com Subject: Re: idea: abigail abixml archive Organization: Me, myself and I References: <20231115155306.GC15862@redhat.com> <87pm08y1qw.fsf@seketeli.org> <87zfzctorg.fsf@redhat.com> X-Operating-System: AlmaLinux 9.2 X-URL: http://www.seketeli.net/~dodji Date: Sat, 18 Nov 2023 00:06:19 +0100 In-Reply-To: <87zfzctorg.fsf@redhat.com> (Frank Ch. Eigler's message of "Fri, 17 Nov 2023 09:53:08 -0500") Message-ID: <87ttpkvv2s.fsf@seketeli.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-GND-Sasl: dodji@seketeli.org X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hello, [...] Dodji Seketeli writes: >> Today, even if you have access to the target distro, it's not practical >> with the current tools to know if the binary is "ABI compatible" with >> it. >> >> If I understand things correctly, you would need to: >> >> 1/ Get the ABI of the (transitive closure) set of dependencies of >> the binary on its original distro. I call it orig-deps-abi. >> 2/ Get the ABI of the set of dependencies of the binary on the >> target distro. I call it target-deps-abi. >> 3/ compare target-deps-abi against orig-deps-abi. fche@redhat.com (Frank Ch. Eigler) a =C3=A9crit: > Heck, if we're just testing binary A against the remote shared > libraries B C D, then the local libraries B C D may not be relevant at > all. I think it all boils down to what we mean by "testing binary A against its dependency". When we want to know if a binary A is compatible with a library B, we consider functions & global variables undefined in A and defined (and exported) in B. The DWARF for the types of the undefined functions & variables are present in A. These are the types "expected" by A. In B, there is going to be same types, because they come with the definition of the exported functions & variables that are expected by A. So these types are "provided" by B. We can compare the types expected by A to their counterpart provided by B and if they are equal, then A is compatible with B, as far as these functions & variables and their types are concerned. This is basically what abicompat does. But then there is a case of incompatibility that we can't catch by looking at just A and B. That is, if a function that was previously defined in B (and is needed by A) is removed from B. In that case, we need to know if that function was moved to another dependency of A. It only is if the function is removed from all the dependencies of A that we can know for sure that the function is missing, and thus, that A is facing an incompatible change in that regard. > Is the transitive closure necessary? I think the transitive closure would be necessary for the case I explained above, because a removed function could have been moved to any other dependant library. Or am I missing something? > If so, then it's just comparing the local binary A vs. the > directly dependentent remote libraries mentioned in DT_NEEDED. If you only want to consider the dependant remote dependencies, then that would amount to doing what abicompat does today, more or less. I think that could work too (instead of going through [1-3]). The only caveat I would have is the transitive closure one. [...] fche@redhat.com (Frank Ch. Eigler) a =C3=A9crit: >>> To keep it dead simple, there could be one branch per /etc/os-release >>> $ID/$VERSION_ID, one file per shared library in the distribution. For >>> example, a fedora-39-x86-64 copy of /usr/lib64/libc.so.6, the file >>> abidw produces could sit at >>> >>> repo git://sourceware.org/git/libabigail.git=20 >>> branch gitabixml/fedora/39/x86_64 >>> file /usr/lib64/libc.so.6.xml Dodji Seketeli writes: >> >> I would even go further as to put the binary inside a subdirectory tree >> with all that information, making it somewhat independent from being in = git: fche@redhat.com (Frank Ch. Eigler) a =C3=A9crit: > hmm >>> repo git://sourceware.org/git/distributions-abi.git >>> file /fedora/39/x86_64/glibc/usr/lib64/libc.so.6.xml > ^^^^^^^^^^^^^^^^^^##### > > While the ^^^^ first part can be known to the client, the #### package > abbreviation may well not be. A binary just makes reference to sonames, > which are only roughly file names, and definitely not package > abbreviations. Indeed, not all binary present on the user's system come from a package. And the ABI of those binaries might indeed end up in the repository. Point taken. OK then, I take the package thing back. Let's just store the thing in Git as you proposed. [...] >> Also, we need to add a mode to libabigail to let it expect debuginfod >> to find the debuginfo because today, it expects the user to provide >> the debug info location in cases where it's not already installed on >> the system. [...] > > Are you sure? I run libabigail tools without any manual -d type > settings or debuginfod overrides, and it already just works, via > elfutils' builtin debuginfod support. > Interesting. I must double check. I must have broken something locally then. I am pretty sure to remember I've had to add the --d{1,2} to abipkgdiff otherwise it wasn't finding debuginfo. But I need to double check. It it works that's great :-) Cheers, --=20 Dodji