* new triplet for x32 psABI? @ 2011-10-03 22:26 Michael LIAO 2011-10-03 22:30 ` Eric Blake 2011-10-03 22:35 ` Mike Frysinger 0 siblings, 2 replies; 19+ messages in thread From: Michael LIAO @ 2011-10-03 22:26 UTC (permalink / raw) To: autoconf, gcc, x32-abi Sorry, resend with plain text format. Hi, Everyone As x32 psABI (https://sites.google.com/site/x32abi/) is invented, do we need a new triplet for system relies on triplet to figure out it's targeted on x32 environment. The new triplet would look like 'x86_64-unknown-linux-gnux32' for x32 vs 'x86_64-unknown-linux-gnu' for regular 64-bit. This's similar to EABI added to ARM or PowerPC, where 'arm-unknown-linux-gnueabi' vs. 'arm-unknown-linux-gnu'. The new triple doesn't introduce a new target (still x86_64) but just a new environment 'gnux32' to specify x32 ABI is used for code generation. The current scheme documented on website (https://sites.google.com/site/x32abi/) uses the existing triplet but specify x32 ABI through compiler/linker options. It works for most compilers aware of that, but how other tools not handling compiler/linker options knows the current build is targeted on a different environment? Any comments or alternative suggestion? Yours - Michael ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: new triplet for x32 psABI? 2011-10-03 22:26 new triplet for x32 psABI? Michael LIAO @ 2011-10-03 22:30 ` Eric Blake 2011-10-03 22:35 ` Mike Frysinger 1 sibling, 0 replies; 19+ messages in thread From: Eric Blake @ 2011-10-03 22:30 UTC (permalink / raw) To: Michael LIAO; +Cc: autoconf, gcc, x32-abi, config-patches On 10/03/2011 04:25 PM, Michael LIAO wrote: > Sorry, resend with plain text format. > > Hi, Everyone > > As x32 psABI (https://sites.google.com/site/x32abi/) is invented, do > we need a new triplet for system relies on triplet to figure out it's > targeted on x32 environment. The new triplet would look like > 'x86_64-unknown-linux-gnux32' for x32 vs 'x86_64-unknown-linux-gnu' > for regular 64-bit. This's similar to EABI added to ARM or PowerPC, > where 'arm-unknown-linux-gnueabi' vs. 'arm-unknown-linux-gnu'. Discussions on new triplets are worthless on the autoconf list, which is only a downstream consumer of config.guess; rather, your questions should be directed to config-patches@gnu.org [added to cc]. > > The new triple doesn't introduce a new target (still x86_64) but just > a new environment 'gnux32' to specify x32 ABI is used for code > generation. > > The current scheme documented on website > (https://sites.google.com/site/x32abi/) uses the existing triplet but > specify x32 ABI through compiler/linker options. It works for most > compilers aware of that, but how other tools not handling > compiler/linker options knows the current build is targeted on a > different environment? > > Any comments or alternative suggestion? > > Yours > - Michael > -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: new triplet for x32 psABI? 2011-10-03 22:26 new triplet for x32 psABI? Michael LIAO 2011-10-03 22:30 ` Eric Blake @ 2011-10-03 22:35 ` Mike Frysinger 2011-10-03 22:57 ` Michael LIAO 2011-10-12 4:49 ` Michael LIAO 1 sibling, 2 replies; 19+ messages in thread From: Mike Frysinger @ 2011-10-03 22:35 UTC (permalink / raw) To: autoconf; +Cc: Michael LIAO, gcc, x32-abi, config-patches [-- Attachment #1: Type: Text/Plain, Size: 1016 bytes --] On Monday, October 03, 2011 18:25:46 Michael LIAO wrote: > As x32 psABI (https://sites.google.com/site/x32abi/) is invented, do > we need a new triplet for system relies on triplet to figure out it's > targeted on x32 environment. The new triplet would look like > 'x86_64-unknown-linux-gnux32' for x32 vs 'x86_64-unknown-linux-gnu' > for regular 64-bit. This's similar to EABI added to ARM or PowerPC, > where 'arm-unknown-linux-gnueabi' vs. 'arm-unknown-linux-gnu'. do you have examples of why you need this ? > The current scheme documented on website > (https://sites.google.com/site/x32abi/) uses the existing triplet but > specify x32 ABI through compiler/linker options. It works for most > compilers aware of that, but how other tools not handling > compiler/linker options knows the current build is targeted on a > different environment? the mips people have been using a single tuple for multiple abis (n32 and n64), and it doesn't appear to have been a blocker for them ... -mike [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: new triplet for x32 psABI? 2011-10-03 22:35 ` Mike Frysinger @ 2011-10-03 22:57 ` Michael LIAO 2011-10-03 23:04 ` Mike Frysinger 2011-10-03 23:06 ` H.J. Lu 2011-10-12 4:49 ` Michael LIAO 1 sibling, 2 replies; 19+ messages in thread From: Michael LIAO @ 2011-10-03 22:57 UTC (permalink / raw) To: Mike Frysinger; +Cc: autoconf, gcc, x32-abi, config-patches 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. Yours - Michael On Mon, Oct 3, 2011 at 3:34 PM, Mike Frysinger <vapier@gentoo.org> wrote: > On Monday, October 03, 2011 18:25:46 Michael LIAO wrote: >> As x32 psABI (https://sites.google.com/site/x32abi/) is invented, do >> we need a new triplet for system relies on triplet to figure out it's >> targeted on x32 environment. The new triplet would look like >> 'x86_64-unknown-linux-gnux32' for x32 vs 'x86_64-unknown-linux-gnu' >> for regular 64-bit. This's similar to EABI added to ARM or PowerPC, >> where 'arm-unknown-linux-gnueabi' vs. 'arm-unknown-linux-gnu'. > > do you have examples of why you need this ? > >> The current scheme documented on website >> (https://sites.google.com/site/x32abi/) uses the existing triplet but >> specify x32 ABI through compiler/linker options. It works for most >> compilers aware of that, but how other tools not handling >> compiler/linker options knows the current build is targeted on a >> different environment? > > the mips people have been using a single tuple for multiple abis (n32 and > n64), and it doesn't appear to have been a blocker for them ... > -mike > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: new triplet for x32 psABI? 2011-10-03 22:57 ` Michael LIAO @ 2011-10-03 23:04 ` Mike Frysinger 2011-10-03 23:48 ` Michael LIAO 2011-10-03 23:06 ` H.J. Lu 1 sibling, 1 reply; 19+ messages in thread From: Mike Frysinger @ 2011-10-03 23:04 UTC (permalink / raw) To: Michael LIAO; +Cc: autoconf, gcc, x32-abi, config-patches [-- Attachment #1: Type: Text/Plain, Size: 987 bytes --] On Monday, October 03, 2011 18:57:28 Michael LIAO wrote: please don't top post > 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. the only difference between x86_64 and x32 is the size of the pointers. please explain why his example won't cover the OpenSSL's needs. (side note; OpenSSL is a terrible example to use because (1) they don't even use autoconf or any autotools and (2) they don't generally use sane tuples like the config project). -mike [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: new triplet for x32 psABI? 2011-10-03 23:04 ` Mike Frysinger @ 2011-10-03 23:48 ` Michael LIAO 2011-10-04 0:47 ` Mike Frysinger 2011-10-04 0:54 ` H.J. Lu 0 siblings, 2 replies; 19+ messages in thread From: Michael LIAO @ 2011-10-03 23:48 UTC (permalink / raw) To: Mike Frysinger; +Cc: autoconf, gcc, x32-abi, config-patches On Mon, Oct 3, 2011 at 4:03 PM, Mike Frysinger <vapier@gentoo.org> wrote: > On Monday, October 03, 2011 18:57:28 Michael LIAO wrote: > > please don't top post > sorry, it's my first post on mailing. >> 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. the 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. > please explain why his example won't cover the OpenSSL's needs. (side note; > OpenSSL is a terrible example to use because (1) they don't even use autoconf > or any autotools and (2) they don't generally use sane tuples like the config > project). > -mike > Openssl may not a good example and I just used as I remembered it uses assembly code. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: new triplet for x32 psABI? 2011-10-03 23:48 ` Michael LIAO @ 2011-10-04 0:47 ` Mike Frysinger 2011-10-04 3:26 ` Michael LIAO 2011-10-04 0:54 ` H.J. Lu 1 sibling, 1 reply; 19+ messages in thread From: Mike Frysinger @ 2011-10-04 0:47 UTC (permalink / raw) To: Michael LIAO; +Cc: autoconf, gcc, x32-abi, config-patches [-- Attachment #1: Type: Text/Plain, Size: 2136 bytes --] 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. the 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. in terms of a tool that generates code itself (like gcc), i'm not sure a different tuple would make it any easier. gcc 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. we have precedence here where multiple abi's work with a single tuple, and it hasn't been a significant hindrance for them. adding a new tuple is also not something to be done lightly ... a lot of code out there parses tuples, and they would need updating. 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 ;). -mike [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: new triplet for x32 psABI? 2011-10-04 0:47 ` Mike Frysinger @ 2011-10-04 3:26 ` Michael LIAO 2011-10-04 3:56 ` Mike Frysinger 0 siblings, 1 reply; 19+ messages in thread From: Michael LIAO @ 2011-10-04 3:26 UTC (permalink / raw) To: Mike Frysinger; +Cc: autoconf, gcc, x32-abi, config-patches On Mon, Oct 3, 2011 at 5:46 PM, Mike Frysinger <vapier@gentoo.org> 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. the 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. gcc 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, and it > hasn't been a significant hindrance for them. adding a new tuple is also not > something to be done lightly ... a lot of code out there parses tuples, and > 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 > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: new triplet for x32 psABI? 2011-10-04 3:26 ` Michael LIAO @ 2011-10-04 3:56 ` Mike Frysinger 0 siblings, 0 replies; 19+ messages in thread From: Mike Frysinger @ 2011-10-04 3:56 UTC (permalink / raw) To: Michael LIAO; +Cc: autoconf, gcc, x32-abi, config-patches [-- Attachment #1: Type: Text/Plain, Size: 631 bytes --] On Monday, October 03, 2011 23:26:25 Michael LIAO wrote: > On Mon, Oct 3, 2011 at 5:46 PM, Mike Frysinger wrote: > > 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.). you don't need to do it yourself. please look at the x32 website near the bottom. it shows you how to use ifdef's that gcc itself provides. -mike [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: new triplet for x32 psABI? 2011-10-03 23:48 ` Michael LIAO 2011-10-04 0:47 ` Mike Frysinger @ 2011-10-04 0:54 ` H.J. Lu 2011-10-04 3:44 ` Michael LIAO 1 sibling, 1 reply; 19+ messages in thread From: H.J. Lu @ 2011-10-04 0:54 UTC (permalink / raw) To: x32-abi; +Cc: Mike Frysinger, autoconf, gcc, config-patches On Mon, Oct 3, 2011 at 4:47 PM, Michael LIAO <michael.hliao@gmail.com> wrote: > On Mon, Oct 3, 2011 at 4:03 PM, Mike Frysinger <vapier@gentoo.org> wrote: >> On Monday, October 03, 2011 18:57:28 Michael LIAO wrote: >> >> please don't top post >> > > sorry, it's my first post on mailing. > >>> 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. the 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 assembly codes, most, if not all, of x86-64 indirect branch work fine for x32 -- H.J. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: new triplet for x32 psABI? 2011-10-04 0:54 ` H.J. Lu @ 2011-10-04 3:44 ` Michael LIAO 2011-10-04 19:53 ` H.J. Lu 0 siblings, 1 reply; 19+ messages in thread From: Michael LIAO @ 2011-10-04 3:44 UTC (permalink / raw) To: x32-abi; +Cc: Mike Frysinger, autoconf, gcc, config-patches On Mon, Oct 3, 2011 at 5:53 PM, H.J. Lu <hjl.tools@gmail.com> wrote: > On Mon, Oct 3, 2011 at 4:47 PM, Michael LIAO <michael.hliao@gmail.com> wrote: >> On Mon, Oct 3, 2011 at 4:03 PM, Mike Frysinger <vapier@gentoo.org> wrote: >>> On Monday, October 03, 2011 18:57:28 Michael LIAO wrote: >>> >>> please don't top post >>> >> >> sorry, it's my first post on mailing. >> >>>> 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. the 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 assembly codes, most, if not all, of x86-64 indirect branch work fine for x32 > that may cause the target IP out of the first 4G range if assembly code won't follow x32 abi, e.g. indirect target is stored in a memory location and assembly direct use 64-bit near absolute indirect call with m64 opernad since the branch target is 32 bits in memory but that call will read 64-bit value and result in garbage on high 32 bits of the final IP. > > -- > H.J. > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: new triplet for x32 psABI? 2011-10-04 3:44 ` Michael LIAO @ 2011-10-04 19:53 ` H.J. Lu 0 siblings, 0 replies; 19+ messages in thread From: H.J. Lu @ 2011-10-04 19:53 UTC (permalink / raw) To: x32-abi; +Cc: Mike Frysinger, autoconf, gcc, config-patches On Mon, Oct 3, 2011 at 8:44 PM, Michael LIAO <michael.hliao@gmail.com> wrote: > On Mon, Oct 3, 2011 at 5:53 PM, H.J. Lu <hjl.tools@gmail.com> wrote: >> On Mon, Oct 3, 2011 at 4:47 PM, Michael LIAO <michael.hliao@gmail.com> wrote: >>> On Mon, Oct 3, 2011 at 4:03 PM, Mike Frysinger <vapier@gentoo.org> wrote: >>>> On Monday, October 03, 2011 18:57:28 Michael LIAO wrote: >>>> >>>> please don't top post >>>> >>> >>> sorry, it's my first post on mailing. >>> >>>>> 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. the 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 assembly codes, most, if not all, of x86-64 indirect branch work fine for x32 >> > > that may cause the target IP out of the first 4G range if assembly > code won't follow x32 abi, e.g. indirect target is stored in a memory > location and assembly direct use 64-bit near absolute indirect call > with m64 opernad since the branch target is 32 bits in memory but that > call will read 64-bit value and result in garbage on high 32 bits of > the final IP. > X32 assembler/linker should handle it properly by zero-extending address to 64bit. -- H.J. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: new triplet for x32 psABI? 2011-10-03 22:57 ` Michael LIAO 2011-10-03 23:04 ` Mike Frysinger @ 2011-10-03 23:06 ` H.J. Lu 1 sibling, 0 replies; 19+ messages in thread From: H.J. Lu @ 2011-10-03 23:06 UTC (permalink / raw) To: x32-abi; +Cc: Mike Frysinger, autoconf, gcc, config-patches On Mon, Oct 3, 2011 at 3:57 PM, Michael LIAO <michael.hliao@gmail.com> 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. > X32 assembly codes are very close to x86-64 ones. In come cases, they are 100% compatible. In kernel, x32 vDSO is built from the x86-64 .o files for x86-64 vDSO. In gmp, you can assemble x86-64 assembly codes directly into x32 object files. Adding x32 target triplet may not be necessarily helpful. -- H.J. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: new triplet for x32 psABI? 2011-10-03 22:35 ` Mike Frysinger 2011-10-03 22:57 ` Michael LIAO @ 2011-10-12 4:49 ` Michael LIAO 2011-10-12 7:13 ` Mike Frysinger 1 sibling, 1 reply; 19+ messages in thread From: Michael LIAO @ 2011-10-12 4:49 UTC (permalink / raw) To: Mike Frysinger; +Cc: autoconf, gcc, x32-abi, config-patches On Mon, Oct 3, 2011 at 3:34 PM, Mike Frysinger <vapier@gentoo.org> wrote: > On Monday, October 03, 2011 18:25:46 Michael LIAO wrote: >> As x32 psABI (https://sites.google.com/site/x32abi/) is invented, do >> we need a new triplet for system relies on triplet to figure out it's >> targeted on x32 environment. The new triplet would look like >> 'x86_64-unknown-linux-gnux32' for x32 vs 'x86_64-unknown-linux-gnu' >> for regular 64-bit. This's similar to EABI added to ARM or PowerPC, >> where 'arm-unknown-linux-gnueabi' vs. 'arm-unknown-linux-gnu'. > > do you have examples of why you need this ? > >> The current scheme documented on website >> (https://sites.google.com/site/x32abi/) uses the existing triplet but >> specify x32 ABI through compiler/linker options. It works for most >> compilers aware of that, but how other tools not handling >> compiler/linker options knows the current build is targeted on a >> different environment? > > the mips people have been using a single tuple for multiple abis (n32 and > n64), and it doesn't appear to have been a blocker for them ... That's not true, at least to build glibc, you can use 'mips64-linux-gnuabi64' to specify a n64 build and ''mips64-linux-gnuabin32' for a n32 build without specifying compiler option explicitly. I just figured this out from mips ports of glibc from http://repo.or.cz/w/glibc-ports.git/blob/HEAD:/sysdeps/mips/preconfigure, where both compiler option and triplet are checked and triplet is preferred if they are not match. > -mike > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: new triplet for x32 psABI? 2011-10-12 4:49 ` Michael LIAO @ 2011-10-12 7:13 ` Mike Frysinger 2011-10-12 7:27 ` Michael LIAO 0 siblings, 1 reply; 19+ messages in thread From: Mike Frysinger @ 2011-10-12 7:13 UTC (permalink / raw) To: Michael LIAO; +Cc: autoconf, gcc, x32-abi, config-patches [-- Attachment #1: Type: Text/Plain, Size: 1506 bytes --] On Tuesday 11 October 2011 22:55:35 Michael LIAO wrote: > On Mon, Oct 3, 2011 at 3:34 PM, Mike Frysinger <vapier@gentoo.org> wrote: > > On Monday, October 03, 2011 18:25:46 Michael LIAO wrote: > >> The current scheme documented on website > >> (https://sites.google.com/site/x32abi/) uses the existing triplet but > >> specify x32 ABI through compiler/linker options. It works for most > >> compilers aware of that, but how other tools not handling > >> compiler/linker options knows the current build is targeted on a > >> different environment? > > > > the mips people have been using a single tuple for multiple abis (n32 and > > n64), and it doesn't appear to have been a blocker for them ... > > That's not true, at least to build glibc, you can use > 'mips64-linux-gnuabi64' to specify a n64 build and > ''mips64-linux-gnuabin32' for a n32 build without specifying compiler > option explicitly. I just figured this out from mips ports of glibc > from > http://repo.or.cz/w/glibc-ports.git/blob/HEAD:/sysdeps/mips/preconfigure, > where both compiler option and triplet are checked and triplet is > preferred if they are not match. while it is true glibc has this code, it doesn't make my statements incorrect: a single tuple works just fine with mips for multiple ABIs. if you look at other projects like gcc, it doesn't check this field at all. so you're still right where you started: you still haven't shown any cases which necessitate a dedicated tuple. -mike [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: new triplet for x32 psABI? 2011-10-12 7:13 ` Mike Frysinger @ 2011-10-12 7:27 ` Michael LIAO 2011-10-12 22:14 ` Mike Frysinger 2011-10-13 0:49 ` H.J. Lu 0 siblings, 2 replies; 19+ messages in thread From: Michael LIAO @ 2011-10-12 7:27 UTC (permalink / raw) To: Mike Frysinger; +Cc: autoconf, gcc, x32-abi, config-patches On Tue, Oct 11, 2011 at 9:21 PM, Mike Frysinger <vapier@gentoo.org> wrote: > On Tuesday 11 October 2011 22:55:35 Michael LIAO wrote: >> On Mon, Oct 3, 2011 at 3:34 PM, Mike Frysinger <vapier@gentoo.org> wrote: >> > On Monday, October 03, 2011 18:25:46 Michael LIAO wrote: >> >> The current scheme documented on website >> >> (https://sites.google.com/site/x32abi/) uses the existing triplet but >> >> specify x32 ABI through compiler/linker options. It works for most >> >> compilers aware of that, but how other tools not handling >> >> compiler/linker options knows the current build is targeted on a >> >> different environment? >> > >> > the mips people have been using a single tuple for multiple abis (n32 and >> > n64), and it doesn't appear to have been a blocker for them ... >> >> That's not true, at least to build glibc, you can use >> 'mips64-linux-gnuabi64' to specify a n64 build and >> ''mips64-linux-gnuabin32' for a n32 build without specifying compiler >> option explicitly. I just figured this out from mips ports of glibc >> from >> http://repo.or.cz/w/glibc-ports.git/blob/HEAD:/sysdeps/mips/preconfigure, >> where both compiler option and triplet are checked and triplet is >> preferred if they are not match. > > while it is true glibc has this code, it doesn't make my statements incorrect: > a single tuple works just fine with mips for multiple ABIs. if you look at > other projects like gcc, it doesn't check this field at all. so you're still > right where you started: you still haven't shown any cases which necessitate a > dedicated tuple. That's why the proposed new triplet won't break existing packages as, if they are compliant to autoconf, they should check that field with 'gnu*' or just ignore it instead of an exact matching. I am not asking a dedicated triplet for x32 to be used exclusively for x32 package build. I am asking additional triplet with enough details of execution environment (ABI definitely a necessary detail.) for package which relies on triplet to tell that. At least that triplet could be canonical and widely accepted for package really caring about that instead of forcing all package checking compiler options. If a package needs to support similar thing to mutlilib just like glibc, that new triplet will simiplifies their decision. gcc definitely is not that kind of package as it could be built to support generate x86-64, x32 and i386 code with the same package and need a runtime option to tell that. - michael > -mike > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: new triplet for x32 psABI? 2011-10-12 7:27 ` Michael LIAO @ 2011-10-12 22:14 ` Mike Frysinger 2011-10-13 0:49 ` H.J. Lu 1 sibling, 0 replies; 19+ messages in thread From: Mike Frysinger @ 2011-10-12 22:14 UTC (permalink / raw) To: Michael LIAO; +Cc: autoconf, gcc, x32-abi, config-patches [-- Attachment #1: Type: Text/Plain, Size: 1004 bytes --] On Wednesday 12 October 2011 01:03:19 Michael LIAO wrote: > I am not asking a dedicated triplet for x32 to be used exclusively for > x32 package build. I am asking additional triplet with enough details > of execution environment (ABI definitely a necessary detail.) for > package which relies on triplet to tell that. At least that triplet > could be canonical and widely accepted for package really caring about > that instead of forcing all package checking compiler options. If a > package needs to support similar thing to mutlilib just like glibc, > that new triplet will simiplifies their decision. > gcc definitely is not that kind of package as it could be built to > support generate x86-64, x32 and i386 code with the same package and > need a runtime option to tell that. except that if gcc doesn't change its default ABI output, it doesn't make it terribly useful. you still need to specify the -mabi flag whenever you execute gcc, thus the tuple is just noise. -mike [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: new triplet for x32 psABI? 2011-10-12 7:27 ` Michael LIAO 2011-10-12 22:14 ` Mike Frysinger @ 2011-10-13 0:49 ` H.J. Lu 2011-10-13 7:26 ` Mike Frysinger 1 sibling, 1 reply; 19+ messages in thread From: H.J. Lu @ 2011-10-13 0:49 UTC (permalink / raw) To: x32-abi; +Cc: Mike Frysinger, autoconf, gcc, config-patches On Tue, Oct 11, 2011 at 10:03 PM, Michael LIAO <michael.hliao@gmail.com> wrote: > On Tue, Oct 11, 2011 at 9:21 PM, Mike Frysinger <vapier@gentoo.org> wrote: >> On Tuesday 11 October 2011 22:55:35 Michael LIAO wrote: >>> On Mon, Oct 3, 2011 at 3:34 PM, Mike Frysinger <vapier@gentoo.org> wrote: >>> > On Monday, October 03, 2011 18:25:46 Michael LIAO wrote: >>> >> The current scheme documented on website >>> >> (https://sites.google.com/site/x32abi/) uses the existing triplet but >>> >> specify x32 ABI through compiler/linker options. It works for most >>> >> compilers aware of that, but how other tools not handling >>> >> compiler/linker options knows the current build is targeted on a >>> >> different environment? >>> > >>> > the mips people have been using a single tuple for multiple abis (n32 and >>> > n64), and it doesn't appear to have been a blocker for them ... >>> >>> That's not true, at least to build glibc, you can use >>> 'mips64-linux-gnuabi64' to specify a n64 build and >>> ''mips64-linux-gnuabin32' for a n32 build without specifying compiler >>> option explicitly. I just figured this out from mips ports of glibc >>> from >>> http://repo.or.cz/w/glibc-ports.git/blob/HEAD:/sysdeps/mips/preconfigure, >>> where both compiler option and triplet are checked and triplet is >>> preferred if they are not match. >> >> while it is true glibc has this code, it doesn't make my statements incorrect: >> a single tuple works just fine with mips for multiple ABIs. if you look at >> other projects like gcc, it doesn't check this field at all. so you're still >> right where you started: you still haven't shown any cases which necessitate a >> dedicated tuple. > > That's why the proposed new triplet won't break existing packages as, > if they are compliant to autoconf, they should check that field with > 'gnu*' or just ignore it instead of an exact matching. > > I am not asking a dedicated triplet for x32 to be used exclusively for > x32 package build. I am asking additional triplet with enough details > of execution environment (ABI definitely a necessary detail.) for > package which relies on triplet to tell that. At least that triplet > could be canonical and widely accepted for package really caring about > that instead of forcing all package checking compiler options. If a > package needs to support similar thing to mutlilib just like glibc, > that new triplet will simiplifies their decision. > > gcc definitely is not that kind of package as it could be built to > support generate x86-64, x32 and i386 code with the same package and > need a runtime option to tell that. > I see 3 separate issues: 1. The file name of an x32 binary package needs to be marked as x32. 2. Compilers need a switch to generate x32 code. 3. We need to configure a software package for x32. Which problem are you trying to resolve? Please explain yours if it isn't covered above. -- H.J. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: new triplet for x32 psABI? 2011-10-13 0:49 ` H.J. Lu @ 2011-10-13 7:26 ` Mike Frysinger 0 siblings, 0 replies; 19+ messages in thread From: Mike Frysinger @ 2011-10-13 7:26 UTC (permalink / raw) To: x32-abi; +Cc: Mike Frysinger, autoconf, gcc, config-patches On Wed, Oct 12, 2011 at 12:28, H.J. Lu <hjl.tools@gmail.com> wrote: > 1. The file name of an x32 binary package needs to be marked as x32. i would think this would be completely a package manager issue and out of scope for any ABI project such as x32 -mike ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2011-10-12 17:38 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-10-03 22:26 new triplet for x32 psABI? Michael LIAO 2011-10-03 22:30 ` Eric Blake 2011-10-03 22:35 ` Mike Frysinger 2011-10-03 22:57 ` Michael LIAO 2011-10-03 23:04 ` Mike Frysinger 2011-10-03 23:48 ` Michael LIAO 2011-10-04 0:47 ` Mike Frysinger 2011-10-04 3:26 ` Michael LIAO 2011-10-04 3:56 ` Mike Frysinger 2011-10-04 0:54 ` H.J. Lu 2011-10-04 3:44 ` Michael LIAO 2011-10-04 19:53 ` H.J. Lu 2011-10-03 23:06 ` H.J. Lu 2011-10-12 4:49 ` Michael LIAO 2011-10-12 7:13 ` Mike Frysinger 2011-10-12 7:27 ` Michael LIAO 2011-10-12 22:14 ` Mike Frysinger 2011-10-13 0:49 ` H.J. Lu 2011-10-13 7:26 ` Mike Frysinger
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).