23297 - [LinuxPPC]fix XPTCall glue

Status: RESOLVED FIXED

(Core :: XPConnect, defect, P3)

Description

[Chris Waterson]

Land code to fix XPTCall (mostly) for Linux/PPC.

Comment 1

[Chris Waterson]

Attachment: "cleaned up" version of [e-mail]'s patch

Comment 2

[Chris Waterson]

beard: could you review the attached patch? in general, the C++ routines have
been cleaned up, and the assembly comments are much better. I'm still having
trouble getting past the ArgumentFormatter test in TextXPC, and assume that this
may be a cause of crashes trying to use mailnews (IMAP slams the proxy code,
IIRC). Anyway, this stuff is definitely a step in the right direction.

Comment 3

[Chris Waterson]

heh, remind me to remove the printfs() before applying the patch ;-).

Comment 4

[Chris Waterson]

Per Franz Sirl's suggestion, I'm going to revert the STUB_ENTRY stuff to
Franz's original patch, which uses the mangled name. Franz made the excellent
point that, although name mangling changes may occur, they will be compile-time
errors, where register scheduling changes (which may stomp our use of r12) are
only detectable at run-time.

Comment 5

[Chris Waterson]

checked in. i'll call myself the reviewer and Franz the submitter. Or vice
versa. beard: lemme know if you've got problems with any of the stuff in there...

Comment 6

[Greg Noel, Unix Guru]

I'm re-opening this because it looks like these changes are implicated in the

missing in-line images.



I've been running Franz Sirl's patches (prior to them being "cleaned up") for

several weeks now.  I have had no problem with in-line images (other than the

generic image problems I've reported).



Earlier in the week, someone (waterson?) reported they were trying the new code

and didn't see any in-line images.  I did a build later the same day and saw them

just fine.



Yesterday, the new XPCOM code went in.  Today I do not see any in-line images.



I do not know how or why a change in the XPCOM code could cause this kind of

problem, but my suspicion immediately falls on the parameter-munging code.  If

the parameters aren't being transcribed correctly, there could be all kinds of

subtle problems.

Comment 7

[Chris Waterson]

greg: do you have a test page that I could go to? most inline images are fine
for me, modulo moderate corruption here and there. The problem i'm having seems
to be more with local images loaded off the hard drive (e.g., back and forward
buttons on the chrome aren't displaying correctly), and my guess is that it has
something to do with the endianness of the codec or something.

also, could you verify that the change did -in fact- cause the problem? you can
do this by reverting the mozilla/xpcom/reflect/xptcall/src/md/unix directory
(e.g., "cvs up -D 'Mon Jan 3 12:00:00 PST 2000'", and then re-applying franz's
original patches he posted in n.p.m.xpcom.

thanks. I'd do this myself, but, I'm not seeing the problem. also, let's file a
new bug for this.

Comment 8

[Chris Waterson]

add [e-mail] to cc list: greg, see above...