public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Uros Bizjak <ubizjak@gmail.com>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: gcc-patches@gcc.gnu.org,
	"Joseph S. Myers" <joseph@codesourcery.com>,
		Paolo Bonzini <bonzini@gnu.org>
Subject: Re: PATCH [1/n] X32: Add initial -x32 support
Date: Tue, 05 Jul 2011 18:18:00 -0000	[thread overview]
Message-ID: <CAFULd4apUvbT4h6iT=+CincfiyWoKZ28=CngUyr9m0Py5+ooAQ@mail.gmail.com> (raw)
In-Reply-To: <CAMe9rOoOUrV7rHb1nADYafkcHrK9v3DR3cjGUfOT0Aej6C3=3g@mail.gmail.com>

On Tue, Jul 5, 2011 at 7:54 PM, H.J. Lu <hjl.tools@gmail.com> wrote:

>>> I'd like to start submitting a series of patches to enable x32:
>>>
>>> https://sites.google.com/site/x32abi/
>>>
>>> The GCC x32 branch is very stable. There are no unexpected failures in
>>> C, C++, Fortran and Objective C testsuites.  SPEC CPU 2K/2006 compile
>>> and run correctly at -O2 and -O3.
>>>
>>> More than 90% of changes are in x86 backend.  I have submitted non-x86
>>> backend patches.  Most of them have been reviewed and checked in.  Only
>>> 4 patches are pending for review/approval.
>>>
>>> This is the first x86 backend patch to support x32.  By default, x32 is
>>> disabled and x32 run-time support isn't required.  OK for trunk?
>>
>> Please strip out --enable-ia32 stuff, it complicates things ATM.  I
>> assume that --enable-x32 applies only to 64bit targets, so this part


I think that better name of the file would be "t-linux64-x32".

@@ -2631,6 +2640,7 @@ esac
 case ${target} in
 i[34567]86-*-linux* | x86_64-*-linux*)
 	tmake_file="${tmake_file} i386/t-pmm_malloc i386/t-i386"
+	libgcc_tm_file="${libgcc_tm_file} i386/value-unwind.h"

Not yet.

@@ -58,25 +58,31 @@ see the files COPYING3 and COPYING.RUNTIME
respectively.  If not, see

 #if TARGET_64BIT_DEFAULT
 #define SPEC_32 "m32"
-#define SPEC_64 "!m32"
+#define SPEC_64 "m32|mx32:;"
+#define SPEC_X32 "mx32"
 #else
-#define SPEC_32 "!m64"
+#define SPEC_32 "m64|mx32:;"
 #define SPEC_64 "m64"
+#define SPEC_X32 "mx32"
 #endif

I really think that "!(m64|mx32)" is more descriptive and clear...

 #undef	LINK_SPEC
 #define LINK_SPEC "%{" SPEC_64 ":-m " GNU_USER_LINK_EMULATION64 "} \
                    %{" SPEC_32 ":-m " GNU_USER_LINK_EMULATION32 "} \
+                   %{" SPEC_X32 ":-m " GNU_USER_LINK_EMULATIONX32 "} \
   %{shared:-shared} \
   %{!shared: \
     %{!static: \
       %{rdynamic:-export-dynamic} \
       %{" SPEC_32 ":-dynamic-linker " GNU_USER_DYNAMIC_LINKER32 "} \
-      %{" SPEC_64 ":-dynamic-linker " GNU_USER_DYNAMIC_LINKER64 "}} \
+      %{" SPEC_64 ":-dynamic-linker " GNU_USER_DYNAMIC_LINKER64 "} \
+      %{" SPEC_X32 ":-dynamic-linker " GNU_USER_DYNAMIC_LINKERX32 "}} \
     %{static:-static}}"

On the border of bikesheding, GNU_USER_LINK_EMULATION64_X32 and
GNU_USER_DYNAMIC_LINKER64_X32 sounds better to me.

Same with the below:

+#define GLIBC_DYNAMIC_LINKERX32 "/libx32/ld-linux-x32.so.2"
+#define UCLIBC_DYNAMIC_LINKERX32 "/lib/ldx32-uClibc.so.0"
+#define BIONIC_DYNAMIC_LINKERX32 "/system/bin/linkerx32"

+++ b/gcc/config/i386/t-linux-x32

Please rename above file to t-linux64-x32.

With above small changes, the patch looks OK to me. Please also wait
for build and options maintainer (CC'd) approvals.

Thanks,
Uros.

  reply	other threads:[~2011-07-05 18:14 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-05 19:55 PATCH [1/n]: " H.J. Lu
2011-06-06 15:47 ` Uros Bizjak
2011-06-07 15:47 ` Joseph S. Myers
2011-06-07 18:54   ` H.J. Lu
2011-06-07 19:19     ` Joseph S. Myers
2011-06-07 15:59 ` Joseph S. Myers
2011-06-07 19:11   ` H.J. Lu
2011-06-07 19:20     ` Joseph S. Myers
2011-06-07 22:02       ` H.J. Lu
2011-06-14 17:52 ` H.J. Lu
2011-07-05 14:42 ` PATCH [1/n] X32: " H.J. Lu
2011-07-05 15:21   ` Uros Bizjak
2011-07-05 17:59     ` H.J. Lu
2011-07-05 18:18       ` Uros Bizjak [this message]
2011-07-05 19:09         ` H.J. Lu
2011-07-05 19:09           ` Joseph S. Myers
2011-07-05 20:07           ` Uros Bizjak
2011-07-06 14:50           ` H.J. Lu
2011-07-06 15:03             ` Richard Guenther
2011-07-06 16:40               ` H.J. Lu
2011-07-07 13:03                 ` H.J. Lu
2011-07-07 13:08                   ` Uros Bizjak
2011-07-07 13:27                 ` Paolo Bonzini
2011-07-07 15:10                   ` H.J. Lu
2011-07-07 15:14                     ` Uros Bizjak
2011-07-07 15:38                       ` Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAFULd4apUvbT4h6iT=+CincfiyWoKZ28=CngUyr9m0Py5+ooAQ@mail.gmail.com' \
    --to=ubizjak@gmail.com \
    --cc=bonzini@gnu.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hjl.tools@gmail.com \
    --cc=joseph@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).