Re: Multiple ABIs for a single compilation unit?

[Lauri Alanko <la at iki dot fi>]

On Thu, Apr 22, 1999, it occurred to Martin v. Loewis to write:
> > Has anyone given these things a thought, or am I the only one who thinks 
> > this is an issue? I think in the future, multiple ABIs will be more of a 
> > reality, and it would be more important to get a single program to
> > utilize many of them, if at all possible..
> 
> Some of the issues you mention are serious, but I don't like your
> proposed solutions.
> 
> The header file *is* the place to declare the ABI. This has a long
> tradition:
> - In C++, external function may get a linkage declaration (extern "C")
>   which affects the ABI.

This is indeed a good example. But the difference is that you can do
extern "C" {
#include <c_header.h>
}

And thus the header itself need not know about ABI issues.

> - Microsoft has been putting ABI aspects into prototypes for ages
>   (remember: far pointers, stdcall attributes, declspec(dllimport))

Then again, in M$ world there isn't a very wide variety of ABIs, at
least you can't compile the system libraries with arbitrary options
yourself.. And what little I've seen of multi-platform library headers
that support M$ systems, their headers usually do look like a horrible
mess..

> - packed structures are declared together with the structure in a number
>   of compilers.

All right, but these are (to my understanding) mostly used in very
architecture-specific situations, and then worrying about ABIs isn't
your biggest portability problem.

> I don't think header maintainance would be too terrible: the examples
> above show what common strategies for these problems are.

Usually, the common strategy is defining macros for all possible
nonportabilities, and filling your headers with these. It works,
granted, but it's not pretty, nor very fun. And messing with system
headers is not an option under in any situation.

> That __attribute__((regparm)) doesn't work for inherited methods is a
> clearly a bug; the right solution is to fix the bug, not to avoid the
> feature.

That is true, of course. It was just an excuse for my dislike of
function-specific attributes for generic ABI matters.

> You didn't elaborate where exactly your command line patterns are
> specified. Whatever the approach is, it seems unmaintainable: When I
> install a library, how do I know what magic patterns I have to use?

You just have to know, just like you have to know where your library's
headers are located, and what other dependency libraries you need to
link with (unless you have a smart enough linker). What would be the
alternative? That all libraries declare their ABI in header files? That
would in theory be possible, but obviously it's not a common practice,
and one can't change the world.. Since this is a pretty marginal issue
(yet, anyway), it seems much more sensible that the user of the libraries

> So, I'd rather prefer to use the existing techniques. If you
> absolutely want to have short-cuts, feel free to write a tool that
> reads the directory lists and then automatically puts the right
> __attribute__s into all function declarations.

Now that is ugly. It is my opinion that when you need compatibility with
something, you should never write something that translates old things
to new things (since there is an indefinite amount of the old things),
but rather change the (finite number of) users of the things to
understand both old and new things. That is, better to modify the
one compiler than all the code in the world.

Actually, upon thinking a little, I do agree that my original idea
wasn't very practical or clean. But your example of C++'s extern "C"
does have the right idea. You can use it to specify the linkage (ABI, if
you will), of a _block_ of code, and this is a very good thing. C
headers don't declare their linkage in their headers (usually), C++
programs that include them do it. So how about extending the same syntax
for some gcc-specific abi definitions?  Like:

extern "regparm=2" "rtd" {
#include "MyLibHeader.H"
}	

This would to me seem quite sufficient, for then it would be easy for
one to do wrapper headers as one needs. Of course the syntax doesn't
really matter, even something like

__attribute__ ((regparm(2)) {
...
}

would be okay. The important thing is that you can somehow declare any
ABI options for a block of code without touching the actual headers.

The other way would of course be some #pragma directives, but since you
can't make macros out of those, that doesn't seem very attractive.

Even the current __attribute__s for function call conventions are a bit
lacking. To my knowledge, there are no attributes for
-freg-struct-return, -fname-mangling-version-x, etc. Having all of these 
definable on a per-block basis would, I think, help in migrating to
newer name mangling versions etc..

So is there any idea in this? I might even be able to help in
implementing it, although currently (having occasionally glanced at the
source), I have no clue of the compiler's internals...

Regards,


Lauri Alanko
la@iki.fi