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.129.124]) by sourceware.org (Postfix) with ESMTPS id D241D383E6B6 for ; Wed, 25 May 2022 08:45:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D241D383E6B6 Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-663-Y5bFE9Q2MXqCM3R1ZfUOaA-1; Wed, 25 May 2022 04:45:43 -0400 X-MC-Unique: Y5bFE9Q2MXqCM3R1ZfUOaA-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id C1174101A54E; Wed, 25 May 2022 08:45:42 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.193.94]) by smtp.corp.redhat.com (Postfix) with ESMTPS id BA9037AD8; Wed, 25 May 2022 08:45:41 +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> Date: Wed, 25 May 2022 10:45:39 +0200 In-Reply-To: <693aa125072ed68a25d1e57aeb87bea9174f96fb.camel@debian.org> (Luca Boccassi's message of "Tue, 24 May 2022 19:38:23 +0100") Message-ID: <87sfoy80gc.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.79 on 10.11.54.5 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, 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: Wed, 25 May 2022 08:45:46 -0000 * 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. 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. Thanks, Florian