From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28040 invoked by alias); 4 Oct 2011 03:26:43 -0000 Received: (qmail 28030 invoked by uid 22791); 4 Oct 2011 03:26:41 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,TW_JL X-Spam-Check-By: sourceware.org Received: from mail-ww0-f51.google.com (HELO mail-ww0-f51.google.com) (74.125.82.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 04 Oct 2011 03:26:27 +0000 Received: by wwf10 with SMTP id 10so70250wwf.8 for ; Mon, 03 Oct 2011 20:26:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.131.29 with SMTP id l29mr4472537wei.45.1317698785876; Mon, 03 Oct 2011 20:26:25 -0700 (PDT) Received: by 10.216.168.10 with HTTP; Mon, 3 Oct 2011 20:26:25 -0700 (PDT) In-Reply-To: <201110032046.49204.vapier@gentoo.org> References: <201110031903.43037.vapier@gentoo.org> <201110032046.49204.vapier@gentoo.org> Date: Tue, 04 Oct 2011 03:26:00 -0000 Message-ID: Subject: Re: new triplet for x32 psABI? From: Michael LIAO To: Mike Frysinger Cc: autoconf@gnu.org, gcc@gcc.gnu.org, x32-abi@googlegroups.com, config-patches@gnu.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2011-10/txt/msg00034.txt.bz2 On Mon, Oct 3, 2011 at 5:46 PM, Mike Frysinger wrote: > On Monday, October 03, 2011 19:47:57 Michael LIAO wrote: >> On Mon, Oct 3, 2011 at 4:03 PM, Mike Frysinger wrote: >> > On Monday, October 03, 2011 18:57:28 Michael LIAO wrote: >> >> Most examples would be related to tools generating code. >> >> >> >> Suppose you have a software package with several hard-coded fully >> >> optimized assembly file for different targets. Your build system need >> >> to know the current target as well as target ABI to select the correct >> >> assembly file to build it. It even desirable if it includes a simple >> >> script to help generate assembly code (like the one in OpenSSL), you'd >> >> better know the target ABI to prepare proper glue code without >> >> breaking ABI. >> > >> > hjlu posted examples to the x32 site as to handle this. =C2=A0the only >> > difference between x86_64 and x32 is the size of the pointers. >> >> Besides the pointer size, there are other differences like indirect >> branch which need different code sequence on x32 and x64. Indirect >> branch would be used in assembly code (yeah, concrete example would >> valuable here but indirect branch should be used potentially and >> possibly in assembly code.) If the assembly code use indirect branch, >> it needs to know the target ABI and generate/use difference code path. > > in terms of asm code, it's still possible to use ifdef's to handle cases = where > you truly need different code paths. Yeah, we could have '#ifdef X32ABI" in assembly file to select different path. But, how to generate that macro, says X32ABI, based on autoconf to detect/select target (not only target architecture but also target ABI.). A new triplet in general is needed to simplify that instead of compiler/linker options only or inventing itself by each software package itself. The reason for a new triplet is to get such information little canonical, in somewhat. > > in terms of a tool that generates code itself (like gcc), i'm not sure a > different tuple would make it any easier. =C2=A0gcc itself simply adds an= abi > configure flag to control what it supports since the backend shares a lot= more > code than is unique to each abi. not all tools like gcc has the chance to specify different ABI through compiler option. it's especially true for simple tool to generate code, maybe just at compile time. They may need something directly to tell which ABI will be used. > > we have precedence here where multiple abi's work with a single tuple, an= d it > hasn't been a significant hindrance for them. =C2=A0adding a new tuple is= also not > something to be done lightly ... a lot of code out there parses tuples, a= nd > they would need updating. yeah, I totally agree. At first stage, people may still need explicit specify compiler/linker options '-mx32' to build a non-x32-aware package with x32 ABI for correctness. But, for package requires to be x32-aware, it could check triplet. > > not that i'm the one to convince here, it's just that you need real data = to > back up proposals that shows pros/cons and why your suggestion ultimately= has > more pros than cons ;). yeah, that's why mailing list is always CCed, :) > -mike >