294835 - Need way of determining ABI in makefiles

Status: RESOLVED FIXED

(Toolkit Graveyard :: Build Config, enhancement, P2)

Description

[Jens Bannmann]

In order to create robust support for platform-specific extension components, we
need a reliable way to detect the compiler type used to build the application.
@TARGET@ is not sufficient here - we need a new compile-time constant that is
filled by some hacky makefile rule.

Comment 1

[Benjamin Smedberg]

For the record, this is more about the ABI in use than about the specific
compiler: If we ever supported the intel compiler on windows, it would use the
same ABI as MSVC.

Comment 2

[Benjamin Smedberg]

cls: how would I tell gcc2.x and 3.x apart from configure/makefiles?

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

HAVE_GCC3_ABI

Comment 4

[Benjamin Smedberg]

Attachment: Add TARGET_ABI, rev. 1

This adds a var TARGET_ABI which can be used from makefiles. This var can (and
will) be empty if we don't have any special knowledge about the compiler in
use, but it at least serves the common purpose of distinguishing between
msvc/mingw and gcc2/gcc3. I'm vaguely concerned because I think we should
probably be adding 32/64-bit info to this var, but I'm not sure where to look
to get that information at all reliably, since MOZ_BITS is hardcoded to 32.

Comment 5

[Jens Bannmann]

(In reply to comment #4)
> Created an attachment (id=184407) [edit]
> Add TARGET_ABI, rev. 1
> 
> This adds a var TARGET_ABI which can be used from makefiles. This var can (and
> will) be empty if we don't have any special knowledge about the compiler in
> use, but it at least serves the common purpose of distinguishing between
> msvc/mingw and gcc2/gcc3. I'm vaguely concerned because I think we should
> probably be adding 32/64-bit info to this var, but I'm not sure where to look
> to get that information at all reliably, since MOZ_BITS is hardcoded to 32.

Then how about hard-coding 32 into TARGET_ABI for now? It can be replaced by a
real distinction as soon as the build system is aware of it...

Comment 6

[cls]

Comment on attachment 184407 [details] [diff] [review]
Add TARGET_ABI, rev. 1

Do gcc4 builds have their own ABI or are they using one of the gcc3 ABIs?  And
given that every minor release of gcc3 is technically incompatible, do we want
to lump them all together?

We already have a variable to determine the 64bitness of the build
(HAVE_64BIT_OS).   But given the flak that variable name is getting (bug
215688) perhaps we should resurrect MOZ_BITS to serve this purpose.

Comment 7

[Benjamin Smedberg]

Attachment: Add TARGET_ABI, rev. 2

For this purpose, because I just need to check ABI, I'm bypassing the 32/64bit
issue by using CPU_ARCH. If either TARGET_COMPILER_ABI or CPU_ARCH are not
recognized, TARGET_ABI is left blank.

Comment 8

[Jens Bannmann]

Comment on attachment 185169 [details] [diff] [review]
Add TARGET_ABI, rev. 2

>+    TARGET_ABI="${CPU_ARCH}/${TARGET_COMPILER_ABI}"

Before checkin, the separator should be changed to a hyphen instead of a slash,
so TARGET_ABI can be used in directory names.

Comment 9

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 185169 [details] [diff] [review]
Add TARGET_ABI, rev. 2

does TARGET_ABI just refer to vtable layout and calling convention, or also
stuff like name mangling?

Comment 10

[Benjamin Smedberg]

TARGET_ABI is the ABI of frozen symbols only (C exports and interface vtable
layout, C++ name mangling is not important).

Comment 11

[Mike Shaver (:shaver emeritus)]

Comment on attachment 185169 [details] [diff] [review]
Add TARGET_ABI, rev. 2

Do we have the same ABI for all MSVCs?	Do we need to be more specific there?

If the ABI is compatible, indeed, then maybe we should name it for the lowest
MSVC version with that ABI?  I guess MSFT can't really break ABI stuff, but
they've surprised me in the past!

Do we want to default TARGET_ABI to "unknownabi"?  That would make it easier to
spot in output, though maybe that's not the point.

Comment 12

[cls]

Comment on attachment 185169 [details] [diff] [review]
Add TARGET_ABI, rev. 2

Ok, so what you're actually targetting is the xpcom (xptcall) ABI, not a
specific compiler C++ ABI.  Perhaps TARGET_ABI should be renamed to
TARGET_XPCOM_ABI to remove any ambiguity.  Why do you include the OS in the
TARGET_COMPILER_ABI for the irixn32 case but none of the gcc cases? Isn't the
xpcom ABI defined as the compiler-OS-hardware trio?  And I agree with Jes about
using - instead of /.

Stupid question time: are athlon(?) builds still identified as i1586 and do
they use the same ABI or should they use the x86_64 abi?

Comment 13

[Benjamin Smedberg]

I will s/TARGET_ABI/TARGET_XPCOM_ABI/

The OS is included separately by the client code using this variable:

$(OS_TARGET)_$(TARGET_XPCOM_ABI)

So I do not need to specify the OS in TARGET_XPCOM_ABI. I use "irixn32" as a
special case because apparently we use the n32 ABI on Irix regardless of the
compiler. This is an educated guess based on reading configure.in.

My windows athlon64 machine is building on 32-bit windows and uses the MSVC
32-bit ABI. Right now I do not recognize either x86_64 or ia64, but I'm happy
for others to add proper detection for interesting processors later.

New patch shortly to cover the s|/|-| nit.

Comment 14

[Benjamin Smedberg]

Attachment: Add TARGET_XPCOM_ABI, rev. 3

Yet another iteration. Changes:

1) Instead of setting CPU_ARCH directly from the various WINNT sections, I set
OS_TEST and then only set CPU_ARCH if we recognize the result of OS_TEST.

2) config.mk has a bunch of OS_ARCH tests that don't belong, including a
separate OpenVMS instruction to set CPU_ARCH from `uname`. I moved these checks
into configure.

3) used TARGET_XPCOM_ABI instead of TARGET_ABI

4) changed "irixn32" to "n32", so the final IRIX vars would be "IRIX" and
"x86-n32"

Comment 15

[Benjamin Smedberg]

Fixed on trunk for 1.8b3