From owner-freebsd-alpha Tue Sep 10 13:38: 6 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A44637B400 for ; Tue, 10 Sep 2002 13:38:00 -0700 (PDT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 251B643E8A for ; Tue, 10 Sep 2002 13:37:59 -0700 (PDT) (envelope-from ticso@cicely5.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) by srv1.cosmo-project.de (8.12.5/8.12.5) with ESMTP id g8AKbq6K038698 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 10 Sep 2002 22:37:54 +0200 (CEST) (envelope-from ticso@cicely5.cicely.de) Received: from cicely5.cicely.de (localhost [IPv6:::1]) by cicely5.cicely.de (8.12.6/8.12.6) with ESMTP id g8AKbogl002636 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 10 Sep 2002 22:37:50 +0200 (CEST) (envelope-from ticso@cicely5.cicely.de) Received: (from ticso@localhost) by cicely5.cicely.de (8.12.6/8.12.6/Submit) id g8AKbmqC002635; Tue, 10 Sep 2002 22:37:48 +0200 (CEST) (envelope-from ticso) Date: Tue, 10 Sep 2002 22:37:47 +0200 From: Bernd Walter To: Andrew Gallatin , Fred Clift Cc: ticso@cicely.de, Joe Marcus Clarke , alpha@FreeBSD.ORG Subject: Re: getting closer (was Re: mozilla failure on 4.6.2) Message-ID: <20020910203747.GE399@cicely5.cicely.de> Reply-To: ticso@cicely.de References: <15737.2550.488154.4401@grasshopper.cs.duke.edu> <20020907000825.GA4091@dragon.nuxi.com> <15739.43883.152090.936327@grasshopper.cs.duke.edu> <15741.2822.526047.253409@grasshopper.cs.duke.edu> <1031605410.351.90.camel@gyros.marcuscom.com> <15741.17468.701009.998323@grasshopper.cs.duke.edu> <1031635953.342.133.camel@gyros.marcuscom.com> <15741.61382.872535.426732@grasshopper.cs.duke.edu> <20020910140414.GC5057@cicely5.cicely.de> <15742.812.130498.758611@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020910112155.E32234-100000@vespa.dmz.orem.verio.net> <15742.812.130498.758611@grasshopper.cs.duke.edu> X-Operating-System: FreeBSD cicely5.cicely.de 5.0-CURRENT i386 User-Agent: Mutt/1.5.1i Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Sep 10, 2002 at 10:35:24AM -0400, Andrew Gallatin wrote: > > Bernd Walter writes: > > On Tue, Sep 10, 2002 at 09:12:38AM -0400, Andrew Gallatin wrote: > > > > > > Joe Marcus Clarke writes: > > > > Add 8 to the stack pointer ("this", right), and store it in $16. > > > > > > I wish it were that simple :-( > > > > > > The problem seems to be that the application code is passing the > > > "wrong" value in and somehow the c++ calling standard corrects it, and > > > we must correct it too: > > > > > > impl == 0x12001c080 > > > foo == 0x12001c080 > > > bar == 0x12001c088 > > > > I have no idea how the class declaration for you example looks like. > > http://lxr.mozilla.org/seamonkey/source/xpcom/reflect/xptcall/tests/TestXPTCInvoke.cpp > > > Possible because I don't know the mozilla code you are talking about. > > What is the difference in direct and invoke calling? > > "direct" is a normal c++ call: bar->BarMethod1(1); > > > "invoke" means the mozilla xptinvoke shims: > > var[0].val.i32 = 1; > var[0].type = nsXPTType::T_I32; > var[0].flags = 0; > XPTC_InvokeByIndex(bar, 3, 1, var); > > > They are described at: > http://www.mozilla.org/scriptable/xptcall-faq.html OK - I see. Well that's evil - I had wished they would at least print a clear warning so everyone would know that specific platform support is missing instead of just producing nameless build errors. > > Lets asume foo is a virtual function of class x which is based on > > class y defining the virtual function bar. > > >From what I know about C++ (which might be outdated) we have the > > following situation when using an object of class x. > > Call of function bar means the caller knows the offset to the function > > pointer, because it's using a pointer of type x. > > The function bar expects a this pointer of type y so it gets the > > this pointer of the embedded y object which may be numericaly different. > > > > Now asume class x reimplement the virtual function bar. > > The newly bar function has to share the calling conventions that were > > declared by class y. > > If we call function bar using a type y pointer we submit a this pointer > > of type y. > > But the function is designed to have a this pointer of type x. > > Now the function must recalculate the supplied y pointer into an x > > pointer. > > If we call funtcion bar using a type x pointer we still have to convert > > the x pointer into an y pointer because the function still expects an y > > pointer. > > I assume this is all done "behind the scenes" by the compiler? Normaly yes. In that case they do it theirself. > Is there a convention for where the conversions are passed? No clue - I'm just a c++ user - not a compiler writer... My knowledge about vtables is just basic to understand how virtual functions could influence performance. On Tue, Sep 10, 2002 at 11:24:04AM -0600, Fred Clift wrote: > On Tue, 10 Sep 2002, Andrew Gallatin wrote: > > > > > Since you know quite a bit about c++, and because you know alpha asm, > > I'd _really_ like your help ;) Do you have an alpha running > > -stable? Or are you all -current these days? > > My knowlege of both c++ and alpha asm is very lacking, but, I have a PWS > 433au running a fairly recent -stable (jul 20 - I could upgrade) on that I > could be pursuaded to set up a useraccount or 3 on if it would help with > this problem. Fred - thank you for that offer but I have access to a stable alpha. cvsup.de.freebsd.org is my machine and is running stable from 31th jul. My home alphas are both running -current. I can boot stable on my NoName - but compiling mozilla - better not... My problem is mostly time. E.g. I recently added an USB controller to my NoName and I promissed Jonathan Mini alpha MD part for his KSE work. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message