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 910B63858D37 for ; Mon, 15 Aug 2022 13:02:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 910B63858D37 Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-386-LZemcsCCOVWlqmoPWUbD_A-1; Mon, 15 Aug 2022 09:02:36 -0400 X-MC-Unique: LZemcsCCOVWlqmoPWUbD_A-1 Received: by mail-wr1-f69.google.com with SMTP id e21-20020adf9bd5000000b002207a51b7feso1185808wrc.10 for ; Mon, 15 Aug 2022 06:02:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:subject:from:references:to :content-language:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc; bh=lj6Fk+f2V47IbiluIQ5MnI7d0Db7I75gmyU2lW0fIKc=; b=ONzrfeEP5O/ALIMsS1f2bGh/zieJkDWLLgGBtkAn8nUlMremEKOEs0H6D3MRvN0RzA DZQBrstpIAsJaNvtQdhrMh/Arevfyg0rp3jbautZA2WEYokg1gn0Zz6e/7jxhn0ayprM VmCz6UTH7gDXSIP2PFbJzBUmIMMuq0G40ZVMGvrImD+Hwo3r2g3bE0zG3AWoyrzTeIJm FxJrw8nISAbQR665hjAEVdW30TrDYSaja6WNia/dJCVOHpUJ/1nhno0ABEheG5cax4j+ r7taQ+IIDKtFHg5WqWb22n+o4F+26P8vVz0xQZ0B7uPxsQKORod7BluZudcr05spi5/S UpSw== X-Gm-Message-State: ACgBeo3YzHz0jl14MTiy5g7DeMeFyyDksXBfRzCmvrWva0irgOO+EkIa NVAQose6Iz5YmpeVQS4mtW6bpl5oZJhSwfnUnqvM/d1hgITe7rnyPNPahe01SVizlw8F9u5VwgB xDkD/uC/T1NkdSfCd9Q== X-Received: by 2002:a05:600c:4f4f:b0:3a5:a530:4fd7 with SMTP id m15-20020a05600c4f4f00b003a5a5304fd7mr16659831wmq.36.1660568554674; Mon, 15 Aug 2022 06:02:34 -0700 (PDT) X-Google-Smtp-Source: AA6agR4RmswiieS6DtbaqwjXALWshaCUz387fZavCkvuFQL2hxO7Uss0PM30aAUyjoCpEbwzjqF9EQ== X-Received: by 2002:a05:600c:4f4f:b0:3a5:a530:4fd7 with SMTP id m15-20020a05600c4f4f00b003a5a5304fd7mr16659816wmq.36.1660568554458; Mon, 15 Aug 2022 06:02:34 -0700 (PDT) Received: from [192.168.1.6] (adsl-2-solo-236-177.claranet.co.uk. [80.168.236.177]) by smtp.gmail.com with ESMTPSA id q4-20020a05600000c400b0021e8d205705sm7389906wrx.51.2022.08.15.06.02.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 15 Aug 2022 06:02:33 -0700 (PDT) Message-ID: <9ae415ef-997a-ac14-4bbf-1d0413b9d6a1@redhat.com> Date: Mon, 15 Aug 2022 14:02:33 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 To: Indu Bhagat , binutils@sourceware.org References: <20220802080452.1143351-1-indu.bhagat@oracle.com> <20220802080452.1143351-7-indu.bhagat@oracle.com> From: Nick Clifton Subject: Re: [PATCH,V6 06/10] bfd: linker: merge .ctf_frame sections In-Reply-To: <20220802080452.1143351-7-indu.bhagat@oracle.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=-3.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, 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 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: Mon, 15 Aug 2022 13:02:39 -0000 Hi Indu, > +ctf_frame_decoder_mark_func_deleted (struct ctf_frame_dec_info *cfd_info, > + unsigned int func_idx) > +{ > + BFD_ASSERT (func_idx < cfd_info->cfd_fde_count); > + cfd_info->cfd_func_bfdinfo[func_idx].func_deleted_p = true; Just for the record, I am not a fan of assertions inside library functions. I believe that libraries should let their users decide what to do when there is a problem, rather than unilaterally calling abort. (The better approach in my opinion is to return an informative error message to the caller). That said there are plenty of other places in the BFD library where assertions are used, so I am not going to complain about this. I just wanted to make sure that you knew of my feelings on this issue. > +/* Try to parse .ctf_frame section SEC, which belongs to ABFD. Store the > + information in the section's sec_info field on success. COOKIE > + describes the relocations in SEC. */ > + > +void > +_bfd_elf_parse_ctf_frame (bfd *abfd, struct bfd_link_info *info, > + asection *sec, struct elf_reloc_cookie *cookie) It seems to me that this function really ought to return a bool, indicating success or failure. > + /* Read the ctf frame unwind information from abfd. */ > + if (!bfd_malloc_and_get_section (abfd, sec, &ctfbuf)) > + goto fail_no_free; The name of this label seems rather ironic, given that ... > +fail_no_free: > + _bfd_error_handler > + (_("error in %pB(%pA); no .ctf_frame will be created"), > + abfd, sec); > +success: > + free (ctfbuf); ... it falls through into the free(). Cheers Nick