229554 - XPTCall, rewritten/cleaned up for GCC platforms, using GCC extension __builtin_apply

Status: RESOLVED INCOMPLETE

(Core :: XPCOM, enhancement)

Description

[Low Zhen Lin]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031018 Firebird/0.7
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031018 Firebird/0.7

GCC has an extension for constructed calls. The URL provided is a link to the
reference page.

It vastly simplifies calling arbritrary functions with arbritrary arguments
without knowing the size of the return value or the type of return value.

This extension is present at least from GCC-2.9.5 onwards.

I have confirmed it exists, and works, for GCC 3.2 for i686-pc-linux-gnu and GCC
3.3 for powerpc-apple-darwin6.8

I will attach sample code in C.

Note that the code for extracting the vtable entries is still needed.

Reproducible: Always

Steps to Reproduce:

Comment 1

[Low Zhen Lin]

Attachment: C code demonstrating GCC extension __builtin_apply

Comment 2

[Benjamin Smedberg]

are you gonna write the patch?

Comment 3

[Low Zhen Lin]

No, I don't understand the gobbledegook going on in the md/ directories... I can
get the gist of it though. 

Apologies for the misleading summary.

Comment 4

[tenthumbs]

I tried this at one point but it's not all that useful. You need to compute 
the space needed for __builtin_apply which we already do. For 
XPTC_InvokeByIndex you also need to attach 'this' (called 'that' in the code) 
to the rest of the arguments, which __builtin_apply does _not_ do.

It's a nice idea but it's not better. I wish it were, it would be _so_ much 
simpler.

Comment 5

[Low Zhen Lin]

It is not neccessary to compute the amount of stack space needed. My sample code
just delivers 640 bytes of arguments - 10 long longs, or 20 words.

Attaching 'this'... Yes, that is a problem, especially since it seems that
'that' != 'this'. In theory... You could swap this for 'that', by rewriting the
preamble code and postamble code. But... It appears that XPTC_InvokeByIndex is a
C function, so 'that' is in the correct location: in GCC, 'this' is leftmost,
therefore on x86, pushed last. 

I have written some code that ought to work for C++ proxying, but for some
reason, it doesn't translate to assembly correctly. (__builtin_apply_args tries
to copy the original arguments to the new set, but offset by 2 positions, so old
argument 1 becomes new argument 3, etc.) 

Comment 6

[Low Zhen Lin]

Attachment: Source code for C++ Call Proxying

I have tested this on powerpc-apple-darwin6.8, GCC 3.3 20030304 (Apple
Computer, Inc. build 1493) -- it works;

It however fails on i686-pc-linux-gnu, GCC 3.2.3 20030422 (Gentoo Linux 1.4
3.2.3-r3, propolice)... Must be a bug in my GCC build. Gr.

Comment 7

[Low Zhen Lin]

Tested my code on another machine (i686) with a different build of GCC (same
version) - still same bug persists.

This patch fixes the rouge instruction...

--- main.s~     2003-12-29 00:26:01.890421279 +0800
+++ main.s      2003-12-29 00:26:16.367272113 +0800
@@ -95,7 +95,7 @@
        movl    (%eax), %ecx
        movl    %esp, %esi
        subl    $32, %esp
-       leal    8(%esp), %edx
+       movl    %esp, %edx
        movl    (%ecx), %eax
        movl    %eax, (%edx)
        movl    4(%ecx), %eax

Comment 8

[Low Zhen Lin]

I've found the problem for compiling the C++ Call Proxy on x86 -- anything
greater than -march=i586 seems to break gcc-3.2.3 and gcc-3.3.2.

Compiling with -march=i586 builds a functioning C++ Call Proxy.

Comment 9

[Low Zhen Lin]

Attachment: Minor corrections to fix bug when optimising at higher levels

It is a bug in GCC, fixed in CVS:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12210

More testing shows that it does not break on -march=i686 or greater only when
optimisation level is -O3. It completely breaks down at -Os for any -march.

Specifically, using '-finline-functions' in addition to -O1 or -O2 produces
correct code; in addition to -O0 or -Os produces wrong code. Curiously, using
the flags equivalent to -O1 plus -finline-functions generates different code
from -O1.

Comment 10

[Mike Shaver (:shaver emeritus)]

I think this should probably wait until there's a released version of gcc with
the fix for that; we have enough trouble with gentoo and other aggressive
optimizers as it is.

Comment 11

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 12

[Benjamin Smedberg]

Still theoretically worth considering.

Comment 13

[Benjamin Smedberg]

Enh, I was wrong in 2005. Let's stick with what already works.