From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id AFD7D3858281; Tue, 6 Jun 2023 21:07:02 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AFD7D3858281 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1686085622; bh=llcwU4jtoBf/W+Zp+tq7j+SCzn3V/NqkOKQcfocJfu0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=vL3IrdjMSCOY/PaLQePcCYkavTyC9UC0ASXH+kniLjoHmqSSO+tqT5VGfZXKFgFM/ 8DecKx9vEngVkQZkjj+YGpLyFwY8EFrAxydtkfoToLOArKsktQHS8PLc6uTPlyQWYP /ZfAn/tKPgALkjrm3xH6a0Ihb3ihgfL09RbH45/I= From: "woodard at redhat dot com" To: libabigail@sourceware.org Subject: [Bug default/30034] [libabigail] Handle library splitting Date: Tue, 06 Jun 2023 21:07:01 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: libabigail X-Bugzilla-Component: default X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: woodard at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: dodji at redhat dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D30034 --- Comment #9 from Ben Woodard --- my original for abicompat was to add --recursive I'm no longer convinced th= at I like that idea. I like the --follow-dependencies or even making that the default and have --exclude-dependencies.=20 Right now we support: FILE_TYPE_XML_TU, (formerly called FILE_TYPE_NATIVE_BI)=20 FILE_TYPE_ELF, FILE_TYPE_AR, FILE_TYPE_XML_CORPUS, FILE_TYPE_XML_CORPUS_GROUP, FILE_TYPE_RPM, FILE_TYPE_SRPM, FILE_TYPE_DEB, FILE_TYPE_DIR, FILE_TYPE_TAR What I'm thinking is: abidw currently either emits FILE_TYPE_XML_CORPUS or FILE_TYPE_XML_CORPUS_G= ROUP in the case of a kernel.=20 I think it should work like this: * normal.o -> FILE_TYPE_XML_TU or by explicit request promotion to FILE_TYPE_XML_CORPUS or even FILE_TYPE_XML_CORPUS_GROUP * elffile -> FILE_TYPE_XML_CORPUS_GROUP which includes dependencies or by explicit request FILE_TYPE_XML_CORPUS without dependencies. Note that this = is a change of behavior. Right now libabigail emits a corpus and only emits FILE_TYPE_XML_CORPUS_GROUP when it given a directory and a kernel vmlinux f= ile. * archive, tar, rpm, deb, dir, or multiple files -> FILE_TYPE_XML_CORPUS_G= ROUP I think for completeness sake abidw should also allow some up and down conversion * FILE_TYPE_XML_TU can be promoted to FILE_TYPE_XML_CORPUS (with one TU) or FILE_TYPE_XML_CORPUS_GROUP (with one TU and a group size of 1) * FILE_TYPE_XML_CORPUS=20 * can be promoted to FILE_TYPE_XML_CORPUS_GROUP with a group size of 1 * can be down converted to FILE_TYPE_XML_TU by specifying the TU to extract. * FILE_TYPE_XML_CORPUS_GROUP * can be down converted to FILE_TYPE_XML_CORPUS if the size of the gro= up is 1 or by specifying the specific corpus to extract.=20 * can be down converted to FILE_TYPE_XML_TU if the size of the group i= s 1 and the TU to extract is specified or by specifying the corpus and the tu within it to extract. Lastly allowing abidw to accept its own xml formats allows additional suppressions to be applied to the abi. --=20 You are receiving this mail because: You are on the CC list for the bug.=