Dear Maintainer,
When packaging the AMD ROCm GPU libraries for Debian, we are currently
using CXX=hipcc or CXX=clang++ to build libraries written in HIP as if
they were written in C++.
This necessitates filtering out flags that are not supported when
building HIP language code. For example, the rocsparse d/rules include:
export CXX=hipcc
export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-fortify optimize=-lto
# filter incompatible options from affecting device code
CXXFLAGS := $(subst -fstack-protector-strong,-Xarch_host -fstack-protector-strong,$(CXXFLAGS))
CXXFLAGS := $(subst -fcf-protection,-Xarch_host -fcf-protection,$(CXXFLAGS))
In the lines above, we are prepending `-Xarch_host` to prevent certain
flags from being applied to device code (i.e., GPU code) while still
ensuring that they are applied to host code (i.e., CPU code).
However, there is HIP language support in CMake. We should use it!
dpkg-buildflags should set HIPFLAGS [1]. The CXXFLAGS make a good
starting place for the HIPFLAGS values, but `-Xarch_host` should be
added to `-fstack-protector-strong` and `-fcf-protection`, like in the
example above.
Sincerely,
Cory Bloor
[1]: https://cmake.org/cmake/help/v3.28/envvar/HIPFLAGS.html
Hi! I guess we should also add HIPCXX (defaulting to <host-triplet>-hipcc and HIPCXX_FOR_BUILD (defaulting to <build-triplet>-hipcc when cross compiling, otherwise to hipcc) like with the other toolchains? An apt-file query seems to indicate thee hipcc package provides no triplet-qualified toolchains? Which means automatic cross-compiling is going to be painful given our current infrastructure. If support for this is really missing from the looks of it, we can always postpone adding the compiler tool variables for now until this is implemented (we can still add the HIPFLAGS variables though). I'm CCing the debian-cross list for further insight. It would be helpful if you could verify whether all flags currently added to CXXFLAGS would work for HIPFLAGS. You can check for all such instances by searching for either default_flags, @compiler_flags and CXXFLAGS from: $ perldoc -m Dpkg::Vendor::Debian Once we have the complete list, I'm happy to add the handling for these flags in the code. Thanks, Guillem
I've tried to read a bit into their faq and my impression is that HIP currently is x86_64-only and when it is not, the use of clang (which notoriously refuse cooperating with cross building efforts) makes it practically impossible to do any cross building. In essence, the HIP ecosystem will opt out of cross building, but then the kind of software that HIP targets requires beefy hardware where cross building isn't very relevant, right? Just make sure to not require HIP for building HIP (i.e. do not cause bootstrapping problems). I think HIPFLAGS is the right way to go about this. If dpkg were to provide HIPFLAGS, you could just export CXXFLAGS:=$(HIPFLAGS). Generally, reusing CXX in this way is a really bad idea on the upstream side, but hardly preventable. It is very plausible to eventually have to build an source package containing both C++ code and HIP code and then you have no correct way of setting CXX. So from a dpkg point of view, treating HIP as a new language with new variables makes most sense, but it also means that source packages using these variables will have to do the variable renaming themselves forever (and thus retaining the ability to correctly scope those renames). Helmut
Hello, I've attached a patch with first rough attempt at specifying which flags apply to HIPFLAGS. I have not tested this patch, but I have tested the flags themselves. I'm trying to set all CXXFLAGS as HIPFLAGS except -Werror=clobbered and all the LTO flags. I've also prepended -Xarch_host to all fsanitize flags [1], -fstack-protector-strong, and -fcf-protection. Sincerely, Cory Bloor [1]: The -fsanitize=address flag works for some GPU targets, but it's not clear to me how to limit it to supported GPU targets when dpkg doesn't know what GPU targets are to be built. For this reason, I'm limiting this flag to the host.