This patch adds the initial toolchain for z/OS that will set some defaults. In subsequent patches, we plan to add support to use the system linker and assembler.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang/lib/Driver/ToolChains/ZOS.h | ||
---|---|---|
26 | According to the RFC re: LLVM on z/OS, the initial support in LLVM for z/OS is only for XPLink. My understanding is that all XPLink applications are DLL-enabled. Does being DLL-enabled not imply that the code is position-independent? I understand that the value of the __DLL__ predefined macro from the XL C compiler does not reflect the implicit DLL-enablement of XPLink code; however, I also note that the same compiler claims falsely that Option NODLL is ignored because option XPLINK is specified when -qnodll does actually suppress the effect of an earlier -qdll in causing __DLL__ to be defined. |
clang/lib/Driver/ToolChains/ZOS.h | ||
---|---|---|
26 | This is not always true because we do not require code to be PIC on z/OS, even for XPLink applications. Absolute addresses may be present in code sections for easier access (e.g. in calls to linkages, branch tables). We also may link to libraries that contain non-PIC code. |
LGTM with minor comments.
clang/lib/Driver/ToolChains/ZOS.cpp | ||
---|---|---|
16 | There should be no need for this using directive. The lookup following the declarator-id in the declarations should operate in the context of the namespace that "owns" the function. There's a chance it's needed because of MSVC build problems though. | |
19 | Same comment. | |
clang/lib/Driver/ToolChains/ZOS.h | ||
26 | Got it (I think). Load-time relocations can occur within the program text instead of using PIC code. |
Confirming LGTM. @abhina.sreeskantharajan, it seems that you have a good number of commits to the project (I see at least three). If you do not yet have commit access, it may be appropriate to request it now so that you can push this change directly when you believe you have the feedback that you're looking for.
According to the RFC re: LLVM on z/OS, the initial support in LLVM for z/OS is only for XPLink. My understanding is that all XPLink applications are DLL-enabled. Does being DLL-enabled not imply that the code is position-independent?
I understand that the value of the __DLL__ predefined macro from the XL C compiler does not reflect the implicit DLL-enablement of XPLink code; however, I also note that the same compiler claims falsely that Option NODLL is ignored because option XPLINK is specified when -qnodll does actually suppress the effect of an earlier -qdll in causing __DLL__ to be defined.