Re^6: GIMME_V==G_ARRAY anomaly on win32 (5.10 only)

Grepping the CORE directory I get in all 3 perls

lib\CORE/op.h:#define GIMME_V OP_GIMME(PL_op, block_gim +me())
[download]

What matters is not no much that the macro #define doesn't differ, but what machine code the compiler has generated for it. After full macro expansion, the GIMME_V macro looks like:

((((*Perl_Top_ptr(((PerlInterpreter *)pthread_getspecific((*Perl_Gthr_
+key_ptr(((void *)0))))))))->op_flags & 3) == 1 ? 128 : (((*Perl_Top_p
+tr(((PerlInterpreter *)pthread_getspecific((*Perl_Gthr_key_ptr(((void
+ *)0))))))))->op_flags & 3) == 2 ? 0 : (((*Perl_Top_ptr(((PerlInterpr
+eter *)pthread_getspecific((*Perl_Gthr_key_ptr(((void *)0))))))))->op
+_flags & 3) == 3 ? 1 : Perl_block_gimme(((PerlInterpreter *)pthread_g
+etspecific((*Perl_Gthr_key_ptr(((void *)0))))))))
[download]

(this is for a threaded 5.8.8 — replace cc -c ... with cc -E ... in the compiler call issued by Inline::C to obtain the respective snippet for whatever Perl version you're interested in)

As you can see, some Perl-internal functions/structures are being accessed. And problems may arise if the machine code for this macro generated by the compiler used to compile the extension DLL does not address memory as layed out by the compiler(+options) that compiled the perl DLL (for example, op_flags might be aligned differently (just for the sake of argument — not saying this is necessarily the issue in this particular case)).

Comment on Re^6: GIMME_V==G_ARRAY anomaly on win32 (5.10 only) Select or Download Code

Replies are listed 'Best First'.
Re^7: GIMME_V==G_ARRAY anomaly on win32 (5.10 only) by Anonymous Monk on Dec 19, 2009 at 19:53 UTC
I get your point regarding memory layout. The macro does expand the same for me perl 5.10.1 void foo() { printf("%x\n", ((((Perl_Iop_ptr(((PerlInterpreter )Perl_get_cont +ext()))))->op_flags & 3) == 1 ? 128 : (((Perl_Iop_ptr(((PerlInterpre +ter )Perl_get_context()))))->op_flags & 3) == 2 ? 0 : (((Perl_Iop_p +tr(((PerlInterpreter )Perl_get_context()))))->op_flags & 3) == 3 ? 1 + : Perl_block_gimme(((PerlInterpreter )Perl_get_context())))); printf("%x\n", 1); printf("%d\n", ((((Perl_Iop_ptr(((PerlInterpreter )Perl_get_cont +ext()))))->op_flags & 3) == 1 ? 128 : (((Perl_Iop_ptr(((PerlInterpre +ter )Perl_get_context()))))->op_flags & 3) == 2 ? 0 : (((Perl_Iop_p +tr(((PerlInterpreter )Perl_get_context()))))->op_flags & 3) == 3 ? 1 + : Perl_block_gimme(((PerlInterpreter )Perl_get_context()))) == 1); } strawbery 5.10.0 void foo() { printf("%x\n", ((((Perl_Iop_ptr(((PerlInterpreter )Perl_get_cont +ext()))))->op_flags & 3) == 1 ? 128 : (((Perl_Iop_ptr(((PerlInterpre +ter )Perl_get_context()))))->op_flags & 3) == 2 ? 0 : (((Perl_Iop_p +tr(((PerlInterpreter )Perl_get_context()))))->op_flags & 3) == 3 ? 1 + : Perl_block_gimme(((PerlInterpreter )Perl_get_context())))); printf("%x\n", 1); printf("%d\n", ((((Perl_Iop_ptr(((PerlInterpreter )Perl_get_cont +ext()))))->op_flags & 3) == 1 ? 128 : (((Perl_Iop_ptr(((PerlInterpre +ter )Perl_get_context()))))->op_flags & 3) == 2 ? 0 : (((Perl_Iop_p +tr(((PerlInterpreter )Perl_get_context()))))->op_flags & 3) == 3 ? 1 + : Perl_block_gimme(((PerlInterpreter )Perl_get_context()))) == 1); } activeperl v5.8.9 build 825 [288577] void foo() { printf("%x\n", ((((Perl_Top_ptr(((PerlInterpreter )Perl_get_cont +ext()))))->op_flags & 3) == 1 ? 128 : (((Perl_Top_ptr(((PerlInterpre +ter )Perl_get_context()))))->op_flags & 3) == 2 ? 0 : (((Perl_Top_p +tr(((PerlInterpreter )Perl_get_context()))))->op_flags & 3) == 3 ? 1 + : Perl_block_gimme(((PerlInterpreter )Perl_get_context())))); printf("%x\n", 1); printf("%d\n", ((((Perl_Top_ptr(((PerlInterpreter )Perl_get_cont +ext()))))->op_flags & 3) == 1 ? 128 : (((Perl_Top_ptr(((PerlInterpre +ter )Perl_get_context()))))->op_flags & 3) == 2 ? 0 : (((Perl_Top_p +tr(((PerlInterpreter )Perl_get_context()))))->op_flags & 3) == 3 ? 1 + : Perl_block_gimme(((PerlInterpreter )Perl_get_context()))) == 1); } [download]	[reply] [d/l]
Re^7: GIMME_V==G_ARRAY anomaly on win32 (5.10 only) by syphilis (Archbishop) on Dec 19, 2009 at 22:31 UTC
problems may arise if the machine code for this macro generated by the compiler used to compile the extension DLL does not address memory as layed out by the compiler(+options) that compiled the perl DLL (for example, op_flags might be aligned differently Isn't this the sort of thing that would most likely cause a crash, rather than a wrong value being returned ? And it would seem to be a coincidence that such a misalignment actually returns one of the three meaningful values (0, 1, 128) instead of a nonsense value. I guess anything is possible - and the proof probably lies in the debugger (as you've already mentioned). Cheers, Rob	[reply]