Thanks!
On x86_64 without -m32, this becomes a problem (as it would on ia64,
alpha, or other Debian architectures I might wind up porting this
to). I've heard from others that 64 bit targets aren't really
interesting to the V8 team, so I assume I'll keep keeping some fixes
out of tree for now, but in cases where I can push patches in upstream
that won't get in the way, I'd like to.
I have a patch in my tree to make doing this build easy while still
letting me test the 32bit build. Debian and Ubuntu have a tool called
'linux32' which will have the system report that it's running on ia32
rather than x86_64. With the following patch, using "linux32 scons"
on amd64 produces the build the way you guys are used to and "scons"
attempts to build it for x86_64. Note that I haven't tested this on
arm as I don't have that environment setup. I don't remember off hand
if arm-linux-gcc accepts -m32. If not, I would need to tweak this
further. I also think the hack to tools/utils.py is probably wrong.
platform.machine() seems to always return the value we want, except
for i[3-7]86 where we want ia32. I suspect it should just test for
that and otherwise return whatever was handed to it. Distros and
whatnot would usually expect to use linux32 and a 32bit chroot to do
ia32 builds.
Patch follows:
Index: tools/utils.py
===================================================================
--- tools/utils.py (revision 1129)
+++ tools/utils.py (working copy)
@@ -63,6 +63,8 @@
id = platform.machine()
if id.startswith('arm'):
return 'arm'
+ if id.startswith('x86_64'):
+ return 'x86_64'
elif (not id) or (not re.match('(x|i[3-6])86', id) is None):
return 'ia32'
else:
Index: SConstruct
===================================================================
--- SConstruct (revision 1129)
+++ SConstruct (working copy)
@@ -57,10 +57,10 @@
'os:freebsd': {
'LIBS': ['execinfo']
},
- 'wordsize:64': {
+ 'wordsize:32': {
'CCFLAGS': ['-m32'],
'LINKFLAGS': ['-m32']
- }
+ },
},
'msvc': {
'all': {
@@ -175,7 +175,7 @@
'all': {
'LIBPATH': [abspath('.')]
},
- 'wordsize:64': {
+ 'wordsize:32': {
'CCFLAGS': ['-m32'],
'LINKFLAGS': ['-m32']
},
@@ -204,7 +204,7 @@
'os:freebsd': {
'LIBS': ['execinfo']
},
- 'wordsize:64': {
+ 'wordsize:32': {
'CCFLAGS': ['-m32'],
'LINKFLAGS': ['-m32']
},
@@ -298,7 +298,7 @@
'help': 'the os to build for'
},
'arch': {
- 'values':['arm', 'ia32'],
+ 'values':['arm', 'ia32', 'x86_64'],
'default': ARCH_GUESS,
'help': 'the architecture to build for'
},
On Jan 22, 9:03 am, Mads Sig Ager <[email protected]> wrote:
> Thanks for the patch! Using %p is the right thing here. It has been
> committed in V8 bleeding_edge revision 1128. :-)
>
> Do you have a build setup where this is a problem? If you do, we
> would be interested in more details of the setup so we can test
> against it.
>
> Cheers, -- Mads
>
> On Wed, Jan 21, 2009 at 7:10 PM, Jeff Bailey <[email protected]> wrote:
>
> > Hi! There seem to be a number of places that assume that a pointer is
> > the same size as an int (or an ILP32 system in general). Will fixes
> > like this be accepted?
>
> > 2009-01-20 Jeff Bailey <[email protected]>
>
> > * src/checks.h: Use %p modifier for displaying pointers.
>
> > Index: src/checks.h
> > ===================================================================
> > --- src/checks.h (revision 1112)
> > +++ src/checks.h (working copy)
> > @@ -136,9 +136,9 @@
> > void* value) {
> > if (expected != value) {
> > V8_Fatal(file, line,
> > - "CHECK_EQ(%s, %s) failed\n# Expected: %i\n# Found:
> > %i",
> > + "CHECK_EQ(%s, %s) failed\n# Expected: %p\n# Found:
> > %p",
> > expected_source, value_source,
> > - reinterpret_cast<int>(expected), reinterpret_cast<int>
> > (value));
> > + expected, value);
> > }
> > }
>
> > @@ -150,8 +150,8 @@
> > const char* value_source,
> > void* value) {
> > if (expected == value) {
> > - V8_Fatal(file, line, "CHECK_NE(%s, %s) failed\n# Value: %i",
> > - expected_source, value_source, reinterpret_cast<int>
> > (value));
> > + V8_Fatal(file, line, "CHECK_NE(%s, %s) failed\n# Value: %p",
> > + expected_source, value_source, value);
> > }
> > }
--~--~---------~--~----~------------~-------~--~----~
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
-~----------~----~----~----~------~----~------~--~---
