When same kernel tree is built with gcc 5.3.1 from Xenial, the generated modlues
can't be loaded any more and '-mcmodel=large' is still passed to gcc
during kernel
building, so it looks like a compiler bug:
On Wed, Jan 13, 2016 at 9:11 AM, Ming Lei <email address hidden> wrote:
> When I built 4.3.0-7-generic on arm64(mustang) Wily with the following steps,
>
> fakeroot debian/rules clean
> fakeroot debian/rules binary-generic
>
> by this compiler:
>
> ubuntu@ubuntu:~$ gcc -v
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/5/lto-wrapper
> Target: aarch64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Ubuntu
> 5.2.1-22ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
> --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++
> --prefix=/usr --program-suffix=-5 --enable-shared
> --enable-linker-build-id --libexecdir=/usr/lib
> --without-included-gettext --enable-threads=posix --libdir=/usr/lib
> --enable-nls --with-sysroot=/ --enable-clocale=gnu
> --enable-libstdcxx-debug --enable-libstdcxx-time=yes
> --with-default-libstdcxx-abi=new --enable-gnu-unique-object
> --disable-libquadmath --enable-plugin --with-system-zlib
> --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
> --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-arm64/jre
> --enable-java-home
> --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-arm64
> --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-arm64
> --with-arch-directory=aarch64
> --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-multiarch
> --disable-werror --enable-checking=release --build=aarch64-linux-gnu
> --host=aarch64-linux-gnu --target=aarch64-linux-gnu
>
>
> the built image just works well:
>
> ubuntu@ubuntu:~$ uname -a
> Linux ubuntu 4.3.0-7-generic #18 SMP Tue Jan 12 10:19:24 EST 2016
> aarch64 aarch64 aarch64 GNU/Linux
>
>
> But I can see the issue when booting a kernel from the following package[1]:
>
> http://launchpadlibrarian.net/230287220/linux-image-4.3.0-5-generic_4.3.0-5.16_arm64.deb
>
> It is a build environment issue instead of kernel issue, please see
> comments from Ard Biesheuvel <email address hidden> [2]:
>
> RELA #275 is the relocation against ADRP instructions, which GCC
> should not emit anymore when -mcmodel=large is in effect.
>
> Can you confirm that the modules have been rebuilt with this config as
> well? Can you double check the GCC command line (with V=1) when doing
> 'make modules' to ensure that '-mcmodel=large' is being passed? Can
> you check with 'readelf -r' which objects still contain
> R_AARCH64_ADR_PREL_PG_HI21 relocations?
>
> I have checked the gcc flag in my building environment, and '-mcmodel=large' is
> passed, and CONFIG_ARM64_ERRATUM_843419 is enabled too.
>
> I don't know how the image in [1] is built, so could anyone check the build
> environment for this building?
>
>
> [1] http://launchpadlibrarian.net/230287220/linux-image-4.3.0-5-generic_4.3.0-5.16_arm64.deb
> [2] http://www.spinics.net/lists/arm-kernel/msg449991.html
>
>
> On Tue, Jan 12, 2016 at 7:47 PM, Raghuram Kota
> <email address hidden> wrote:
>> ** Tags added: hs-arm64
>>
>> --
>> You received this bug notification because you are subscribed to linux
>> in Ubuntu.
>> https://bugs.launchpad.net/bugs/1533009
>>
>> Title:
>> arm64: "unsupported RELA relocation"
>>
>> Status in linux package in Ubuntu:
>> Confirmed
>>
>> Bug description:
>> linux-image-4.3.0-5-generic 4.3.0-5.16 arm64 fails to load modules
>> (and therefore boot). It emits messages like the following for each
>> attempted module load:
>>
>> [ 2.156817] module libahci: unsupported RELA relocation: 275
>>
>> This is reminiscent of LP: #1502946 - except that fix appears to still
>> be in-tact. What has changed, however, is the build environment. If I
>> rebuild the same kernel source in a wily chroot, it boots fine.
>>
>> Marking "Confirmed" because Paulo Pisatti reported this to me, and I
>> reproduced.
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533009/+subscriptions
When same kernel tree is built with gcc 5.3.1 from Xenial, the generated modlues
can't be loaded any more and '-mcmodel=large' is still passed to gcc
during kernel
building, so it looks like a compiler bug:
ubuntu@ ubuntu: ~/git$ gcc -v LTO_WRAPPER= /usr/lib/ gcc/aarch64- linux-gnu/ 5/lto-wrapper pkgversion= 'Ubuntu/ Linaro bugurl= file:// /usr/share/ doc/gcc- 5/README. Bugs languages= c,ada,c+ +,java, go,d,fortran, objc,obj- c++ linker- build-id --libexecdir= /usr/lib included- gettext --enable- threads= posix --libdir=/usr/lib clocale= gnu libstdcxx- debug --enable- libstdcxx- time=yes default- libstdcxx- abi=new --enable- gnu-unique- object libquadmath --enable-plugin --with-system-zlib browser- plugin --enable- java-awt= gtk --enable-gtk-cairo java-home= /usr/lib/ jvm/java- 1.5.0-gcj- 5-arm64/ jre jvm-root- dir=/usr/ lib/jvm/ java-1. 5.0-gcj- 5-arm64 jvm-jar- dir=/usr/ lib/jvm- exports/ java-1. 5.0-gcj- 5-arm64 arch-directory= aarch64 ecj-jar= /usr/share/ java/eclipse- ecj.jar --enable-multiarch checking= release --build= aarch64- linux-gnu aarch64- linux-gnu --target= aarch64- linux-gnu
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_
Target: aarch64-linux-gnu
Configured with: ../src/configure -v --with-
5.3.1-5ubuntu2' --with-
--enable-
--prefix=/usr --program-suffix=-5 --enable-shared
--enable-
--without-
--enable-nls --with-sysroot=/ --enable-
--enable-
--with-
--disable-
--disable-
--with-
--enable-java-home
--with-
--with-
--with-
--with-
--disable-werror --enable-
--host=
Thread model: posix
gcc version 5.3.1 20160108 (Ubuntu/Linaro 5.3.1-5ubuntu2)
On Wed, Jan 13, 2016 at 9:11 AM, Ming Lei <email address hidden> wrote: LTO_WRAPPER= /usr/lib/ gcc/aarch64- linux-gnu/ 5/lto-wrapper pkgversion= 'Ubuntu bugurl= file:// /usr/share/ doc/gcc- 5/README. Bugs languages= c,ada,c+ +,java, go,d,fortran, objc,obj- c++ linker- build-id --libexecdir= /usr/lib included- gettext --enable- threads= posix --libdir=/usr/lib clocale= gnu libstdcxx- debug --enable- libstdcxx- time=yes default- libstdcxx- abi=new --enable- gnu-unique- object libquadmath --enable-plugin --with-system-zlib browser- plugin --enable- java-awt= gtk --enable-gtk-cairo java-home= /usr/lib/ jvm/java- 1.5.0-gcj- 5-arm64/ jre jvm-root- dir=/usr/ lib/jvm/ java-1. 5.0-gcj- 5-arm64 jvm-jar- dir=/usr/ lib/jvm- exports/ java-1. 5.0-gcj- 5-arm64 arch-directory= aarch64 ecj-jar= /usr/share/ java/eclipse- ecj.jar --enable-multiarch checking= release --build= aarch64- linux-gnu aarch64- linux-gnu --target= aarch64- linux-gnu launchpadlibrar ian.net/ 230287220/ linux-image- 4.3.0-5- generic_ 4.3.0-5. 16_arm64. deb ADR_PREL_ PG_HI21 relocations? ARM64_ERRATUM_ 843419 is enabled too. launchpadlibrar ian.net/ 230287220/ linux-image- 4.3.0-5- generic_ 4.3.0-5. 16_arm64. deb www.spinics. net/lists/ arm-kernel/ msg449991. html /bugs.launchpad .net/bugs/ 1533009 4.3.0-5- generic 4.3.0-5.16 arm64 fails to load modules /bugs.launchpad .net/ubuntu/ +source/ linux/+ bug/1533009/ +subscriptions
> When I built 4.3.0-7-generic on arm64(mustang) Wily with the following steps,
>
> fakeroot debian/rules clean
> fakeroot debian/rules binary-generic
>
> by this compiler:
>
> ubuntu@ubuntu:~$ gcc -v
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_
> Target: aarch64-linux-gnu
> Configured with: ../src/configure -v --with-
> 5.2.1-22ubuntu2' --with-
> --enable-
> --prefix=/usr --program-suffix=-5 --enable-shared
> --enable-
> --without-
> --enable-nls --with-sysroot=/ --enable-
> --enable-
> --with-
> --disable-
> --disable-
> --with-
> --enable-java-home
> --with-
> --with-
> --with-
> --with-
> --disable-werror --enable-
> --host=
>
>
> the built image just works well:
>
> ubuntu@ubuntu:~$ uname -a
> Linux ubuntu 4.3.0-7-generic #18 SMP Tue Jan 12 10:19:24 EST 2016
> aarch64 aarch64 aarch64 GNU/Linux
>
>
> But I can see the issue when booting a kernel from the following package[1]:
>
> http://
>
> It is a build environment issue instead of kernel issue, please see
> comments from Ard Biesheuvel <email address hidden> [2]:
>
> RELA #275 is the relocation against ADRP instructions, which GCC
> should not emit anymore when -mcmodel=large is in effect.
>
> Can you confirm that the modules have been rebuilt with this config as
> well? Can you double check the GCC command line (with V=1) when doing
> 'make modules' to ensure that '-mcmodel=large' is being passed? Can
> you check with 'readelf -r' which objects still contain
> R_AARCH64_
>
> I have checked the gcc flag in my building environment, and '-mcmodel=large' is
> passed, and CONFIG_
>
> I don't know how the image in [1] is built, so could anyone check the build
> environment for this building?
>
>
> [1] http://
> [2] http://
>
>
> On Tue, Jan 12, 2016 at 7:47 PM, Raghuram Kota
> <email address hidden> wrote:
>> ** Tags added: hs-arm64
>>
>> --
>> You received this bug notification because you are subscribed to linux
>> in Ubuntu.
>> https:/
>>
>> Title:
>> arm64: "unsupported RELA relocation"
>>
>> Status in linux package in Ubuntu:
>> Confirmed
>>
>> Bug description:
>> linux-image-
>> (and therefore boot). It emits messages like the following for each
>> attempted module load:
>>
>> [ 2.156817] module libahci: unsupported RELA relocation: 275
>>
>> This is reminiscent of LP: #1502946 - except that fix appears to still
>> be in-tact. What has changed, however, is the build environment. If I
>> rebuild the same kernel source in a wily chroot, it boots fine.
>>
>> Marking "Confirmed" because Paulo Pisatti reported this to me, and I
>> reproduced.
>>
>> To manage notifications about this bug go to:
>> https:/