This is an archive of the discontinued LLVM Phabricator instance.

[Solaris] replace Solaris.h hack with a set of better hacks
ClosedPublic

Authored by fedor.sergeev on Jun 13 2017, 1:33 AM.

Details

Summary

Got rid of unwieldy -include Solaris.h portability solution, replacing it with interposed header and moving endian defines into Host.h.

Fixes PR28370.

Diff Detail

Event Timeline

fedor.sergeev created this revision.Jun 13 2017, 1:33 AM

LLVM/Clang build passes on Sparc/X86-Solaris11/Solaris12.
libcxx cmake passes on Sparc/X86-Solaris11/Solaris12.

Do you need to modify include/llvm/module.modulemap for Solaris.h?

removed reference to Solaris.h from module.modulemap, thanks to Kamil for noticing.

ugh, now with a proper patch...

joerg added inline comments.Jun 13 2017, 5:56 AM
include/llvm/Support/Host.h
25

Can't you use sys/byteorder.h or is that post-Solaris11?

include/llvm/Support/Solaris/sys/regset.h
10–11

Maybe:

This file works around excessive name space pollution from the system header on Solaris hosts.

fedor.sergeev added a comment.EditedJun 13 2017, 5:56 AM

Verified that sys/regset.h works by adding
+#include <sys/regset.h>
+int ES = 1;
into lib/CodeGen/LivePhysRegs.cpp source and checking that it compiles.

Btw, there is one catch here, gcc reports a pedantic warning on include_next:

In file included from  llvm/lib/CodeGen/LivePhysRegs.cpp:16:0:
llvm/include/llvm/Support/Solaris/sys/regset.h:18:2: warning: #include_next is a GCC extension
 #include_next <sys/regset.h>

I can silence this warning by adding
#pragma GCC system_header

into sys/regset.h interposing header, but I'm not sure whats the policy for using GCC pragmas in LLVM project...

krytarowski added inline comments.Jun 13 2017, 5:56 AM
include/llvm/module.modulemap
279

Do we want to install globally Solaris/sys/regset.h? Is it needed by Clang, LLDB or other projects?

ro added inline comments.Jun 13 2017, 6:00 AM
include/llvm/Support/Host.h
25

Wouldn't it be better to just switch LLVM to always use
BYTE_ORDER, ORDER_LITTLE_ENDIAN, ORDER_BIG_ENDIAN which are predefined by
both clang and gcc? There are only a few files left using
BYTE_ORDER and friends.

fedor.sergeev added inline comments.Jun 13 2017, 6:06 AM
include/llvm/module.modulemap
279

I dont quite understand all the module implications, but Solaris/sys/regset.h is just a crude fix for system sys/regset.h.
I dont really see how it belongs to LLVM modules.

Also, currently there are no uses of regset.h outside of Solaris.h (as git grep in monorepo tells me).
So it is just a guard against possible future misuse.
It is very likely that it will never ever be used.

krytarowski added inline comments.Jun 13 2017, 6:09 AM
include/llvm/module.modulemap
279

Then we should blacklist this header from installing globally.

exclude header "Support/Solaris/sys/regset.h"
fedor.sergeev marked an inline comment as done.Jun 13 2017, 6:23 AM
fedor.sergeev added inline comments.
include/llvm/Support/Host.h
25

sys/byteorder.h on my Solaris11/Solaris12 provides only #define _LITTLE_ENDIAN/_BIG_ENDIAN, which does not really help.

fedor.sergeev marked an inline comment as not done.

module.modulemap: exclude Solaris/sys/regset.h
regset.h: modifying file comments as per Joerg's suggestion.

fedor.sergeev marked an inline comment as done.EditedJun 13 2017, 6:38 AM

Ahem... I'm not sure that "Support/Solaris/sys/regset.h" is a right name for this module thing.
The header is being included through -I <LLVM_MAIN_DIR>/include/llvm/Support/Solaris path, and its relative name is "sys/regset.h".

Besides, it doesnt belong to the Support module in any practical way.

To me it is more akin to normal system headers.
We should not be mentioning any system headers in this modulemap thing.

removing module.modulemap entry for sys/regset.h.
For one, there is nothing specific to "module Support" in that header.

joerg added inline comments.Jun 13 2017, 11:04 AM
include/llvm/Support/Host.h
25

OK, I only have the Illumos version at hand, which uses _BIG_ENDIAN to decide whether ntohl and friends should do something or not.

25

ro: I disagree since we don't require gcc or clang to build.

fedor.sergeev added inline comments.Jun 13 2017, 11:21 AM
include/llvm/Support/Host.h
25

You can use _BIG_ENDIAN instead of __sparc, thats all. You still have to manually define all those 1234 values.
And, btw, the header providing this define is sys/isa_defs.h, not sys/byteorder.h.
I wonder how stable this interface is...

ro added inline comments.Jun 14 2017, 1:11 AM
include/llvm/Support/Host.h
25

joerg: Even so, there are already unconditional uses of
BYTE_ORDER etc. inside LLVM without guards or
a fallback definition (e.g. lib/Demangle/ItaniumDemangle.cpp.
projects/compiler-rt/lib/sanitizer_common/sanitizer_symbolizer_libcdep.cc), so I though this might
be a way forward.

ro added inline comments.Jun 14 2017, 1:14 AM
include/llvm/Support/Host.h
25

According to types.h(3HEAD), <sys/types.h> is the header
required to get the definitions of _BIG_ENDIAN and
_LITTLE_ENDIAN. <sys/isa_defs.h> isn't mentioned
anywhere, so seems like an implementation detail.

joerg added inline comments.Jun 14 2017, 1:52 AM
include/llvm/Support/Host.h
25

The use in the Demangler is a bug. compiler-rt is different as we are not required to support arbitrary compilers for that one.

a bit more portable Host.h, using _BIG_ENDIAN selector from sys/types.h

fedor.sergeev marked an inline comment as done.Jun 14 2017, 2:55 AM
krytarowski added inline comments.Jun 14 2017, 2:57 AM
include/llvm/Support/Host.h
25

I can currently build compiler-rt only with Clang (GCC isn't supported).

Perhaps, the use of __BYTE_ORDER__ in ItaniumDemangle.cpp is dictated by its declared "independence":

// It also has no dependencies on the rest of llvm. It is implemented this way
// so that it can be easily reused in libcxxabi.

I was going to adapt it to Endian.h use, and now I'm not that sure.
Anyway, that should be a separate bugfix.

I believe I'm done here :-)

formatted diffs with clang-format.

joerg accepted this revision.Jun 22 2017, 4:47 AM
This revision is now accepted and ready to land.Jun 22 2017, 4:47 AM

I'm going to commit it now.

fedor.sergeev closed this revision.Jul 6 2017, 4:58 AM

Integrated as rL306002.