From fnaumann@mail.cs.uni-magdeburg.de Tue Aug 24 20:09:25 2004 Message-ID: <412B822B.1070800@seznam.cz> Date: Tue, 24 Aug 2004 20:00:11 +0200 From: Standa Opichal User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040810 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mint@fishpool.com Subject: Re: [MiNT] Shared Libs References: <1093209407.25052.9.camel@localhost> <20040823223705.61ea9ae3.mandin.patrice@wanadoo.fr> <412A657A.9070907@seznam.cz> <412AF784.8090809@users.sf.net> <412B26D5.30406@seznam.cz> <412B4E8C.3000204@users.sf.net> In-Reply-To: <412B4E8C.3000204@users.sf.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Delivered-To: mint@fishpool.com Delivered-To: mint@lists.fishpool.fi X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: opichals@seznam.cz Precedence: bulk List-help: List-unsubscribe: List-ID: X-List-ID: X-Milter: ClamAV 0.70/0.70kjel X-Milter: milter-regex 1.5jel X-Milter: ClamAV 0.70/0.70kjel X-Milter: milter-regex 1.5jel 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