From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21186 invoked by alias); 11 Oct 2014 01:42:32 -0000 Mailing-List: contact libffi-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libffi-discuss-owner@sourceware.org Received: (qmail 21147 invoked by uid 89); 11 Oct 2014 01:42:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-vc0-f173.google.com Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com) (209.85.220.173) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Sat, 11 Oct 2014 01:42:29 +0000 Received: by mail-vc0-f173.google.com with SMTP id ij19so3569346vcb.4 for ; Fri, 10 Oct 2014 18:42:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=z3SlmnDBACKQ2R0qcM1MLVYBpwNsmXcWNkglnoga1RE=; b=O30Jbal/1Ja7lTgL5s+HODw8aFfOprpYCAUXVUwd4wqUmEXRTFuLQl1ih4a7dYSs5v JfEvrOqnZee1l5I03N7wc/5HmLAVCjpPLSCiqlblFvJBRMXt/OelSCAEagRkcejh8LZw 0VdLeCWvZoDJ7leO8vM3BwE0QkednOLmEUUdkKVWfjwp1gr3AQO132Q50sew+Tus41xC jfeM0yuweNBSavFIWT2wgOMjX8DB3s9XOdefc0fLBNhjiJFWrmDG6GpcSuoxey0/ytTF qDVYTp71t/ehDjE84bYQyyq/I6/zaguadBr+eIL5Sa60JZ+oagAC8WcDgskev3YlUe/R jBjQ== X-Gm-Message-State: ALoCoQmGn3sHkY3w+AZEQPSMKY0Uq6ziT97dODgaqGrzdxHdNr52nz1eHi29SALH+mWu9LsF7FY7 MIME-Version: 1.0 X-Received: by 10.220.251.13 with SMTP id mq13mr8596798vcb.25.1412991747253; Fri, 10 Oct 2014 18:42:27 -0700 (PDT) Received: by 10.52.139.37 with HTTP; Fri, 10 Oct 2014 18:42:27 -0700 (PDT) In-Reply-To: References: <1412973773-3942-1-git-send-email-rth@redhat.com> <1412973773-3942-4-git-send-email-rth@redhat.com> Date: Sat, 11 Oct 2014 01:42:00 -0000 Message-ID: Subject: Re: [gofrontend-dev] Re: [PATCH 03/13] HACK! Allow the static chain to be set from C From: Peter Collingbourne To: Ian Lance Taylor Cc: Richard Henderson , gcc-patches , "libffi-discuss@sourceware.org" , "gofrontend-dev@googlegroups.com" Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2014/txt/msg00112.txt.bz2 On Fri, Oct 10, 2014 at 6:06 PM, Peter Collingbourne wrote: > On Fri, Oct 10, 2014 at 5:33 PM, 'Ian Lance Taylor' via gofrontend-dev > wrote: >> >> On Fri, Oct 10, 2014 at 1:42 PM, Richard Henderson wrote: >> > >> > This is awful syntax, and therefore contains no documentation. >> > But we'll need to be able to set the static chain on a few calls >> > within the Go runtime, so we need to expose this by some means. >> > >> > It currently looks like >> > >> > function(args...) __builtin_call_chain(pointer) >> > >> > because that was easy to parse. >> >> How crazy would it be to move __builtin_call_chain into the function >> arguments, as in >> function(a1, a2, __builtin_call_chain(pointer)) >> This __builtin_call_chain call would be removed from the argument list >> so type checking would only look at a1, a2. It would just set the >> static chain value. That at least puts the call_chain in the right >> place, which is a special kind of function argument. > > > Clang will need to be able to parse this syntax too, so let's not do > anything that diverges too much from the standard. > > Can we perhaps make this look like a new calling convention? So e.g. you > could do: > > (((void (__attribute__((chaincall)) *)(void *, int, int)))function)(pointer, > a1, a2); A colleague has suggested a perhaps nicer syntax: __builtin_call_chain(pointer, call) where call must be a call expression Peter