91840 - Implement xptcall for 64bit sparc

Status: VERIFIED FIXED

(Core :: XPConnect, defect)

Description

[Roland Mainz]

A 64bit sparcv9 Mozilla (see bug 20860 for build instructions) crashes in
XPTC_InvokeByIndex().
Is it possible that 64bit sparcv9 isn't supported yet ?

Stack trace looks like this:
-- snip --
t@1 (l@1) signal BUS (invalid address alignment) in invoke_copy_to_stack at line
112 in file "xptcinvoke_sparc_solaris.cpp"
  112               *((void**)l_d) = l_s->ptr;
(/opt/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) where
current thread: t@1
=>[1] invoke_copy_to_stack(d = ???, paramCount = ???, s = ???) (optimized), at
0xffffffff7f12b504 (line ~112) in "xptcinvoke_sparc_solaris.cpp"
  [2] XPTC_InvokeByIndex(0x1002841e0, 0x9, 0x1, 0xffffffff7fffcbf0, 0x0, 0x0),
at 0xffffffff7f12d8a4
  [3] XPCWrappedNative::CallMethod(ccx = CLASS, mode = ???) (optimized), at
0xffffffff7bc7597c (line ~1880) in "xpcwrappednative.cpp"
  [4] XPCWrappedNative::GetAttribute(ccx = CLASS) (optimized), at
0xffffffff7bc843f0 (line ~1781) in "xpcprivate.h"
  [5] XPC_WN_GetterSetter(cx = ???, obj = ???, argc = ???, argv = ???, vp = ???)
(optimized), at 0xffffffff7bc83460 (line ~1285) in "xpcwrappednativejsops.cpp"
  [6] js_Invoke(cx = ???, argc = ???, flags = ???) (optimized), at
0xffffffff7f354d3c (line ~807) in "jsinterp.c"
  [7] js_InternalInvoke(cx = ???, obj = ???, fval = ???, flags = ???, argc =
???, argv = ???, rval = ???) (optimized), at 0xffffffff7f355028 (line ~896) in
"jsinterp.c"
  [8] js_GetProperty(cx = ???, obj = ???, id = ???, vp = ???) (optimized), at
0xffffffff7f372af0 (line ~2408) in "jsobj.c"
  [9] js_Interpret(cx = ???, result = ???) (optimized), at 0xffffffff7f35e95c
(line ~2531) in "jsinterp.c"
  [10] js_Execute(cx = ???, chain = ???, script = ???, down = ???, special =
???, result = ???) (optimized), at 0xffffffff7f35549c (line ~986) in
"jsinterp.c"
  [11] JS_ExecuteScript(cx = ???, obj = ???, script = ???, rval = ???)
(optimized), at 0xffffffff7f32c3cc (line ~3169) in "jsapi.c"
  [12] mozJSComponentLoader::GlobalForLocation(this = ???, aLocation = ???,
component = ???) (optimized), at 0xffffffff7ba0b4a4 (line ~1172) in
"mozJSComponentLoader.cpp"
  [13] mozJSComponentLoader::ModuleForLocation(this = ???, registryLocation =
???, component = ???) (optimized), at 0xffffffff7ba0aae0 (line ~988) in
"mozJSComponentLoader.cpp"
  [14] mozJSComponentLoader::AttemptRegistration(this = ???, component = ???,
deferred = ???) (optimized), at 0xffffffff7ba0a448 (line ~828) in
"mozJSComponentLoader.cpp"
  [15] mozJSComponentLoader::AutoRegisterComponent(this = ???, when = ???,
component = ???, registered = ???) (optimized), at 0xffffffff7ba0a13c (line
~758) in "mozJSComponentLoader.cpp"
  [16] mozJSComponentLoader::RegisterComponentsInDir(this = ???, when = ???, dir
= ???) (optimized), at 0xffffffff7ba09ab0 (line ~588) in
"mozJSComponentLoader.cpp"
  [17] mozJSComponentLoader::AutoRegisterComponents(this = ???, when = ???,
aDirectory = ???) (optimized), at 0xffffffff7ba09914 (line ~544) in
"mozJSComponentLoader.cpp"
  [18] AutoRegister_enumerate(key = ???, aData = ???, aClosure = ???)
(optimized), at 0xffffffff7f0da014 (line ~1956) in "nsComponentManager.cpp"
  [19] _hashEnumerate(he = ???, i = ???, arg = ???) (optimized), at
0xffffffff7f08c1c0 (line ~192) in "nsHashtable.cpp"
  [20] PL_HashTableEnumerateEntries(0x100139b90, 0xffffffff7f08c1ac,
0xffffffff7fffe4f0, 0x4, 0x1, 0x0), at 0xffffffff7ec02024
  [21] nsHashtable::Enumerate(this = ???, aEnumFunc = ???, closure = ???)
(optimized), at 0xffffffff7f08c8f0 (line ~360) in "nsHashtable.cpp"
  [22] nsSupportsHashtable::Enumerate(this = ???, aEnumFunc = ???, closure =
???) (optimized), at 0xffffffff7f0db7b0 (line ~159) in "nsHashtable.h"
  [23] nsComponentManagerImpl::AutoRegisterImpl(this = ???, when = ???,
inDirSpec = ???) (optimized), at 0xffffffff7f0da88c (line ~2093) in
"nsComponentManager.cpp"
  [24] nsComponentManagerImpl::AutoRegister(this = ???, when = ???, inDirSpec =
???) (optimized), at 0xffffffff7f0da100 (line ~1981) in "nsComponentManager.cpp"
  [25] nsComponentManager::AutoRegister(when = ???, directory = ???)
(optimized), at 0xffffffff7f0ea9e0 (line ~201) in "nsRepository.cpp"
  [26] NS_AutoregisterComponents() (optimized), at 0x100010348 (line ~92) in
"nsSetupRegistry.cpp"
  [27] NS_SetupRegistry_1(needAutoreg = ???) (optimized), at 0x100010470 (line
~123) in "nsSetupRegistry.cpp"
  [28] main1(argc = ???, argv = ???, nativeApp = ???) (optimized), at
0x100008238 (line ~1184) in "nsAppRunner.cpp"
  [29] main(argc = ???, argv = ???) (optimized), at 0x10000957c (line ~1490) in
"nsAppRunner.cpp"
-- snip --

Comment 1

[Roland Mainz]

Adding to 64bit/sparcv9-tracker bug...

Comment 2

[Edward Kandrot]

Reassigning to the default owner of the area in which this bug falls.

Comment 3

[Roland Mainz]

blizzard/rogerl:
Wanna take a look at this, please ?

Comment 4

[Phil Schwartau]

cc'ing cls, to see if he knows other good cc's for this -

Comment 5

[cls]

xptcall for 64-bit sparc has not been implemented.  See
http://lxr.mozilla.org/seamonkey/source/xpcom/reflect/xptcall/status.html . 
Having no xptcall experience at all, I'm going to offer that you might be able
to make a useable port by looking at the existing 32bit solaris port & the 64bit
osf1 port.  Adding shaver & jband for enlightenment.
  

Comment 6

[cls]

Pavlov and I spent some time working on this the past couple of days and the
initial version of the sparcv9 code has been checked into the tree. Floats still
aren't working but other than that, it seems to pass all of TestXPTCInvoke's tests.

http://lxr.mozilla.org/seamonkey/source/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_sparcv9_solaris.cpp
http://lxr.mozilla.org/seamonkey/source/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_asm_sparcv9_solaris_SUNW.s

Comment 7

[Stuart Parmenter]

reassigning to self.

Comment 8

[cls]

Attachment: Makefile change & additional TestXPTCInvoke tests

Comment 9

[Stuart Parmenter]

rogerl: can you sr= the code in the lxr files that cls posted earlier?

Comment 10

[rogerl (gone)]

To the best of my (limited) knowledge this looks plenty good. I don't know that
I'm qualified to give sr= ? but no problem with r=rogerl

Comment 11

[Stuart Parmenter]

brendan, waterson, can we get sr=?

Comment 12

[Brendan Eich [:brendan]]

rs=[e-mail], it can't hurt.

It seems int is 64 bits for sparcv9, at least with the compiler options you're
using.  Are there other type models (SGI called these ILP64, LP64, etc. for
which of Int, Long, and Pointer types were 64 bits rather than 32)?  Do we care
only about ILP64?  Just curious.

/be

Comment 13

[Brendan Eich [:brendan]]

Hmm, pav sez int is 32 bits (LP64, is long long also 64, or [shades of
MicroUnity!] 128 bits).  So the *(PRBool*)l_d = l_s->val.b assignment is picking
the lower-addressed 32-bit word in *l_d, i.e., the one at the address in l_d.
That says you don't need to copy both hi and lo float halves -- just do the one
at the lower address (called hi in the struct DU).

How'm I doing?

/be

Comment 14

[Brendan Eich [:brendan]]

Hey, fix the "propogate" misspellings (where-ever you find 'em) while you are in
this code.

/be

Comment 15

[Brendan Eich [:brendan]]

So pav showed me more sparc compliance definition doc, which suggests that
floats are right-justified in extended (64-bit) words within paramater arrays.
Therefore it seems to me the lo part of DU is the one that "counts", and hi is
ignored.  Now how'm I doing?

/be

Comment 16

[Stuart Parmenter]

I've changed the code for floats to get rid of the struct and to just do
*(((float*)l_d) + 1) = l_s->val.f instead of the struct stuff.
I added a comment on what we were doing there, as well as a few other comments
including one pointing people to http://www.sparc.com for the SCD should they
get overly confused :)

code enabled and new tests checked in.

Comment 17

[Phil Schwartau]

Marking Verified -