From mint-bounce@lists.fishpool.fi Sun Oct 31 00:20:49 2004 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Message-ID: <4184138D.7090304@highlandsun.com> Date: Sat, 30 Oct 2004 15:19:57 -0700 From: Howard Chu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041002 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Patrice Mandin Cc: Mint list Subject: Re: [MiNT] Shareable/loadable libraries: a preliminary document References: <20041029210939.1d32bc21.mandin.patrice@wanadoo.fr> <693A750D-29E7-11D9-B308-00039357F826@epfl.ch> <20041030211600.422fdada.mandin.patrice@wanadoo.fr> <0322B8A2-2AB7-11D9-91AD-00039357F826@epfl.ch> <20041030233014.0fa3d0eb.mandin.patrice@wanad In-Reply-To: <20041030233014.0fa3d0eb.mandin.patrice@wanadoo.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by highlandsun.propagation.net id i9UMJxmg000522 X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: hyc@highlandsun.com Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: X-Virus-Scanned: by amavisd-new at relay.boerde.de X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on relay.boerde.de X-Spam-Status: No, hits=-1.0 tagged_above=-50.5 required=3.8 tests=BAYES_00 X-Spam-Level: Patrice Mandin wrote: > Le Sat, 30 Oct 2004 23:02:30 +0200 > Philipp Donz=E9 a =E9crit: >>>Even if an executable has only one translation table, you know the=20 >>>size of the TEXT segment, so you know if you are relocating an address >>>in the TEXT or the DATA segment, so you can align the segments on MMU >>>pages boundaries. >> >>But this doesn't work if the compiler generates PC relativ addresses.=20 >>E.g. "move.l data(PC), D0" can't work correctly if the assembler does=20 >>not know the correct offset to generate. >>I must admit, I'm new to GCC. But Pure C makes extensive use of PC=20 >>relativ addressing modes. (=3D> this gives smaller and faster code) > You're right, I did not think of the case of relative to PC. But I don'= t > know if gcc generate this type of code or not to access the DATA segmen= t. > You talk about PureC, but I don't know if creating dynamic linked > libraries will be possible with it, so I just stick with binutils+gcc. > And on Linux, the segments are aligned on a page boundary to make the T= EXT > segment read-only, so either it is done: > - in the file > - no relative to PC when accessing a different segment On systems where -fPIC is supported, the compiler assumes that the data=20 segment will always be mapped at a fixed offset from the text segment.=20 Thus an MMU is required so that every process sees the same memory map.=20 This has always been the stumbling block that prevented using gcc's=20 existing PIC support for Atari; we always had to bend over backward and=20 support 68000 in addition to everything else so we couldn't rely on the=20 presence of an MMU or virtual memory. The fix for this was to add the -mbaserel support to gcc, so that all=20 data references were relative to a base register which was loaded with=20 the address of the data+bss segment. Unfortunately I don't think the=20 baserel code has been maintained through recent gcc releases. It's been=20 a long time since I looked at the gcc/Atari code. Also, as I recall, the MiNT kernel support for baserel executables was=20 dropped a long time ago. The hardest part in making the baserel code work for shared libraries=20 was loading the proper offset into the base register when calling into a=20 shared library function. On Unix systems with virtual memory, there's no=20 problem as I noted above because the code can just use a fixed offset=20 from its own text segment. If you can mandate that virtual memory is=20 being used, you can use the same approach. Otherwise you need a search=20 function to locate the data segment for the current shared library. I believe the correct approach is still to use baserel, even though it=20 sacrifices an address register. This is the approach that SPARC and=20 other RISC machines use (of course, they have more registers to work with= ). I'm not sure that you need to define a new EXE format, but it may be=20 helpful to adopt M68K ELF format. That lets you leverage a lot of=20 existing binutils support. For flexibility, I believe you should adopt the external linker approach=20 - i.e., on a dynamically linked program, the first piece of code=20 executed simply loads ld.so which goes through and links all the=20 dependent shared libraries. Again, you can adopt most of the dynamic=20 linking support already in GNU libc if you follow this route, so life=20 should be relatively easy. Every shared library should export a Procedure Linkage Table which=20 external modules will use to access the library's entry points. To=20 support lazy resolution, the code pointed to by the PLT will initially=20 all point to a function that invokes ld.so. This function then searches=20 the dynamic link table to resolve a symbol to its actual entry point. For sharing compatibility on non-MMU systems, I suggest that this entry=20 point actually be a search function that locates the data segment for=20 the shared library. The binutils linker will need to generate these=20 stubs. All calls within a library can execute directly, all calls from=20 outside the library must perform a segment swap on the base register. When compiling PIC, code never directly accesses data, it always goes=20 through a Global Offset Table. One of the jobs of ld.so is to populate=20 the GOT with the actual address of every data variable. There will be a noticable decrease in performance for dynamic code vs=20 static code because of this indirection, but it needs to be done, even=20 with an MMU. The linker must generate the GOT and include it in the object files.=20 Most of the code to do this already exists for ELF platforms. Also, ld.so should be a baserel program, but I don't think it needs to=20 be fully PIC. --=20 -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support