Re: modules!??

[Zefram <zefram@xxxxxxxxxxxxxxxxx>]

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