[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] Shared Libs

Hi!

Guillaume Déflache wrote:

Hi Standa, glad to talk to you once again! :D


:)


BTW does my previous message got to the MiNT mailing-list???


I guess so...


Done :
...
TODO:
...
Eh.. quite a lot of things... But the problem is to maintain that amount in assembler. The other thing I see there is that it needs a TSR. I keep trying to avoid such things whereever possible. 


For now the TSR-launcher communication uses a cookie JAR with a pointer
to a function: IIRC this is ugly from a MP/VM/Unixish whatever point of
view (although I cannot remember why and where I read it). But it is the
simplest way I could think of for anything other than MiNT, as I did not
want to add a new system call (for MiNT I guess I would be the best
solution).
Hmm, Pexec() should handle that IMO. So TSR for patching TOS and kernel modification for MiNT. In case we go your way: modification of the OS. 


In short (assuming my_main.o contains the "main" symbol) :

Static linking:
my_main.o + *.o + *.a + crt0.o --(GCC linker)--> my_prog.prg
where + more or less means concatenation *and* resolving symbols


Errm? I thought (the order matters) it would be like this:

crt0.o + my_main.o + *.o + *.a -> (GCC linker) -> my_prog.prg


My approach:
cat launcher.prg main.o ${other_library_or_objects_to_embed} > my_prog.prg
where all symbols in not embedded library or object files will be
resolved when my_prog.prg starts
My intent was to not to affect people are building their applications. So simple gcc + ld should work without .o and .a files restructuralization into your 'main' library. This is unacceptable IMO. 
My proposals:

* Approach 1 - binutils and OS modification:

Modify linker to produce this:
crt0.o + my_main.o + *.o + *.a + {symbols to resolve (and their addresses)} + {.so libs list to load} -> my_prog.prg
The OS would recognize the symbol table and library list at the end somehow and would resolve all the loading/symbol resolution. 


* Approach 2 - binutils and mintlib modification:

Modify linker to produce this:
crtS.o + my_main.o + *.o + *.a + {symbols to resolve (and their addresses)} + {.so libs list to load} -> my_prog.prg
Where crtS.o would contain your crt0.o + launcher.prg(functionality only and modified to jump to the concatenated my_main.o to the _main symbol like it is doing now. However it would resolve all the symbols from the .so libs and adjust the references appropriately.
No Pexec() behaviour modification needed. Perhaps some helper syscalls, but not necessary IMO. 


Sure, there were never any of these in C AFAIK.
Of course, but I think some object formats (ELF) provide this (probably for C++ anyway). 

It is not ELF, but the C++ compiler symbol mangling that ensures this IIRC.
To start with something simple we can do the loader which just loads all the other libs to a private process context (no sharing at all). Later we will see what we can do about it more. 

That is not the hardest part IMHO, so I did it the other way round! :)


;)


Time to get my fingertips on it again! :)
I'm affraid that work would be unmaintainable by another person which is kind of unacceptable for longterm. The code language should be C for a code of this size I believe. It is like fVDI... nobody except Johan is able to tweak it. :( 

regards

STan