[llvm-dev] RFC: Adding support for the z/OS platform to LLVM and clang

[Kai Peter Nacke via llvm-dev]

Fangrui Song <maskray at google.com> wrote on 11.06.2020 01:32:55:

> >Our plans include setting up z/OS build bots and we will update the 
list
> >when we have them ready to go.
> 
> I think most contributors don't have access and probably don't have any
> desire to buy z/OS devices if their changes somehow break z/OS. When a
> commit caused problems on z/OS, is it the responsibility of the z/OS
> community to fix:) ?
> 
> If the patch author wants to be nice and fix the issues, are z/OS
> developers willing to provide VM access or other resources if such a
> scenario arises? Are the binary formats experimental like experimental
> targets? (Someone may disagree with experimental targets, but I believe
> a new binary format has much larger impact than a new target and it
> seems we will have two more)

I'm not sure if I really understand your concern. Sorry for that.
I assume that no LLVM developer has access to all supported hardware, so 
in
this respect z/OS is no different than any other target. Following the 
developer
policy (compiling the code and running the tests) should catch most
problems here. Of course, changing z/OS specific source code is a 
different
story. I expect that this is mostly limited to the Support library and 
should
pose no general problem.

The intention is to add support for GOFF format first. So far, we just 
implemented
the required MC interfaces and do not use something like an "experimental 
binary
format". As long as GOFF is not requested through the triple, the new 
format is not
used and therefore should not affect other platforms.
But I'm sure you have a specific scenario in mind. May be can elaborate a 
bit on it?
 
> >  Our intent is that patches that incrementally add support for GOFF
> >object generation such as code sections and records would follow. The 
next
> >steps after support for the object file format would be handling the 
z/OS
> >XPLINK calling convention. This would involve changes to both Clang and
> >LLVM and we intend to follow the same style of functional component
> >responsibility as is done for other platforms calling conventions. If 
we
> >believe deviations from this is necessary, we plan on notifying the
> >community and ensuring the reasons behind the deviations are valid and
> >accepted.
> 
> As someone who cares a lot on the lowlevel stuff, I have more questions
> regarding this bullet point.
> 
> A MCGOFFStreamer inheriting MCObjectStreamer and possibly also a
> MCXOBJStreamer? Do you expect GOFF and XOBJ will fit well in the current
> MC framework and will not cause too much burden for developers who are
> refactoring generic MC code?

We'll begin with GOFF first. This fits well with the current 
MCObjectStreamer
hierarchy and should therefore not cause a burden when refactoring MC 
code.

> Will z/OS reuse binary utilities (llvm-ar llvm-cov llvm-cxxfilt llvm-nm
> llvm-objcopy llvm-objdump llvm-readobj llvm-size llvm-strings llvm-strip
> llvm-symbolizer)? Are their any utilities where z/OS's counterparts
> diverge enough (from commonplace platforms) that creating new utilities
> may be better than reusing existing ones?

We reuse at least the binary utilities which are required for testing, 
e.g.
llvm-readobj and llvm-objdump are very valuable here. The z/OS UNIX System
Services are a certified UNIX, so the commonplace utilities have all a
familar interface. Of course, there are differences in detail.

Thanks for your feedback!
 
Best regards,
Kai Nacke
IT Architect

IBM Deutschland GmbH
Vorsitzender des Aufsichtsrats: Sebastian Krause
Geschäftsführung: Gregor Pillen (Vorsitzender), Agnes Heftberger, Norbert 
Janzen, Markus Koerner, Christian Noll, Nicole Reimer
Sitz der Gesellschaft: Ehningen / Registergericht: Amtsgericht Stuttgart, 
HRB 14562 / WEEE-Reg.-Nr. DE 99369940