From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail8.parnet.fi (mail8.parnet.fi [77.234.108.134]) by sourceware.org (Postfix) with ESMTPS id 3C12A385772A for ; Mon, 22 May 2023 08:53:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3C12A385772A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=martin.st Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=martin.st Received: from mail9.parnet.fi (mail9.parnet.fi [77.234.108.21]) by mail8.parnet.fi with ESMTP id 34M8rA7Z014490-34M8rA7a014490; Mon, 22 May 2023 11:53:10 +0300 Received: from foo.martin.st (host-97-187.parnet.fi [77.234.97.187]) by mail9.parnet.fi (Postfix) with ESMTPS id 18BDBA1407; Mon, 22 May 2023 11:53:09 +0300 (EEST) Date: Mon, 22 May 2023 11:53:09 +0300 (EEST) From: =?ISO-8859-15?Q?Martin_Storsj=F6?= To: Jan Beulich cc: Tristan Gingold , Nick Clifton , binutils Subject: Re: [PATCH] pe/coff - add support for base64 encoded long section names In-Reply-To: <2f283c17-ebda-442a-568e-5a2cfaeae0bc@suse.com> Message-ID: References: <243D0799-E3D0-4938-A438-DD8725593F67@free.fr> <040cfba6-009c-4e57-34b9-07469191aa88@free.fr> <2f283c17-ebda-442a-568e-5a2cfaeae0bc@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-FE-Policy-ID: 3:14:2:SYSTEM X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_PASS,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 List-Id: On Mon, 22 May 2023, Jan Beulich via Binutils wrote: > I further wonder what LLVM's motivation is to zero-pad (i.e. 'A'-prefix) > the encoded values, rather than - like pre-existing section name > representation - nul-padding at the end. FYI, this format isn't LLVM's own invention, it's modelled after what MSVC does produce. See https://github.com/llvm/llvm-project/commit/9d2c15eff7edd220a3246ebedd2e502051e49844 for the commit where it was introduced in LLVM: > MC: Support COFF string tables larger than 10MB > > Offsets past the range of single-slash encoding are encoded as base64, > padded to 6 characters, and prefixed with two slashes. This encoding is > undocumented but used by MSVC. > At the very least I'm inclined to suggest that we also support that > obvious (I think) alternative here. I guess that's fine, but it's probably safest to produce the zero-padded format, if support for generating it gets added later. // Martin