From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Fri, 20 Jun 2003 14:07:10 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 133 ************************************************** Thursday 19 June 2003 Number 133 ************************************************** Subjects for today 1 Re: libc : Knut St. Osmundsen" 2 Re: libc : Knut St. Osmundsen" 3 Re: libc : Dave and Natalie" 4 Re: [EMX] Re: libc : Holger Veit **= Email 1 ==========================** Date: Fri, 20 Jun 2003 00:57:19 +0200 From: "Knut St. Osmundsen" Subject: Re: libc Andreas Buening wrote: > Knut St. Osmundsen wrote: > > [snip] > > >>Build system isn't an issue anylonger, and even if it were, there are millions >>of them (allready responsible for 10+ (closed and open) myself). (If anything, a >>working GNU make is of much better use than yet another build system - the >>latest port is leaking a file/pipe handle everytime it's spawning a child, and >>-j is broken.) > > > Which make version? $ make --version GNU Make version 3.79.2a1, by Richard Stallman and Roland McGrath. Built for i386-pc-os2-emx [snip] $ ls -l `which make` -rwxrwx--a 112288 Feb 20 20:30 G:\GCCOS2\TREE\TOOLS\usr\bin\make.exe Kind Regards, knut **= Email 2 ==========================** Date: Fri, 20 Jun 2003 01:43:05 +0200 From: "Knut St. Osmundsen" Subject: Re: libc Stefan Neis wrote: > On Tue, 17 Jun 2003, Knut St. Osmundsen wrote: > > >>Now, I just wanna say that I do not see any reasons why there should be several >>efforts provding gcc and libc for OS/2. > > > Right. OTOH, we want to simplify life for people trying to port unix > software to OS/2. Ideally, "sh ./configure && make" should be enough, > so the libc must be quite unix-compatible. > > >>PS. Holger, by the by, named exports sucks performance wise on OS/2 - period - . > > > I keep hearing: > a) "named exports suck" > b) That's only true for antique versions of OS/2. Any modern version of > OS/2 with any remotely reasonable amount of RAM can use named exports > without noticeable cost in performance. > Could you experts please agree some time on whether or not b) is true? ok. I'll try explain quickly what the OS/2 loader does here. When ever a page is loaded, the loader will have to process fixups for that page. The fixups associated with a page is sorted so that the external fixups comes first and internal fixups last, this is to help the loader skip the internal ones for modules which are loaded at the address they were linked for. Each of the external fixups, or imports if you like, references a module and either a ordinal or a named export in that module. Looking up the module is very efficient since that is done using an index into the table of imported modules for the module. Finding an ordinal export is fearly simple, it's a matter of walking thru the export bundles for the module and find the one which contains the ordinal (struct b32_bundle in exe386.h). The bundle gives you the object and the particular entry in the bundle gives you the offset (exception is forwarders). This is only fast if the number of bundles is low, if the exports are a mix of data and code exports there will be a lot of bundles to run thru. Also gaps in the ordinal numbers makes bundles. For performance exports should be sorted by segment. Some OS/2 system DLLs are apparently ordering their exports trying to keep the bundle number low. Now finding a named export means the loader have to resolve the name into an ordinal first. This is done using two name tables, one resident and one non-resident. The resident is of course searched first if present. The two name tables are on this form: byte length_of_string; char achString[length_of_string]; word ordinal; Terminated by an empty entry. Each time the loader have to resolve a named import it will have to linary search thru the name tables of the module imported from. There it then finds the ordinal associated with the name and uses does the ordinal lookup I tried to explain above. Preformance wise, a big nametable takes time to search. C++ with it's long mangled names doesn't make this any better. Now if the name is in the non-resident nametable it might also have to be loaded into memory before it can be searched. I mentioned that OS/2 does this for every page load - OS/2 _can_ have external relocation for any page in the module. ELF and PE doesn't do it this way. They have structures in executable image which is dedicated for external relocations. I don't know how the symbol table of ELF is, but I know that PE (WinXX) have a sorted nametable for exported symbols so it can be searched in a binary fashion. Collection imports in the fashion of PE is possible when emximp can be sure the export is actually code, and it's a thing we're considering to support (if I get around to do it that is). And by the by, I did two mozilla builds here some months back. One with the default back then which was named imports, and one with only ordinal imports. The difference in startup time (on non hpfs.ifs disk) was noticable. Some 30% IIRC. Kind Regards, knut **= Email 3 ==========================** Date: Fri, 20 Jun 2003 08:31:07 -0800 From: "Dave and Natalie" Subject: Re: libc On Thu, 19 Jun 2003 21:49:47 -0700 (PDT), Steve Wendt wrote: >On Thu, 19 Jun 2003 21:06:42 -0800, Dave and Natalie wrote: > >>>$ ls -l `which make` >>>-rwxrwx--a 112288 Feb 20 20:30 G:\GCCOS2\TREE\TOOLS\usr\bin\make.exe >> >>Maybe try this one >>http://unix.os2site.com/sw/pub/binary/make/make-3_79_2a1-r2-bin.zip > >Isn't that the same one? Your right, sorry for the confusion Dave **= Email 4 ==========================** Date: Fri, 20 Jun 2003 14:13:34 +0200 From: Holger Veit Subject: Re: [EMX] Re: libc On Fri, Jun 20, 2003 at 02:15:34AM -0700, Ilya Zakharevich wrote: > On Thu, Jun 19, 2003 at 01:43:39PM +0200, Holger Veit wrote: > > Do we really want an improvement of the free OS/2 libc (call it EMX or > > different)? > > > > If the answer is yes, then we *must* break something in order to > > build something better, faster,more powerful (whatever the design goal > > is). This is the unavoidable price to pay. > > Now try to prove this. AFAIU, your argument looks very much like bullying. Proof by example: If we set off_t to longlong, structures like struct stat will change. We could get around with a specific distinction of struct stat and struct stat64, forcing each one to explicitly request the 64 bit APIs. It is unlikely to happen, so "old" code will still not be able to take advantage of JFS or other modern WSEB filesystems. One could argue that we would not need support for this then anyway. So why should we change anything then? Stay with the bugs and problems of EMX. There are some more incompatibilities to occur; let's assume setuid() and chown()/chmod() would get implemented; thus an awful lot of software would suddenly underlie file protection effects, including the effect that former NO OPs (like setuid()) that simply returned 0 for success, will now fail. Not only that, some eager porters have used #define setuid() (0) or similar to get code work; suddenly such software would subtly fail, because the process does not get the appropriate privilege and the original check whether the process gained setuid privilege from the Unix code which would fail on a real Unix is disabled due to that (0) return. Consequence: if you want to avoid subtle breaking of the code, just avoid putting such code in. Stay with the bugs and problems of EMX. If this is not sufficient as a proof, I cannot help you. Besides: I don't think anyone needs backward compatibility at all for a DLL which is then not even named EMX*.DLL even if it stemmed from EMX and maybe shared 90% of the code. Old apps can still resolve against old EMX*.DLLs, and for new apps one has to clearly decide what he wants - again, see other posting a question of decision making which is fatally flawed here: Do you want Unix or EM(i)X? Requesting EMUNIX or UNEMIX is not the answer - this will never happen. Holger Holger