ffi_call( 'Wolf!' )
I was pretty excited today because I thought I had my interface for ffi_call working on Linux, and told Twitter and the #soc-help channel all about it. It did seem to be working, until I changed a slight detail in my test script and it became apparent that either there was bewitchery afoot, or I need to read perlxs / perlguts more and it was random change that it hadn't blown up in the first place. I think I'm nearly there though. Next step will be fleshing out the OO functionality in Perl for a bit before diving back into the C for callbacks.
I'm having trouble getting gdb to play ball with macros though, which would be a huge help in finding out where I'm going wrong. make'ing with OPTIMIZE=-g3 (in Makefile.PL or on the command line) doesn't let me examine the stack with *SP, nor does -ggdb3 or '-gdwarf-2 -g3 -O0'. The error is always "No symbol 'SP' in this context". I keep asking people if I need a -DDEBUGGING Perl to be able to say 'p *SP[0]' at the gdb prompt but no-one's said that that's the case. Anyone have any advice on that front? The only other thing for it is even more #ifdef'd warn()s littering my XS, which takes five times as long.
I was thrown off track for longer than I'd like to admit by the fact that although xsubpp won't complain about a C-style comment after a parameter in the INPUT: section, said comment will in fact prevent xsubpp from inserting the typemap code for that parameter into the C. Moral of the story is when stuff isn't making sense, look at the .c output rather than the .xs, and sooner rather than later. Obvious in hindsight. This is what the 'student' part of GSoC is about I suppose. This and clobbering the stack. In any case, given the types of things xsubpp will usually error at you for, I think it ought to have given me a poke about this.
Nearer the start of last week I essentially wasted some time going through all three major build systems trying to configure them to build my extension correctly before settling for EUMM. I think I'll write a short musing about that in another post.
Finally, I've spent a little time cleaning up my local repo, removing h2xs / M::I stubs and the like, getting ready to push stuff public. I'm not sure about how to make sure libffi is installed for people on Win32 though. This is the kind of thing the Alien:: namespace is for I guess, but is there a standard framework for this kind of dependency checking? Again, advice much appreciated.
Student perl-lover in the UK, finishing my law degree in June.
I think for Win32 you would want to either:
a) bundle your external library dependencies or;
b) setup a Alien::libffi or something like that.
First choice is probably more convenient for users. I think some of the wrappers for external libraries on CPAN already just bundle the library along with the module.
Windows applications usually come bundled with whatever external libraries they need as pre-compiled DLLs.
Hmm. For debugging perl, why would you *not* build a "debugging perl"?
I suggest building perl with something like this:
sh Configure -Doptimize="-g -O0" -Dprefix='/somewhere' -Dusedevel -Dcc=ccache\ gcc -Dld=gcc -Dusethreads -DDEBUGGING -de
The ccache bit assumes that you'll be building perl a couple of times. Replace -g with your debugging flags of choice.
At this debugging stage I rather recommend
-Uusethreads.
-g3 resolves SP for me.
(gdb) info macro SP
Defined at /usr/lib/perl/5.10/CORE/pp.h:54
included at /usr/lib/perl/5.10/CORE/perl.h:4815
included at /home/rurban/Perl/perl-ctypes-nolib/Ctypes.c:13
#define SP sp
(gdb) p *SP
$2 = (SV *) 0x79e1d8
(gdb) p *SP[0]
$3 = {sv_any = 0x603b78, sv_refcnt = 1, sv_flags = 279557, sv_u = {
svu_iv = 6409872, svu_uv = 6409872, svu_rv = 0x61ce90,
svu_pv = 0x61ce90 "sdd", svu_array = 0x61ce90, svu_hash = 0x61ce90,
svu_gp = 0x61ce90}}
I use
-ggdb3, also make sure you're using GDB 7.0 or later. Debugging Perl got a lot easier on it due to improved macro expansion support.When you create Alien::libffi I would suggest that you bundle the actual library as part of it, but only install that library if it's already not installed. You can use something like Devel::CheckLib to do the actual check.
Hmm. For debugging perl, why would you *not* build a "debugging perl"?
Only because I've never built my own Perl and assume it could be a bit of a can of worms :) Thanks for the config advice, I'll try it.@Reini Urban, Ævar Arnfjörð Bjarmason:
Either there's gremlins, or the last time I tried I only tried the ST macro, because today after changing nothing (I was already trying combinations of those settings) the SP macro will give me results! :) ST still gives me this:
(gdb) info macro STDefined at /usr/lib/perl/5.10/CORE/XSUB.h:97
included at /home/doubi/GSoC2010/Ctypes-nolib/Ctypes.c:14
#define ST(off) PL_stack_base[ax + (off)]
(gdb) p ST
No symbol "ST" in current context.
(gdb) p ax
$8 = 1
(gdb) p PL_stack_base
$9 = 135775568
(gdb) p PL_stack_base[ax]
cannot subscript something of type `int'
Oh well. SP + ax will likely tell me everything I need to know. Thanks for the -g3 advice.
@Nilson Santos Figueiredo Junior: A binary could probably make a large swathe of people happy, but I can't create binaries for WinXP/Vista/7 32/64bit. Maybe I could provide the most general purpose of those, plus the sources and leave the rest to sort themselves out.
@mpeters: I hadn't seen Devel::CheckLib, thanks for the tip. Hope it's win32 compatible. Nice to hear from you by the way! :)