From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-f43.google.com (mail-ot1-f43.google.com [209.85.210.43]) by sourceware.org (Postfix) with ESMTPS id 3CCA33857BBB for ; Wed, 25 May 2022 13:53:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3CCA33857BBB 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-ot1-f43.google.com with SMTP id n2-20020a9d6f02000000b0060b22af84d4so3154908otq.1 for ; Wed, 25 May 2022 06:53:11 -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=LcQBLM+SViT+ZItiIsew8ZfKQuJGVWSJt29004Iscl4=; b=VVBGBAp0b716vsZ89C1yLJoEvgEC1Ps0YGrfpUf47gv7o5WGsGMFbURlDmpG/UZYNK 4rDq09mBBuZDgRi0nzj6lKXaGSxc9SfETfE4dOVInvSHEUUhRUwo9sfHbrJrVdQfISkq x2Wt4uWPkJipZF/Lt9CdAlxmYFZuuDgTwdUMsBPBO3Y294eE2V0Abh8rh52/6oBLdIm+ DeHFo4b4FiUkh2OrS4oPWMcAGEAbHC9fEWptWvEjP6QiRH6HRyscawCcGMVt5g73FTtX khUhj3oRXrETHwdkh+w5pJEUrc7K9GgcgMJZD0/8YssUcH3qLQ1G2qTgw0/xMFVAhT2z g5aw== X-Gm-Message-State: AOAM530PXaTNYeKY4kjJcHhWnQnCa7BZaDs8npG9htHdLEvpwl14fBVc FgSe8M36Vgo0ZO8VFuWqihk= X-Google-Smtp-Source: ABdhPJyrhr3cALsWSXV1h21IqpG8wdlgI57P9yVjW4KZv5tVsOq/ijV1N1FVP4YUHUvmS6hT/IuFiA== X-Received: by 2002:a9d:6649:0:b0:60b:3655:cf75 with SMTP id q9-20020a9d6649000000b0060b3655cf75mr781780otm.303.1653486790495; Wed, 25 May 2022 06:53:10 -0700 (PDT) Received: from localhost ([2a01:4b00:f41a:3600:360b:9754:2e3a:c344]) by smtp.gmail.com with ESMTPSA id bg9-20020a056820080900b0040e6e53f6bfsm3953382oob.15.2022.05.25.06.53.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 May 2022 06:53:09 -0700 (PDT) Message-ID: <06ee175e2bf89f2f1ee9a6961749a3dcf56edc13.camel@debian.org> Subject: Re: [PATCH] ld: add --package-metadata From: Luca Boccassi To: Florian Weimer Cc: Nick Clifton , binutils@sourceware.org Date: Wed, 25 May 2022 14:53:06 +0100 In-Reply-To: <87sfoy80gc.fsf@oldenburg.str.redhat.com> References: <20220515191846.114257-1-luca.boccassi@gmail.com> <7cd459a6-ac46-e9c2-14d1-16d78118bb92@redhat.com> <693aa125072ed68a25d1e57aeb87bea9174f96fb.camel@debian.org> <87sfoy80gc.fsf@oldenburg.str.redhat.com> Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-QmYnLjZKTYg83h8c0O9M" User-Agent: Evolution 3.38.3-1+plugin MIME-Version: 1.0 X-Spam-Status: No, score=-2.7 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.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2022 13:53:12 -0000 --=-QmYnLjZKTYg83h8c0O9M Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2022-05-25 at 10:45 +0200, Florian Weimer wrote: > * Luca Boccassi: >=20 > > So with that experience in the bag, the most obvious next step is to > > have a first-class option, that allows a self-contained flag to be > > passed instead. After all the idea is similar to the build-id, and > > there we have a first-class option too, and it works well. >=20 > Maybe it's better to just pre-allocate space for the program header note > (and corresponding data) and patch the actual contents in later, maybe > as part of the debuginfo post-processing. >=20 > This would also side-step any shell encoding issues of the JSON object. I'm not sure - that still requires to do a lot of the work here, while also leaving each and every distro builder to implement a whole load of integration on their own, risking divergence to appear at some point, while allowing for many more things to go wrong at multiple stages. The advantage of having a common, standard and shared interface is that every distro that opts-in will produce the same results, so that tooling doesn't need to take these differences into account. And it either works or not, in a single step. The advantages would be very minimal - there is already knowledge about specific fields, this was pretty much modelled on the existing --build- id support, and it would still require implementation support here. Given there seems to be some concerns with the jansson integration, I've flipped it in v3 to be default-disabled, regardless of the status of the build env. It now is explicit opt-in. I hope that makes the patch more palatable? > A really nice approach would require changes to the way we generate > coredumps: teach the dumper to copy non-allocated sections from a file > region. Then we wouldn't have to pre-allocate section contents at all. > I think the core dumper would have to look at section headers for this, > not program headers. We could add a program header that describes the > file region to be copied, but it would get out of sync with the file > contents if ELF editing tools don't know that it has to be updated if > non-allocated sections are changed. Requiring such sweeping changes in the kernel (it would be a default behaviour change, whether one opts in to this or not), which means they need to be propagated everywhere, would take years at best, even if it was possible, acceptable and it were to actually happen. Also, the consumer implementation would no longer be compatible with what we have published now in production in CBL-Mariner and Fedora. --=20 Kind regards, Luca Boccassi --=-QmYnLjZKTYg83h8c0O9M Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEErCSqx93EIPGOymuRKGv37813JB4FAmKONMIACgkQKGv37813 JB4MUg/+OZ/+i+bwxWZ1xtR+PF7kGsPXbjJKUiBg4ACXABgsHno5PJVbxytKp5F3 sYB4QbJc5J8WD7AMeBFYIN9EyGdpsvRm+O4YQw9cpV1tkdQdakzYNzB8hKBbo8RB sifg6VsbFjzqJMtKXIsrsJkh2f5+2FOr0Ui5cvqUOcnj/kN0hWoyZ6vEej4fRQfJ XaMelLYMismgn+UCXItIR3RB/MuImLweJTcNyWNd0X1WK7eZcV0VoUoQkUfyPw9f MEHlL00xzsDPrSunRDoCGHwrGB2ki/wZ6HcjS8eaTBbtEe1tw5LuOfnrTp/7pF3D jOGYj2f4P+Fh8E3bT+G2LGn1PW2XVmY2yoHEqN7lssSaaKeKEt9J/aIO+IRGOAPC JhIMkv6g7fFas7zW+vDXwD5ZjXPvwLsKskjIg//Ok5Y2LUAPs57gRqVZornvO4EG MftxE2+FacFd/GGilV8kUZU+HixfEZWUxUyOQRkqgrbPVrB3YN2N93NwoCmAa6Mq q2yNSewOBNj6iQHFCkzn5Yac23lOgxq6BTCOECgMsMpAa4Gs0mXQkbQvC7+qA5Oh utzfkH524ckkiGcCSO08EZeQf8REIEODAoKcOaXgtnCzuBTJ7rmD7ouD1YQFBUz8 4ky+N+kMQqrLlhndUiXvoyXRXyHmqnfUcrltCGN2xk49tiloCHY= =1UMA -----END PGP SIGNATURE----- --=-QmYnLjZKTYg83h8c0O9M--