perlxs + blackbox testing

nostromo has asked for the wisdom of the Perl Monks concerning the following question:

hello!
for a blackbox tester that uses linux shared libraries i want to use perlxs. the problem is that it seems that perlxs assumes that one knows the way a certain function works (as it will be described in the CODE: fragment of an .xs file). the problem is, when using blackbox-testing i just know the input, and a the category (int, float, string, etc + lt, eq, gt, etc, e.g.), so i can not provide any CODE:-lines beforehand.
is there a way to still make use of perlxs? i get my header-info from a .xml-file that describes what input to a certain function is expected.
so, for example if i have a "hello"-function in my hello_lib.so library that will print out "hello world" n times, my .xml-file says "func: hello, arg: int", which will reflect in the .xs file as "void hello(i) \n int i". but it seems if i don't provide a CODE:-line like "printf (...)" i always get a "symbol lookup error: ..../myhello.so: undefined symbol: hello". any hints? TIA

Comment on perlxs + blackbox testing

Replies are listed 'Best First'.
Re: perlxs + blackbox testing by chromatic (Archbishop) on Jun 12, 2006 at 20:34 UTC
Have you tried P5NCI?	[reply]
Re^2: perlxs + blackbox testing by nostromo (Sexton) on Jun 12, 2006 at 20:40 UTC
yes, i had a short look at it, but haven't tried it yet. do you know that this might be of help to my problem, or are you pointing out some alternatives? in any case, thanks for your answer! :)	[reply]
Re^2: perlxs + blackbox testing by nostromo (Sexton) on Jun 12, 2006 at 21:46 UTC
ok, i tried to install P5NCI, but all i get is a machine that nearly dies and does not react to any input at all, since the Build-process uses up all RAM and swap. since P5NCI is maintained by chromatic, is it your module? :) do you know what's going wrong here? all i do is untar, then run - as suggested - a "perl ./Build.PL; ./Build".	[reply]
Re^3: perlxs + blackbox testing by chromatic (Archbishop) on Jun 12, 2006 at 23:50 UTC
It takes a while to build up the big shared library of thunks. That's normal. Hopefully someone will enhance it in the near future to use something like `libffi` or a JIT library to make that unnecessary.	[reply] [d/l]
Re^4: perlxs + blackbox testing by nostromo (Sexton) on Jun 13, 2006 at 08:10 UTC
Re^3: perlxs + blackbox testing by nostromo (Sexton) on Jun 12, 2006 at 22:21 UTC
ok, running various tests on various unix-derivates and linux-distribution, it seems, the Build-process simply just takes up all ram and a loooooong time (according to my CPU speed). but i've converted a .rpm to a format that suits my distribution with a conversion-tool, and installed this package. my first tests with P5NCI have shown, that this is exactly what i need. this is great, thx chromatic!	[reply]
Re: perlxs + blackbox testing by eyepopslikeamosquito (Archbishop) on Jun 12, 2006 at 22:19 UTC
I've read your post several times but I don't really understand what you are trying to achieve. Please provide more background information about the bigger picture, what you are trying to achieve. Are you writing your own black box testing framework or using one written by someone else? If the latter, which one are you using? Do you want to test some .xs code? Or do you want to use .xs code in your test harness? Where does the .xml file you speak of come from?	[reply]
Re^2: perlxs + blackbox testing by nostromo (Sexton) on Jun 12, 2006 at 22:31 UTC
ok, i'll retry to explain my basic problem. i hope it brings some light into my ideas :) i want to write a blackbox-tester in perl. this means that the object to be analyzed is a linux shared-library - the ".so"-files. they provide various functions one can call by including this library. in my case the exact working principle of a function is not clear to the tester. instead, it gets input from a .xml-file that describes what values can be fed to a certain function, what name this function has, and what _might_ be an expected output. so, for example, a library, let's call it hello_world(.so) provides a function called "hello", that takes an integer as argument, where this argument defines how often the string "hello world\n" shall be printed to STDOUT. thus my blackbox-tester would read (theoretically up to now): "func: hello; arg: int; ret: string" and run a test on the function "hello" provided by hello_world.so handing over an integer. the given output from this function can then later be processed for further investigation, but is expected to be a string in this case. pretty long, but i hope this makes it a bit more clear to you. chromatics hint taking a closer look at P5NCI was very very helpful. P5NCI seems to be just what i need and it does it's job much better than DynaLoader oder perlxs. i already tried it on my sample library and it worked perfectly :)	[reply]
Re^3: perlxs + blackbox testing by eyepopslikeamosquito (Archbishop) on Jun 13, 2006 at 00:58 UTC
OK, thanks, much clearer now. Yep, P5NCI is what you want. Notice that P5NCI is currently limited to C functions taking up to four arguments -- which is why it took so long to build, since p5NCI.xs contains over 100,000 lines of code covering all type combinations of up to 4 arguments. The only way to avoid this brute-force approach is to manipulate the call stack with non-portable assembler, which I assume is how it's done by Win32::API and libffi (now maintained as part of GCC). See also Win32::API equivalent for Unix and Re: Disputation of g0n on the power and efficacy of XS.	[reply]