[erlang-questions] OTP / HiPE broken with GCC 6.2

Mikael Pettersson mikpelinux@REDACTED
Sun Nov 6 12:32:52 CET 2016

Johannes Weißl writes:
 > Hi Mikael,
 > On Thu, Nov 03, 2016 at 08:12PM +0100, Mikael Pettersson wrote:
 > > I cannot reproduce this with the tip of the otp master branch, and gcc's built
 > > from either the gcc-6.2.0 release tar ball or from a recent head of the gcc-6 branch.
 > Can you try to configure gcc with "--enable-default-pie"? With this flag
 > (which is used for the Debian gcc package) I could reproduce the bug on
 > Debian and Fedora with the gcc-6.2.0 release tar ball and the current
 > gcc svn trunk (rev 241852). PIE also seems to have been used for the
 > official Fedora erlang19.1.4-1.fc25 package, as there HiPE is also
 > broken.

Using a gcc-6.2.0 configured with --enable-default-pie reproduces the bug for me
on FC23.

 > > Most likely the Erlang VM was compiled with non-standard options, for instance
 > > as a PIE (position-independent executable) which would break all address space
 > > layout assumptions.
 > This seems to be the case, thanks for the pointer! What would be your
 > preferred solution to solve this problem? One possibility would be to
 > add an option to the OTP build system to compile without PIE, so
 > that it does not break for compilers that have PIE enabled by default.
 > Similar has been suggested here for the Linux kernel:
 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841438
 > With CFLAGS and LDFLAGS set to "-no-pie -fno-pie" I can compile a
 > working version with the current Debian Testing gcc.

If this problem had been limited to Debian, I would have said that the
Erlang/OTP package maintainer for Debian should add the necessary options
to disable PIE.  However, reading some related Linux Kernel ML messages
today it seems that Gentoo and Fedora (so eventually also RHEL and CentOS)
also are affected, so we have no option but to work around it in OTP.

A change in erts/configure.in to add options to disable PIE if HiPE is
not disabled and the target arch is x86_64 should take care of the issue.
People building older versions will have to backport the patch or
override the compiler options, but that's nothing new.

More information about the erlang-questions mailing list