From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-f174.google.com (mail-pg1-f174.google.com [209.85.215.174]) by sourceware.org (Postfix) with ESMTPS id D50F53858D35 for ; Thu, 3 Feb 2022 20:48:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D50F53858D35 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-pg1-f174.google.com with SMTP id j10so3256293pgc.6 for ; Thu, 03 Feb 2022 12:48:05 -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=kbnXpw6LOtkpHp+98D/SIDXEa35Km0psBaywxTfC47A=; b=tlA6d1IB/cnkDnEn1t847DPBVxUCe++lqm9YiXPkBkKrSzeFavHjAlLS2KLY5H4frW Oks+Q06PMY2JyVt7iajqdMPBOyeRg2AKqNc09WZpsGS6vI9XXZAJE1z5cgG4QI6fEPgb LxOarednBEha8zahLHsaEDiBN6QEPD1Hyf1ViewsDy9JNSEjoxNVVD+DPHd7lxKuKH+E h7vmDSEddBwSZ7ZMQaUccvYW6AEmz/uyovC2bnU6DOIc/R7tl/tAr5S12OwM2bB/qUVt m9BERjP0zyfhd0bl4PzWND4a6WddICUTeErwn1W4C5TFzG0YUc9kuZdQIceOzqbCup6e Tvow== X-Gm-Message-State: AOAM533aVccM4VUS1Sn+KZP2YtKTkNExsBDfwc+OmnwYeczUbTu5a87e bZA6iUpII20DElL8T8zMBH3v6ldacqo= X-Google-Smtp-Source: ABdhPJzIR2Vs2l6TZ0UeKXk54ZkD6Xt/b8XlZnGWzmCkqp6xFm05ZZgLm5KQUjycmfeeAwRuMxoZYw== X-Received: by 2002:a05:6a00:9a9:: with SMTP id u41mr35262740pfg.75.1643921284954; Thu, 03 Feb 2022 12:48:04 -0800 (PST) Received: from localhost ([2601:647:6300:b760:fbc3:98b5:57a2:a3b8]) by smtp.gmail.com with ESMTPSA id y27sm5003463pga.22.2022.02.03.12.48.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 03 Feb 2022 12:48:04 -0800 (PST) Date: Thu, 3 Feb 2022 12:48:03 -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: <20220203204803.b3lci3axxzxi5a4s@gmail.com> References: <20220202071044.1480421-1-maskray@google.com> <20220202183206.fhnivs3kb4ntnkmp@gmail.com> <20220203194656.ljthsfag5chdzadb@gmail.com> <5483e1b249b67e143c540362213625cf1dccaefb.camel@debian.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <5483e1b249b67e143c540362213625cf1dccaefb.camel@debian.org> X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_00, BODY_8BITS, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_INFOUSMEBIZ, 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.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 20:48:08 -0000 On 2022-02-03, Luca Boccassi wrote: >On Thu, 2022-02-03 at 11:46 -0800, Fangrui Song wrote: >> 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 value >> > > > > to be specified. Some ELF section type names are supported as >> > > > > well, >> > > > >> > > > Thanks for the patch submission.=A0 I am regression testing it at >> > > > the moment >> > > > 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 they >> > > > 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.=A0 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. >> > > >> > > > >> > > > >> > > > > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 case type_section: >> > > > > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 if (os->sectype_value->typ= e.node_class =3D=3D >> > > > > etree_name >> > > > > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 && os->sectype= _value->type.node_code =3D=3D >> > > > > NAME) >> > > > > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0{ >> > > > > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 const char *na= me =3D os->sectype_value- >> > > > > >name.name; >> > > > > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 if (strcmp (na= me, "SHT_PROGBITS") =3D=3D 0) >> > > > > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 type =3D= SHT_PROGBITS; >> > > > > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 else if (strcm= p (name, "SHT_NOTE") =3D=3D 0) >> > > > > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 type =3D= SHT_NOTE; >> > > > > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 else if (strcm= p (name, "SHT_NOBITS") =3D=3D 0) >> > > > > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 type =3D= SHT_NOBITS; >> > > > > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 else if (strcm= p (name, "SHT_INIT_ARRAY") =3D=3D >> > > > > 0) >> > > > > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 type =3D= SHT_INIT_ARRAY; >> > > > > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 else if (strcm= p (name, "SHT_FINI_ARRAY") =3D=3D >> > > > > 0) >> > > > > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 type =3D= SHT_FINI_ARRAY; >> > > > > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 else if (strcm= p (name, "SHT_PREINIT_ARRAY") >> > > > > =3D=3D 0) >> > > > > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 type =3D= SHT_PREINIT_ARRAY; >> > > > > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 else >> > > > > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 einfo (_= ("%F%P: invalid type for output >> > > > > section `%s'\n"), >> > > > > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 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 entry >> > > > 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 understand you don't like it, but as I've already explained again, >and again, and again, it is needed, and frankly I'm getting exhausted. >If you don't want to update your patch that's fine, it's no problem at >all, I'll send a follow-up myself if it gets merged. What I repeatedly requested is how you got SHF_WRITE .note.package but I never never get an example. You may understand how I got exausted after my two questions in 2021 were ignored and the recent https://sourceware.org/pipermail/binutils/2022-January/119537.html got a reply "it is used" with no detail.