Ndless bFLT loader

Update:

Houston, we have a problem!

I've been working on getting shared libraries working and I've modified the toolchain slightly to produce shared libraries and have them link (almost!) correctly to binaries. I can also grab the address of the function of the shared library at runtime. Basically, the bFLT loader support for shared libraries is done.

But there's a problem. I noticed that the address the binary actually branches to doesn't match the address of the function. Whatever it's branching to, it's also crashing the calculator.

Turns out GCC inserts some code verneers (or bridge, if you like) that is supposed to "glue" the main binary to the shared library. This is bad for us because the address the code verneer directs us to is not relocated.

Here's a nice colorful diagram:

Basically, calling a shared library function looks like this right now:

Code: Select All | Copy To Clipboard

1 2	library_call() -> gcc code verneer -> unrelocated address = crash

~~We want GCC to skip making a code verneer so it looks more like this:~~

Code: Select All | Copy To Clipboard

1 2	library_call() -> library function = win

~~Theoretically, we could work around this by defining and using a macro like this:~~

Code: Select All | Copy To Clipboard

#define DIRECT_LIB_CALL(x, args...) do { \
        typeof(x) * volatile tmp = x; \
        tmp(#args); \
    } while (0)

DIRECT_LIB_CALL(library_call);

That should bypass the code veneer but of course, this isn't very elegant nor portable.

All the code is in the shared-library-support branch of the main project.

If anyone can help me look for an option to disable the making of a code veneer (also known as code glue, code bridge etc...) when linking with shared libraries, that would be great.

Never mind, discovered a workaround (although quite annoying)