As mentioned in a previous mail, the following notes still apply: 1) Linux/x86-64 specific fow now. 2) Gcc complained about the cast in accessible/src/base/nsAccessible.cpp (nsAccessible::GetAccId). I believe all 64-bit platforms complain about it? The patch contains a workaround for it but I am not sure it's sane. 3) The check for ix86 architecture in Makefiles needs to be preceded with a check for x86-64 architecture because ifeq (86,$(findstring 86,$(OS_TEST))) would match x86-64 as well. 4) The other hunks than xptcall are derived from previous ports (i386, IA-64).

Add more xptcall tests from Franz Sirl (#142594) + add new MixedFloats test.

confirming for consideration

When making diffs, you should use cvs diff -u. Your diff appears to have some binary information and/or control characters at the top.

-> xpconnect

Cleanly repost xptcall tests. Sorry to have used bogus MSIE/MacOS X...

Repost and update to use real architecture name.

Comment on attachment 95608 [details] [diff] [review] xptcall machinery + nsprpub (nsprpub and security portions checked in) #else /* __alpha */ should be #else /* __alpha || __x86_64__ */

NS_IMETHODIMP nsAccessible::GetAccId(PRInt32 *aAccId) { - *aAccId = - NS_REINTERPRET_CAST(PRInt32, (mDOMNode.get())); + *aAccId = - (PRInt32) NS_REINTERPRET_CAST(PRUptrdiff, (mDOMNode.get())); return NS_OK; } This makes me a little queezy. I'm not up on nsAccessible usage. I gather what's trying to be done here is provide some kind of unique ID. What makes me a little uneasy is that if the 64 bit CPU decided to use a segmented scheme for memory allocation, making the top 32 bits the selector, the lower 32 bits may not always be that unique. I honestly don't know what memory models x86 64 bit systems use. If it's flat then this is probably pretty safe till we pass the 4 gig memory boundary. And I assume that once this pointer is converted to an integer and returned it is never converted back.

Does anyone want to speculate on whether my concern is valid or not?

Gentelmen, place your bets. 8^) Sorry for spam.

David, Microsoft Active Accessibility is not available for 64 bit architectures, and I'm not sure it will ever be -- it might be superceded by Microsoft's newer API for Longhorn. I don't know about Sun's ATK Unix accessibility, and their plans for 64 bit archictectures. When we wrote that 32 bit-specific code we decided to deal with the 64 bit issues later.

ccing Bill who is the architect of ATK. Bill, is ATK 64-bit compliant? Or do we have any plan to port it on 64-bit architecture?

Aaron Leventhal wrote: > When we wrote that 32 bit-specific code we decided to deal with the 64 bit > issues later. What about other 64bit architectures like Power/SPARCv9/Alpha - does the accessibility code work on these platforms ?

MSAA doesn't, but we're waiting for an answer from Bill Haneman to tell us if ATK does.

That portion of the patch was already committed to CVS with the checkin for Bug 177906. We have not yet tested accessibility support in 64-bit on AIX, and so we went ahead and went with a patch which would at least let us complete a 64- bit build. I am fairly certain that the code as it is currently written will not work correctly on 64-bit builds.

Moving out

i think AMD has changed the the hammer architecture name as "AMD64" and instruction set name as "AMD64 ISA" . x86-64 will not be used AFAIK. Maybe summary should be changed like "AMD64 (x86-64)" http://www.amd.com/us-en/Processors/TechnicalResources/0,,30_182_861_1024,00.html

Moving out

We have noticed that the 1.4.x amd 1.5 downloads from mozilla.org intermittently hang using SLES 8 on AMD64 when running in 32bit mode. It looks like a memory leak but I'm trying to get some diagnostics from a machine that only barely responds to a ping

I believe that you should port nsprpub/lib/ds/, too. Because this code uese 32bit pointers. But AMD64 has 64bits pointer. (PRUword isn't 64bits, and etc) A patch that I attached to Bug #225859 is consided this. I think that NSPR issue should be split to be simple of this bug.

Moving out

Re Previous SLES 32bit hangs comment, this was due to a microstar AMI bios bug.This is now fixed on my machine (bios date 07/04/03)

Adding a dependency. I just filed bug 232742, which deals with making mozilla build in amd64 bit mode under gentoo linux. In order to get it to build I simply re-applyed the gentoo amd64 patch that they have in portage, onto my cvs pulled tree. I have successfully build both the suite and firebird. Also requesting that this blocks 1.7, since it blocks building and testing of the applications.

We're not going to hold the 1.7a release because porting fixes aren't in. Trying to get porting fixes in is a good thing, but blocking flags aren't the way to do it.

Please Release a 64-bit version of Firefox for windows xp-64 bit edition and linix 64-bit versions

An x86-64 Windows (XP beta, 2003 beta, Longhorn preview) version would be nice as well.

If there is a an AMD64/Linux64 64 bit binary where can it be obtained from? If not, when is a potential release date? Thanks to the Mozilla team!

Hmm, seems that the comment posted through bugzilla-daemon@ a few months ago didn't pass. On Sat, 15 Nov 2003 bugzilla-daemon@mozilla.org wrote: > I believe that you should port nsprpub/lib/ds/, too. Because this code > uese 32bit pointers. But AMD64 has 64bits pointer. (PRUword isn't > 64bits, and etc) There is another part too, especially for NS4-type plugins support. e.g. mozplugger but I already fixed the latter (which includes its own set of nsapi.h et al.). Sadly, sounds like current practise is to duplicate moz headers for 3rdparty nsplugins. i.e. even if we fix Mozilla, other plugins have to be audited.

Concerning #29, major Linux/AMD64 distributions already provide binary packages. That could already help for testing.

gbeauchesne@mandrakesoft.com: bugzilla.mozilla.org does not support adding comments by replying to the daemon. i'm sorry that it's not currently bouncing such mails.

Dan Star wrote: > If there is a an AMD64/Linux64 64 bit binary where can it be obtained from? > If not, when is a potential release date? I suggest to ask drivers@mozilla.org AMD64 support for mozilla is available since more than a year but noone cares to integrate the patches into mozilla.

Roland, since I have seen patches in the last few months to make Mozilla compile in an LLP64 type model (one where long is not big enough to hold a pointer), I do not believe your assertion that AMD64 support has been available for a year. Stop exagerrating, please. Drivers will help get patches in as needed, but module owners are the first stop in shopping patches around. Which module owners are not responding? Please cite bugs that have properly attached patches with review flags set. /be

(In reply to comment #34) > Drivers will help get patches in as needed, but module owners are the first stop > in shopping patches around. Which module owners are not responding? Please > cite bugs that have properly attached patches with review flags set. I really don't like pointing fingers but patches have been available for quite some time. luckily now it seems to be moving along albeit a bit slow. check out bug 232742 which i submitted a week after getting my new amd64 machine. I did not make this patch, it was included in the gentoo install. as far as i can read from these lines in the patch then the patch is way old.. +++ mozilla/xpcom/reflect/xptcall/src/md/unix/xptcstubs_x86_64_linux.cpp 2003-09-27 16:20:55.106321952 -0400 +++ mozilla/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_x86_64_linux.cpp 2003-09-27 16:20:55.105322104 -0400 (this is roughly 5 month) I don't know what has occured these five month since I was now involved in the whole timeframe, so I don't know if it is the gentoo people being sloppy and not submitting the patch, or they got it from someone else, or if mozilla devs gave it the cold shoulder..

Bug 232742 has comments from wtc, from whom review was requested; also an unsolicited review from jshin. These comments were prompt responses in the second week of February 2004 to Roland's setting of request-tracker flags; these comments have not been addressed yet. It takes two to keep a patch under review alive. Any other patches starving? Mail me if you prefer. David, sorry to clutter your bug a bit here. /be

brendan@mozilla.org wrote: > Stop exagerrating, please. I am not exagerrating. The AMD64 support was working a year ago since I've seen a working prototype on CeBIT 2003 (that build passed the i18n bowser buster without problems). The patches were likely contributed little bit later, but IMHO mozilla.org is very slow in adopting such stuff (that's not only my own observation).

Concerning #34, I initially wrote the Mozilla/amd64 bridges code in 2002/08, which BTW is an extension to the C version available in the Kaffe JVM produced at around the same time. As initially reported, remaining 64-bit stuff was derived from the ia64 port. I have not received bug reports from users since, apart one with occasional freezes but that was not Mozilla related, rather kernel^Wbroken BIOSes. As AMD64 is not the first 64-bit platform where Mozilla runs, I think remaining bits to be addressed are reported in #22 and #30, or do you know other locations?

Comment on attachment 95608 [details] [diff] [review] xptcall machinery + nsprpub (nsprpub and security portions checked in) The nsprpub and security changes in this patch have already been checked in (bug 232742).

For someone that asked, I believe AMD64 uses a flat memory model.

Anyone closes this bug, please. Because xpcall code is already checked in. RCS file: /cvsroot/mozilla/xpcom/reflect/xptcall/src/md/unix/xptcstubs_x86_64_linux.cpp,v Working file: xptcstubs_x86_64_linux.cpp head: 1.1 branch: locks: strict access list: symbolic names: THUNDERBIRD_0_6_BRANCH: 1.1.2.1.0.2 THUNDERBIRD_0_6_BASE: 1.1.2.1 MOZILLA_1_7_BRANCH: 1.1.0.2 keyword substitution: kv total revisions: 2; selected revisions: 2 description: ---------------------------- revision 1.1 date: 2004/04/20 21:38:14; author: jst%mozilla.jstenback.com; state: Exp; branches: 1.1.2; Fixing bug 232742 (patch by mozilla@rosenauer.org). Make Mozilla build and run on Linux/x86-64. r+sr=darin@meer.net, jst@mozilla.jstenback.com ---------------------------- revision 1.1.2.1 date: 2004/04/22 20:50:05; author: jst%mozilla.jstenback.com; state: Exp; lines: +0 -0 Fixing bug 232742. Making Mozilla build on Linux/x86-64. Patch by mozilla@rosenauer.org. r=jst@mozilla.jstenback.com, sr=darin@meer.net, a=brendan@mozilla.org =============================================================================

Makoto Kato wrote: > Anyone closes this bug, please. Can you please confirm that Mozilla starts and works on Linux/AMD-64 ?

Roland, this bug is moved to Bug 232742.

Makoto Kato wrote: > Roland, this bug is moved to Bug 232742. I know that someof the work happened in bug 232742... but the the dependicy bug 225859 is still open. Is that bug still valid ?

(In reply to comment #44) > Makoto Kato wrote: > > Roland, this bug is moved to Bug 232742. > > I know that someof the work happened in bug 232742... but the the dependicy bug > 225859 is still open. Is that bug still valid ? Invaild. I removed it

Makoto Kato wrote: > > Makoto Kato wrote: > > > Roland, this bug is moved to Bug 232742. > > > > I know that someof the work happened in bug 232742... but the the dependicy > > bug > 225859 is still open. Is that bug still valid ? > > Invaild. I removed it OK... I'll mark this bug as FIXED then.