Front page | perl.perl5.porters |
Postings from January 2008
Jan, Many thanks for the very quick analysis, and clear explanation. Further research turns up the '-mms-bitfields' option for (mingw only?) gcc, which causes it to use the same alignment as Microsoft's compilers. I can confirm that using this option at least fixes my immediate problem[1]. It might be a better option for 5.10.x to patch ActivePerl::Config to add this flag? I'll generate a patch and attach it to the ActiveState Bug report for this item. Regards, Rob. [1] Although I have in the process discovered that ExtUtils::CBuilder::Windows doesn't honour the extra_compiler_flags option - patch forthcoming. On 30/01/2008, Jan Dubois <jand@activestate.com> wrote: > On Tue, 29 Jan 2008, Robert May (via RT) wrote: > > ----------------------------------------------------------------- > > I'm building the following XS extension with > > gcc 3.4.5 (mingw special) against ActiveState Perl 5.10.0 > > (builds 1001 and 1002) > > > > GIMME_V appears to always return G_VOID (128), regardless of the > > context the XSUB is called in. > > > > The same code and compiler works fine when built against ActiveState > > Perl 5.8.8 (build 822). It is also fine when compiled with VC++ 6 > > for all 3 perl builds. > > This is not really a core Perl bug; the problem is that VC++ and GCC > are incompatible as far as bit-fields are concerned. In Perl 5.10 > the BASEOP structure contains bitfields: > > unsigned op_type:9; \ > unsigned op_opt:1; \ > unsigned op_latefree:1; \ > unsigned op_latefreed:1; \ > unsigned op_attached:1; \ > unsigned op_spare:3; \ > > In VC++ the combined size of the fields above is 4 bytes, whereas > in GCC it is only 2. This also pushes the size of the complete > structure from 20 to 24 bytes for VC++. > > The GIMME_V() function retrieves the context information from the > op_flags byte. Under GCC the op_flags member fetches one of the > 2 filler bytes VC++ inserts into the structure and is therefore > wrong. > > VC++ uses the base type (unsigned int, in this case) to determine > the alignment requirements and total size of the combined bit-field. > You can use the non-standard extension of using smaller integer sizes > to force the fields into a smaller size and different alignment. > In this case using "unsigned short" for the type of the bit-fields > should work. > > I guess for Perl 5.12 we need a way to let us use the smaller base > size for VC++ to keep the size of the OP structure down. I'll create > a patch for it eventually, when I get a bit more time. I also need > to check if there are other places where Perl is now using bit fields > in its structure definitions. > > I would suggest to keep this bug report open until the size of > the BASEOP structure in bleadperl has been reduced for VC++. > > For ActivePerl 5.10.x we will probably modify op.h to provide an > alternate definition of BASEOP for GCC that contains 2 filler bytes to > make everything align the same way as it does for VC++ (unless we decide > to break binary compatibility between 5.10 and 5.10.1, which I would not > be too fond of). > > I have not yet verified that otherwise the bit mapping between > VC++ and GCC would be compatible though; many details of C bit-field > implementation is really up for the compiler to decide. > > The ability to compile extensions with GCC for a Perl compiled > with VC++ is really an ActivePerl feature and not guaranteed > by core Perl. You have also opened a corresponding ActivePerl bug > that should be used to track that part of the issue: > > http://bugs.activestate.com/show_bug.cgi?id=74532 > > Cheers, > -Jan > > > -- Please update your address book with my new email address: rob@themayfamily.me.ukThread Previous | Thread Next