dynamically calling functions

dynamically calling functions

Post by Chad E. Dioni » Wed, 10 Jun 1998 04:00:00

What I would like to do is be able to call a function in a library
without it being named in the
source file.  For example:

        printf("test> ");
        for(trav=str; (!isspace(*trav)); ++trav);
        strncpy(cmd, str, (trav - str));
        cmd[trav-str] = 0;
        strcpy(arg, trav + 1);
        /* command here */


when run:

test> puts hello

would dynamically find the function "puts" and call it to print out
I DO NOT want to put a switch with every system call in it.  I do not
if it is a non-portable solution such as manually look through a library
and write assembly to put the arguments on the stack.

Thank you



dynamically calling functions

Post by Ben Pfaf » Wed, 10 Jun 1998 04:00:00

   What I would like to do is be able to call a function in a library
   without it being named in the
   source file.  For example:

See manpage dlopen(3).


dynamically calling functions

Post by Bernd Paysa » Thu, 11 Jun 1998 04:00:00

> You can use dlopen() to open the shared library, and then use dlsym() to
> search for a function by name and then call it. Of course, you still have the
> problem of casting the function to the appopriate pointer type.  If it is a
> function that takes a single char * argument and returns int (like puts), you
> have to create a function pointer of type ``int (*)(char *)'', cast the
> pointer returned from dlsym() to it and use that pointer to do the call. So
> you may still end up with a large switch for different kinds of function
> signatures.

On the x86, it's fairly easy - there are only four different function
types: {void,int,long long,double} (*)(...). The problem: this is not
portable. GCC has some supporting functions, but __builtin_apply_args
can't construct argument lists portably (it only creates the argument
list of the function it's in - and that's what I can have without all
this __builtin_apply* functions).

If GCC had a propper set of functions (the corresponding functions for
the vararg functions), you could write something like

void call_library_void(void (*function)(), char * params, ...)
  va_list ap;
  apply_list al;
    switch(params[i] {
    case 'i': applyarg(al, int, varargs(ap, int)); break;
    case 'f': applyarg(al, float, vaargs(ap, float)); break;
    case 'P': applyarg(al, void*, vaargs(ap, void*)); break;
  apply(function, al);


sample usage:

  call_library_void(printf, "Piif", "%d %x %f\n", 1, 0xabc, 3.5);

I hope you get the idea.

We (the Gforth development team) discussed this recently, since we want
to include a portable library interface. IMHO it is useful for any
scripting language (Forth, Perl, Python, etc.) to allow interfacing to
shared libraries without much overhead. However this either needs
compiler support or at least architecture specific files to create
something to feed __builtin_apply with. Volunteers, any?

Bernd Paysan
"Late answers are wrong answers!"


1. HELP:cant call functions dynamically via nlist!?

I have some 'System V' code to port to the RS6000 that makes dynamic function
calls, ie it uses nlist(3) to search its own symbol table at run time for a
named function and directly calls the address returned by nlist.

This process fails because the RS6000 nlist appears to return a value for the
symbol that is an offset into the data segment (probably into the TOC), which
when dereferenced should give the address of the function. At least it does in

Unfortunately when my code dereferences the pointer I get 0, probably because
my address is treated as an offset from the beginning of segment 2 (private)
rather than from the origin of my data section?

I can find no answers in info, or the man pages or the system headers so does

1) Know how to call function addresses returned by nlist?


2) Know how to read explicit locations from the (local) data section?

Thanks in advance for any help.


  Bull Information Systems
  Maxted Road  -  UK03-HM14
  Hemel Hempstead
  Herts  HP2 7DZ                Tel:    +44-442-88 4250
  England                       Fax:    +44-442-88 4570

  "The future ain't what is used to be!"

2. Compiling problem

3. how to know the instruction address of calling function within called function?

4. Holy crap! Sorry about multipost!!

5. Browser calls CGI C function which sets an env var and call a c function crashes

6. Broadcom bcm 4401

7. Call function within a function

8. Notebook/laptop recommendation?

9. Tree of Functions calling Functions etc.

10. Main function calling another main function

11. Non-__init functions calling __init functions

12. Name of the function/script that called the actual function?

13. C functions calling C++ functions on Solaris