x32 ABI support

[Paweł Hajdan, Jr.]

Is v8 expected to support x32 ABI? I tried "make native" (using v8 bleeding_edge, r12652) on an x32 ABI Gentoo install, and it failed with e.g.:

In file included from ../src/conversions-inl.h:35:0,

                 from ../src/conversions.cc:32:

../src/globals.h:243:33: warning: overflow in implicit constant conversion [-Woverflow]

../src/globals.h:244:38: warning: large integer implicitly truncated to unsigned type [-Woverflow]

../src/atomicops_internals_x86_gcc.h: In function 'void v8::internal::Acquire_Store(volatile Atomic64*, v8::internal::Atomic64)':

../src/atomicops_internals_x86_gcc.h:222:13: error: redefinition of 'void v8::internal::Acquire_Store(volatile Atomic64*, v8::internal::Atomic64)'

../src/atomicops_internals_x86_gcc.h:122:13: error: 'void v8::internal::Acquire_Store(volatile Atomic32*, v8::internal::Atomic32)' previously defined here

../src/atomicops_internals_x86_gcc.h: In function 'void v8::internal::Release_Store(volatile Atomic64*, v8::internal::Atomic64)':

../src/atomicops_internals_x86_gcc.h:227:13: error: redefinition of 'void v8::internal::Release_Store(volatile Atomic64*, v8::internal::Atomic64)'

../src/atomicops_internals_x86_gcc.h:149:13: error: 'void v8::internal::Release_Store(volatile Atomic32*, v8::internal::Atomic32)' previously defined here

../src/atomicops_internals_x86_gcc.h: In function 'v8::internal::Atomic64 v8::internal::NoBarrier_Load(const volatile Atomic64*)':

../src/atomicops_internals_x86_gcc.h:248:17: error: redefinition of 'v8::internal::Atomic64 v8::internal::NoBarrier_Load(const volatile Atomic64*)'

../src/atomicops_internals_x86_gcc.h:155:17: error: 'v8::internal::Atomic32 v8::internal::NoBarrier_Load(const volatile Atomic32*)' previously defined here

../src/atomicops_internals_x86_gcc.h: In function 'v8::internal::Atomic64 v8::internal::Acquire_Load(const volatile Atomic64*)':

../src/atomicops_internals_x86_gcc.h:252:17: error: redefinition of 'v8::internal::Atomic64 v8::internal::Acquire_Load(const volatile Atomic64*)'

../src/atomicops_internals_x86_gcc.h:159:17: error: 'v8::internal::Atomic32 v8::internal::Acquire_Load(const volatile Atomic32*)' previously defined here

../src/atomicops_internals_x86_gcc.h: In function 'v8::internal::Atomic64 v8::internal::Release_Load(const volatile Atomic64*)':

../src/atomicops_internals_x86_gcc.h:260:17: error: redefinition of 'v8::internal::Atomic64 v8::internal::Release_Load(const volatile Atomic64*)'

../src/atomicops_internals_x86_gcc.h:166:17: error: 'v8::internal::Atomic32 v8::internal::Release_Load(const volatile Atomic32*)' previously defined here

../src/atomicops_internals_x86_gcc.h: In function 'v8::internal::Atomic64 v8::internal::Acquire_CompareAndSwap(volatile Atomic64*, v8::internal::Atomic64, v8::internal::Atomic64)':

../src/atomicops_internals_x86_gcc.h:265:17: error: redefinition of 'v8::internal::Atomic64 v8::internal::Acquire_CompareAndSwap(volatile Atomic64*, v8::internal::Atomic64, v8::internal::Atomic64)'

../src/atomicops_internals_x86_gcc.h:94:17: error: 'v8::internal::Atomic32 v8::internal::Acquire_CompareAndSwap(volatile Atomic32*, v8::internal::Atomic32, v8::internal::Atomic32)' previously defined here

../src/atomicops_internals_x86_gcc.h: In function 'v8::internal::Atomic64 v8::internal::Release_CompareAndSwap(volatile Atomic64*, v8::internal::Atomic64, v8::internal::Atomic64)':

../src/atomicops_internals_x86_gcc.h:275:17: error: redefinition of 'v8::internal::Atomic64 v8::internal::Release_CompareAndSwap(volatile Atomic64*, v8::internal::Atomic64, v8::internal::Atomic64)'

../src/atomicops_internals_x86_gcc.h:104:17: error: 'v8::internal::Atomic32 v8::internal::Release_CompareAndSwap(volatile Atomic32*, v8::internal::Atomic32, v8::internal::Atomic32)' previously defined here

On the other hand, "make ia32.release" succeeded, but I'm not sure if that's what should be done on x32.

For more info about this issue on Gentoo, see https://bugs.gentoo.org/show_bug.cgi?id=423815

In case you wonder what x32 ABI is all about, please take a look at http://en.wikipedia.org/wiki/X32_ABI and https://sites.google.com/site/x32abi/

I have a working x32 install and can contribute patches, but any guidance and feedback is welcome.

[Jakob Kummerow]

V8 does not support x32 at this time. Sorry.

Adding support is not just a matter of fixing a few lines. It would be an entire new platform port (albeit similar to the existing ia32/x64 ports); roughly 40K lines of code.

The reason is that V8 is not just any C++ program which you can simply compile for x32 -- it's actually a compiler of its own and emits native code, so it has to know about registers, machine instructions, calling conventions and all the other stuff that differentiates x32 from ia32 and x64. AFAIK x32 and ia32 are incompatible enough that V8's ia32 port will probably just crash on an x32 system (I'm kind of surprised that it compiles at all).

--
v8-users mailing list
v8-u...@googlegroups.com
http://groups.google.com/group/v8-users

[Paweł Hajdan, Jr.]

On Tue, Oct 2, 2012 at 4:32 PM, Jakob Kummerow <jkum...@chromium.org> wrote:

V8 does not support x32 at this time. Sorry.

OK - do you plan to add that support? Just asking e.g. so I can take the right action as maintainer of v8 package in Gentoo. It's fine for me if you don't have such plans. :)

 

Adding support is not just a matter of fixing a few lines. It would be an entire new platform port (albeit similar to the existing ia32/x64 ports); roughly 40K lines of code.

Got it. For reference - would you accept patches adding such a port? Note that I'm rather not going to work on it atm, but someone else might be interested.

 

The reason is that V8 is not just any C++ program which you can simply compile for x32 -- it's actually a compiler of its own and emits native code, so it has to know about registers, machine instructions, calling conventions and all the other stuff that differentiates x32 from ia32 and x64. AFAIK x32 and ia32 are incompatible enough that V8's ia32 port will probably just crash on an x32 system (I'm kind of surprised that it compiles at all).

FYI, I ran ia32 d8 on that x32 system and on simple cases like "a = 8" or "for (a = 0; a < 10; a++);" it didn't crash. Anyway, trying to combine resulting v8 shared library with x32 ABI binaries would indeed cause trouble.

[Jakob Kummerow]

On Fri, Oct 5, 2012 at 3:29 PM, Paweł Hajdan, Jr. <phajd...@chromium.org> wrote:

On Tue, Oct 2, 2012 at 4:32 PM, Jakob Kummerow <jkum...@chromium.org> wrote:

V8 does not support x32 at this time. Sorry.

OK - do you plan to add that support? Just asking e.g. so I can take the right action as maintainer of v8 package in Gentoo. It's fine for me if you don't have such plans. :)

No. (For reasoning, see below.)

 

Adding support is not just a matter of fixing a few lines. It would be an entire new platform port (albeit similar to the existing ia32/x64 ports); roughly 40K lines of code.

Got it. For reference - would you accept patches adding such a port? Note that I'm rather not going to work on it atm, but someone else might be interested.

It's not just the initial creation of a new platform port that's a bunch of work, it's also the ongoing maintenance of it (i.e. making it keep up with the continuing development of V8). As long as the potential user base for x32 is as small as it currently is, it doesn't make sense for the team to spend resources on that. 

The obvious alternative is a third-party maintained port in a separate repository that tracks V8, as our MIPS port is currently doing it (https://github.com/paul99/v8m-rb). This model can work with or without upstreaming of the changes, but either way with a clear statement that the core V8 team does not commit to making sure the port works and is up to date.

 

The reason is that V8 is not just any C++ program which you can simply compile for x32 -- it's actually a compiler of its own and emits native code, so it has to know about registers, machine instructions, calling conventions and all the other stuff that differentiates x32 from ia32 and x64. AFAIK x32 and ia32 are incompatible enough that V8's ia32 port will probably just crash on an x32 system (I'm kind of surprised that it compiles at all).

FYI, I ran ia32 d8 on that x32 system and on simple cases like "a = 8" or "for (a = 0; a < 10; a++);" it didn't crash. Anyway, trying to combine resulting v8 shared library with x32 ABI binaries would indeed cause trouble.

Hm... I would have expected the interaction of assembly stubs and C++ compiled code to be broken/crashy right inside V8. Maybe the ia32 and x32 calling conventions are more similar than I thought (haven't spent time with the technical specification yet). Does the test suite ("make ia32.release.check TESTJOBS=-j4" or whatever many cores you have) pass? Do Chromium and/or node.js work on x32? There is no way the ia32 version of V8 will make use of x32's benefits (more registers, instructions and so on), but if it happens to work without obvious errors, you could simply make it available to users running x32 systems, as it would be better than nothing :-)

[Paweł Hajdan, Jr.]

On Fri, Oct 5, 2012 at 4:11 PM, Jakob Kummerow <jkum...@chromium.org> wrote:

The obvious alternative is a third-party maintained port in a separate repository that tracks V8, as our MIPS port is currently doing it (https://github.com/paul99/v8m-rb). This model can work with or without upstreaming of the changes, but either way with a clear statement that the core V8 team does not commit to making sure the port works and is up to date.

Got it. Just in case, for other people reading it, I would rather not make such a port a part of the Gentoo package and stay as close as possible to v8 upstream.

 

 

The reason is that V8 is not just any C++ program which you can simply compile for x32 -- it's actually a compiler of its own and emits native code, so it has to know about registers, machine instructions, calling conventions and all the other stuff that differentiates x32 from ia32 and x64. AFAIK x32 and ia32 are incompatible enough that V8's ia32 port will probably just crash on an x32 system (I'm kind of surprised that it compiles at all).

FYI, I ran ia32 d8 on that x32 system and on simple cases like "a = 8" or "for (a = 0; a < 10; a++);" it didn't crash. Anyway, trying to combine resulting v8 shared library with x32 ABI binaries would indeed cause trouble.

Hm... I would have expected the interaction of assembly stubs and C++ compiled code to be broken/crashy right inside V8. Maybe the ia32 and x32 calling conventions are more similar than I thought (haven't spent time with the technical specification yet). Does the test suite ("make ia32.release.check TESTJOBS=-j4" or whatever many cores you have) pass? Do Chromium and/or node.js work on x32? There is no way the ia32 version of V8 will make use of x32's benefits (more registers, instructions and so on), but if it happens to work without obvious errors, you could simply make it available to users running x32 systems, as it would be better than nothing :-)

make ia32.release.check succeeded on my x32 system. Note that I haven't tested with Chromium or any other reverse dependencies of v8, and I'd expect problems there (those apps would either actually mix x32 and x86 calling conventions which would obviously lead to weird behavior, or would just be built for x86 platform, which means nothing x32-specific at all).