From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from master.debian.org (master.debian.org [IPv6:2001:41b8:202:deb:216:36ff:fe40:4001]) by sourceware.org (Postfix) with ESMTPS id 51F69393C846; Fri, 14 May 2021 10:41:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 51F69393C846 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=debian.org Authentication-Results: sourceware.org; spf=none smtp.mailfrom=guillem@master.debian.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debian.org; s=smtpauto.master; h=In-Reply-To:Content-Type:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description; bh=8Qja3uXZFweEDiO4RYlWVtxTHPo2AYzSYG/PZgjXkMs=; b=eiZHhpBNvpMtmXyaYouKmIsR2u AlrFhDZEyX3JsvSGOpvW122LAtnVUYup7jNVq2C9cusozw+Keqqp8WrPYmm22O3lRQoMA67azZdBA MCLOfegnJLkP714T/7xU77CFJUM/PmboOQNr+U0I2FRbO3JtsP2WashAtTHYGd3ial9tb6hTY2vre w1kxbCoclSY4J4uLvTzl1fu9AcKBUYcTAaDf/PpKYQ82qrzkKKEybWU06rEoaib9EIKEA/J6gbjTQ L7X2/JdiH89PILdaGX0ZlsNu2SX4QDfLG6qmU6t86+k5jo7L5nK8PKPF5igFoRHkbN0TuwICw0wAU kGF5VNWA==; Received: from guillem by master.debian.org with local (Exim 4.92) (envelope-from ) id 1lhVFl-0005Ho-42; Fri, 14 May 2021 10:41:09 +0000 Date: Fri, 14 May 2021 12:41:07 +0200 From: Guillem Jover To: Luca Boccassi Cc: SystemD Devel , "elfutils-devel@sourceware.org" , binutils@sourceware.org, debhelper@packages.debian.org, debian-dpkg@lists.debian.org, devel@lists.fedoraproject.org, Zbigniew =?utf-8?Q?J=C4=99drzejewski-Szmek?= , Lennart Poettering Subject: Re: Storing package metadata in ELF objects Message-ID: Mail-Followup-To: Luca Boccassi , SystemD Devel , "elfutils-devel@sourceware.org" , binutils@sourceware.org, debhelper@packages.debian.org, debian-dpkg@lists.debian.org, devel@lists.fedoraproject.org, Zbigniew =?utf-8?Q?J=C4=99drzejewski-Szmek?= , Lennart Poettering References: <2b91ec1654b6c07cca2b5c113df772c85c0dd22c.camel@debian.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2b91ec1654b6c07cca2b5c113df772c85c0dd22c.camel@debian.org> X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: elfutils-devel@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Elfutils-devel mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2021 10:41:21 -0000 On Sat, 2021-04-10 at 13:38:31 +0100, Luca Boccassi wrote: > On Sat, 2021-04-10 at 13:29 +0100, Luca Boccassi wrote: > > After an initial discussion [0], recently we have been working on a new > > specification [0] to encode rich package-level metadata inside ELF > > objects, so that it can be included automatically in generated coredump > > files. The prototype to parse this in systemd-coredump and store the > > information in systemd-journal is ready for testing and merged > > upstream. We are now seeking further comments/opinions/suggestions, as > > we have a few months before the next release and thus there's plenty of > > time to make incompatible changes to the format and implementation, if > > required. I've skimmed over the discussion at [0], and while having this data seems like it might be "nice", I've to agree with the comments there voicing that there does not really seem to be an actual need and the overhead and additional work do not seem worth it, TBH, at least in the Debian context. > > The Fedora Wiki and the systemd.io document have more details, but to > > make a long story short, a new .notes.package section with a JSON > > payload will be included in ELF objects, encoding various package- > > build-time information like distro name&version, package name&version, > > etc. > > > > To summarize from the discussion, the main reasons why we believe this > > is useful are as following: > > > > 1) minimal containers: the rpm database is not installed in the > > containers. The information about build-ids needs to be stored > > externally, so package name information is not available immediately, > > but only after offline processing. The new note doesn't depend on the > > rpm db in any way. In the Debian context, the build-ids data is going to be available in the affected executables, and in debug symbols packages and the Packages metaindices listing them, so there's no need for access to any local dpkg database. Given that someone needing to install debug packages will need access to those indices (either with outgoing network access or with a repository mirror), these can be queried at that time. Not to mention that AFAIR the Debian debug symbol servers make it possible to query for specific build-ids. > > 2) handling of a core from a container, where the container and host > > have different distros How each distribution handles debug packages and debug symbols is going to be different, so it seems there will be a need for explicit handling of these, at which point the above mentioned querying can be implemented as well, w/o the need to encode the packaging data inside the executable. > > 3) self-built and external packages: unless a lot of care is taken to > > keep access to the debuginfo packages, this information may be lost. > > The new note is available even if the repository metadata gets lost. > > Users can easily provide equivalent information in a format that makes > > sense in their own environment. It should work even when rpms and debs > > and other formats are mixed, e.g. during container image creation. I'm not sure I see the problem here. Either these self-built 3rd-party packages are kept in repos that also provide the debug symbols somewhere for all historically released versions or these will not be accessible anyway. If they are, they can as well be located as per above from the Packages metaindices, and even if the repository metadata gets lost, as long as the debug symbol packages are present (if they are not what's the point anyway) the build-ids can always be re-scanned from them as they are part of the Build-Ids field in the .deb control file. > > Other than in Fedora, we are already making the required code changes > > at Microsoft to use the same format&specification for internally-built > > binaries, and for tools that parse core files and logs. > > > > Tools for RPM and DEB (debhelper) integration are also available [3]. So, to conclude, I don't really see the point of this in the Debian context. (Not to mention the problems with encoding binary versions that might be wrong, and the busy work involved.) > > [0] https://github.com/systemd/systemd/issues/18433 > > [1] https://systemd.io/COREDUMP_PACKAGE_METADATA/ > > [2] https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects > > [3] https://github.com/systemd/package-notes Thanks, Guillem