gnupic: Re: [gnupic] Re: gpasm `extern' vs `global' (new feature patch)
Subject:
Re: [gnupic] Re: gpasm `extern' vs `global' (new feature patch)
From:
Ian Jackson ####@####.####
Date:
17 Jan 2006 19:47:34 +0000
Message-Id: <17357.18896.746756.213941@davenant.relativity.greenend.org.uk>
Craig Franklin writes ("Re: [gnupic] Re: gpasm `extern' vs `global' (new feature patch)"):
> Please post a project that uses the new feature. I want to make sure I
> understand how you are using it.
http://www.chiark.greenend.org.uk/ucgi/~ijackson/cvsweb/trains/
http://www.chiark.greenend.org.uk/~ian/d/trains-snapshot-2006-01-17.tar.gz
The nicest directory you want is probably the detpic one; the others
were tests and experiments.
Note that the files there don't have a uniform copyright status; for
ease of constructing my build system I've mixed in (eg) SPICE models
from semiconductor manufacturers and other things with restricted
licences. So you should ask me before redistributing.
> Back when I wrote gplink, I found out all sorts of neat things about
> mpasm. They allowed the same symbol name to be local and static and
> also be extern (might have the details wrong, but you get the idea).
It's conventional for a toolchain to distinguish symbols local to each
file from global symbols with the same name; but often this is done by
having the local symbols not appear in the object file at all (since
they're not needed for linking). I haven't looked at gputils's
arrangements for this in detail.
> This history has me more than a little cautious about this change. It
> looks innocent enough. If this feature is added, there will have to be
> a command line option to enable it. Another option is to create a new
> direction, unique to gpasm, to prevent confusion. Regardless, I will
> wait to see your project before deciding on incorporating your patch.
I have no objection to a new directive. That would solve the problem
just as well. But, note that this feature only applies new semantics
to what was previously an error so there is no need for an option to
turn it on (unless you think people will accidentally glue together
identically-named symbols in different files).
> I did add a feature to gpvo to help with this problem. Don't remember
> if I told anyone. There is a symbol export feature on gpvo. It reads
> an object file and exports all the global symbols to a test file. Of
> course you still have to include that file, but most of the hard work is
> done. Should be simple enough to add to automate. Circular references
> might be a problem.
I have had some success with seddery of source files, but this (like
your suggestion) feels rather like a hack to someone who really
expects a toolchain to work the way the Unix C one does.
Thanks,
Ian.
