How do I access functions from all compiled software?

What do you mean by "access"?
Since you have the standard C library (and C++ and a few other languages) as part of the base system, and since you can install lots of development libraries, you can just call all the functions from the kernel and all these libraries. Or are you looking for manual pages for these functions? That's usually what man is for. Or are you looking for an IDE which offers autocomplete when writing source code, and suggests functions? I know several of those, and I presume some (like eclipse) are available in FreeBSD. I don't know whether/how emacs can do this, never tried.

Please explain in more detail what you really want.
 
Sorry for any misconfusion

For example, lets say theres the function "displayWindow(char* titleName, int id)" in gui.h in binary program /usr/local/bin/Xtest

I could fire up a program that reads the source code of Xtest from /usr/local/src/Xtest or debugs Xtest using gdb and execute it at any point in the programs execution, perhaps even while the program isnt running too but again that can be done with gdb. I would write something like:

gdb_execute_function /usr/local/bin/Xtest DisplayWindow("This is a test", 200)

and it would execute the function from the binary, not from the source code. This could be excellent for debugging or general hackery.

How I want this to be done is either to read the source code of Xtest then run it against gdb, or use gdb for the whole thing.

I'm not that great of a programmer so I need help writing some sort of browser for all functions in a binary and the kernel. Maybe if you hack emacs enough it can read C library code instead of lisp in its built in browser. The hard part is executing the function correctly.

I can explain more if needed
 
You can always use nm(1) to extract dynamic symbols from a shared library:

Code:
nm --dynamic --extern-only --defined-only /lib/libc.so.7 | less

For executables your question makes no sense in a general case because the executables will only have the unresolved dynamic symbols visible, references to other symbols are already resolved at link time. You can compile everything with DEBUG turned on which prevents the executables from getting stripped from debug symbols and then you can inspect all symbols with nm(1) but that still won't give you the possibility to call those functions from the outside.
 
You might want to look into LuaJIT and in particular FFI. For example:

Code:
local ffi = require("ffi")
ffi.cdef[[
int printf(const char *fmt, ...);
]]
ffi.C.printf("Hello %s!", "world")

Or, a Windows API specific example but actually quite impressive:

Code:
local ffi = require("ffi")
ffi.cdef[[
int MessageBoxA(void *w, const char *txt, const char *cap, int type);
]]
ffi.C.MessageBoxA(nil, "Hello world!", "Test", 0)
 
Methods seldom are atomic, there may resources to be allocated, files opened,… this might fail more often than not.

For a system allowing much of what you want maybe you should check out forth.
 
check out forth.
I have actually been looking for something similar to the OP that does work better with the complexities of C. Can I ask specifically how forth might be a good avenue? In my experience it is just a very portable stack based system. Can this interface better with C for various reasons I am missing?
 
Forth is not per-se better in that but it is also a functional language where globals are avoided, thus increasing the chance that calling something actually works. Also the command prompt of the system gives you immediate access to all symbols, so maybe even to externals from shared libraries? More research is required.
 
Take a look at this: Radare2.

I don't know if it will build in FreeBSD; I have not tried it. I generally use it in Linux and it provides a lot of very useful capability (though you won't be able to invoke an internal function from outside).

I suspect it can be made to build in FreeBSD if it doesn't already support that, but given that I have not tried it I don't know for sure.

edit: I just checked, and it does say it runs on *bsd.
 
I suspect it can be made to build in FreeBSD if it doesn't already support that, but given that I have not tried it I don't know for sure.

Heh, I actually made the initial port of Radare2 to FreeBSD (The hard work was already done by the authors, I just wrote the port's Makefile) :)

Yes, you could use it to call into C libraries. I would expect it to be quite unsafe and cause a lot of crashes for some of the more complex stuff though.

That said, perhaps one of the underlying technologies could be useful? http://www.unicorn-engine.org. It would require work to make something usable but it might be a start.
 
Heh, I actually made the initial port of Radare2 to FreeBSD (The hard work was already done by the authors, I just wrote the port's Makefile) :)

Yes, you could use it to call into C libraries. I would expect it to be quite unsafe and cause a lot of crashes for some of the more complex stuff though.

That said, perhaps one of the underlying technologies could be useful? http://www.unicorn-engine.org. It would require work to make something usable but it might be a start.
Hmmm... there is no thumbs-up smiley. :D
 
it can be done with gdb, Ive just been busy at work

basically attach gdb to every process and issue some sort of queue system, the fault in this; is gdb only debugs in a linear fashion, but it can be hacked into an input/output server type thing

for example, I could do:

debug wine

gdb will debug wine step by step, the server takes this information and stores it for future use
if you call the function from within the binary from gdb, it cycles until it finds the function and execute it
clean up

that works, right?
 
Back
Top