From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-f54.google.com (mail-ej1-f54.google.com [209.85.218.54]) by sourceware.org (Postfix) with ESMTPS id 0B04B3858C56 for ; Mon, 28 Mar 2022 10:41:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0B04B3858C56 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=debian.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ej1-f54.google.com with SMTP id bg10so27728587ejb.4 for ; Mon, 28 Mar 2022 03:41:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version; bh=rztMDjH/p1wHNbBRxJJSKlWuqJwKWrqlOf1lJTPutSA=; b=NyaZExdbYW6Lpwo479XACcSQPmP7+P9hnOu34VeFP+ZqPVhrHJDAuBQt6OKHs7OV0L lKDu3E2B2wIGaNjo0y1C/5cZD8WiCOjE4aEhBLqrpAaFffBuEWr6fPsPTzDfjPrQ8/pq +Q73xZ3YPT2c5LI3krqi0cSJnUmkC+ieVT6iCjR7t5YQF/alpRNUpwkpiu2NFAwFwZmn +FJi3mLtBgej8pDvmFijrbAMMOFRjCAFniCLuNdqAMbc/zZGdbSzICaQBnIr4utoK35Z k9gjFwD6Cxc7z7Oe7Ts9KTumbpAldyea8zpPn5J6R0xoYjihilIde48HtxU4u9zaP1AX H3aA== X-Gm-Message-State: AOAM532jkB6MlqB7/Ga1dJPu+mvqKoyGiI3d+j5ZfxQfBtBd6WjDB0j6 KrmSxJLCk2oHA9SW6aEWjVE= X-Google-Smtp-Source: ABdhPJzf7Z919r+4LsCKvO3/WBKpbrQfAc9HiXzo9pkGRaUA+MfDF7MqzVCyZqs7gX38JYxca45j7A== X-Received: by 2002:a17:906:a2d9:b0:6df:b8c9:e694 with SMTP id by25-20020a170906a2d900b006dfb8c9e694mr27319579ejb.448.1648464083229; Mon, 28 Mar 2022 03:41:23 -0700 (PDT) Received: from localhost ([2a01:4b00:f41a:3600:360b:9754:2e3a:c344]) by smtp.gmail.com with ESMTPSA id s11-20020a170906284b00b006e108693850sm1598478ejc.28.2022.03.28.03.41.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Mar 2022 03:41:22 -0700 (PDT) Message-ID: <7ede1fe0509cdc773ff7ba24426de3369a35e649.camel@debian.org> Subject: Re: [PATCH v2] libebl: recognize FDO Packaging Metadata ELF note From: Luca Boccassi To: Mark Wielaard Cc: elfutils-devel@sourceware.org, Tom Stellard Date: Mon, 28 Mar 2022 11:41:20 +0100 In-Reply-To: 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: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-uJKgzhwfuGB+jOHvfIAA" User-Agent: Evolution 3.38.3-1+plugin MIME-Version: 1.0 X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, 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 10:41:28 -0000 --=-uJKgzhwfuGB+jOHvfIAA Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2022-03-28 at 11:57 +0200, Mark Wielaard wrote: > Hi Luca, >=20 > 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! >=20 > 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. >=20 > 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. Fix for the doc is queued too: https://github.com/systemd/systemd/pull/22879 > 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. Yes, that would definitely be ideal. But a bit of a chicken-and-egg: we had to get the spec established before there's any realistic change of getting a full new feature merged in BFD, but we can't get it established if we can't use it anywhere. This way we can 'bootstrap' ourselves, and once the idea and usage is more widely accepted, we have a good case to do just that. --=20 Kind regards, Luca Boccassi --=-uJKgzhwfuGB+jOHvfIAA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEErCSqx93EIPGOymuRKGv37813JB4FAmJBkNAACgkQKGv37813 JB6maw//XzCqFx3xwHZPBf6rB18UqcMIC7c8EQAQpN9EQ/jq7fzBOlwemKnutOWv 7Otwy7kg0IR0gCMedef0TqD9u7XGahghPG9aGsVMwGDn/kVsbe3mOq+r8Y8nLQ+/ CYgfr/7JBOca28zjdhcpGc9AP00ELpDHTDyv98PR6uDRxdj6zxzhT2TXyTU/+z95 0DU3Mnz9hBqU7CSwdMnhVzlShRw7PhZ9dSatISS+dzUmuvkc6raFGlclwfFCYBPc S6TVj+NPzGF1d5MnyfQYsF6I47ZSruqOdsnUl8AmgbPC5o41NeH+M878n3sGhqfU G1eYRs+ffEu2yovcBCfEdC0gXPqsF3MM930+LViApvCtDSUng14tngPDZW0aXIOq Rmz7yE5srZyTZFTAg+1u+mxRveNGmFEHJsfac1cu8k08BZJ+B9150X0g6/o6ROmi HnGQoZ2EkE1r3sBuyFYqQXA3VgprE3tbYd9VSVbWB9hprvYoAlTgoCdlweVnunZa aJ+1cLK06sNMAAqQzut2ELXt1yU0HdJhXJ2U83bkmib1iMMURDdj6C6s7QNGcR/b OyFBQ+cRsZhwWk1IxOSdXqytxe23jJBrAfLU864CHE21yE5YFLTuxtCgrIA7r7/Q AL7tRIxOM/6c3zU3ZZ82N1zHsYjCCvyN6iIKOGMUoVnEt7ah7Ww= =haL1 -----END PGP SIGNATURE----- --=-uJKgzhwfuGB+jOHvfIAA--