From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-f50.google.com (mail-ej1-f50.google.com [209.85.218.50]) by sourceware.org (Postfix) with ESMTPS id 0BFFC3858D1E for ; Wed, 2 Feb 2022 11:46:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0BFFC3858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=debian.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ej1-f50.google.com with SMTP id j2so63851776ejk.6 for ; Wed, 02 Feb 2022 03:46:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version; bh=lKSvxAhnwNyh2/Yc9Ieyre60gYmyi4UfknfYchVyyaQ=; b=E/W+8nor9YukBm4mohfbJJjScZhnjO5GcPKBXgP9OyIzuq/PfMJVFVwwB2M2/g5iNw vT77nPnpOzJfwBkXMl0G1WnxHF+uaR/YXlakH0gMo0TNXZMbyzg57mA5hysSUljB88Gb PrbCxQXA0e7EBhROqdgoRjlWEPW7W1GFcRX4SKhE8f/UUEmJ+XetbLH+iUoRNRGTC/lL 3HUejHXGE//pe9FOxtjkCQ6oWVso+RWEKsNpcCpdYWKLoYh9HIG9rE0chCZkAbsJa53K UIf+1amSST1lLXxso7AXiBFZl5BhZsepCw3sXSTwR81sZDKJothGMhrR2GklmS3hCigP JSoQ== X-Gm-Message-State: AOAM5310CkaCOtL06lQ2CvPUnEkOMTw0IZRFgSWCXML18bKTKLXDd6uI tUHwu5iQvtH3yVG02h+l+Lo= X-Google-Smtp-Source: ABdhPJz5LP6D/Y3Y41QSd51cMUeY8xu+qOzs1TN4s8VEF4Z4AH2kwOpn5r9Jp4gSFwAo2dFh+B/Bbw== X-Received: by 2002:a17:906:5d0f:: with SMTP id g15mr25278200ejt.751.1643802374810; Wed, 02 Feb 2022 03:46:14 -0800 (PST) Received: from localhost ([137.220.125.106]) by smtp.gmail.com with ESMTPSA id co19sm20931782edb.7.2022.02.02.03.46.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Feb 2022 03:46:14 -0800 (PST) Message-ID: Subject: Re: [PATCH] ld: Support customized output section type From: Luca Boccassi To: Nick Clifton , Fangrui Song , binutils@sourceware.org, Alan Modra Date: Wed, 02 Feb 2022 11:46:12 +0000 In-Reply-To: References: <20220202071044.1480421-1-maskray@google.com> Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-fLgpgpU2hu88Xe9INAME" User-Agent: Evolution 3.38.3-1+plugin MIME-Version: 1.0 X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, 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: Wed, 02 Feb 2022 11:46:17 -0000 --=-fLgpgpU2hu88Xe9INAME Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2022-02-02 at 11:36 +0000, Nick Clifton wrote: > Hi Fangrui, >=20 > > The current output section type allows to set the ELF section type to > > SHT_PROGBITS or SHT_NOLOAD. This patch allows an arbitrary section valu= e > > to be specified. Some ELF section type names are supported as well, >=20 > Thanks for the patch submission. I am regression testing it at the momen= t > but in the meantime a couple of things stood out for me: >=20 >=20 > > +@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}. >=20 > Rather than having users guess, it would probably be best to list which > type names are supported. >=20 > 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_GRO= UP) > but then they do not also arrange for whatever necessary support that fea= ture > needs. Something like: "it is the user's responsibility to ensure that > any special requirements of the section type are met". >=20 >=20 >=20 > > + 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); >=20 > It might be worth adding SHT_STRTAB to this list, as I can imagine some > weird sceanario where someone would want it. >=20 >=20 > Also - given that this is a new feature, there really ought to be an entr= y > for it in the ld/NEWS file. Hi, Does this patch allow specifying both this new attribute and the READONLY attribute? It is required for our use case, and cannot be used otherwise. --=20 Kind regards, Luca Boccassi --=-fLgpgpU2hu88Xe9INAME Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEErCSqx93EIPGOymuRKGv37813JB4FAmH6bwQACgkQKGv37813 JB5qmQ/9HdlEfDflcBZGkRcUCvOLfdoIxqkA/r1TQTw7BaMEA3WDDij76v4kbB4S gE78/WUvY54b28y3lUmKaaMPcwOjpafO9orE2yISfa/4+F1f3OFDxtaSa5QjzVhI +Z0YEzsjEyHdHIZBwd6qpl/Kp4yqIsouO5msf3iqYaaP50SmO+1qtAyywiN9IYnC 8RJ3JSSldwQspmZrg8C8jWTORBjsgbGewnsQOpv6h2oCtOsXKntLVN5xUpTEjxVq tsfneI22OD86T2CU2aHWnTb1DcKMQ6kbfZoh+JO1TYAwYm7EuEIi1iqHsnMvQL/Y uMs0DB6LtfZq+ubENzmu05e4al/1BDov/pLtOanLPNW6p+XiL+m/kYUjtZOnvVRO G4XpJDM05JhyTfCnovWXVsD/CuqLjV54BxcDAGk2lkXn7zEqspZHBH7Hl04ZO5eK KI8jrFgK+o5EkAi4C0qJG+Qe6NzBZtBKFdiyWVlHCeys/Fqg4+HrkmQQPDMVRYtk 6555plU0qIk5amyrqlvtEO2e3+yNmbt2pctp/uyeB/RMOAH0gh0iVyYmZprvbVzS AkyorM8xol/LGv6/6CnQ3OMiL3lxEf+G6F0xx+mDePC785MfqFM7MsD8oy87WbY1 3lbxV/7xgfhAIaOSlGCKz4sFqYQQhJ0mAKZwgymQIXTumjEaoYg= =kK6p -----END PGP SIGNATURE----- --=-fLgpgpU2hu88Xe9INAME--