[Bug 1826811] Re: Valgrind unhandled instruction 0xD5380000 on Aarch64
This bug was fixed in the package valgrind - 1:3.13.0-2ubuntu2.2 --- valgrind (1:3.13.0-2ubuntu2.2) bionic; urgency=medium * d/p/0013-ARM64-mask-AT_HWCAPS-to-those-instructions-VEX-implements.patch - arm64: Handle feature registers access on 4.11 Linux kernel or later (LP: #1826811) -- Eric Desrochers Wed, 11 Dec 2019 19:26:13 + ** Changed in: valgrind (Ubuntu Bionic) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1826811 Title: Valgrind unhandled instruction 0xD538 on Aarch64 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1826811/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1826811] Re: Valgrind unhandled instruction 0xD5380000 on Aarch64
Thanks David for your time testing the proposed package. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1826811 Title: Valgrind unhandled instruction 0xD538 on Aarch64 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1826811/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1826811] Re: Valgrind unhandled instruction 0xD5380000 on Aarch64
I tested on an ARM machine with the proposed package and it works fine. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1826811 Title: Valgrind unhandled instruction 0xD538 on Aarch64 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1826811/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1826811] Re: Valgrind unhandled instruction 0xD5380000 on Aarch64
** Description changed:
[Impact]
valgrind on bionic coredump and errors out as follows:
ARM64 front end: branch_etc
disInstr(arm64): unhandled instruction 0xD538
disInstr(arm64): 1101'0101 0011'1000 ' '
==11950== valgrind: Unrecognised instruction at address 0x4014c90.
==11950==at 0x4014C90: init_cpu_features (cpu-features.c:72)
==11950==by 0x4014C90: dl_platform_init (dl-machine.h:208)
==11950==by 0x4014C90: _dl_sysdep_start (dl-sysdep.c:231)
==11950==by 0x40018C3: _dl_start_final (rtld.c:414)
==11950==by 0x4001B47: _dl_start (rtld.c:523)
==11950==by 0x40011C7: ??? (in /lib/aarch64-linux-gnu/ld-2.27.so)
==11950== Your program just tried to execute an instruction that Valgrind
==11950== did not recognise. There are two possible reasons for this.
==11950== 1. Your program has a bug and erroneously jumped to a non-code
==11950==location. If you are running Memcheck and you just saw a
==11950==warning about a bad jump, it's probably your program's fault.
==11950== 2. The instruction is legitimate but Valgrind doesn't handle it,
==11950==i.e. it's Valgrind's fault. If you think this is the case or
==11950==you are not sure, please let us know and we'll try to fix it.
==11950== Either way, Valgrind will now raise a SIGILL signal which will
==11950== probably kill your program.
==11950==
==11950== Process terminating with default action of signal 4 (SIGILL)
==11950== Illegal opcode at address 0x4014C90
==11950==at 0x4014C90: init_cpu_features (cpu-features.c:72)
==11950==by 0x4014C90: dl_platform_init (dl-machine.h:208)
==11950==by 0x4014C90: _dl_sysdep_start (dl-sysdep.c:231)
==11950==by 0x40018C3: _dl_start_final (rtld.c:414)
==11950==by 0x4001B47: _dl_start (rtld.c:523)
==11950==by 0x40011C7: ??? (in /lib/aarch64-linux-gnu/ld-2.27.so)
The crash occurs because Valgrind is trying to simulate the CPU
instructions when debugging a specific process. Valgrind tries to
disassemble the whole instructions running by the process and insert the
debugging instructions in run time. However, in this case, Valgrind
cannot identify the MIDR_EL1 flag which happens in the "mrs %0,
midr_el1" instruction. And this instruction means to read the CPU ID
state register to %0(id) variable. asm volatile ("mrs %0, midr_el1" :
"=r"(id)); so, Valrind cannot recognize what "midr_el1" is and then
crashes.
https://www.kernel.org/doc/Documentation/arm64/cpu-feature-registers.txt
d) CPU Identification :
MIDR_EL1 is exposed to help identify the processor. On a
heterogeneous system, this could be racy (just like getcpu()). The
process could be migrated to another CPU by the time it uses the
register value, unless the CPU affinity is set. Hence, there is no
guarantee that the value reflects the processor that it is
currently executing on. The REVIDR is not exposed due to this
constraint, as REVIDR makes sense only in conjunction with the
MIDR. Alternately, MIDR_EL1 and REVIDR_EL1 are exposed via sysfs
at:
/sys/devices/system/cpu/cpu$ID/regs/identification/
\- midr
\- revidr
[Test Case]
1) Write a 'Hello World' program:
#include
void main(void) {
printf("Hello World!\n");
};
2) Build it:
$ cc -o hello hello.c
3) Then run valgrind on it:
$ valgrind ./hello
[Regression Potential]
For the regression possibility, it should be fine.
The symtpom happens when Valgrind is trying to disassemble code inside
glibc (sysdeps/unix/sysv/linux/aarch64/cpu-features.c):
Even if the HWCAP_CPUID is not supported, the default value is to assign
0 to the midr variable. So, I think it's not an important feature to
support.
As stated in the fix itself as a comment:
++ /* Limit the AT_HWCAP to just those features we explicitly
++ support in VEX. */
-
Additionally, the fix is found in Ubuntu already (disco and late).
For some reasons, if a regression happens, the regression will be
limited to ARM arch and shouldn't affect other cpu(s) architecture.
[Other information]
Upstream fix:
https://sourceware.org/git/?p=valgrind.git;a=commit;h=fbbb696c5d1e93d4ac6cb548c68bb3f443ceef42
+
+ * For some reason, Xenial is not affected:
+
+ # lsb_release -cs
+ xenial
+
+ # lscpu
+ Architecture: aarch64
+
+ # valgrind ./hello
+ ==32367== Memcheck, a memory error detector
+ ==32367== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
+ ==32367== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
+ ==32367== Command: ./hello
+ ==32367==
+ Hello World!
+ ==32367==
+ ==32367== HEAP SUMMARY:
+ ==32367== in use at exit: 0 bytes in 0 blocks
+ ==32367== total heap usage: 1 allocs, 1 free
[Bug 1826811] Re: Valgrind unhandled instruction 0xD5380000 on Aarch64
@Jeffrey Walton, Can you test as well and confirm ? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1826811 Title: Valgrind unhandled instruction 0xD538 on Aarch64 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1826811/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1826811] Re: Valgrind unhandled instruction 0xD5380000 on Aarch64
[VERIFICAITON BIONIC] # lscpu Architecture:aarch64 Byte Order: Little Endian # lsb_release -cs bionic # dpkg ii valgrind 1:3.13.0-2ubuntu2.2arm64 instrumentation framework for building dynamic analysis tools # valgrind ./hello ==25231== Memcheck, a memory error detector ==25231== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==25231== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==25231== Command: ./hello ==25231== Hello World! ==25231== ==25231== HEAP SUMMARY: ==25231== in use at exit: 0 bytes in 0 blocks ==25231== total heap usage: 1 allocs, 1 frees, 1,024 bytes allocated ==25231== ==25231== All heap blocks were freed -- no leaks are possible ==25231== ==25231== For counts of detected and suppressed errors, rerun with: -v ==25231== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) I confirmed the problem is now solved. - Eric ** Tags removed: verification-needed-bionic ** Tags added: verification-done-bionic -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1826811 Title: Valgrind unhandled instruction 0xD538 on Aarch64 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1826811/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1826811] Re: Valgrind unhandled instruction 0xD5380000 on Aarch64
Hello Jeffrey, or anyone else affected, Accepted valgrind into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/valgrind/1:3.13.0-2ubuntu2.2 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: valgrind (Ubuntu Bionic) Status: In Progress => Fix Committed ** Tags added: verification-needed verification-needed-bionic -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1826811 Title: Valgrind unhandled instruction 0xD538 on Aarch64 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1826811/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1826811] Re: Valgrind unhandled instruction 0xD5380000 on Aarch64
Uploaded in bionic[0]. It is now waiting for SRU acceptance for valgrind
to start buiding in bionic-proposed and start the testing phase of the
SRU.
[0] [ubuntu/bionic-proposed] valgrind 1:3.13.0-2ubuntu2.2 (Waiting for approval)
- Eric
** Description changed:
[Impact]
valgrind on bionic coredump and errors out as follows:
ARM64 front end: branch_etc
disInstr(arm64): unhandled instruction 0xD538
disInstr(arm64): 1101'0101 0011'1000 ' '
==11950== valgrind: Unrecognised instruction at address 0x4014c90.
==11950==at 0x4014C90: init_cpu_features (cpu-features.c:72)
==11950==by 0x4014C90: dl_platform_init (dl-machine.h:208)
==11950==by 0x4014C90: _dl_sysdep_start (dl-sysdep.c:231)
==11950==by 0x40018C3: _dl_start_final (rtld.c:414)
==11950==by 0x4001B47: _dl_start (rtld.c:523)
==11950==by 0x40011C7: ??? (in /lib/aarch64-linux-gnu/ld-2.27.so)
==11950== Your program just tried to execute an instruction that Valgrind
==11950== did not recognise. There are two possible reasons for this.
==11950== 1. Your program has a bug and erroneously jumped to a non-code
==11950==location. If you are running Memcheck and you just saw a
==11950==warning about a bad jump, it's probably your program's fault.
==11950== 2. The instruction is legitimate but Valgrind doesn't handle it,
==11950==i.e. it's Valgrind's fault. If you think this is the case or
==11950==you are not sure, please let us know and we'll try to fix it.
==11950== Either way, Valgrind will now raise a SIGILL signal which will
==11950== probably kill your program.
==11950==
==11950== Process terminating with default action of signal 4 (SIGILL)
==11950== Illegal opcode at address 0x4014C90
==11950==at 0x4014C90: init_cpu_features (cpu-features.c:72)
==11950==by 0x4014C90: dl_platform_init (dl-machine.h:208)
==11950==by 0x4014C90: _dl_sysdep_start (dl-sysdep.c:231)
==11950==by 0x40018C3: _dl_start_final (rtld.c:414)
==11950==by 0x4001B47: _dl_start (rtld.c:523)
==11950==by 0x40011C7: ??? (in /lib/aarch64-linux-gnu/ld-2.27.so)
The crash occurs because Valgrind is trying to simulate the CPU
instructions when debugging a specific process. Valgrind tries to
disassemble the whole instructions running by the process and insert the
debugging instructions in run time. However, in this case, Valgrind
cannot identify the MIDR_EL1 flag which happens in the "mrs %0,
midr_el1" instruction. And this instruction means to read the CPU ID
state register to %0(id) variable. asm volatile ("mrs %0, midr_el1" :
"=r"(id)); so, Valrind cannot recognize what "midr_el1" is and then
crashes.
-
https://www.kernel.org/doc/Documentation/arm64/cpu-feature-registers.txt
d) CPU Identification :
- MIDR_EL1 is exposed to help identify the processor. On a
- heterogeneous system, this could be racy (just like getcpu()). The
- process could be migrated to another CPU by the time it uses the
- register value, unless the CPU affinity is set. Hence, there is no
- guarantee that the value reflects the processor that it is
- currently executing on. The REVIDR is not exposed due to this
- constraint, as REVIDR makes sense only in conjunction with the
- MIDR. Alternately, MIDR_EL1 and REVIDR_EL1 are exposed via sysfs
- at:
+ MIDR_EL1 is exposed to help identify the processor. On a
+ heterogeneous system, this could be racy (just like getcpu()). The
+ process could be migrated to another CPU by the time it uses the
+ register value, unless the CPU affinity is set. Hence, there is no
+ guarantee that the value reflects the processor that it is
+ currently executing on. The REVIDR is not exposed due to this
+ constraint, as REVIDR makes sense only in conjunction with the
+ MIDR. Alternately, MIDR_EL1 and REVIDR_EL1 are exposed via sysfs
+ at:
- /sys/devices/system/cpu/cpu$ID/regs/identification/
- \- midr
- \- revidr
+ /sys/devices/system/cpu/cpu$ID/regs/identification/
+ \- midr
+ \- revidr
[Test Case]
1) Write a 'Hello World' program:
#include
void main(void) {
printf("Hello World!\n");
};
2) Build it:
$ cc -o hello hello.c
3) Then run valgrind on it:
$ valgrind ./hello
[Regression Potential]
For the regression possibility, it should be fine.
The symtpom happens when Valgrind is trying to disassemble code inside
glibc (sysdeps/unix/sysv/linux/aarch64/cpu-features.c):
Even if the HWCAP_CPUID is not supported, the default value is to assign
0 to the midr variable. So, I think it's not an important feature to
support.
+
+ As stated in the fix itself as a comment:
+
+ ++ /*
[Bug 1826811] Re: Valgrind unhandled instruction 0xD5380000 on Aarch64
** Description changed:
- ## DRAFT ###
[Impact]
valgrind on bionic coredump and errors out as follows:
ARM64 front end: branch_etc
disInstr(arm64): unhandled instruction 0xD538
disInstr(arm64): 1101'0101 0011'1000 ' '
==11950== valgrind: Unrecognised instruction at address 0x4014c90.
==11950==at 0x4014C90: init_cpu_features (cpu-features.c:72)
==11950==by 0x4014C90: dl_platform_init (dl-machine.h:208)
==11950==by 0x4014C90: _dl_sysdep_start (dl-sysdep.c:231)
==11950==by 0x40018C3: _dl_start_final (rtld.c:414)
==11950==by 0x4001B47: _dl_start (rtld.c:523)
==11950==by 0x40011C7: ??? (in /lib/aarch64-linux-gnu/ld-2.27.so)
==11950== Your program just tried to execute an instruction that Valgrind
==11950== did not recognise. There are two possible reasons for this.
==11950== 1. Your program has a bug and erroneously jumped to a non-code
==11950==location. If you are running Memcheck and you just saw a
==11950==warning about a bad jump, it's probably your program's fault.
==11950== 2. The instruction is legitimate but Valgrind doesn't handle it,
==11950==i.e. it's Valgrind's fault. If you think this is the case or
==11950==you are not sure, please let us know and we'll try to fix it.
==11950== Either way, Valgrind will now raise a SIGILL signal which will
==11950== probably kill your program.
- ==11950==
+ ==11950==
==11950== Process terminating with default action of signal 4 (SIGILL)
==11950== Illegal opcode at address 0x4014C90
==11950==at 0x4014C90: init_cpu_features (cpu-features.c:72)
==11950==by 0x4014C90: dl_platform_init (dl-machine.h:208)
==11950==by 0x4014C90: _dl_sysdep_start (dl-sysdep.c:231)
==11950==by 0x40018C3: _dl_start_final (rtld.c:414)
==11950==by 0x4001B47: _dl_start (rtld.c:523)
==11950==by 0x40011C7: ??? (in /lib/aarch64-linux-gnu/ld-2.27.so)
+ The crash occurs because Valgrind is trying to simulate the CPU
+ instructions when debugging a specific process. Valgrind tries to
+ disassemble the whole instructions running by the process and insert the
+ debugging instructions in run time. However, in this case, Valgrind
+ cannot identify the MIDR_EL1 flag which happens in the "mrs %0,
+ midr_el1" instruction. And this instruction means to read the CPU ID
+ state register to %0(id) variable. asm volatile ("mrs %0, midr_el1" :
+ "=r"(id)); so, Valrind cannot recognize what "midr_el1" is and then
+ crashes.
+
+
+ https://www.kernel.org/doc/Documentation/arm64/cpu-feature-registers.txt
+
+ d) CPU Identification :
+ MIDR_EL1 is exposed to help identify the processor. On a
+ heterogeneous system, this could be racy (just like getcpu()). The
+ process could be migrated to another CPU by the time it uses the
+ register value, unless the CPU affinity is set. Hence, there is no
+ guarantee that the value reflects the processor that it is
+ currently executing on. The REVIDR is not exposed due to this
+ constraint, as REVIDR makes sense only in conjunction with the
+ MIDR. Alternately, MIDR_EL1 and REVIDR_EL1 are exposed via sysfs
+ at:
+
+ /sys/devices/system/cpu/cpu$ID/regs/identification/
+ \- midr
+ \- revidr
[Test Case]
1) Write a 'Hello World' program:
#include
void main(void) {
printf("Hello World!\n");
};
2) Build it:
$ cc -o hello hello.c
3) Then run valgrind on it:
$ valgrind ./hello
[Regression Potential]
+ For the regression possibility, it should be fine.
+
+ The symtpom happens when Valgrind is trying to disassemble code inside
+ glibc (sysdeps/unix/sysv/linux/aarch64/cpu-features.c):
+
+ Even if the HWCAP_CPUID is not supported, the default value is to assign
+ 0 to the midr variable. So, I think it's not an important feature to
+ support.
+
+ Additionally, the fix is found in Ubuntu already (disco and late).
+
+ For some reasons, if a regression happens, the regression will be
+ limited to ARM arch and shouldn't affect other cpu(s) architecture.
+
[Other information]
- Upstream fix:
+ Upstream fix:
https://sourceware.org/git/?p=valgrind.git;a=commit;h=fbbb696c5d1e93d4ac6cb548c68bb3f443ceef42
* Only affecting Bionic:
# git describe --contains fbbb696c5d1e93d4ac6cb548c68bb3f443ceef42
VALGRIND_3_14_0~96
# rmadison valgrind
- => valgrind | 1:3.13.0-2ubuntu2.1 | bionic-updates
-valgrind | 1:3.14.0-2ubuntu6| disco
-valgrind | 1:3.15.0-1ubuntu3.1 | eoan-updates
-valgrind | 1:3.15.0-1ubuntu5| focal
-
+ => valgrind | 1:3.13.0-2ubuntu2.1 | bionic-updates
+ valgrind | 1:3.14.0-2ubuntu6| disco
+ valgrind | 1:3.15.0-1ubuntu3.1 | eoan-updates
+ valgrind | 1:3.15.0-1ubuntu5| focal
[Original Descr
[Bug 1826811] Re: Valgrind unhandled instruction 0xD5380000 on Aarch64
** Description changed:
+ ## DRAFT ###
+ [Impact]
+ valgrind on bionic coredump and errors out as follows:
+
+ ARM64 front end: branch_etc
+ disInstr(arm64): unhandled instruction 0xD538
+ disInstr(arm64): 1101'0101 0011'1000 ' '
+ ==11950== valgrind: Unrecognised instruction at address 0x4014c90.
+ ==11950==at 0x4014C90: init_cpu_features (cpu-features.c:72)
+ ==11950==by 0x4014C90: dl_platform_init (dl-machine.h:208)
+ ==11950==by 0x4014C90: _dl_sysdep_start (dl-sysdep.c:231)
+ ==11950==by 0x40018C3: _dl_start_final (rtld.c:414)
+ ==11950==by 0x4001B47: _dl_start (rtld.c:523)
+ ==11950==by 0x40011C7: ??? (in /lib/aarch64-linux-gnu/ld-2.27.so)
+ ==11950== Your program just tried to execute an instruction that Valgrind
+ ==11950== did not recognise. There are two possible reasons for this.
+ ==11950== 1. Your program has a bug and erroneously jumped to a non-code
+ ==11950==location. If you are running Memcheck and you just saw a
+ ==11950==warning about a bad jump, it's probably your program's fault.
+ ==11950== 2. The instruction is legitimate but Valgrind doesn't handle it,
+ ==11950==i.e. it's Valgrind's fault. If you think this is the case or
+ ==11950==you are not sure, please let us know and we'll try to fix it.
+ ==11950== Either way, Valgrind will now raise a SIGILL signal which will
+ ==11950== probably kill your program.
+ ==11950==
+ ==11950== Process terminating with default action of signal 4 (SIGILL)
+ ==11950== Illegal opcode at address 0x4014C90
+ ==11950==at 0x4014C90: init_cpu_features (cpu-features.c:72)
+ ==11950==by 0x4014C90: dl_platform_init (dl-machine.h:208)
+ ==11950==by 0x4014C90: _dl_sysdep_start (dl-sysdep.c:231)
+ ==11950==by 0x40018C3: _dl_start_final (rtld.c:414)
+ ==11950==by 0x4001B47: _dl_start (rtld.c:523)
+ ==11950==by 0x40011C7: ??? (in /lib/aarch64-linux-gnu/ld-2.27.so)
+
+
+ [Test Case]
+
+ 1) Write a 'Hello World' program:
+
+ #include
+
+ void main(void) {
+ printf("Hello World!\n");
+ };
+
+
+ 2) Build it:
+ $ cc -o hello hello.c
+
+ 3) Then run valgrind on it:
+ $ valgrind ./hello
+
+ [Regression Potential]
+
+ [Other information]
+
+ Upstream fix:
+
https://sourceware.org/git/?p=valgrind.git;a=commit;h=fbbb696c5d1e93d4ac6cb548c68bb3f443ceef42
+
+ * Only affecting Bionic:
+
+ # git describe --contains fbbb696c5d1e93d4ac6cb548c68bb3f443ceef42
+ VALGRIND_3_14_0~96
+
+ # rmadison valgrind
+ => valgrind | 1:3.13.0-2ubuntu2.1 | bionic-updates
+valgrind | 1:3.14.0-2ubuntu6| disco
+valgrind | 1:3.15.0-1ubuntu3.1 | eoan-updates
+valgrind | 1:3.15.0-1ubuntu5| focal
+
+
+ [Original Description]
+
I'm performing Valgrind testing on an ElPotato running Ubuntu Bionic
Aarch64 image. My program is dying like in
https://bugs.kde.org/show_bug.cgi?id=381556 :
-
```
$ valgrind --track-origins=yes --suppressions=cryptopp.supp ./cryptest.exe v
==12969== Memcheck, a memory error detector
==12969== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==12969== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==12969== Command: ./cryptest.exe v
==12969==
ARM64 front end: branch_etc
disInstr(arm64): unhandled instruction 0xD538
disInstr(arm64): 1101'0101 0011'1000 ' '
==12969== valgrind: Unrecognised instruction at address 0x4014c90.
==12969==at 0x4014C90: init_cpu_features (cpu-features.c:72)
==12969==by 0x4014C90: dl_platform_init (dl-machine.h:208)
==12969==by 0x4014C90: _dl_sysdep_start (dl-sysdep.c:231)
==12969==by 0x40018C3: _dl_start_final (rtld.c:414)
==12969==by 0x4001B47: _dl_start (rtld.c:523)
==12969==by 0x40011C7: ??? (in /lib/aarch64-linux-gnu/ld-2.27.so)
...
```
Here's a similar Red Hat issue report:
https://bugzilla.redhat.com/show_bug.cgi?id=1467952 .
Please pickup the patch in the 381556 bug report.
-
$ lsb_release -rd
Description:Ubuntu 18.04.2 LTS
Release:18.04
$ apt-cache policy valgrind
valgrind:
- Installed: 1:3.13.0-2ubuntu2.1
- Candidate: 1:3.13.0-2ubuntu2.1
- Version table:
- *** 1:3.13.0-2ubuntu2.1 500
- 500 http://ports.ubuntu.com bionic-updates/main arm64 Packages
- 100 /var/lib/dpkg/status
- 1:3.13.0-2ubuntu2 500
- 500 http://ports.ubuntu.com bionic/main arm64 Packages
+ Installed: 1:3.13.0-2ubuntu2.1
+ Candidate: 1:3.13.0-2ubuntu2.1
+ Version table:
+ *** 1:3.13.0-2ubuntu2.1 500
+ 500 http://ports.ubuntu.com bionic-updates/main arm64 Packages
+ 100 /var/lib/dpkg/status
+ 1:3.13.0-2ubuntu2 500
+ 500 http://ports.ubuntu.com bionic/main arm64 Packages
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1826811
Title:
Valgrind unhandled i
[Bug 1826811] Re: Valgrind unhandled instruction 0xD5380000 on Aarch64
[Pre-SRU testing] ** With valgrind 3.13.0-2ubuntu2.1 ** # lsb_release -cs bionic # lscpu Architecture:aarch64 Byte Order: Little Endian # valgrind ./hello =7287== Memcheck, a memory error detector ==7287== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==7287== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==7287== Command: ./hello ==7287== ARM64 front end: branch_etc disInstr(arm64): unhandled instruction 0xD538 disInstr(arm64): 1101'0101 0011'1000 ' ' ==7287== valgrind: Unrecognised instruction at address 0x4014c90. ==7287==at 0x4014C90: init_cpu_features (cpu-features.c:72) ==7287==by 0x4014C90: dl_platform_init (dl-machine.h:208) ==7287==by 0x4014C90: _dl_sysdep_start (dl-sysdep.c:231) ==7287==by 0x40018C3: _dl_start_final (rtld.c:414) ==7287==by 0x4001B47: _dl_start (rtld.c:523) ==7287==by 0x40011C7: ??? (in /lib/aarch64-linux-gnu/ld-2.27.so) ==7287== Your program just tried to execute an instruction that Valgrind ==7287== did not recognise. There are two possible reasons for this. ==7287== 1. Your program has a bug and erroneously jumped to a non-code ==7287==location. If you are running Memcheck and you just saw a ==7287==warning about a bad jump, it's probably your program's fault. ==7287== 2. The instruction is legitimate but Valgrind doesn't handle it, ==7287==i.e. it's Valgrind's fault. If you think this is the case or ==7287==you are not sure, please let us know and we'll try to fix it. ==7287== Either way, Valgrind will now raise a SIGILL signal which will ==7287== probably kill your program. ==7287== ==7287== Process terminating with default action of signal 4 (SIGILL) ==7287== Illegal opcode at address 0x4014C90 ==7287==at 0x4014C90: init_cpu_features (cpu-features.c:72) ==7287==by 0x4014C90: dl_platform_init (dl-machine.h:208) ==7287==by 0x4014C90: _dl_sysdep_start (dl-sysdep.c:231) ==7287==by 0x40018C3: _dl_start_final (rtld.c:414) ==7287==by 0x4001B47: _dl_start (rtld.c:523) ==7287==by 0x40011C7: ??? (in /lib/aarch64-linux-gnu/ld-2.27.so) ==7287== ==7287== HEAP SUMMARY: ==7287== in use at exit: 0 bytes in 0 blocks ==7287== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==7287== ==7287== All heap blocks were freed -- no leaks are possible ==7287== ==7287== For counts of detected and suppressed errors, rerun with: -v ==7287== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) ==> Illegal instruction (core dumped) ** With valgrind 3.13.0-2ubuntu2.1 + commit fbbb696 on top of it ** [0] # lsb_release -cs bionic # lscpu Architecture:aarch64 Byte Order: Little Endian # valgrind ./hello ==8918== Memcheck, a memory error detector ==8918== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==8918== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==8918== Command: ./hello ==8918== Hello World! ==8918== ==8918== HEAP SUMMARY: ==8918== in use at exit: 0 bytes in 0 blocks ==8918== total heap usage: 1 allocs, 1 frees, 1,024 bytes allocated ==8918== ==8918== All heap blocks were freed -- no leaks are possible ==8918== ==8918== For counts of detected and suppressed errors, rerun with: -v ==8918== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) [0] Test package: sudo add-apt-repository ppa:slashd/lp1826811 sudo apt-get update ** Changed in: valgrind (Ubuntu Bionic) Status: Confirmed => In Progress -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1826811 Title: Valgrind unhandled instruction 0xD538 on Aarch64 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1826811/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1826811] Re: Valgrind unhandled instruction 0xD5380000 on Aarch64
- commit fbbb696c5d1e93d4ac6cb548c68bb3f443ceef42 Author: Mark Wielaard Date: Tue Jun 19 18:00:45 2018 +0200 Mask AT_HWCAPS on arm64 to those instructions VEX implements. This patch makes sure that the process running under valgrind only sees the AES, PMULL, SHA1, SHA2, CRC32, FP, and ASIMD features in auxv AT_HWCAPS. https://bugs.kde.org/show_bug.cgi?id=381556 - # git describe --contains fbbb696c5d1e93d4ac6cb548c68bb3f443ceef42 VALGRIND_3_14_0~96 - # rmadison valgrind ... => valgrind | 1:3.13.0-2ubuntu2.1 | bionic-updates | source, amd64, arm64, armhf, i386, ppc64el, s390x valgrind | 1:3.14.0-2ubuntu6 | disco | source, amd64, arm64, armhf, i386, ppc64el, s390x valgrind | 1:3.15.0-1ubuntu3 | eoan | source, amd64, arm64, armhf, i386, ppc64el, s390x valgrind | 1:3.15.0-1ubuntu3.1 | eoan-updates | source, amd64, arm64, armhf, i386, ppc64el, s390x valgrind | 1:3.15.0-1ubuntu5 | focal | source, amd64, arm64, armhf, i386, ppc64el, s390x ** Also affects: valgrind (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: valgrind (Ubuntu) Status: Confirmed => Fix Released ** Changed in: valgrind (Ubuntu Bionic) Status: New => Confirmed ** Changed in: valgrind (Ubuntu Bionic) Assignee: (unassigned) => Eric Desrochers (slashd) ** Changed in: valgrind (Ubuntu Bionic) Importance: Undecided => Medium -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1826811 Title: Valgrind unhandled instruction 0xD538 on Aarch64 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1826811/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1826811] Re: Valgrind unhandled instruction 0xD5380000 on Aarch64
I'll build a test package and start testing soon. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1826811 Title: Valgrind unhandled instruction 0xD538 on Aarch64 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1826811/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1826811] Re: Valgrind unhandled instruction 0xD5380000 on Aarch64
** Tags added: sts -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1826811 Title: Valgrind unhandled instruction 0xD538 on Aarch64 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1826811/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1826811] Re: Valgrind unhandled instruction 0xD5380000 on Aarch64
Launchpad has imported 15 comments from the remote bug at
https://bugzilla.redhat.com/show_bug.cgi?id=1464211.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
On 2017-06-22T16:23:16+00:00 fweimer wrote:
+++ This bug was initially created as a clone of Bug #1464085 +++
valgrind currently does not know anything about the CPUID flag added to
the HWCAP auxv entry in kernel 4.11. It passes this flag through to
applications, but it will then choke when the application uses it, like
this:
ARM64 front end: branch_etc
disInstr(arm64): unhandled instruction 0xD538
disInstr(arm64): 1101'0101 0011'1000 ' '
==924== valgrind: Unrecognised instruction at address 0x11f548.
==924==at 0x11F548: init_cpu_features (cpu-features.c:32)
==924==by 0x11F548: dl_platform_init (dl-machine.h:241)
==924==by 0x11F548: _dl_sysdep_start (dl-sysdep.c:231)
==924==by 0x10981B: _dl_start_final (rtld.c:412)
==924==by 0x109AAB: _dl_start (rtld.c:520)
The crashing instruction is the mrs in the glibc startup code, which
means that currently no applications run under valgrind:
if (hwcap & HWCAP_CPUID)
{
register uint64_t id = 0;
asm volatile ("mrs %0, midr_el1" : "=r"(id));
cpu_features->midr_el1 = id;
}
else
cpu_features->midr_el1 = 0;
Perhaps valgrind should mask all the HWCAP bits it knows nothing about.
Workaround: Run with “LD_HWCAP_MASK=1”.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1826811/comments/0
On 2017-06-23T10:52:41+00:00 mjw wrote:
See also upstream https://bugs.kde.org/show_bug.cgi?id=381556
arm64: Handle feature registers access on 4.11 Linux kernel or later
For now worked around in valgrind valgrind-3.13.0-3.fc27 as suggested in
the original description of this bug:
--- a/coregrind/m_initimg/initimg-linux.c
+++ b/coregrind/m_initimg/initimg-linux.c
@@ -703,6 +703,12 @@ Addr setup_client_stack( void* init_sp,
(and anything above) are not supported by Valgrind. */
auxv->u.a_val &= VKI_HWCAP_S390_TE - 1;
}
+# elif defined(VGP_arm64_linux)
+{
+ /* Linux 4.11 started pupulating this for arm64, but we
+ currently don't support any. */
+ auxv->u.a_val = 0;
+}
# endif
break;
#if defined(VGP_ppc64be_linux) || defined(VGP_ppc64le_linux)
Keeping this bug open to see how upstream resolves this.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1826811/comments/1
On 2017-06-29T20:11:01+00:00 updates wrote:
valgrind-3.13.0-4.fc26 has been submitted as an update to Fedora 26.
https://bodhi.fedoraproject.org/updates/FEDORA-2017-4315a2f0cd
Reply at:
https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1826811/comments/2
On 2017-06-30T20:25:29+00:00 updates wrote:
valgrind-3.13.0-4.fc26 has been pushed to the Fedora 26 testing repository. If
problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2017-4315a2f0cd
Reply at:
https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1826811/comments/3
On 2017-07-07T23:05:15+00:00 updates wrote:
valgrind-3.13.0-4.fc26 has been pushed to the Fedora 26 stable
repository. If problems still persist, please make note of it in this
bug report.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1826811/comments/4
On 2018-06-13T19:15:57+00:00 rclark wrote:
(In reply to Mark Wielaard from comment #1)
> See also upstream https://bugs.kde.org/show_bug.cgi?id=381556
> arm64: Handle feature registers access on 4.11 Linux kernel or later
>
> For now worked around in valgrind valgrind-3.13.0-3.fc27 as suggested in the
> original description of this bug:
>
> --- a/coregrind/m_initimg/initimg-linux.c
> +++ b/coregrind/m_initimg/initimg-linux.c
> @@ -703,6 +703,12 @@ Addr setup_client_stack( void* init_sp,
>(and anything above) are not supported by Valgrind. */
> auxv->u.a_val &= VKI_HWCAP_S390_TE - 1;
> }
> +# elif defined(VGP_arm64_linux)
> +{
> + /* Linux 4.11 started pupulating this for arm64, but we
> +
[Bug 1826811] Re: Valgrind unhandled instruction 0xD5380000 on Aarch64
** Changed in: valgrind (Ubuntu) Status: New => Confirmed ** Bug watch added: Red Hat Bugzilla #1464211 https://bugzilla.redhat.com/show_bug.cgi?id=1464211 ** Also affects: valgrind (Fedora) via https://bugzilla.redhat.com/show_bug.cgi?id=1464211 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1826811 Title: Valgrind unhandled instruction 0xD538 on Aarch64 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1826811/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
