From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com [209.85.214.171]) by sourceware.org (Postfix) with ESMTPS id 6D6A33858D35 for ; Thu, 3 Feb 2022 19:46:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6D6A33858D35 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=maskray.me Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pl1-f171.google.com with SMTP id c3so3109403pls.5 for ; Thu, 03 Feb 2022 11:46:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=i0WbfUlkqY8Eg6ce7R4bpqMs0IpKJua6CNCfvPRT3RA=; b=PBbIjMTLhDiC1Rvn54n06v6htv3LDztjhCu+BmPKlhqbkfyN4rBR0ngBN+rkaA2KpJ 7xT/p4nUirr7XZYk9SA9eOpTxlR1SoFvc3FnC0zFtq2Zwuz+kmcsOPxjw9pIsCJhQrxQ 5d0bCaodlnqGelFlCTYOPYw8CYDzkC7u//0pBuwv1QQh/MrtwfJJCQOpU3UrRUiRhW2e wcsyyRgwcoJuot35TzYWnY28hh/QjxCWvEpcc4DHV8+tBkNdnG83ZqnMSiG6gdCrq0mj x8Xe3ZC92uD42TQGoSL2nEVoz1M98FL0u0eGGICtNbw3k6QxltJtk3V5oeoKuhOkWW1O S4XA== X-Gm-Message-State: AOAM530QkIDNdhk5bmIwHnEEp4f34olVUudxUTBpiuLIzfGqh0lhcbBy 0pl4X9wAgWdsgELcSn8AmMc= X-Google-Smtp-Source: ABdhPJyBOffTNABIL9cw58qOqRSxq0OgpRmpEmR4mz0vbefxkUUdBnNlbJ/jvjqvKaX742x3S4oGKA== X-Received: by 2002:a17:90b:4c92:: with SMTP id my18mr15070163pjb.135.1643917617398; Thu, 03 Feb 2022 11:46:57 -0800 (PST) Received: from localhost ([2601:647:6300:b760:fbc3:98b5:57a2:a3b8]) by smtp.gmail.com with ESMTPSA id pc4sm12703439pjb.3.2022.02.03.11.46.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 03 Feb 2022 11:46:56 -0800 (PST) Date: Thu, 3 Feb 2022 11:46:56 -0800 From: Fangrui Song To: Luca Boccassi Cc: Nick Clifton , binutils@sourceware.org, Alan Modra Subject: Re: [PATCH] ld: Support customized output section type Message-ID: <20220203194656.ljthsfag5chdzadb@gmail.com> References: <20220202071044.1480421-1-maskray@google.com> <20220202183206.fhnivs3kb4ntnkmp@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_INFOUSMEBIZ, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, 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: 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: Thu, 03 Feb 2022 19:47:01 -0000 On 2022-02-03, Luca Boccassi wrote: >On Wed, 2022-02-02 at 10:32 -0800, Fangrui Song wrote: >> On 2022-02-02, Nick Clifton via Binutils wrote: >> > Hi Fangrui, >> > >> > > The current output section type allows to set the ELF section type to >> > > SHT_PROGBITS or SHT_NOLOAD. This patch allows an arbitrary section v= alue >> > > to be specified. Some ELF section type names are supported as well, >> > >> > Thanks for the patch submission. I am regression testing it at the mo= ment >> > but in the meantime a couple of things stood out for me: >> > >> > >> > > +@item TYPE =3D @var{type} >> > > +Set the section type to the integer @var{type}. For the ELF output >> > > +file, some type names (e.g. @code{SHT_NOTE}) are also allowed for >> > > +@var{type}. >> > >> > Rather than having users guess, it would probably be best to list which >> > type names are supported. >> > >> > Also it is probably worth documenting that it is the user's fault if t= hey >> > set the section type to something which has special semantics (eg SHT_= GROUP) >> > but then they do not also arrange for whatever necessary support that = feature >> > needs. Something like: "it is the user's responsibility to ensure that >> > any special requirements of the section type are met". >> >> Thanks for the quick review! Adopted the wording and the change below. >> The new patch is in the attachment. >> >> >> For SHT_GROUP, I think it is useful to support SHT_GROUP as well. I >> actually did an experiment last night but SHT_GROUP led to an internal >> error. There may be some issues that need to be fixed to use the >> SHT_GROUP feature. >> >> > >> > >> > > + case type_section: >> > > + if (os->sectype_value->type.node_class =3D=3D etree_name >> > > + && os->sectype_value->type.node_code =3D=3D NAME) >> > > + { >> > > + const char *name =3D os->sectype_value->name.name; >> > > + if (strcmp (name, "SHT_PROGBITS") =3D=3D 0) >> > > + type =3D SHT_PROGBITS; >> > > + else if (strcmp (name, "SHT_NOTE") =3D=3D 0) >> > > + type =3D SHT_NOTE; >> > > + else if (strcmp (name, "SHT_NOBITS") =3D=3D 0) >> > > + type =3D SHT_NOBITS; >> > > + else if (strcmp (name, "SHT_INIT_ARRAY") =3D=3D 0) >> > > + type =3D SHT_INIT_ARRAY; >> > > + else if (strcmp (name, "SHT_FINI_ARRAY") =3D=3D 0) >> > > + type =3D SHT_FINI_ARRAY; >> > > + else if (strcmp (name, "SHT_PREINIT_ARRAY") =3D=3D 0) >> > > + type =3D SHT_PREINIT_ARRAY; >> > > + else >> > > + einfo (_ ("%F%P: invalid type for output section `%s'\n"), >> > > + os->name); >> > >> > It might be worth adding SHT_STRTAB to this list, as I can imagine some >> > weird sceanario where someone would want it. >> >> Added. >> >> > >> > Also - given that this is a new feature, there really ought to be an e= ntry >> > for it in the ld/NEWS file. >> >> Added. The NEW entry is for 2.39, but feel free to port it to 2.38 if >> you think appropriate:) > >Hi, > >I tested this patch, it doesn't seem to allow combining multiple >attributes. Tried both in the same brackets and separately, eg: > >.note.foo (READONLY) (TYPE=3DSHT_NOTE) > >.note.foo (READONLY TYPE=3DSHT_NOTE) > >Could you please send a new revision that fixes this (no opinion on the >syntax), so that we can use it? Thanks! > It doesn't, as I am not sure the combination is useful. --- I raised my concern twice when READONLY was added: * https://sourceware.org/pipermail/binutils/2021-May/116579.html * https://sourceware.org/pipermail/binutils/2021-July/117492.html See also Michael Matz's https://sourceware.org/pipermail/binutils/2022-Febr= uary/119598.html "IOW: I think the introduction of READONLY was ill-advised :-/ But, ... w= ell :)" In another place, you said > As I have already shown, it is necessary. The note is read/write > otherwise: >=20 > [ 3] .note.package NOTE 00000000000002e8 000002e8 >=20 > 0000000000000030 0000000000000000 WA 0 0 4 > and that breaks processing the note from core files. It needs to be > read/only, like the build-id, and hence the required change in bfd to > make it possible to do so. I believe none of Alan, Matz, and I can reproduce what you have seen. (If Alan noticed it, he should have fixed it in https://sourceware.org/bugz= illa/show_bug.cgi?id=3D26378#c11) Can you give more instructions how your .note.package got the SHF_WRITE flag? It looks like a separate ld bug, if your ld included the above change.