From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 97488 invoked by alias); 18 Oct 2019 09:15:47 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 97307 invoked by uid 89); 18 Oct 2019 09:15:37 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=Strictly X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 18 Oct 2019 09:15:25 +0000 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E22E22B8F; Fri, 18 Oct 2019 09:15:23 +0000 (UTC) Received: from oldenburg2.str.redhat.com (dhcp-192-200.str.redhat.com [10.33.192.200]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4B41260BF1; Fri, 18 Oct 2019 09:15:23 +0000 (UTC) From: Florian Weimer To: Josef Wolf Cc: gcc-help@gcc.gnu.org Subject: Re: Propagating addresses from linker to the runtie References: <20191016131759.GA11171@raven.inka.de> <5b75d9aa-9f33-2ec6-ff46-713b113b3539@gmail.com> <20191017113157.GC11171@raven.inka.de> <20191018090705.GF11171@raven.inka.de> Date: Fri, 18 Oct 2019 09:15:00 -0000 In-Reply-To: <20191018090705.GF11171@raven.inka.de> (Josef Wolf's message of "Fri, 18 Oct 2019 11:07:05 +0200") Message-ID: <87d0euv2hh.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2019-10/txt/msg00074.txt.bz2 * Josef Wolf: > Strictly speaking, the symbols defined by the linker (_sidata, _sdata, _edata, > _sbss and _ebss) are unrelated when seen from the perspective of the > compiler. Therefore, it is not allowed by the standard to use their addresses > for comparison. > > So what would be the proper way to pass this information from the linker to the > compiler? In glibc, we use this: /* Perform vtable pointer validation. If validation fails, terminate the process. */ static inline const struct _IO_jump_t * IO_validate_vtable (const struct _IO_jump_t *vtable) { /* Fast path: The vtable pointer is within the __libc_IO_vtables section. */ uintptr_t section_length = __stop___libc_IO_vtables - __start___libc_IO_vtables; uintptr_t ptr = (uintptr_t) vtable; uintptr_t offset = ptr - (uintptr_t) __start___libc_IO_vtables; if (__glibc_unlikely (offset >= section_length)) /* The vtable pointer is not in the expected section. Use the slow path, which will terminate the process if necessary. */ _IO_vtable_check (); return vtable; } I do not know how effective this is. In C++, you can use std::less, which was enhanced to cover your use case. Thanks, Florian