From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 201 invoked from network); 5 Jun 1997 19:15:26 -0000 Received: from euclid.skiles.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 5 Jun 1997 19:15:26 -0000 Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id PAA27612; Thu, 5 Jun 1997 15:08:02 -0400 (EDT) Resent-Date: Thu, 5 Jun 1997 15:08:02 -0400 (EDT) From: Zefram Message-Id: <13453.199706051911@stone.dcs.warwick.ac.uk> Subject: Re: modules!?? To: hzoli@VNET.IBM.COM (Zoltan T. Hidvegi) Date: Thu, 5 Jun 1997 20:11:30 +0100 (BST) Cc: zsh-workers@math.gatech.edu In-Reply-To: <9706051824.AA14896@belgium.fishkill.ibm.com> from "Zoltan T. Hidvegi" at Jun 5, 97 02:24:55 pm X-Loop: zefram@dcs.warwick.ac.uk X-Stardate: [-31]9438.99 X-Phase: The Moon is New X-US-Congress: Moronic fuckers X-Personality: INTJ X-This-is-not-HTML: Content-Type: text Resent-Message-ID: <"4azOy.0.Kl6.Hwmbp"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/3212 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu Zoltan T. Hidvegi wrote: >Yes, I was thingking something like that. I do not understand what you >mean about several sizes of pointer. Could you give some more detail? The C standard permits most pointer types to have different representations and sizes. In particular, function pointers and data pointers are not even required to be losslessly convertible. So if we were to make a symbol table store void *s, it might not be possible to extract a working function pointer from it, and vice versa. However, on second thoughts, the dlsym() interface assumes that all pointers can be converted to void * anyway, so I suppose it wouldn't be a problem to assume that in our symbol tables too. >The nm output format varies from system to system, so it's probably hard to >make it portable. And one should not have to have nm to compile zsh. But >if we can automatize everything on Linux I'd be happy. There is one format for nm that is overwhelmingly common (BSD in origin, perhaps?). A script could detect whether the local nm conforms to this convention, and if so will have the capability to generate these symbol lists. (As the GNU nm uses the popular format, I expect this will include all of our usual development systems.) In case there isn't an appropriate nm around, we'd have to include the symbol lists in the distribution. More thoughts... We don't need to know the exact list of symbols imported by each module. If we know which *modules* it references, all symbols in that module can be turned into #defined symbol table references, and the module boot code only needs to get its hands on those particular symbol tables (a matter of looking throught the module table). There is no overhead for #defining a symbol that is not actually referenced. Since the module reference tree is small and doesn't often change, it can continue to be maintained by hand. We therefore only need to automatically generate the *ex*ported symbol lists. We already have a first approximation to the exported symbol lists in the *.pro files. If we extend these to include data objects (i.e., put data objects in their logical places and automatically generate extern declarations -- globals.h disappears), the *.pro files would be almost perfect symbol lists, without ever having to touch nm, or even compile anything. The icing on the cake would be for makepro.sh to pass #ifdef lines through to the .pro file, to cope with symbols that only exist conditionally. (Oh yes, I really like the things you are making makepro.sh do in 3.1.2. It's a much neater solution to the varying name problem than I had.) I should have some time to play around with these ideas this week, having just finished my exams. -zefram