Closed Bug 10060 Opened 20 years ago Closed 20 years ago

xptcall doesnt work on solaris 7 (sunos 5.7) 64bit

Categories

(Core :: XPConnect, defect, P3)

Sun
Solaris
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: tomi.leppikangas, Assigned: margaret.chan)

Details

Attachments

(1 file)

xptcall test abort when run on sunos 5.7 in 64bit mode. Builded with
native compiler.

Machine info:
> isainfo -v
64-bit sparcv9 applications
32-bit sparc applications
> uname -a
SunOS sun4 5.7 Generic_106541-04 sun4u sparc SUNW,Ultra-Enterprise
> /opt/SUNWspro/bin/cc -V
cc: WorkShop Compilers 5.0 98/12/15 C 5.0


Output from TestXPTCInvoke:
./TestXPTCInvoke
calling direct:
        1 + 1 = 2
        1L + 1L = 2
        2 * 2 = 4
        2L * 2L = 4
        1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 = 55.000000
        1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 = 55.000000f
calling via invoke:
        1 + 1 = 0
Pure virtual function calledAbort
Assignee: jband → rogerl
rogerl is working on this
Status: NEW → ASSIGNED
How can I get access to this machine to test stuff?
Cant get access to our machine, but i think there is Solaris 7/64bit
machine at netscape too. Ask from Chris McAfee <mcafee@netscape.com>
or Wan-Teh Chang <wtc@netscape.com>, they were testing some nspr
stuff with Solaris 7
Looks like this fixes both TestXPTCInvoke and apprunner's sidebar on Solaris 7.
If it works for other versions too, put it to tree and mark this fixed.
I need to figure out how to switch between this and the GCC vtable layout at
Mozilla build time.
Sigh, well I put it to the tree and it broke the 4.2 SUNW builds. Matthias at
Sun reckons he knows how to get the 5.0 workshop to produce 4.2 & GCC compatible
vtables, I'm waiting for details.
Target Milestone: M13 → M14
Not going to make M13 for these.
Punt.
Target Milestone: M14 → M15
Moving all XPConnect QA contact to rginda
QA Contact: cbegle → rginda
Matthias has left Sun.  My understanding is that the -compat=4 option for WS5.0
will produce 4.2 compatible vtables.  Reading from the comments,
I saw that rogerl wanted to switch the vtable layout at build time.  If the 
above option is not specified, perhaps, bug 20297 (fixed by tor) might have
this vtable switching problem resolved.
Per Clayton, bulk moving Solaris bugs to Sun.
Assignee: rogerl → drapeau
Status: ASSIGNED → NEW
Re-assinging to Margaret Chan, working on Solaris port of Netscape 6.
Assignee: drapeau → mtchan
I am trying to reproduce this bug from my build with the M14 source, I am not
able to reproduce the problem.  I am running it on 5.7.  Below is the 
configuration of my machine and the result of the run:

% isainfo -v
64-bit sparcv9 applications
32-bit sparc applications

Output from TestXPTCInvoke:

calling direct:
        1 + 1 = 2
        1L + 1L = 2
        2 * 2 = 4
        2L * 2L = 4
        1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 = 55.000000
        1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 = 55.000000f
calling via invoke:
        1 + 1 = 2
        1L + 1L = 2
        2 * 2 = 4
        2L * 2L = 4
        1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 = 55.000000
        1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 = 55.000000f

impl == 2d5e8
foo  == 2d5e8
bar  == 2d5f8
Calling Foo...
direct calls:
        FooImpl::FooMethod1 called with i == 1, FooImpl part of a FooBarImpl
        FooImpl::FooMethod2 called with i == 2, FooImpl part of a FooBarImpl
invoke calls:
        FooImpl::FooMethod1 called with i == 1, FooImpl part of a FooBarImpl
        FooImpl::FooMethod2 called with i == 2, FooImpl part of a FooBarImpl

Calling Bar...
direct calls:
        BarImpl::BarMethod1 called with i == 1, BarImpl part of a FooBarImpl
        BarImpl::BarMethod2 called with i == 2, BarImpl part of a FooBarImpl
invoke calls:
        BarImpl::BarMethod1 called with i == 1, BarImpl part of a FooBarImpl
        BarImpl::BarMethod2 called with i == 2, BarImpl part of a FooBarImpl


impl == 28ca0
foo  == 28ca0
bar  == 28ca4
Calling Foo...
direct calls:
        FooBarImpl2::FooMethod1 called with i == 1, local value = 12345678
        FooBarImpl2::FooMethod2 called with i == 2, local value = 12345678
invoke calls:
        FooBarImpl2::FooMethod1 called with i == 1, local value = 12345678
        FooBarImpl2::FooMethod2 called with i == 2, local value = 12345678

Calling Bar...
direct calls:
        FooBarImpl2::BarMethod1 called with i == 1, local value = 12345678
        FooBarImpl2::BarMethod2 called with i == 2, local value = 12345678
invoke calls:
        FooBarImpl2::BarMethod1 called with i == 1, local value = 12345678
        FooBarImpl2::BarMethod2 called with i == 2, local value = 12345678

My machine supports 64bit, but my build is not a 64bit build.  When you say
that running in 64bit mode, are you referring to running the 32bit build 
mozilla on a 64bit machine?  Are you still seeing this problem?  If so, 
I need some more information from you to reproduce the problem.  Thanks.
Ok, now it works. I tested with 4.2 and 5.0 compilers. Dont
know when this is fixed.. Maybe when bug 20297 fixed.

I mark this fixed.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Thanks for the testing.  Maybe 20297 or some other checkin fixes it.  It has
been a while anyway.
You need to log in before you can comment on or make changes to this bug.