in reply to Re^2: GIMME_V==G_ARRAY anomaly on win32 (5.10 only)
in thread GIMME_V==G_ARRAY anomaly on win32 (5.10 only)

What's the result matrix for 
void foo() {
     printf("%x\n", GIMME_V);
     printf("%x\n", G_ARRAY);
     printf("%d\n", GIMME_V == G_ARRAY);
}

[download]

Maybe it would help if you posted the generated C and XS files for each Perl. They normally get deleted, but you can avoid that with 

perl -MInline=NOCLEAN,force script.pl

[download]

( "force" forces a rebuild )

Replies are listed 'Best First'.
Re^4: GIMME_V==G_ARRAY anomaly on win32 (5.10 only)
by syphilis (Archbishop) on Dec 19, 2009 at 01:04 UTC
    ( "force" forces a rebuild )

    Everything works fine if I do a rebuild. It's only when I run MinGW-built binaries on ActivePerl or ActivePerl-built binaries on MinGW perl that the problem arises (even though it's the exact same compiler building the binaries, irrespective of which perl is being used.) When I run the "foreign" binary on the "perl that didn't build the binary", GIMME_V inevitably returns G_VOID (afaict).

    Now some people may raise eyebrows at the practice of throwing binaries around like I'm doing - but it's something I've been doing for quite some time without any troubles at all. I don't see why it should pose a problem, until now I've been quietly confident it would never pose a problem, it's still *not* a problem on perl-5.8.x, but all of a sudden I find that I can't do it on 5.10.x when an XSub relies on GIMME_V.

    I'm hoping it's a bug - but even if it is, I may have trouble convincing the people that count :-)
    Then again, fairk, I may have been indulging in a bad pratice for all these years, after all. If so, then the implication is that you must provide separate binaries for Strawberry Perl (or any MinGW-built perl) and ActivePerl - which is probably not such a big deal since Strawberry users aren't generally interested in binaries anyway, but it's interesting nonetheless.

    I actually provide a few ppm packages (including Net-SSH2) to the uwinnipeg rep - all built using the MinGW compiler. In the past, I haven't paid much attention to whether I built the packages with ActivePerl or with my own MinGW-built perl. But it now looks like I ought to make sure that I build them using ActivePerl.

    The result matrices for the code you posted are:
    1) For the perl 5.10.x that compiles the script: 
    1
1
1

    [download]
    2) For the "other" perl 5.10.x: 
    80
1
0

    [download]
    No matter which perl builds the script, the generated XS and C files are identical. (These files are reproduced below my sig in the <readmore> section.)

    Cheers,
    Rob
    Read more... (3 kB)
[reply]
[d/l]
[select]
      Using gcc version 3.4.5 (mingw-vista special r3) I get 
      1
1
1

      [download]
      on strawberry v5.10.0, self built 5.10.1 , and activeperl v5.8.9 Build 825 288577

      The XS looks identical to yours and doesn't change between the 3 perls

      Grepping the CORE directory I get in all 3 perls 

      CORE/cop.h:#define G_ARRAY               1
lib\CORE/op.h:#define GIMME_V                OP_GIMME(PL_op, block_gim
+me())

      [download]
      but on bleadperl I see #define G_ARRAY 3
[reply]
[d/l]
[select]

        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)).

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom