Is busybox available in shared library form? I would like to use individual apps programmatically instead of using system(). I've heard about libbusybox and libbb but could not find any documentation.
There exists busybox library in a shared form called libbusybox(.so), you just have to enable it while making menuconfig. When you have compiled, it will be avalible in 0_lib folder. In this library you have nice little function called int lbb_main(char **argv).
What you need to do in your code is something like this:
extern int lbb_main(char **argv);
int main()
{
char* strarray[] = {"ifconfig",0};
lbb_main(strarray);
return 1;
}
You could import libb.h, but that didn't work for me, because I got many errors.
After that you just have to compile using somethin like gcc -o code code.c -Lpath_to_0_lib_fodler -lbusyboxand that's it!
To intercept output you will have to redefine printf and similar calls, buts that's clearly doable by using soemthing macros like #define printf(...) code' inlibb.h'.
You could even spawn busybox's shell that doesn't use fork or system, but that doesn't work well yet.
If you are on a tiny embedded system where it matters, you can link your own app into the busybox binary, then you can call its functions without any dynamic linker at all.
If you are not, just use system(), or some fork/exec combo.
It is unlikely you'll want to call the utilities so often that performance matters.
Related
I'm building a plugin (extension module) system for a language interpreter I'm writing in C.
During runtime, the program uses LoadLibrary in order to load a specified DLL file. This seems to work, with basic DLLs which don't depend on functions defined in the main program.
However, I'm trying to build a plugin DLL which does depend on functions which are defined in the main program binary.
To do so, I defined a interface.h header in the main code base, for these plugins to include and use. It defines the headers for the functions they might require. The plugin does #include <interface.h> in its header.
I compile the plugin DLL like so:
gcc myplugin.c -shared -Wl,--subsystem,windows -D MYPLUGIN_EXPORTS -o myplugin.dll -I..\main_program_headers
I then get the following kind of errors:
undefined reference to 'some function name'
Does this mean I have to compile the plugins with dynamic linking to the actual binaries they depend on in the main program?
If so, does this mean I need to keep the individual .o files of the main program around, even after linking them to the result .exe? Can GCC link directly against the .o files?
Anyway, I really hoped LoadLibrary takes care of fixing the function references on load during runtime. Doesn't it?
Update:
As #tenfour kindly answered, a DLL must follow normal linking rules and function references need to be resolved at build time. He / she suggested a system where the host program passes into the plugin pointers for the needed function.
This approach will indeed work, but I would still like to know:
What kind of build process is necessary to allow the plugin to call functions from the main app directly, without any special system at runtime (except for LoadLibrary).
I would like to say that my main source of influence here is the extension system for the CPython interpreter. It seems to me judging by its documentation that a CPython extension doesn't receive function pointers from the host interpreter, and is still able to directly call Py_* functions from it.
Any idea how such a thing can be done? How can the plugin DLL be built to support this? What and how do I need to link against?
Since you didn't post interface.h, I can only guess that you are forward-declaring functions there, for example:
int some_func();
If the plugin code tries to invoke this method, it will compile, but the linker has no reference to it. The body of that function only exists in your host application.
Instead, if you want to dynamically link, using LoadLibrary, you need to use function pointers, e.g.:
typedef int (*some_func_ptr)(); // declare the fn pointer type
...
some_func_ptr some_func = x; // assign it after the host passes you x
...
some_func(); // now you can call it without linker issues.
And viola you have used dynamic linking to create a plugin system. Of course the design of your interface will force this to be more complex but that's mostly just labor once you understand the concept.
I am working on a C program (under Linux ) that relies on shared libraries as plugins.
I provide each plugin with several functions from a static library of mine. In order to change the workflow of my program, I need to know at runtime whether a plugin is going to call a certain function included from the aforementioned library.
What I need is the C equivalent of:
readelf -a ${PLUGIN_NAME} | grep ${FUNCTION_NAME}
Is that possible to exploit the <dlfcn.h> library in order to achieve that ? Needless to say, I prefer not executing the oneliner above in a system() call.
Thanks
You can try LibELF which allows you to manipulate ELF binaries (i.e. read sections). Very nice examples you can find here.
i have program like
int main()
{
char *ptr = malloc(2);
free(ptr);
}
So i just want to trace of all function calls happening inside the program ,till system call
like
malloc
|____ libc( sme_fn)
|
|__sme_system_call
Could you please tell some way to get this ?
As you know, "system calls" come in two flavors:
Calls directly to the operating system ("open", "close", "fork", "exec", "exit", etc)
Standard C runtime functions for the platform ("printf()", "malloc()", "free(), etc.)
You can view the former with "strace".
You can view (at least calls into) the latter with gdb.
You can look at the complete implementation, and all internals, directly from the source code:
Gnu C Library
Linux kernel
Finally, if you're having issues with "malloc()", "valgrind" is (one of several) very, very useful tools to consider.
If you're using gcc, compile with -pg and then use the gprof command.
Or, if you're on Linux, you can use oprofile to do something similar without recompiling.
Both tools should give you call graphs, which is what you're looking for.
c and i use it to generate x.so shared library
in x.c i want to use few functions that are in the main module, (dir containing main files and exe), kind of recursive dependeny.
is there a way to do this (without copying those functions in x.c) ?
i read about -rdynamic , but could not get it fully.
when i compile i get 'somefunc' undeclared. (somefunc is in main module, i did extern somefunx in x.c but did not work)
please let me know
thanks
You could define the affected methods in your shared library to take the call back function pointer arguments, and then at call time pass the main module's functions as arguments. E.g.
// Library
void dosomething (int arg, void (*callback)(void)) { ... }
// Main module
void called_from_lib(void) { ... }
dosomething(10, called_from_lib);
This looks like unix. There is a function, dlopen(), that lets you dynamically call a function in a library - without referencing it at compile time and without linking it into the program. dlopen() is POSIX, and so should be on any modern unix box.
Example here:
http://www.dwheeler.com/program-library/Program-Library-HOWTO/x172.html
There is also LD_LIBRARY_PATH. This environment variable lets you use the same code, but allows you to substitute in a library that was not there at compile time. This is not exactly what you are asking, but it can be made to do something along the lines of using adhoc shared libraries without resorting to dlopen. Some systems like HPUX also support SHLIB_PATH which does the same thing.
I would like to trace calls to some 3rd party library which are made from another 3rd party library.
Example: I want to trace calls to library A. My application statically links library B, which in turn is statically linked to library A. So basically what I have is libAB.a
In case of dynamic linking I could write library A2 with wrappers for functions which I want to trace of library A and use LD_PRELOAD=A2.so. Then, my wrappers will be called instead, and I will see the trace.
In my case I cannot use dynamic linking.
Is it possible to achieve the same using static linking?
In ideal case I would like to link my application with libAB.a and trace library libA2.a and get the trace.
Thanks,
Robusta
Okay, I found it :)
man ld
--wrap symbol
Use a wrapper function for symbol. Any undefined reference to symbol will be resolved to "__wrap_symbol". Any undefined ref‐
erence to "__real_symbol" will be resolved to symbol.
This can be used to provide a wrapper for a system function. The wrapper function should be called "__wrap_symbol". If it
wishes to call the system function, it should call "__real_symbol".
Here is a trivial example:
void *
__wrap_malloc (size_t c)
{
printf ("malloc called with %zu\n", c);
return __real_malloc (c);
}
If you link other code with this file using --wrap malloc, then all calls to "malloc" will call the function "__wrap_malloc"
instead. The call to "__real_malloc" in "__wrap_malloc" will call the real "malloc" function.
Depending on how much performance matters you could do it with gdb... (Set a breakpoint on all the functions you care about and log the stack traces... but that involves learning how to script gdb)
There's also things like Oprofile http://oprofile.sourceforge.net/, LTTng http://lttng.org/, and perf (comes with recent kernels in the kernel source it's under tools/perf/ you need to compile it, on Ubuntu I think it's in the linux-tools package)
I can't tell you how to achieve what you want with any of those tools but oprofile and LTTng have lots of documentation and an active user community.
Well, it seems like a dead lock :)
But I think you may solve it using macros. Although this solution might not be clean and may not work for all situations.
You can try this:
void functionFromLibA();
#define functionFromLibA() trace(); functionFromLibA()
int main()
{
functionFromLibA();
}
This will be expanded to:
void myfunc();
int main()
{
trace(); functionFromLibA();
}
EDIT: But note that for this solution, all declarations of functions prototypes should be done before defining the macros. Else you will have the prototypes expanded in preprocessing as well.