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 E1F703858C56 for ; Mon, 28 Mar 2022 09:57:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E1F703858C56 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 9706A300047C; Mon, 28 Mar 2022 11:57:53 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id CBF9A413CEB2; Mon, 28 Mar 2022 11:57:52 +0200 (CEST) Message-ID: Subject: Re: [PATCH v2] libebl: recognize FDO Packaging Metadata ELF note From: Mark Wielaard To: Luca Boccassi Cc: elfutils-devel@sourceware.org, Tom Stellard Date: Mon, 28 Mar 2022 11:57:52 +0200 In-Reply-To: <976e9368e62fb585b9084a7c200e55615588a123.camel@debian.org> References: <20211119003127.466778-1-luca.boccassi@gmail.com> <20211121194318.105654-1-luca.boccassi@gmail.com> <40a5de54f089f344697ece88e11eb41e526462ac.camel@gmail.com> <17e1d554c9a52598d2c7d27e7a40f17381285ba5.camel@klomp.org> <20220324231438.350551-1-mark@klomp.org> <3ad724af194ed4b05d539f0807d77ae7955371df.camel@debian.org> <77321d756629343a321f4e011e52d1a1fcdd7302.camel@klomp.org> <723cfa8d317969f3ea48947da2cd9c3051cbb937.camel@debian.org> <79cab1ec6a8a5556f65e7a2ba0d7f8125a1db865.camel@klomp.org> <976e9368e62fb585b9084a7c200e55615588a123.camel@debian.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.8 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Mon, 28 Mar 2022 09:57:58 -0000 Hi Luca, On Sat, 2022-03-26 at 18:19 +0000, Luca Boccassi wrote: > > Already working on the updated script, the native type is exactly > > the > > approach I was taking, this works fine on a Debian machine on s390x > > (and also on x86_64), eg: > >=20 > > - BYTE(0x04) BYTE(0x00) BYTE(0x00) BYTE(0x00) /* Length of > > Owner including NUL */ > > - BYTE(0x47) BYTE(0x00) BYTE(0x00) BYTE(0x00) /* Length of > > Value including NUL */ > > - BYTE(0x7e) BYTE(0x1a) BYTE(0xfe) BYTE(0xca) /* Note ID */ > > + LONG(0x04) /* Length of > > Owner including NUL */ > > + LONG(0x0047) /* Length of > > Value including NUL */ > > + LONG(0xcafe1a7e) /* Note ID */ > >=20 > > The rest of the fields are C strings so no change needed, I > > believe. > >=20 > > Does this look right to you as well? >=20 > Here's the fix: >=20 > https://src.fedoraproject.org/rpms/package-notes/pull-request/3# >=20 > Now it's up to the Fedora folks what to do with it. I tested the > updated script on Debian x86_64 and s390x, and it all works as > intended. Sorry again for the breakage! Yes, that looks correct. Note that the example on=20 https://systemd.io/COREDUMP_PACKAGE_METADATA/ also uses BYTEs for everything, instead of LONGs for the namesz, descsz and type words. This also seems to make sure everything is aligned (at 4 bytes). An ELF note is defined as an array of (4 byte) words. Where the first 3 (n_namesz, n_descsz, n_type) have a special interpretation. Your name string is also exactly 4 bytes "FDO\0", so you don't need any extra padding to make the start of the descriptor be aligned. And since you don't add any other notes to the section you don't need to explicitly pad the description. The linker should take care of that in case it merges note sections/segments. Still I would really recommend trying to add native support to linkers for package notes, just like they support build-ids by default. That also makes it easier for the linker to simply merge the notes. Trying to do this with inserting a linker script really feels very fragile. Cheers, Mark