[Vm-dev] NoDbgRegParms bug bites again--this time with CMake

[Eliot Miranda]

Hi Timothy,
   The right thing to do is to report the bug to the FCC maintainers.  This is legal C and useful.  So it should not be causing problems right?

Eliot (phone)

On Mar 30, 2015, at 8:58 AM, gettimothy <gettimothy at zoho.com> wrote:

> Just a heads up/progress report.
> 
> The "fix" of putting a 
> #define NoDbgRegParms               "<--empty definition"
> in config.h.in for autotools does NOT translate to CMake because CMake builds its own config.h based on some tests/probing in a config.cmake file.
> This then creates its own config.h.in (cmake version) and then config.h
> 
> When it does so, it does NOT respect the "empty definition" and just leave things alone, but "helps" by placing a 
> /* #undef NoDbgRegParms */ 
> in config.h
> 
> 
> There are 3 strategies I have in mind.
> 
> 1. Have the user hand edit config.h (unacceptable, rejected)
> 2. Find a CMake workaround to generate the #define NoDbgRegParms 
> 3. Take this as a clue about how autotools expects things and make the logic in Cog/src/vm/cogit.h Cog/src/vm/cointerp.h etc logic so that it works with 
> 
> #if !PRODUCTION && defined(__GNUC__) && !defined(NoDbgRegParms)
> # define NoDbgRegParms __attribute__ ((regparm (0)))
> #endif
> 
> I will be focusing on approach 3 for a bit. "Maybe" its
> 
> a. something about a comparison between the !defines and the !PRODUCTION
> b. a conflict created when autotools does its macro-expansion since the test is in multiple .h files.
> 
> cheers.
> 
> tty.
> 
> 
> 
> 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20150330/832d97a2/attachment.htm