Support JavaScript Core for WinXP AMD64

RESOLVED FIXED in mozilla1.9alpha1

Status

()

Core
JavaScript Engine
P2
enhancement
RESOLVED FIXED
14 years ago
12 years ago

People

(Reporter: m_kato, Assigned: brendan)

Tracking

({js1.6})

Trunk
mozilla1.9alpha1
x86
Windows XP
js1.6
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.8a1 -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

14 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007

Currently code doesn't support WinXP for AMD64.  Because Pointer structure is
jsword.  So, since jsword is 32bit value, AV occurs on everywhere.

Reproducible: Always

Steps to Reproduce:
N/A
Actual Results:  
Cannot build and don't work

Expected Results:  
Can build and work.
(Reporter)

Comment 1

14 years ago
Created attachment 135808 [details] [diff] [review]
mozilla/js diff
Attachment #135808 - Flags: review?(brendan)
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 2

14 years ago
Comment on attachment 135808 [details] [diff] [review]
mozilla/js diff

This is all wrong. First, jsuword and JSUptrdiff must be the same size for
things to work correctly.  Don't go hacking in code to change type names at
each point of use -- change the type definition if it's wrong!

Now, without hacking up a totally bogus patch that changes too many lines, can
you say why jsword/jsuword are only 32 bits on your target compiler/CPU system?

Hint: jstypes.h requires, as does NSPR's prtypes.h on which it was based, that
a long is big enough to hold a pointer on all target platforms.

If you're using a compilation type model where long is 32 bits but pointer is
64 bits (an LLP64 model), you are using the wrong model.  Mozilla does not
support that model, and never will.

/be
Attachment #135808 - Flags: review?(brendan) → review-
(Reporter)

Comment 3

14 years ago
Windows 64bit Platform is the following.

- long is 32bits.
- long long is 64bits.
- void* / long* is 64bits.
- LONG_PTR is 64bits.

So, since jsuword is defined as "unsigned long" in jstype.h, void* cannot cast
to long correctly.

I think that JavaScript Engine should have pointer type like GLIB of GTK (this
has gpointer type).

Also, I already filed NSPR issue as Bug #225859.
(Reporter)

Comment 4

14 years ago
See
http://www.amd.com/us-en/assets/content_type/DownloadableAssets/AMD_TechEdEMEA2003_Final.pdf#22.

"Types int and long remain 32 bits."


So there is no option of that long is 64bits.
(Reporter)

Comment 5

14 years ago
Created attachment 135935 [details] [diff] [review]
mozilla/js diff at 2003-11-20
Attachment #135808 - Attachment is obsolete: true
(Assignee)

Comment 6

14 years ago
jsword/jsuword is the JS engine's pointer type.  The forked prtypes.h named
jstypes.h muddies the waters a bit, and adds the JSPtrdiff/JSUptrdiff types, but
they could be unified.

I still think any LLP64 model is going to require lots of changes, and not just
to NSPR.  Other parts of Mozilla assume a long is big enough to hold a pointer.

Why can't you use an LP64 model?

/be
(Assignee)

Comment 7

14 years ago
Sorry, I was replying based on bugmail.  That pdf looks like a slideshow.  How
early are we in the evolution of the compiler 'port?  It's extremely naive to
claim that LLP64 makes all 32-bit code work, precisely because lots of code
assumes you can fit a pointer in either an int (very old code, not commonly
assumed these days) or a long (much more common an assumption).

Someone should talk to the AMD people, or whoever the people are responsible for
this port.  LLP64 is not a compilation model that we want to support.

The patch looks ok, but before I review it I'd like to get this LLP64 issue
sorted out with more people.  Cc'ing them.

/be
(Reporter)

Comment 8

14 years ago
Microsfot C/C++ complier for Windows 64 bit has LLP64 model only.

But about js engine, it works fine by my fix.  Now I am submitting many LLP64
issues for WinXP AMD64.  (mozilla/nsprpub, mozilla/db, and mozilla/content and etc)
Making this block the other bugs on the topic until we decide whether we want to
support LLP64.
Blocks: 225859, 229722

Comment 10

14 years ago
wtc: attachment 135935 [details] [diff] [review] changes the meaning of JSWord/JSUword which are supposed
to be consistent with PRWord/PRuword (see also bug 229722 where the same mess is
present)

Updated

13 years ago
Blocks: 237202

Updated

13 years ago
Flags: blocking1.8a?

Updated

13 years ago
Flags: blocking1.8a? → blocking1.8a-

Comment 11

13 years ago
Is there a mailing list or forum for the Windows-64 port? My system arrives
Thursday and I have the Beta kit ready to install. I CCd myself to all the AMD
64 bugs that I could find.

It would be nice if there were an area for Windows-64 builders could chat on
progress to getting a native port working.

Comment 12

13 years ago
I put together a little page with porting resources on it at:
http://www.geocities.com/mmoy/mozilla-windows-xp-64.html

I have also started a topic at pryan's forum if anyone wants to discuss building
issues on Windows-64 in a forum-style rather than in separate bugs at
http://63.246.131.156/mozilla/forums/viewtopic.php?t=39
(Reporter)

Comment 13

13 years ago
Michael, testing binaries and buildtools are here.

http://oldskool.jp/mozilla64/
http://raven2000.hp.infoseek.co.jp/

Comment 14

13 years ago
(In reply to comment #13)
> Michael, testing binaries and buildtools are here.
> 
> http://oldskool.jp/mozilla64/
> http://raven2000.hp.infoseek.co.jp/

Thanks for the info. Someone else gave me the first link. I didn't realize that
there were already builds on Windows-XP 64-bit edition. Is this project more or
less done by one person or a group of people or people working independently?

My machine is in Indiana and should arrive tomorrow. Looking for some directions
on setting up dual-boot and will probably look at the Microsoft Newsgroup.

Updated

12 years ago
QA Contact: pschwartau → general
(Assignee)

Comment 15

12 years ago
Created attachment 201707 [details] [diff] [review]
dos2unix plus vertical space cleanup and merge conflict fixing

Thanks, r=me and I'll check this into the trunk now.

Bob, this should be linked to the JS1.6 release bug, for landing on the minibranch.  Thanks,

/be
Assignee: general → brendan
Status: NEW → ASSIGNED
Attachment #201707 - Flags: review+
(Assignee)

Updated

12 years ago
Keywords: js1.6
Priority: -- → P2
Target Milestone: --- → mozilla1.9alpha
(Assignee)

Comment 16

12 years ago
Fixed on trunk.

/be
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED

Comment 17

12 years ago
Comment on attachment 201707 [details] [diff] [review]
dos2unix plus vertical space cleanup and merge conflict fixing

Brendan:

In jscpucfg.h, we have:

>-#if defined(_WIN32) || defined(XP_OS2) || defined(WINCE)
>+#if defined(_WIN64)
>+
>+#if defined(_AMD64_)

I found that _AMD64_ is not a compiler predefined macro.
It is defined either by an application's build system or
by <windows.h>.  So it is better to change the last line to

 #if defined(_M_X64) || defined(_M_AMD64) || defined(_AMD64_)

where _M_X64 is the predefined macro in Visual C++ 2005 and
_M_AMD64 is the predefined macro in the compiler included
with Microsoft Platform SDK.
(Assignee)

Comment 18

12 years ago
Wan-Teh: thanks!  Updated per your comment.

/be
(Assignee)

Comment 19

12 years ago
Er, muffed a merge conflict resolution.  Fixed now, sorry.

/be
You need to log in before you can comment on or make changes to this bug.