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.133.124]) by sourceware.org (Postfix) with ESMTPS id 9F38F3851C01 for ; Wed, 2 Feb 2022 11:36:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9F38F3851C01 Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-618-hOBInR3hOZaKJ1G-tJI6rA-1; Wed, 02 Feb 2022 06:36:33 -0500 X-MC-Unique: hOBInR3hOZaKJ1G-tJI6rA-1 Received: by mail-wm1-f69.google.com with SMTP id 7-20020a1c1907000000b003471d9bbe8dso1303154wmz.0 for ; Wed, 02 Feb 2022 03:36:33 -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:date:mime-version:user-agent :content-language:to:cc:references:from:subject:in-reply-to :content-transfer-encoding; bh=o2+DCtZkDvsLviqdhpJCRUk4uUyBKj2KOL6O7MYnioE=; b=JGhWdGF99ZaoFsiA0AcY2MhROsEAPgIMkOj2ro9hQqVYdQ8B+2VRi1u9JhNxY5u/2j hC4fbWsvdjWM5Ofjo6kQGtFuPNfhoNIzdnoUrdtMd6R/gghHHyECDQut5cBOtI730nGU Hx9DMu+lWP/5ATPLiMpekspLPWDq0Vkc/DrEdOd7KyKa1CdD/62i2c+YDMkMH0+LpzpY CUHQurGNQL5aS6xll7W2ytxAmI7KImROylLUB11J+dYdmpUM8HuK3pOH+9g6iFv9Micx KyFsIim9aKRETyvOq78tFWh9Xw5amdUtrtBj3gZHDGPP11BamwzsUd6/ETc8OFwlbmFu 04QQ== X-Gm-Message-State: AOAM530igAIGExwlmpLEvSlcXb/VW2xGj38ijjexyduQCT7Kd3LkfJr1 48XTA/TaYDq7RE1GU8sUYTAYjpA3UkX/pNoLGBw9BRVACgdQkV5s1lBYE7JzAc2FW++BlkD8Vb4 oANrvx9Do+vl/Y10l6Q== X-Received: by 2002:adf:e54e:: with SMTP id z14mr25391819wrm.490.1643801792091; Wed, 02 Feb 2022 03:36:32 -0800 (PST) X-Google-Smtp-Source: ABdhPJwSr5IwK/suz91jGkMk+K4hQqCos+EBU/kvH86dae5jM3ffoV81Rxv9ufn4WCYQyO2VxhInug== X-Received: by 2002:adf:e54e:: with SMTP id z14mr25391809wrm.490.1643801791933; Wed, 02 Feb 2022 03:36:31 -0800 (PST) Received: from [192.168.1.6] (adsl-164-239.freeuk.com. [80.168.164.239]) by smtp.gmail.com with ESMTPSA id m5sm16421623wrs.22.2022.02.02.03.36.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Feb 2022 03:36:31 -0800 (PST) Message-ID: Date: Wed, 2 Feb 2022 11:36:30 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 To: Fangrui Song , binutils@sourceware.org, Alan Modra Cc: Luca Boccassi References: <20220202071044.1480421-1-maskray@google.com> From: Nick Clifton Subject: Re: [PATCH] ld: Support customized output section type In-Reply-To: <20220202071044.1480421-1-maskray@google.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-GB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, 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:36:36 -0000 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. I am regression testing it at the moment but in the meantime a couple of things stood out for me: > +@item TYPE = @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. Something like: "it is the user's responsibility to ensure that any special requirements of the section type are met". > + case type_section: > + if (os->sectype_value->type.node_class == etree_name > + && os->sectype_value->type.node_code == NAME) > + { > + const char *name = os->sectype_value->name.name; > + if (strcmp (name, "SHT_PROGBITS") == 0) > + type = SHT_PROGBITS; > + else if (strcmp (name, "SHT_NOTE") == 0) > + type = SHT_NOTE; > + else if (strcmp (name, "SHT_NOBITS") == 0) > + type = SHT_NOBITS; > + else if (strcmp (name, "SHT_INIT_ARRAY") == 0) > + type = SHT_INIT_ARRAY; > + else if (strcmp (name, "SHT_FINI_ARRAY") == 0) > + type = SHT_FINI_ARRAY; > + else if (strcmp (name, "SHT_PREINIT_ARRAY") == 0) > + type = 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. Also - given that this is a new feature, there really ought to be an entry for it in the ld/NEWS file. Cheers Nick