Re: [Vm-dev] How to think about cogit.c compile error that is    consistent in both gnu an cmake builds

gettimothy gettimothy at zoho.com
Thu Jul 31 17:56:45 UTC 2014


Thank you,



I am able to compile by modifying the cogit.h and cointerp.h to unconditionally set the NoDbgRegParms --so that confirms my theory.



The !defined(NoDbgRegParms) phrase allows someone to define an alternative on the command line via a -D argument, so it allows the
     # define NoDbgRegParms __attribute__ ((regparm (0)))
def to be a default, rather thna the only way.

 
ahhh...."ding! ding! ding!" goes the bell in my head...





PRODUCTION is defined in platforms/Cross/vm/sqAssert.h

I see it. -DNDEBUG toggles it , my problems with assert enabled builds probably lies in here....
#undef assert
# define __stringify(foo) #foo
# define __stringifyNum(n) __stringify(n)
#ifdef NDEBUG /* compatible with Mac OS X (FreeBSD) /usr/include/assert.h */
# define assert(expr) 0 /* hack disabling of asserts. Better in makefile? */
# define asserta(expr) (expr)
# define assertf(msg) 0
# define assertl(expr,line) 0
# define assertal(expr,line) (expr)
# define assertfl(msg,line) 0
# define PRODUCTION 1
#elif 1
# define assert(expr) ((expr)||(warning(#expr " " __stringifyNum(__LINE__)),0))
# define asserta(expr) ((expr)||(warning(#expr " " __stringifyNum(__LINE__)),0))
# define assertf(msg) (warning(#msg " " __stringifyNum(__LINE__)),0)
# define assertl(expr,line) ((expr)||(warningat(#expr,line),0))
# define assertal(expr,line) ((expr)||(warningat(#expr,line),0))
# define assertfl(msg,line) (warningat(#msg,line),0)
# define PRODUCTION 0
#endif


 



so, I have two/three more -D definitions to think through...-DNoDbgRegParms  -DNoDbgRegParms "something funky here"   -DNeverInline





Thanks your answer has given me the tools I need to think this through. .


cheers.


tty

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20140731/30247d6e/attachment-0001.htm


More information about the Vm-dev mailing list