"solved" [Vm-dev] Adding -DNoDbgRegParms problem

gettimothy gettimothy at zoho.com
Sat Nov 22 18:21:16 UTC 2014


I should have proof-read before sending. Please excuse the sloppy english and structure, I think the explanation is clear despite my mangling of it.

---- On Sat, 22 Nov 2014 10:14:25 -0800 gettimothy<gettimothy at zoho.com> wrote ---- 

 Hi all.





In Cog/src/vm/cogit.c in moving the #include "dispdbg.h" above the #include "cointerp.h" and #include "cogit.h" like so:




#include <stddef.h>
#include "sq.h"
#include "sqCogStackAlignment.h"
#include "cogmethod.h"
#include "dispdbg.h"
#if COGMTVM
#include "cointerpmt.h"
#else
#include "cointerp.h"
#endif
#include "cogit.h"
 

appears to solve the problem. 


My initial thinking is a so.


dispdg.h brings in sqAssert.h which defines PRODUCTION as 1 or 0 depending on CFLAGS passed in.


With dispbdg.h included after cogit.h, PRODUCTION  was not defined and the tests in cogit.h



#if !PRODUCTION && defined(__GNUC__) && !defined(NoDbgRegParms)
# define NoDbgRegParms __attribute__ ((regparm (0)))
#endif

#if !defined(NoDbgRegParms)
# define NoDbgRegParms /*empty*/
#endif
 


My conjecture is as follows (I am NOT fluent in the semantics of cpp, just a script kiddy who bit the bullet and rtfm this week (: ).


In the ....../build/vm/Makefile, $(interp)?.o is generated prior to cogit.o.
gcc3x-cointerp.c includes sqAssert.h via dispdg.h prior to the cogit.h and cointerp.h included.
This PRODUCTION is set 0 or 1 and NoDbgRegParms is defined one way or the other.
cpp then pre-processes cogit.h. 
At this point, I lose track of the semantics, but I deduce that NoDbgRegParms IS defined from the gcc3x-cointerp.c parse so NoDbgRegParms is left as is in the cogit.c file.
This was the bug I was tracking down.


I leave it to the more experienced to judge the correctness of the forensics.


cheers.


tty.
















-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20141122/8abeb38e/attachment.htm


More information about the Vm-dev mailing list