call function in unrelated executable linux

Question

If I have a pointer to a function and I give that to another (Unrelated/Child) Executable, how can I call that function without making a segfault?

At the moment I can create a function and assign it this memory adress:

Dim As Function (ByRef As String) As Integer MyFunction
' get pointer...
MyFunction = FunctionPointer

But then calling MyFunction I get a segfault (Obviously because the function I am calling is in another executables adress space whitch I am not allowed to access)

How can I fix this/Work around it?

Peavey

At the level which the question is pitched, the most appropriate answer appears to be: you can't – Harlow

Answer 1

Update:

Note: this solution no longer works for newer GLIBC versions: dlopen refuses to open PIE binaries.

---

If you have control over the other executable (the one you want to call a function from), then build it as a PIE (position-independent executable), and load it into the first executable's address space.

In C, you would build with -fPIC -pie, then use dlopen(3) and dlsym(3).

In BASIC, I have no clue ;-(

Intrude

BAD idea. The executable's entry point will call the C library's initialization routine, which will reset the malloc heap and call the new executable's main, and all kinds of weirdness will result. – Expurgatory

You don't know what you are talking about. When libc.so.6 is dynamically linked (which it would be for a PIE executable), then libc initialization is not called by the executable's entry point; it is called directly by the dynamic loader, and the loader will not call it twice (there is no reason for it to do so). – Intrude

I'm referring to the calls to __libc_start_main called from statically linked entry point code in every C program. This, among other things, scans for the ELF aux vector (not present when invoked from dlopen), sets up stack guards (this WILL crash the program if it already thinks it has one), sets up TLS (which should already be set up, right? you just lost all TLS values) and does various other initialization – Expurgatory

When PIE-executable is dlopen()ed, it's _start is not called (you can verify that in the debugger). The _start in the (main) executable is only called once from _dl_start via RTLD_START macro. See elf/rtld.c and the definition of RTLD_START in e.g. sysdeps/x86_64/dl-machine.h – Intrude

Interesting. Does this mean that static constructors are not called? – Expurgatory

No, it doesn't. Static constructors on Linux are not called by _start or _main; they are called from a special .init section (referenced by DT_INIT in the PIE binary); both when the PIE binary itself runs, and when it is dlopen()ed by another executable. – Intrude

Interesting. I still hold it's a bad idea, though, given how many executables perform critical initialization in main() – Expurgatory

Answer 2

It's not so much that you're "not allowed to access" the address space of the other function, but rather that that space is a totally different and unrelated address space. Each process has its own virtual address space, so the numeric value of your pointer has no meaning inside another functions address space, even if you were able to exchange it somehow.

For general inter-process communication you usually request shared memory explicitly from the system, but I'm not sure if FreeBasic exposes such functionality. Why not look up some existing remote procedure call libraries?

Ruskin