While trying to call a C function from Lua module, using Lua-lanes, the control doesn't transfer to the 'C' function. Is there any problem with which Lua-lanes won't work in a threaded way with an external C dll?
Below is the code snippet
Lua Snippet:
lanes.gen("*",func)
thread = func()
thread:join()
function func()
foo() -- expected to print "Hello world", by
-- calling below C function,but not happening
end
C snippet compiled to a dll with VS-2012:
static int foo(lua_state *L)
{
printf("Hello world\n")
}
If you want that C function accessible in the new thread then you have to somehow transfer that from the main lua thread over to the new thread when you create the lane. You can do this by using .required from the lua-lane docs.
For example, say you have this simple foomodule:
// foomodule.c
// compiles to foomodule.dll
#include <stdio.h>
#include "lua.h"
#include "lauxlib.h"
static int foo(lua_State *L)
{
printf("Hello world\n");
return 0;
}
int luaopen_foomodule(lua_State *L)
{
lua_pushcfunction(L, foo);
lua_pushvalue(L, -1);
lua_setglobal(L, "foo");
return 1;
}
And from your lua script:
// footest.lua
lanes = require 'lanes'.configure()
function func()
print("calling foo", foo)
return foo()
end
thr = lanes.gen("*", {required = {'foomodule', }}, func)
thr():join()
One possible output:
calling foo function: 0x003dff98
Hello world
You are using lanes wrong. This is what you need to do:
function func()
foo() -- expected to print "Hello world", by
-- calling below C function,but not happening
end
local launcher = lanes.gen("*", func)
thread = launcher()
thread:join()
That should work fine.
Related
I have read that C does not support dynamic function calls. My program has an ever growing number of test cases implemented as separate functions like -
int testcase1(void);
int testcase2(void);
int testcase3(void);
Each time I add a new test case, I also have have to add the call to my main function like -
int main(int argc, char **argv){
assert(!testcase1());
assert(!testcase2());
assert(!testcase3());
}
I would prefer to call something like assert(!testcase*()) where * matches any string which resolves to a valid function name in my program.
Can you think of a more convenient solution?
If you all your testcases have same signature then you can use an array of function pointers:
void (*func[])() = { testcase1, testcase2 };
for (size_t i = 0; i < sizeof(func)/sizeof(func[0]); i++) {
assert(!func[i]());
}
The best solution is likely to write a few extra lines of code when you add new test cases - it really isn't a big issue. I would recommend something along the lines of the function pointer array, as suggested in another answer.
However, just to show that everything is possible in C if you throw ugly macros at the problem, here is a not recommended alternative:
#include <assert.h>
#include <stdbool.h>
#include <stdio.h>
#define TEST_CASES \ // list of "x macros"
X(testcase1) \
X(testcase2) \
X(testcase3)
#define X(func) bool func (void); // declare function prototypes
TEST_CASES
#undef X
bool (*const test_cases[])(void) = // array of read-only function pointers
{
#define X(func) &func, // point at each function
TEST_CASES
#undef X
};
int main (void)
{
for(size_t i=0; i<sizeof(test_cases)/sizeof(test_cases[0]); i++)
{
assert(test_cases[i]());
}
}
bool testcase1 (void) { puts(__func__); return true; }
bool testcase2 (void) { puts(__func__); return true; }
bool testcase3 (void) { puts(__func__); return false; }
Output:
testcase1
testcase2
testcase3
Assertion failed!
For each new test case, you would only have to write a function definition and then add it to the "x macro" list TEST_CASES. However, you need very good reasons to introduce ugly tricks like these in production code!
You can use function pointers. Read also about closures (but C99 or C11 don't have them) and callbacks.
Many operating systems provide dynamic loading. On POSIX operating systems (such as Linux or MacOSX) you can get a function pointer (actually an address) from its name in some library (or in the program executable) using dlopen & dlsym. Other operating systems may provide similar functionalities.
At last, you should consider having your testing main function be generated by some script (or some program emitting C code), using metaprogramming techniques. So you would write something which generates the C code of your testing main having a long sequence of assert, and improve your build procedure (e.g. your Makefile if using make) to run appropriately that specialized C code generator. Details are of course specific to your code. You might add some conventions (e.g. add some special comment to be parsed by your test generator, etc...).
I decided to follow #Nominal Animal and #Basile Starynkevitch's approach. In mymainprog.c, I added -
int runtests(void){
void *testh;
int (*testp)(void);
char *dlmsg;
int rc;
char funcname[8];
int testnum;
testh = dlopen("libsmtests.so", RTLD_LAZY);
if (!testh){
printf("%s\n", dlerror());
return 1;
}
dlerror();
for (testnum =1; testnum < 1000; testnum++){
sprintf(funcname,"testcase%d", testnum);
*(void **) (&testp) = dlsym(testh, funcname);
dlmsg = dlerror();
if (dlmsg == NULL) {
rc = (*testp)();
printf("%s called, rc=%d\n", funcname, rc);
}
}
dlclose(testh);
return 0;
}
I add my testcases to a separate file (testcases.c) like this -
int testcase1(void){
return [some testcase expression]
}
int testcase2(void){
return [another testcase expression]
}
and then compile it as a shared library with position-independant code (-fPIC) to libsmtests.so. The advantage is slightly less typing since I don't need to code a call to testNNNN() after adding the implementation of a new functionint testcaseNNN(void) to testcases.c
Disclaimer: asked over at perlmonks.
I hope I'm describing and depicting my issue properly... In XS, I'm trying to send a callback into an external library's function, where the callback has Perl specific functions. The XSUB is passed as a function pointer to an external C function. The XSUB callback being sent in turn calls back to a sub in the `main` perl application:
void callback(){
dSP;
PUSHMARK(SP);
call_pv("p_callback", G_DISCARD|G_NOARGS);
}
// example extern call
externFunc(&callback);
This segfaults. I think it's because the external library doesn't understand the perl functions that are being called. Things work fine if I call the C `callback()` function directly though.
Is there some magic that I can do to make the external library "see" the Perl C functions, or am I doing something wrong?
Here's the code I'm testing with:
use warnings;
use strict;
use Inline ('C' => 'DATA', libs => '-lwiringPi');
init();
setInterrupt(27, 3);
# direct call
callback();
# on() triggers the external function and sends
# it the callback
on(27);
sub p_callback {
print "in perl callback\n";
}
__DATA__
__C__
#include <stdlib.h>
#include <stdio.h>
#include <wiringPi.h>
void init();
void on(int pin);
void off(int pin);
void setInterrupt(int pin, int edge);
void callback();
void init(){
printf("in init\n");
wiringPiSetup();
}
void on(int pin){
pinMode(pin, 1);
digitalWrite(pin, 1);
}
void off(int pin){
digitalWrite(pin, 0);
pinMode(pin, 0);
}
void setInterrupt(int pin, int edge){
wiringPiISR(pin, edge, &callback);
}
void callback(){
dSP;
PUSHMARK(SP);
call_pv("p_callback", G_DISCARD|G_NOARGS);
}
Output:
in init
in perl callback
Segmentation fault
If I remove the perl specific C calls from within the callback and just do a `printf()` or other pure-C work, things proceed without a segfault.
Just came across this question and thought I'd give it my own answer as I did resolve it some time ago.
There were some important bits I was missing to set the Perl context, as well as within the C exec_perl_callback() function.
use warnings;
use strict;
use Inline 'C';
use Inline 'NoClean';
sub p_callback {
print "hello, world from perl!\n";
}
exec_perl_callback('p_callback');
__END__
__C__
#define PERL_NO_GET_CONTEXT
PerlInterpreter * mine;
void callback(char* perl_callback){
PERL_SET_CONTEXT(mine);
dSP;
ENTER;
SAVETMPS;
PUSHMARK(SP);
PUTBACK;
exec_perl_callback(perl_callback, G_DISCARD|G_NOARGS);
FREETMPS;
LEAVE;
}
Output:
hello world, from perl!
Here is what I want to do as part of a larger thread scheduling api.
I want to create a thread and when the main thread (the one creating the thread) exits, the thread I just created should execute. I am trying to do this with ucontext and the uc_link, but it is not working. It appears that my uc_link does not work when I try to set it for the current thread.
Here is a slightly modified example from this link which is what I tired to make this work.
http://pubs.opengroup.org/onlinepubs/009695399/functions/makecontext.html
#include <stdio.h>
#include <ucontext.h>
static ucontext_t ctx[3];
static void
f1 (void)
{
puts("start f1");
swapcontext(&ctx[1], &ctx[2]);
puts("finish f1");
}
static void
f2 (void)
{
puts("start f2");
swapcontext(&ctx[2], &ctx[1]);
puts("finish f2");
}
int
main (void)
{
char st1[8192];
char st2[8192];
getcontext(&ctx[1]);
ctx[1].uc_stack.ss_sp = st1;
ctx[1].uc_stack.ss_size = sizeof st1;
ctx[1].uc_link = 0;
makecontext(&ctx[1], f1, 0);
getcontext(&ctx[2]);
ctx[2].uc_stack.ss_sp = st2;
ctx[2].uc_stack.ss_size = sizeof st2;
ctx[2].uc_link = &ctx[1];
makecontext(&ctx[2], f2, 0);
getcontext(&ctx[0]);
ctx[0].uc_link = &ctx[2];
return 0;
}
Expected output :
finished main
start f2
start f1
finish f2
finish f1
Given output :
finished main
How do I go about setting the uc_link for the current thread/process in a meaningful manner ?
Replacing main in the above code with the following produces the expected output.
int
main (void)
{
char st1[8192];
char st2[8192];
getcontext(&ctx[1]);
ctx[1].uc_stack.ss_sp = st1;
ctx[1].uc_stack.ss_size = sizeof st1;
ctx[1].uc_link = &ctx[0];
makecontext(&ctx[1], f1, 0);
getcontext(&ctx[2]);
ctx[2].uc_stack.ss_sp = st2;
ctx[2].uc_stack.ss_size = sizeof st2;
ctx[2].uc_link = &ctx[1];
makecontext(&ctx[2], f2, 0);
getcontext(&ctx[0]);
ctx[0].uc_mcontext.gregs[16] += 0x26;
puts("finish main");
setcontext(&ctx[2]);
return 0;
}
BUT this doesn't do what you say you want.
The context functions are a way to put a specific return address on the stack.
getcontext captures the address of the next instruction into a struct
makecontext changes the address in the struct to that of its function argument
setcontext/swapcontext puts the address in the struct on the stack and returns to it
This program above has only one thread of control. I think you really want multiple threads, in which case you wouldn't use these context functions.
For more information about the stack and the C calling convention, Eli Bendersky has two nice articles with diagrams:
Where the top of the stack is on x86
Stack frame layout on x86-64
FWIW, to get the 0x26 constant in the above code, I had to disassemble main to find the first address after the setcontext call.
At the link you provided they say
The uc_link member is used to determine the context that shall be
resumed when the context being modified by makecontext() returns.
Since your program doesn't resume (execute) any context modified by makecontext(), the above does not apply and the program ends without resuming any context.
To achieve what you want, you have to define some function like
void main_context()
{
// do everything you yet wanted to do in main()
puts("finished main");
}
and replace the
return 0;
with
char st0[8192];
ctx[0].uc_stack.ss_sp = st0;
ctx[0].uc_stack.ss_size = sizeof st0;
makecontext(&ctx[0], main_context, 0);
return -setcontext(&ctx[0]);
I have the following code calling three different functions named func_a, func_b and func_c, which are using the same parameter. Before and after each call I need to call the functions foo and bar in order to reset/print some variables. Both are doing the same thing every time I call them.
foo();
func_a(param);
bar();
foo();
func_b(param);
bar();
foo();
func_c(param);
bar();
So, my question: is there any way to make this part more elegant? In my case it is going up to func_e, so I have five near repeats of this code.
I suppose you can put all the things that are in common into a single function that invokes a function pointer. Then iterate over an array of function pointers, passing them into the single helper function:
void invoke_foo_func_bar (void (*func)(int), int param) {
foo();
func(param);
bar();
}
/* ... */
void (*funcs[])(int) = { func_a, func_b, func_c };
for (int i = 0; i < sizeof(funcs)/sizeof(*funcs); ++i) {
invoke_foo_func_bar(funcs[i], param);
}
I got a homework assignment asking me to invoke a function without explicitly calling it, using buffer overflow. The code is basically this:
#include <stdio.h>
#include <stdlib.h>
void g()
{
printf("now inside g()!\n");
}
void f()
{
printf("now inside f()!\n");
// can only modify this section
// cant call g(), maybe use g (pointer to function)
}
int main (int argc, char *argv[])
{
f();
return 0;
}
Though I'm not sure how to proceed. I thought about changing the return address for the program counter so that it'll proceed directly to the address of g(), but I'm not sure how to access it. Anyway, tips will be great.
The basic idea is to alter the function's return address so that when the function returns is continues to execute at a new hacked address. As done by Nils in one of the answers, you can declare a piece of memory (usually array) and overflow it in such a way that the return address is overwritten as well.
I would suggest you to not blindly take any of the programs given here without actually understanding how they work. This article is very well written and you'll find it very useful:
A step-by-step on the buffer overflow vulnerablity
That is compiler dependent, so no single answer can be given.
The following code will do what you want for gcc 4.4.1. Compile with optimizations disabled (important!)
#include <stdio.h>
#include <stdlib.h>
void g()
{
printf("now inside g()!\n");
}
void f()
{
int i;
void * buffer[1];
printf("now inside f()!\n");
// can only modify this section
// cant call g(), maybe use g (pointer to function)
// place the address of g all over the stack:
for (i=0; i<10; i++)
buffer[i] = (void*) g;
// and goodbye..
}
int main (int argc, char *argv[])
{
f();
return 0;
}
Output:
nils#doofnase:~$ gcc overflow.c
nils#doofnase:~$ ./a.out
now inside f()!
now inside g()!
now inside g()!
now inside g()!
now inside g()!
now inside g()!
now inside g()!
Segmentation fault
Since this is homework, I would like to echo codeaddict's suggestion of understanding how a buffer overflow actually works.
I learned the technique by reading the excellent (if a bit dated) article/tutorial on exploiting buffer overflow vulnerabilities Smashing The Stack For Fun And Profit.
Try this one:
void f()
{
void *x[1];
printf("now inside f()!\n");
// can only modify this section
// cant call g(), maybe use g (pointer to function)
x[-1]=&g;
}
or this one:
void f()
{
void *x[1];
printf("now inside f()!\n");
// can only modify this section
// cant call g(), maybe use g (pointer to function)
x[1]=&g;
}
While this solution doesn't use an overflow technique to overwrite the function's return address on the stack, it still causes g() to get called from f() on its way back to main() by only modifying f() and not calling g() directly.
Function epilogue-like inline assembly is added to f() to modify the value of the return address on the stack so that f() will return through g().
#include <stdio.h>
void g()
{
printf("now inside g()!\n");
}
void f()
{
printf("now inside f()!\n");
// can only modify this section
// cant call g(), maybe use g (pointer to function)
/* x86 function epilogue-like inline assembly */
/* Causes f() to return to g() on its way back to main() */
asm(
"mov %%ebp,%%esp;"
"pop %%ebp;"
"push %0;"
"ret"
: /* no output registers */
: "r" (&g)
: "%ebp", "%esp"
);
}
int main (int argc, char *argv[])
{
f();
return 0;
}
Understanding how this code works can lead to a better understanding of how a function's stack frame is setup for a particular architecture which forms the basis of buffer overflow techniques.