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.
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@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.
- Have the user hand edit config.h (unacceptable, rejected)
- Find a CMake workaround to generate the #define NoDbgRegParms
- 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.
On 30-03-2015, at 9:57 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
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?
I’m pretty sure you mean ‘gcc’. The FCC has other problems it needs to sort out…
And a weird thing worth pointing out - the code as-is compiles ok on Raspbian. Complains on ubuntu 14. Might make some sense to someone.
tim -- tim Rowledge; tim@rowledge.org; Why do airplanes need hangars? Because they lose their shape if you hang them on a nail
On Mar 30, 2015, at 10:31 AM, tim Rowledge tim@rowledge.org wrote:
On 30-03-2015, at 9:57 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
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?
I’m pretty sure you mean ‘gcc’. The FCC has other problems it needs to sort out…
Bloody autocorrect!
And a weird thing worth pointing out - the code as-is compiles ok on Raspbian. Complains on ubuntu 14. Might make some sense to someone.
tim
tim Rowledge; tim@rowledge.org; Why do airplanes need hangars? Because they lose their shape if you hang them on a nail
Ok, very interesting stuff.
The problem is not a problem with the pre-processor.
SOME __attributes__ are substituted just fine.
For some reason, on my architecture the replacement does not happen for certain __attributes__.
https://gcc.gnu.org/onlinedocs/gcc-4.0.0/gcc/Function-Attributes.html
1. # define NoDbgRegParms <--compiles 2. # define NoDbgRegParms __attribute__ ((regparm (0))) <--function type mismatch error due to NoDbgRegParms not being replaced 3. # define NoDbgRegParms __attribute__ ((deprecated)) <--This spit out a bunch of warnings (as expected) but it compiled! yay! 4. #define NoDbgRegParms __attribute__ ((noinline)) <--function type mismatch error due to NoDbgRegParms not being replaced 5. #define NoDbgRegParms __attribute__ ((always_inline)) <-- error: inlining failed in call to always_inline 'printNameOfClasscount': recursive inlining
regparm (number) On the Intel 386, the regparm attribute causes the compiler to pass up to number integer arguments in registers EAX, EDX, and ECX instead of on the stack. Functions that take a variable number of arguments will continue to be passed all of their arguments on the stack.
I am running an AMD processor.
I will research this some more.
cheers.
tty.
@Tim
Is there a way to test the 'fix' I emailed about several weeks ago where I wrote putting the empty #define NoDbgRegParms in config.h.in "fixes" the problem?
Running the cog --version command shows an Assert VM, but I wonder if that is just an artefact and what is really there is a production VM and the __attribute__((regparm(0)))__ functiona attributes where never put in place.
gdb? something else?
thx.
tty
Tim,
the way I'd test it is a) look at the preprocessed output via -E to check that the attributes were included in the souerce, and b) I'd open the executable in gdb, disassemble some of the funcitons with the attribute that take arguments and look at the disassembly to verify that the functions take their arguments from the stack and not from registers. I might then try and run the VM under gdb, put a breakpoint some where in the VM (or just interrupt it after it ran for a while) and then try and call one of the funcitons in a suitable state. Of course getting the VM to a suitable state and knowing which function to call is not trivial. So better is probably looking at the disassembly between an Assert compile (-O1) with the attributes and an Assert compile without the attributes.
On Tue, Mar 31, 2015 at 5:09 AM, gettimothy gettimothy@zoho.com wrote:
@Tim
Is there a way to test the 'fix' I emailed about several weeks ago where I wrote putting the empty #define NoDbgRegParms in config.h.in "fixes" the problem?
Running the cog --version command shows an Assert VM, but I wonder if that is just an artefact and what is really there is a production VM and the __attribute__((regparm(0)))__ functiona attributes where never put in place.
gdb? something else?
thx.
tty
vm-dev@lists.squeakfoundation.org