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.129.124]) by sourceware.org (Postfix) with ESMTPS id 422883858D39 for ; Fri, 26 Nov 2021 16:17:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 422883858D39 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-441-mq2YrU0WOWmgcwszY4F-0A-1; Fri, 26 Nov 2021 11:17:23 -0500 X-MC-Unique: mq2YrU0WOWmgcwszY4F-0A-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id CF0D51023F4E; Fri, 26 Nov 2021 16:17:22 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.29]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7363B1001F50; Fri, 26 Nov 2021 16:17:21 +0000 (UTC) From: Florian Weimer To: Jakub Jelinek Cc: libc-alpha@sourceware.org, Adhemerval Zanella , gcc-patches@gcc.gnu.org Subject: Re: [PATCH v2] elf: Add _dl_find_object function References: <87wnkwj7nh.fsf@oldenburg.str.redhat.com> <20211126154611.GI2646553@tucnak> Date: Fri, 26 Nov 2021 17:17:19 +0100 In-Reply-To: <20211126154611.GI2646553@tucnak> (Jakub Jelinek's message of "Fri, 26 Nov 2021 16:46:11 +0100") Message-ID: <87pmqmj3hs.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=unavailable autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Nov 2021 16:17:28 -0000 * Jakub Jelinek: > On Thu, Nov 25, 2021 at 09:35:14PM +0100, Florian Weimer wrote: >> +struct dl_find_object >> +{ >> + unsigned long long int dlfo_flags; /* Currently 0. */ >> + void *dlfo_map_start; /* Beginning of mapping containing address. */ >> + void *dlfo_map_end; /* End of mapping. */ >> + struct link_map *dlfo_link_map; >> + void *dlfo_eh_frame; /* Exception handling data of the object. */ >> +# if DLFO_STRUCT_HAS_EH_DBASE >> + void *dlfo_eh_dbase; /* Base address for DW_EH_PE_datarel. */ >> +# endif >> +# if DLFO_STRUCT_HAS_EH_COUNT >> + int dlfo_eh_count; /* Number of exception handling entries. */ >> +# endif >> +}; > > I must say I still don't really like these conditionally included > fields, if in the future one needs some of them on some other architecture, > we'd need to add another API or symbol version it etc. That suggests to me that I should add a few __dwlfo_unused members. And if the fields are actually used, a future version would set a flag (in case a zero value for the field has meaning). We don't even have to initialize these members today. (Although I do not see much need for members like dbase: we are copying a value that the link editor has computed. It could have easily written that to the EH segment, too.) Thanks, Florian