From patchwork Thu Oct 22 20:25:24 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Henderson X-Patchwork-Id: 534569 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 5D832141311 for ; Fri, 23 Oct 2015 07:25:36 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=ZjYMIJe3; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :subject:to:references:cc:from:message-id:date:mime-version :in-reply-to:content-type; q=dns; s=default; b=DzDYIee92+iSxoB2u uJaaPtpZbyFeqr8oIkO5ntEzO4m1b1mi7OfnE8uw7in0z7BdnavbO1Q9Jnjju+Q4 VW7mym8fUCGA9eP0wS3VsaTIsWGALvfZ1VnAmw2I5EZQxySRy6by50W2K7SmIfq1 6FQqARTIt37AQyCpyRm+1WU914= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :subject:to:references:cc:from:message-id:date:mime-version :in-reply-to:content-type; s=default; bh=/oo4Hutm5UNTKp739J0B3Q1 fN+g=; b=ZjYMIJe3vhXhPnefq0ojqoYTTNTEIkK3lCFWRScMHOruieMTVo9bn5i UVKZf4m539wV4iNaqFxEwsRUpfJzvXj3eIXiMvT8zmswNn8VoEXZDAYjWDg8bjvE nBBnywl7eGEV7zMtLxFrVEiGAQOqCD1J445r8SEnQdovAbSnf2sw= Received: (qmail 78926 invoked by alias); 22 Oct 2015 20:25:29 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 78913 invoked by uid 89); 22 Oct 2015 20:25:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD, SPF_HELO_PASS autolearn=ham version=3.3.2 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 22 Oct 2015 20:25:28 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 9F1B78E678; Thu, 22 Oct 2015 20:25:26 +0000 (UTC) Received: from bigtime.twiddle.net (ovpn-113-171.phx2.redhat.com [10.3.113.171]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t9MKPPiT005185; Thu, 22 Oct 2015 16:25:25 -0400 Subject: Re: [PATCH v2 12/13] Document the x86 address spaces To: Sandra Loosemore References: <1445376433-14658-1-git-send-email-rth@redhat.com> <1445376433-14658-13-git-send-email-rth@redhat.com> <56285741.4070303@codesourcery.com> Cc: gcc-patches@gcc.gnu.org, richard.guenther@gmail.com From: Richard Henderson Message-ID: <56294634.1060205@redhat.com> Date: Thu, 22 Oct 2015 10:25:24 -1000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56285741.4070303@codesourcery.com> X-IsSubscribed: yes I believe I've addressed all of your comments like so. r~ diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi index e54fe67..5793868 100644 --- a/gcc/doc/extend.texi +++ b/gcc/doc/extend.texi @@ -1240,8 +1240,8 @@ As an extension, GNU C supports named address spaces as defined in the N1275 draft of ISO/IEC DTR 18037. Support for named address spaces in GCC will evolve as the draft technical report changes. Calling conventions for any target might also change. At -present, only the AVR, SPU, M32C, and RL78 targets support address -spaces other than the generic address space. +present, only the AVR, SPU, M32C, RL78, and i386/x86_64 targets support +address spaces other than the generic address space. Address space identifiers may be used exactly like any other C type qualifier (e.g., @code{const} or @code{volatile}). See the N1275 @@ -1430,6 +1430,49 @@ It may use runtime library support, or generate special machine instructions to access that address space. +@subsection x86 Named Address Spaces +@cindex x86 named address spaces + +On the x86 target, variables may be declared as being relative +to the @code{%fs} or @code{%gs} segments. + +@table @code +@item __seg_fs +@itemx __seg_gs +@cindex @code{__seg_fs} x86 named address space +@cindex @code{__seg_gs} x86 named address space +The object is accessed with the respective segment override prefix. + +The respective segment base must be set via some method specific to +the operating system. Rather than require an expensive system call +to retrieve the segment base, these address spaces are not considered +to be subspaces of the generic (flat) address space. This means that +explicit casts are required to convert pointers between these address +spaces and the generic address space. In practice the application +should cast to @code{uintptr_t} and apply the segment base offset +that it installed previously. + +The preprocessor symbols @code{__SEG_FS} and @code{__SEG_GS} are +defined when these address spaces are supported. + +@item __seg_tls +@cindex @code{__seg_tls} x86 named address space +Some operating systems define either the @code{%fs} or @code{%gs} +segment as the thread-local storage base for each thread. Objects +within this address space are accessed with the appropriate +segment override prefix. + +The pointer located at address 0 within the segment contains the +offset of the segment within the generic address space. Thus this +address space is considered a subspace of the generic address space, +and the known segment offset is applied when converting addresses +to and from the generic address space. + +The preprocessor symbol @code{__SEG_TLS} is defined when this +address space is supported. + +@end table + @node Zero Length @section Arrays of Length Zero @cindex arrays of length zero