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 [63.128.21.124]) by sourceware.org (Postfix) with ESMTP id 11906382E80E for ; Wed, 27 Jan 2021 22:15:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 11906382E80E Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-90-KGONjEKkP7qJ_5CbKoHg1g-1; Wed, 27 Jan 2021 17:15:53 -0500 X-MC-Unique: KGONjEKkP7qJ_5CbKoHg1g-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id EF064180A092; Wed, 27 Jan 2021 22:15:51 +0000 (UTC) Received: from greed.delorie.com (ovpn-114-77.rdu2.redhat.com [10.10.114.77]) by smtp.corp.redhat.com (Postfix) with ESMTPS id BEBF45D6A1; Wed, 27 Jan 2021 22:15:51 +0000 (UTC) Received: from greed.delorie.com.redhat.com (localhost [127.0.0.1]) by greed.delorie.com (8.14.7/8.14.7) with ESMTP id 10RMFouc020562; Wed, 27 Jan 2021 17:15:50 -0500 From: DJ Delorie To: "Madhavan T. Venkataraman" Cc: libffi-discuss@sourceware.org Subject: Re: [RFC PATCH v3 1/5] Libffi Static Trampolines In-Reply-To: <8b4d70a2-42a1-43a0-6a60-25576591f4e2@linux.microsoft.com> (madvenka@linux.microsoft.com) Date: Wed, 27 Jan 2021 17:15:50 -0500 Message-ID: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-7.0 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_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libffi-discuss@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libffi-discuss mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2021 22:15:57 -0000 "Madhavan T. Venkataraman" writes: >>> +case "$target" in >>> + *-linux*) >>> + AC_DEFINE(FFI_EXEC_STATIC_TRAMP, 1, >>> + [Define this if you want statically defined trampolines]) >>> + ;; >>> +esac >> >> Ok. Might want to conditional for the arches that are supported too. >> > > ok. I will add the arches although the code currently handles that by testing > ffi_tramp_arch == NULL. /me ponders... Is the intent here that a Linux client has to check for static trampolines in configure (i.e. it's on linux) but *also* check if it's supported at runtime? If we could minimize the number of checks, that would help the developer. If the API is always present (or always hidden, so that the client need do nothing), that's best. Ideally, the client would need do nothing regardless, but that only works if the static trampoline functionality is 100% hidden. > My intention is to allow applications and libraries that currently use dynamic code > to use the libffi API to eliminate their dynamic code. The maintainers of these > apps/libs would rewrite their dynamic code into static code. All they need is a > way to pass data to their static code (that uses PC-relative access). The libffi > API will let them do that. Ok, as long as there's a use case. Note that adding public APIs is MUCH easier than removing them later... > My intention is to always have the API functions defined in the library. If > FFI_EXEC_STATIC_TRAMP is defined, then, the API will supply static trampolines. > Else, the stub API functions will return an error and the caller can fall back > on his existing method if any. Ok. I guess that answers one of my earlier questions (above) ;-) >>> @@ -943,12 +966,17 @@ void * >>> ffi_data_to_code_pointer (void *data) >>> { >>> msegmentptr seg = segment_holding (gm, data); >>> + >> >> Extraneous but ok. > > This is needed. I meant the extra blank line ;-) >>> + if (table->nfree == gtramp.ntramp && gtramp.ntables > 1) >> >> You can't compare these. The first is a count of *trampolines* and the >> second is a count of *tables*. >> > > There are two conditions here: > > If (table->nfree == gtramp.ntramp) is true, then all of the table's slots are free. This reads as "If the number of trampolines equals the number of tables" which are not comparable. If you're doing some math magic hack here to get the right answer, it *really* needs a big comment explaining how it works. >> tramp_table_del unlinks the table, but doesn't deallocate its >> resources. Are these resources lost/leaked? >> > > The table list contains tables that have free slots. If all slots of a table > are allocated, the table is removed from the list. Its trampoline resources > are held inside closures. When those closures are freed, the table will be back > on the list. When the table gets back all of its trampolines, it will be freed > along with all of its trampolines. Ah, ok.