Smalltalk › Squeak › Squeak VM

How to think about cogit.c compile error that is consistent in both gnu an cmake builds

‹ Previous Topic Next Topic ›
 
classic Classic list List threaded Threaded
♦
♦
 11 messages Options
tty
Reply | Threaded
Open this post in threaded view
♦
♦
|

How to think about cogit.c compile error that is consistent in both gnu an cmake builds

tty
 
Hi all




After doing that my previously successfull  cmake build bit the dust.

As a sanity check, I then attempted a  mvm build in  build.linux32x86/squeak.cog.v3/build/mvm and this bombed out. 

The same mvm build on an older source tree works fine. 

For the c build, it gripes a lot about a lot of 'x' is used but never defined  and ends with:

/../oscogvm/src/vm/cogit.c:1094:14: warning: 'oopisLessThan' used but never defined [enabled by default]
static sqInt oopisLessThan(sqInt anOop, sqInt otherOop) NoDbgRegParms;
^
make[1]: *** [cogit.o] Error 1
make: *** [vm/vm.a] Error 2

My cmake build (which was working prior to my svn CO of the latest) started complaining along similar lines:


 /..../oscogvm/src/vm/cogit.c:21286:1: error: conflicting types for 'oopisLessThan'
oopisLessThan(sqInt anOop, sqInt otherOop)
^
/.../oscogvm/src/vm/cogit.c:1094:14: note: previous declaration of 'oopisLessThan' was here
static sqInt oopisLessThan(sqInt anOop, sqInt otherOop) NoDbgRegParms;
^
make[2]: *** [CMakeFiles/cog.dir/home/wm/usr/src/smalltalk/CMake.oscog/cogVMMaker/Contents/Resources/oscogvm/src/vm/cogit.c.o] Error 1
make[1]: *** [CMakeFiles/cog.dir/all] Error 2
make: *** [all] Error 2

Any pointers on how to think about this are appreciated.

cheers.

tty


thx.

tty
Eliot Miranda-2
Reply | Threaded
Open this post in threaded view
♦
♦
|

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

Eliot Miranda-2
 



On Sat, Jul 19, 2014 at 1:18 PM, gettimothy <[hidden email]> wrote:
 
Hi all




After doing that my previously successfull  cmake build bit the dust.

As a sanity check, I then attempted a  mvm build in  build.linux32x86/squeak.cog.v3/build/mvm and this bombed out. 

The same mvm build on an older source tree works fine. 

For the c build, it gripes a lot about a lot of 'x' is used but never defined  and ends with:

/../oscogvm/src/vm/cogit.c:1094:14: warning: 'oopisLessThan' used but never defined [enabled by default]
static sqInt oopisLessThan(sqInt anOop, sqInt otherOop) NoDbgRegParms;
^
make[1]: *** [cogit.o] Error 1
make: *** [vm/vm.a] Error 2

My cmake build (which was working prior to my svn CO of the latest) started complaining along similar lines:


 /..../oscogvm/src/vm/cogit.c:21286:1: error: conflicting types for 'oopisLessThan'
oopisLessThan(sqInt anOop, sqInt otherOop)
^
/.../oscogvm/src/vm/cogit.c:1094:14: note: previous declaration of 'oopisLessThan' was here
static sqInt oopisLessThan(sqInt anOop, sqInt otherOop) NoDbgRegParms;
^
make[2]: *** [CMakeFiles/cog.dir/home/wm/usr/src/smalltalk/CMake.oscog/cogVMMaker/Contents/Resources/oscogvm/src/vm/cogit.c.o] Error 1
make[1]: *** [CMakeFiles/cog.dir/all] Error 2
make: *** [all] Error 2

Any pointers on how to think about this are appreciated.

It looks like you have the "treat warnings as errors" compiler flag switched on.  I admire the purity of those that think this is appropriate but we're not there yet.  There are very few warnings issued from the interpreter, one form the cogit, but many from plugins.  And that warning form the cogit is IMO fascist, and I'm not interested in buckling under ;-)
--
aloha,
Eliot
tty
Reply | Threaded
Open this post in threaded view
♦
♦
|

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

tty
 
Hi Eliot.

I was able to get the code to compile by modifiying the function declarations in cogit.c and gcc3x-interp.c

Apologies in advance if my terms are not exact--I am a bit tired and my brain is duller than usual.

Taking the first compile error as representative,

 
/home/wm/usr/src/smalltalk/CMake.oscog/cogVMMaker/Contents/Resources/oscogvm/src/vm/cogit.c:1820:1: error: conflicting types for 'abstractRegisterForConcreteRegister'
abstractRegisterForConcreteRegister(AbstractInstruction * self_in_abstractRegisterForConcreteRegister, sqInt reg)
^
/home/wm/usr/src/smalltalk/CMake.oscog/cogVMMaker/Contents/Resources/oscogvm/src/vm/cogit.c:384:14: note: previous declaration of 'abstractRegisterForConcreteRegister' was here
static sqInt abstractRegisterForConcreteRegister(AbstractInstruction * self_in_abstractRegisterForConcreteRegister, sqInt reg) NoDbgRegParms;

 the problem was the "NoDbgRegParms" tacked on to the end of the function declaration at line 384 and not being there on the function implementation at 1820--that error happened for all the declarations.

you can see them here:


http://www.squeakvm.org/svn/squeak/branches/Cog/src/vm/cogit.c

I noticed too that my old branch did not have those NoDbgRegParms tacked on while the live Cog trunk does.


So, I edited both cogit.c and gcc3x-cointerp.c and got rid of those NoDbgRegParms and then torched the -DNDEBUG -DDEBUGVM flags and the thing compiled in both cmake and make and ran.
(The cmake version does use the -D flags)


It will be a couple of days before I can devote a study session to your email on the assertion inlining stuff. I just wanted to bring this to your attention  in case some 'assertion inlined code' was submitted to svn if such a thing is possible.

Thanks for your pointers on the -w stuff. I have always lived in fear of gcc output, but I am starting to look at it logically;  I am beginning to see the outlines of a forest for the trees (:


cordially,

tty.
Eliot Miranda-2
Reply | Threaded
Open this post in threaded view
♦
♦
|

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

Eliot Miranda-2
 
Hi Timothy,


On Sun, Jul 20, 2014 at 12:40 PM, gettimothy <[hidden email]> wrote:
 
Hi Eliot.

I was able to get the code to compile by modifiying the function declarations in cogit.c and gcc3x-interp.c

Apologies in advance if my terms are not exact--I am a bit tired and my brain is duller than usual.

Taking the first compile error as representative,

 
/home/wm/usr/src/smalltalk/CMake.oscog/cogVMMaker/Contents/Resources/oscogvm/src/vm/cogit.c:1820:1: error: conflicting types for 'abstractRegisterForConcreteRegister'
abstractRegisterForConcreteRegister(AbstractInstruction * self_in_abstractRegisterForConcreteRegister, sqInt reg)
^
/home/wm/usr/src/smalltalk/CMake.oscog/cogVMMaker/Contents/Resources/oscogvm/src/vm/cogit.c:384:14: note: previous declaration of 'abstractRegisterForConcreteRegister' was here
static sqInt abstractRegisterForConcreteRegister(AbstractInstruction * self_in_abstractRegisterForConcreteRegister, sqInt reg) NoDbgRegParms;

 the problem was the "NoDbgRegParms" tacked on to the end of the function declaration at line 384 and not being there on the function implementation at 1820--that error happened for all the declarations.

Read the commit comment for r2922:

Slang:
In non-production VMs add an attribute to disable register parameters (at least
for GCC-compliant compilers), allowing all static functions to be called from
gdb even in the -O1 assert VMs.

These defines, which precede the external declaration of e.g. abstractRegisterForConcreteRegister:

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

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

should result in 

static sqInt abstractRegisterForConcreteRegister(AbstractInstruction * self_in_abstractRegisterForConcreteRegister, sqInt reg) __attribute__ ((regparm (0)));
...
static sqInt
abstractRegisterForConcreteRegister(AbstractInstruction * self_in_abstractRegisterForConcreteRegister, sqInt reg)
{
...


or


static sqInt abstractRegisterForConcreteRegister(AbstractInstruction * self_in_abstractRegisterForConcreteRegister, sqInt reg);
...
static sqInt
abstractRegisterForConcreteRegister(AbstractInstruction * self_in_abstractRegisterForConcreteRegister, sqInt reg)
{
...

The first is legal input to gcc.  The second is legal C.
 
you can see them here:


I noticed too that my old branch did not have those NoDbgRegParms tacked on while the live Cog trunk does.


So, I edited both cogit.c and gcc3x-cointerp.c and got rid of those NoDbgRegParms and then torched the -DNDEBUG -DDEBUGVM flags and the thing compiled in both cmake and make and ran.
(The cmake version does use the -D flags)


It will be a couple of days before I can devote a study session to your email on the assertion inlining stuff. I just wanted to bring this to your attention  in case some 'assertion inlined code' was submitted to svn if such a thing is possible.

Thanks for your pointers on the -w stuff. I have always lived in fear of gcc output, but I am starting to look at it logically;  I am beginning to see the outlines of a forest for the trees (:


cordially,

tty.

--
Aloha,
Eliot
tty
Reply | Threaded
Open this post in threaded view
♦
♦
|

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

tty
 
Hi Eliot.

Thank you. I have to switch gears for a couple of days to make some $$. I will study this in detail later this week.


Cordially,

tty

---- On Tue, 22 Jul 2014 08:59:12 -0700 Eliot Miranda <[hidden email]> wrote ----

Hi Timothy,


On Sun, Jul 20, 2014 at 12:40 PM, gettimothy <[hidden email]> wrote:
 
Hi Eliot.

I was able to get the code to compile by modifiying the function declarations in cogit.c and gcc3x-interp.c

Apologies in advance if my terms are not exact--I am a bit tired and my brain is duller than usual.

Taking the first compile error as representative,

 
/home/wm/usr/src/smalltalk/CMake.oscog/cogVMMaker/Contents/Resources/oscogvm/src/vm/cogit.c:1820:1: error: conflicting types for 'abstractRegisterForConcreteRegister'
abstractRegisterForConcreteRegister(AbstractInstruction * self_in_abstractRegisterForConcreteRegister, sqInt reg)
^
/home/wm/usr/src/smalltalk/CMake.oscog/cogVMMaker/Contents/Resources/oscogvm/src/vm/cogit.c:384:14: note: previous declaration of 'abstractRegisterForConcreteRegister' was here
static sqInt abstractRegisterForConcreteRegister(AbstractInstruction * self_in_abstractRegisterForConcreteRegister, sqInt reg) NoDbgRegParms;

 the problem was the "NoDbgRegParms" tacked on to the end of the function declaration at line 384 and not being there on the function implementation at 1820--that error happened for all the declarations.

Read the commit comment for r2922:

Slang:
In non-production VMs add an attribute to disable register parameters (at least
for GCC-compliant compilers), allowing all static functions to be called from
gdb even in the -O1 assert VMs.

These defines, which precede the external declaration of e.g. abstractRegisterForConcreteRegister:

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

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

should result in 

static sqInt abstractRegisterForConcreteRegister(AbstractInstruction * self_in_abstractRegisterForConcreteRegister, sqInt reg) __attribute__ ((regparm (0)));
...
static sqInt
abstractRegisterForConcreteRegister(AbstractInstruction * self_in_abstractRegisterForConcreteRegister, sqInt reg)
{
...


or


static sqInt abstractRegisterForConcreteRegister(AbstractInstruction * self_in_abstractRegisterForConcreteRegister, sqInt reg);
...
static sqInt
abstractRegisterForConcreteRegister(AbstractInstruction * self_in_abstractRegisterForConcreteRegister, sqInt reg)
{
...

The first is legal input to gcc.  The second is legal C.
 
you can see them here:


I noticed too that my old branch did not have those NoDbgRegParms tacked on while the live Cog trunk does.


So, I edited both cogit.c and gcc3x-cointerp.c and got rid of those NoDbgRegParms and then torched the -DNDEBUG -DDEBUGVM flags and the thing compiled in both cmake and make and ran.
(The cmake version does use the -D flags)


It will be a couple of days before I can devote a study session to your email on the assertion inlining stuff. I just wanted to bring this to your attention  in case some 'assertion inlined code' was submitted to svn if such a thing is possible.

Thanks for your pointers on the -w stuff. I have always lived in fear of gcc output, but I am starting to look at it logically;  I am beginning to see the outlines of a forest for the trees (:


cordially,

tty.

--
Aloha,
Eliot
tty
Reply | Threaded
Open this post in threaded view
♦
♦
|

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

tty
In reply to this post by Eliot Miranda-2
 
Hi Eliot.

What/where sets the PRODUCTION and NoDbgRegParms  variables in the #if !PRODUCTION && defined(__GNUC__) && !defined(NoDbgRegParms) check ?

Are they set by 'somewhere' by various -D flags in the mvm? I have grepped to no avail. 

Here is my thinking at the moment. The compiler error is showing that the NoDbgRegParms is not being replaced. 


 /home/wm/usr/src/smalltalk/CMake.oscog/cogVMMaker/Contents/Resources/oscogvm/src/vm/cogit.c:1071:13: note: previous declaration of 'ssAllocateRequiredRegMaskupThrough' was here
static void ssAllocateRequiredRegMaskupThrough(sqInt requiredRegsMask, sqInt stackPtr) NoDbgRegParms;
^
/home/wm/usr/src/smalltalk/CMake.oscog/cogVMMaker/Contents/Resources/oscogvm/src/vm/cogit.c:20947:1: error: conflicting types for 'ssAllocateRequiredReg'
ssAllocateRequiredReg(sqInt requiredReg)

 

So the question becomes "why not".

Well, because the pre-processor (?) is not replacing them. Why? hmmmm....

thx for your time.

tty
Eliot Miranda-2
Reply | Threaded
Open this post in threaded view
♦
♦
|

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

Eliot Miranda-2
 



On Thu, Jul 31, 2014 at 6:48 AM, gettimothy <[hidden email]> wrote:
 
Hi Eliot.

What/where sets the PRODUCTION and NoDbgRegParms  variables in the #if !PRODUCTION && defined(__GNUC__) && !defined(NoDbgRegParms) check ?

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

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.



Are they set by 'somewhere' by various -D flags in the mvm? I have grepped to no avail. 

Here is my thinking at the moment. The compiler error is showing that the NoDbgRegParms is not being replaced. 


 /home/wm/usr/src/smalltalk/CMake.oscog/cogVMMaker/Contents/Resources/oscogvm/src/vm/cogit.c:1071:13: note: previous declaration of 'ssAllocateRequiredRegMaskupThrough' was here
static void ssAllocateRequiredRegMaskupThrough(sqInt requiredRegsMask, sqInt stackPtr) NoDbgRegParms;
^
/home/wm/usr/src/smalltalk/CMake.oscog/cogVMMaker/Contents/Resources/oscogvm/src/vm/cogit.c:20947:1: error: conflicting types for 'ssAllocateRequiredReg'
ssAllocateRequiredReg(sqInt requiredReg)

 

So the question becomes "why not".

Well, because the pre-processor (?) is not replacing them. Why? hmmmm....

Both gcc -v & gcc -E can help debug these kinds of things.

thx for your time.

tty
--
Aloha,
Eliot
tty
Reply | Threaded
Open this post in threaded view
♦
♦
|

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

tty
 
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
EstebanLM
Reply | Threaded
Open this post in threaded view
♦
♦
|

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

EstebanLM
 
btw in my builds for windows I needed to declare the ifdef like this:

#if !PRODUCTION && defined(__GNUC__) && !(defined(__MINGW32__) || defined(__MINGW64__)) && !defined(NoDbgRegParms)

because otherwise mingw build was going crazy :P

Esteban


On 31 Jul 2014, at 19:56, gettimothy <[hidden email]> wrote:

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
tty
Reply | Threaded
Open this post in threaded view
♦
♦
|

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

tty
 
Hi Estaban,


btw in my builds for windows I needed to declare the ifdef like this:

#if !PRODUCTION && defined(__GNUC__) && !(defined(__MINGW32__) || defined(__MINGW64__)) && !defined(NoDbgRegParms)

because otherwise mingw build was going crazy :P


That is good to know. 

thx.

tty
tty
Reply | Threaded
Open this post in threaded view
♦
♦
|

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

tty
In reply to this post by Eliot Miranda-2
 
Good news.

I get the same failure on a pure 32 bit Slackware install on a different computer. (!) That removes one variable from the problem set.

I can follow the rabbit trail down on my good workstation with renewed confidence. Work will be slow for a bit, but I am still on it.


cordially,

tty. 





---- On Thu, 31 Jul 2014 10:39:16 -0700 Eliot Miranda <[hidden email]> wrote ----




On Thu, Jul 31, 2014 at 6:48 AM, gettimothy <[hidden email]> wrote:
 
Hi Eliot.

What/where sets the PRODUCTION and NoDbgRegParms  variables in the #if !PRODUCTION && defined(__GNUC__) && !defined(NoDbgRegParms) check ?

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

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.



Are they set by 'somewhere' by various -D flags in the mvm? I have grepped to no avail. 

Here is my thinking at the moment. The compiler error is showing that the NoDbgRegParms is not being replaced. 


 /home/wm/usr/src/smalltalk/CMake.oscog/cogVMMaker/Contents/Resources/oscogvm/src/vm/cogit.c:1071:13: note: previous declaration of 'ssAllocateRequiredRegMaskupThrough' was here
static void ssAllocateRequiredRegMaskupThrough(sqInt requiredRegsMask, sqInt stackPtr) NoDbgRegParms;
^
/home/wm/usr/src/smalltalk/CMake.oscog/cogVMMaker/Contents/Resources/oscogvm/src/vm/cogit.c:20947:1: error: conflicting types for 'ssAllocateRequiredReg'
ssAllocateRequiredReg(sqInt requiredReg)

 

So the question becomes "why not".

Well, because the pre-processor (?) is not replacing them. Why? hmmmm....

Both gcc -v & gcc -E can help debug these kinds of things.

thx for your time.

tty
--
Aloha,
Eliot
Free forum by Nabble Edit this page