Chris, These macros provide a very basic abstraction of the calling convention. All of the emit_callhelper_(I4|I8|R4|R8)* resolve to a emit_callhelper(helper, sizeof((I4|I8|R4|R8)*)). Here is an example:
#define emit_callhelper_I8I4 emit_callhelper_QD #define emit_callhelper_QD(helper) emit_callhelper(helper,3*sizeof(void*)) Profiling functions don't follow the same calling convention as the rest of the helpers. This is the reason for emit_callhelper_prof. Finally emit_callhelper_il does no stack management, if you use that helper you need to manage the stack manually. Thanks, Vladimir This posting is provided "AS IS" with no warranties, and confers no rights. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Tavares Sent: Thursday, May 22, 2003 12:15 AM To: DOTNET-SSCLI list; Rotor Mailing List Subject: RE: [Dotnet-sscli] Rotor 1.0 broke my JIT helper function Vladamir, Thanks for the suggestion - I put in the call to callInfo.reset and my access violation went away. I'm not convinced it's a real fix just because I don't really understand what's going on, but it's enough for me to move on, and I'm used to confusion. Thanks for the help. On a side note, I noticed several different versions of emit_callhelper. There's emit_callhelper_il, *_prof, *_I4I4I4, and a couple of others. What's the difference? -Chris > -----Original Message----- > From: Vladimir Fedorov [mailto:[EMAIL PROTECTED] > Sent: Friday, May 16, 2003 10:27 AM > To: Chris Tavares; DOTNET-SSCLI list; Rotor Mailing List > Subject: RE: [Dotnet-sscli] Rotor 1.0 broke my JIT helper function > > > Hi Chris, > > It is hard to say exactly without seeing the places from which this > helper is called, but my first guess would be - you are missing a call > to callInfo.reset() before emit_callhelper(....). The callInfo data > structure is used to correctly clean up the stack when some arguments > are enregistered. > > Here is the relevant code for x86: > > #define call_frame_size(args, enreg) (args - enreg) > > #define emit_callhelper(helper,argsize) > > { > > deregisterTOS; > > mov_constant(CALLREG, helper); > > .... > call_register(CALLREG); > > if ( ... call_frame_size(argsize,callInfo.EnregSize)) > { add_constant(SP, (call_frame_size(argsize, callInfo.EnregSize)) > );} > } > > If callInfo.EnregSize has a random value in it, you end up corrupting > the stack. > > This posting is provided "AS IS" with no warranties, and confers no > rights. > > Vladimir > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Chris Tavares > Sent: Thursday, May 15, 2003 8:52 PM > To: DOTNET-SSCLI list; Rotor Mailing List > Subject: [Dotnet-sscli] Rotor 1.0 broke my JIT helper function > > I defined a new Jit helper as the following (names have been changed to > protect the innocent): > > HCIMPL1( void, JIT_NewHelper, Object *obj ) > if( obj != 0 ) > { > } > HCIMPLEND > > (There was other stuff inside the if, but it doesn't matter for this > discussion.) > > This helper function is called from the Jitter in various places like > this: > > void *newHelper = jitInfo->getHelperFtn(CORINFO_HELP_NEWHELPER, > NULL); > emit_DUP_PTR(); > emit_callhelper(newHelper, sizeof(void *)); > > emit_DUP_PTR is just the following: > > #ifndef emit_DUP_PTR > #define emit_DUP_PTR() \ > emit_WIN32(emit_DUP_I4()) \ > emit_WIN64(emit_DUP_I8()) > #endif // emit_DUP_PTR > > I used the separate macro since it is more descriptive this way. The > stack > currently has an object pointer on the top. > > Anyway, the code I have above worked fine in the beta Rotor drop. After > several months away, I took my work and put it into the 1.0 release. Now > I > get an access violation triggered in class.cpp, line 9778, at a call to > CallDescrWorkerInternal. > > Has something changed with worker function stack setup, or do I have > some > other problem? This code did work just fine in the beta. > > Thanks for any help you can provide, > > -Chris > > _______________________________________________ > Dotnet-sscli mailing list > [EMAIL PROTECTED] > http://mailserver.di.unipi.it/mailman/listinfo/dotnet-sscli _______________________________________________ Dotnet-sscli mailing list [EMAIL PROTECTED] http://mailserver.di.unipi.it/mailman/listinfo/dotnet-sscli
