This is an archive of the discontinued LLVM Phabricator instance.

[mips] Define macros related to -mabicalls in the preprocessor

Authored by sdardis on Jan 23 2017, 7:47 AM.



Historically, NetBSD, FreeBSD and OpenBSD have defined the macro ABICALLS in
the preprocessor when -mabicalls is in effect.

Mainline GCC later defined __mips_abicalls when -mabicalls is in effect.

This patch teaches the preprocessor to define these macros when appropriate.

This resolves PR/31694.

Thanks to Sean Bruno for highlighting this issue!

Event Timeline

sdardis created this revision.Jan 23 2017, 7:47 AM

Sending it to the correct list this time.

joerg added a subscriber: joerg.Jan 23 2017, 3:23 PM

I'm not terribly attached to using ABICALLS for NetBSD, but let me check back with some of the MIPS folks. I would prefer __mips_abicalls to be always defined though, independent of the historic behavior.

seanbruno accepted this revision.Jan 24 2017, 6:27 AM

FreeBSD is happy with this.

This revision is now accepted and ready to land.Jan 24 2017, 6:27 AM

As mentioned in D29032 I agree with @joerg - __mips_abicalls should always be defined if this is what GCC does.

As mentioned in D29032

Err, that should be D29024

@joerg , @emaste : My concern is that the stock gcc distributions for FreeBSD, NetBSD from your sources doesn't define __mips_abicalls, so I'm worried about potential incompatibilities.


Nit to self: this should be MIPS-ABICALLS-NETBSD64-NOT. Likewise for FREEBSD64 and OPENBSD64.

joerg added a comment.Jan 24 2017, 2:54 PM

Always defining mips_abicalls is certainly the saner choice. I'm discussing with the NetBSD/MIPS guys whether we just want to go with it all the time and drop our custom changes for ABICALLS__. Chances are quite good that we are going in that direction.

My concern is that the stock gcc distributions for FreeBSD, NetBSD from your sources doesn't define __mips_abicalls,

I think we should consider that a bug in GCC that we'll rectify. If __mips_abicalls is used in Linux GCC then we can expect 3rd party sources to check it, and we can migrate the in-tree (base system) uses to follow suit (even if we're stuck with the toolchain defining both indefinitely).

joerg added a comment.Feb 15 2017, 6:24 AM

No need to preserve the BSD behavior for NetBSD.

Ok, I'll have __mips_abicalls unconditionally defined for everyone, The other two BSD's will have the traditional macro defined as well.

This revision was automatically updated to reflect the committed changes.