From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 0049F3857343 for ; Mon, 30 May 2022 14:08:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0049F3857343 Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-12-xTIeACZWNHGcS6OeJfrOXQ-1; Mon, 30 May 2022 10:08:30 -0400 X-MC-Unique: xTIeACZWNHGcS6OeJfrOXQ-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 31B8738349C7; Mon, 30 May 2022 14:08:30 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.134]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3E1444050C40; Mon, 30 May 2022 14:08:29 +0000 (UTC) From: Florian Weimer To: Luca Boccassi Cc: Nick Clifton , binutils@sourceware.org Subject: Re: [PATCH] ld: add --package-metadata 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> <06ee175e2bf89f2f1ee9a6961749a3dcf56edc13.camel@debian.org> Date: Mon, 30 May 2022 16:08:27 +0200 In-Reply-To: <06ee175e2bf89f2f1ee9a6961749a3dcf56edc13.camel@debian.org> (Luca Boccassi's message of "Wed, 25 May 2022 14:53:06 +0100") Message-ID: <87h757i04k.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.11.54.2 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham 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: Mon, 30 May 2022 14:08:34 -0000 * Luca Boccassi: > On Wed, 2022-05-25 at 10:45 +0200, Florian Weimer wrote: >> * Luca Boccassi: >> >> > 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. >> >> 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. >> >> 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. But there are far fewer distributions and ELF post-processing mechanisms than upstream build systems. (The RPM mechanisms are even shared by multiple RPM-based distributions which are otherwise quite dissimilar.) If the JSON is passed as a shell argument, you have to worry about encoding backslashes and double quotes. When constructing the string, you really have to know whether it will be subject to shell parsing or not. The current CFLAGS and LDFLAGS we have in the distribution do not have this issue because they do not contain any shell metacharacters, so we do not have sufficient experience with this. I guess you could side-step this with optional base64 encoding. > The advantage of having a common, standard and shared interface is > that every distro that opts-in will produce the same results, You have to get it through the package build system, though. That's easier with short, fixed option strings, strings which do not contain any funny characters. >> 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. Fedora will switch to a different scheme if a better one becomes available. Even the present feature itself is redundant relative to Fedora's build IDs, and clearly they haven't blocked implementation of the new thing. Thanks, Florian