tagging data/funcs for export

[DJ Delorie <dj at delorie dot com>]

When building the cygwin dll, we export various bits of newlib so that
they're visible to the applications.  However, we have recently
discovered:

1. Not everything is being exported.

2. Data items aren't being properly tagged in the headers so that they
   can be imported correctly.

Rather than hack a few bits here and there to fix immediate problems,
I'd like to discuss a scheme for marking the API points in newlib that
could be reused for other dll-like applications (AIX so's come to
mind).

I'm thinking of, maybe, macros like APIDATA(foo) or APIFUNC(foo), or
instead PUBAPI(sym) for exports and APIIMPORT for imports.

Here's what Cygwin needs for imports/exports, for a baseline:

-- exporting functions --

Functions are exported either by being listed in cygwin's cygwin.din,
which is a clumsy, manual, error-prone process.  Unlisted functions
are not exported by default, meaning that applications linking against
cygwin cannot use those functions (like malloc_r, for example).

Individual functions can be tagged for export at the source level
by using a syntax like this:

__declspec(dllexport) int foo (int x)
{
}

When thusly tagged, they will be exported even if omitted from
cygwin.din.

-- exporting data --

Same as functions.

__declspec(dllexport) int bar;

-- importing functions --

Nothing needs to be done; just link.

-- importing data --

This is different.  Because dlls can only export *pointers*, gcc
MUST know when data is being imported so that it can change
all data references to indirect references.  To tag such data,
the header files must have this kind of syntax:

extern __declspec(dllimport) int foo;

Note that when newlib itself is being compiled, these definitions must
NOT be seen by gcc.  Usually, we define a macro DLLEXPORT that is
either "" or "__declspec(dllimport)" depending on whether you're
building the dll, or an application that uses it.  Such declarations
then become:

extern DLLEXPORT int bar;