Valgrind unhandled instruction 0xD5380000 on Aarch64

[Jeffrey Walton]

[Impact]
valgrind on bionic coredump and errors out as follows:

ARM64 front end: branch_etc
disInstr(arm64): unhandled instruction 0xD5380000
disInstr(arm64): 1101'0101 0011'1000 0000'0000 0000'0000
==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 <stdio.h>

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 frees, 1,024 bytes allocated
==32367==
==32367== All heap blocks were freed -- no leaks are possible
==32367==
==32367== For counts of detected and suppressed errors, rerun with: -v
==32367== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
----

* 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 0xD5380000
disInstr(arm64): 1101'0101 0011'1000 0000'0000 0000'0000
==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

[fweimer (fweimer-redhat-bugs)]

+++ 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 0xD5380000
disInstr(arm64): 1101'0101 0011'1000 0000'0000 0000'0000
==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”.

[mjw (mjw-redhat-bugs)]

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.

[updates (updates-redhat-bugs)]

valgrind-3.13.0-4.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-4315a2f0cd

[updates (updates-redhat-bugs)]

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

[updates (updates-redhat-bugs)]

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.

[rclark (rclark-redhat-bugs)]

(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
> + 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.

hmm, I just saw the same issue on rawhide (valgrind 1:3.13.0-18.fc29).. did a patch get lost from the spec file?

[mjw (mjw-redhat-bugs)]

(In reply to Rob Clark from comment #5)
> hmm, I just saw the same issue on rawhide (valgrind 1:3.13.0-18.fc29).. did
> a patch get lost from the spec file?

The patch (valgrind-3.13.0-arm64-hwcap.patch) is there (and still the same, no change upstream), and applied. Is the issue exactly the same as in the description? Could you paste the command line and the valgrind error message?

[rclark (rclark-redhat-bugs)]

cmdline:

  valgrind --leak-check=yes ./deqp-gles31 --deqp-case=dEQP-GLES31.functional.ssbo.layout.random.arrays_of_arrays.1

(debuging some dEQP test crashes in mesa/freedreno)

output (without LD_HWCAP_MASK=1 which works around the issue) (also attached):

==32073== Memcheck, a memory error detector
==32073== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==32073== Using Valgrind-3.13.0.SVN and LibVEX; rerun with -h for copyright info
==32073== Command: ./deqp-gles31 --deqp-visibility=hidden --deqp-case=dEQP-GLES31.functional.ssbo.layout.random.arrays_of_arrays.1 --deqp-log-filename=results/dEQP-GLES31.functional.ssbo.layout.random.arrays_of_arrays.1.qpa
==32073==
ARM64 front end: branch_etc
disInstr(arm64): unhandled instruction 0xD5380000
disInstr(arm64): 1101'0101 0011'1000 0000'0000 0000'0000
==32073== valgrind: Unrecognised instruction at address 0x40150cc.
==32073== at 0x40150CC: init_cpu_features (cpu-features.c:72)
==32073== by 0x40150CC: dl_platform_init (dl-machine.h:208)
==32073== by 0x40150CC: _dl_sysdep_start (dl-sysdep.c:231)
==32073== by 0x40018C3: _dl_start_final (rtld.c:411)
==32073== by 0x4001B3F: _dl_start (rtld.c:520)
==32073== by 0x4001047: ??? (in /usr/lib64/ld-2.27.9000.so)
==32073== Your program just tried to execute an instruction that Valgrind
==32073== did not recognise. There are two possible reasons for this.
==32073== 1. Your program has a bug and erroneously jumped to a non-code
==32073== location. If you are running Memcheck and you just saw a
==32073== warning about a bad jump, it's probably your program's fault.
==32073== 2. The instruction is legitimate but Valgrind doesn't handle it,
==32073== i.e. it's Valgrind's fault. If you think this is the case or
==32073== you are not sure, please let us know and we'll try to fix it.
==32073== Either way, Valgrind will now raise a SIGILL signal which will
==32073== probably kill your program.
==32073==
==32073== Process terminating with default action of signal 4 (SIGILL): dumping core
==32073== Illegal opcode at address 0x40150CC
==32073== at 0x40150CC: init_cpu_features (cpu-features.c:72)
==32073== by 0x40150CC: dl_platform_init (dl-machine.h:208)
==32073== by 0x40150CC: _dl_sysdep_start (dl-sysdep.c:231)
==32073== by 0x40018C3: _dl_start_final (rtld.c:411)
==32073== by 0x4001B3F: _dl_start (rtld.c:520)
==32073== by 0x4001047: ??? (in /usr/lib64/ld-2.27.9000.so)

valgrind: m_coredump/coredump-elf.c:506 (fill_fpu): Assertion 'Unimplemented functionality' failed.
valgrind: valgrind

host stacktrace:
==32073== at 0x3803E0FC: show_sched_status_wrk (m_libcassert.c:378)
==32073== by 0x3803E22B: report_and_quit (m_libcassert.c:449)
==32073== by 0x3803E387: vgPlain_assert_fail (m_libcassert.c:515)
==32073== by 0x380706FB: fill_fpu.isra.4 (coredump-elf.c:506)
==32073== by 0x380708CF: dump_one_thread (coredump-elf.c:563)
==32073== by 0x380708CF: make_elf_coredump (coredump-elf.c:667)
==32073== by 0x380708CF: vgPlain_make_coredump (coredump-elf.c:748)
==32073== by 0x3805654F: default_action (m_signals.c:1937)
==32073== by 0x3805654F: deliver_signal (m_signals.c:1997)
==32073==...

[rclark (rclark-redhat-bugs)]

Created attachment 1451010
valgrind output

[fweimer (fweimer-redhat-bugs)]

That's from the midr_el1 read:

  /* If there was no useful tunable override, query the MIDR if the kernel
     allows it. */
  if (midr == UINT64_MAX)
    {
      if (hwcap & HWCAP_CPUID)
 asm volatile ("mrs %0, midr_el1" : "=r"(midr));
      else
 midr = 0;
    }

So it looks like we get the wrong (host) hwcap value without masking.

[fweimer (fweimer-redhat-bugs)]

It might be helpful to run “LD_SHOW_AUXV=1 /bin/true” with and without valgrind.

[rclark (rclark-redhat-bugs)]

so, quick disclaimer, but I'm running a non-standard kernel atm, if any kernel config/etc could effect this, I can retry w/ a vanilla kernel (but not immediately, and possibly not on the same device)

(In reply to Florian Weimer from comment #10)
> It might be helpful to run “LD_SHOW_AUXV=1 /bin/true” with and without
> valgrind.

[robclark@db820c:~]$ LD_SHOW_AUXV=1 /bin/true
AT_SYSINFO_EHDR: 0xffff81924000
AT_HWCAP: 8ff
AT_PAGESZ: 4096
AT_CLKTCK: 100
AT_PHDR: 0xaaaac8ba2040
AT_PHENT: 56
AT_PHNUM: 9
AT_BASE: 0xffff818f6000
AT_FLAGS: 0x0
AT_ENTRY: 0xaaaac8ba38d0
AT_UID: 1000
AT_EUID: 1000
AT_GID: 1000
AT_EGID: 1000
AT_SECURE: 0
AT_RANDOM: 0xfffff1883f68
AT_EXECFN: /bin/true
AT_PLATFORM: aarch64
[robclark@db820c:~]$
[robclark@db820c:~]$ LD_SHOW_AUXV=1 valgrind --leak-check=yes /bin/true
AT_SYSINFO_EHDR: 0xffff9eb51000
AT_HWCAP: 8ff
AT_PAGESZ: 4096
AT_CLKTCK: 100
AT_PHDR: 0x400040
AT_PHENT: 56
AT_PHNUM: 9
AT_BASE: 0xffff9eb23000
AT_FLAGS: 0x0
AT_ENTRY: 0x4011d0
AT_UID: 1000
AT_EUID: 1000
AT_GID: 1000
AT_EGID: 1000
AT_SECURE: 0
AT_RANDOM: 0xffffc66278c8
AT_EXECFN: /usr/local/bin/valgrind
AT_PLATFORM: aarch64
==1668== Memcheck, a memory error detector
==1668== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==1668== Using Valgrind-3.13.0.SVN and LibVEX; rerun with -h for copyright info
==1668== Command: /bin/true
==1668==
ARM64 front end: branch_etc
disInstr(arm64): unhandled instruction 0xD5380000
disInstr(arm64): 1101'0101 0011'1000 0000'0000 0000'0000
==1668== valgrind: Unrecognised instruction at address 0x40150cc.
==1668== at 0x40150CC: init_cpu_features (cpu-features.c:72)
==1668== by 0x40150CC: dl_platform_init (dl-machine.h:208)
==1668== by 0x40150CC: _dl_sysdep_start (dl-sysdep.c:231)
==1668== by 0x40018C3: _dl_start_final (rtld.c:411)
==1668== by 0x4001B3F: _dl_start (rtld.c:520)
==1668== by 0x4001047: ??? (in /usr/lib64/ld-2.27.9000.so)
==1668== Your program just tried to execute an instruction that Valgrind
==1668== did not recognise. There are two possible reasons for this.
==1668== 1. Your program has a bug and erroneously jumped to a non-code
==1668== location. If you are running Memcheck and you just saw a
==1668== warning about a bad jump, it's probably your program's fault.
==1668== 2. The instruction is legitimate but Valgrind doesn't handle it,
==1668== i.e. it's Valgrind's fault. If you think this is the case or
==1668== you are not sure, please let us know and we'll try to fix it.
==1668== Either way, Valgrind will now raise a SIGILL signal which will
==1668== probably kill your program.
==1668==
==1668== Process terminating with default action of signal 4 (SIGILL): dumping core
==1668== Illegal opcode at address 0x40150CC
==1668== at 0x40150CC: init_cpu_features (cpu-features.c:72)
==1668== by 0x40150CC: dl_platform_init (dl-machine.h:208)
==1668== by 0x40150CC: _dl_sysdep_start (dl-sysdep.c:231)
==1668== by 0x40018C3: _dl_star...

[mjw (mjw-redhat-bugs)]

hohum, so that shows the HWCAP of valgrind itself, which then execs /bin/true and crashes before showing the auxv Maybe try:

 LD_HWCAP_MASK=1 LD_SHOW_AUXV=1 valgrind -q /bin/true

[rclark (rclark-redhat-bugs)]

heh, so this makes my problem a bit more obvious.. at one point in the past I had built my own valgrind (in /usr/local/bin which was ahead of /usr/bin in $PATH).. so in fact the problem all along was not with fedora's valgrind but pebkac ;-)

/me reaches for brown paper bag

------
[robclark@db820c:~]$ LD_HWCAP_MASK=1 LD_SHOW_AUXV=1 valgrind -q /bin/true
AT_SYSINFO_EHDR: 0xffffb56ca000
AT_HWCAP: 8ff
AT_PAGESZ: 4096
AT_CLKTCK: 100
AT_PHDR: 0x400040
AT_PHENT: 56
AT_PHNUM: 9
AT_BASE: 0xffffb569c000
AT_FLAGS: 0x0
AT_ENTRY: 0x4011d0
AT_UID: 1000
AT_EUID: 1000
AT_GID: 1000
AT_EGID: 1000
AT_SECURE: 0
AT_RANDOM: 0xffffd156b538
AT_EXECFN: /usr/local/bin/valgrind
AT_PLATFORM: aarch64
AT_HWCAP: 8ff
AT_PAGESZ: 4096
AT_CLKTCK: 100
AT_PHDR: 0x108040
AT_PHENT: 56
AT_PHNUM: 9
AT_BASE: 0x4000000
AT_FLAGS: 0x0
AT_ENTRY: 0x1098d0
AT_UID: 1000
AT_EUID: 1000
AT_GID: 1000
AT_EGID: 1000
AT_SECURE: 0
AT_RANDOM: 0xfff000fda
AT_EXECFN: /bin/true
AT_PLATFORM: aarch64

[mjw (mjw-redhat-bugs)]

(In reply to Rob Clark from comment #13)
> heh, so this makes my problem a bit more obvious.. at one point in the past
> I had built my own valgrind (in /usr/local/bin which was ahead of /usr/bin
> in $PATH).. so in fact the problem all along was not with fedora's valgrind
> but pebkac ;-)
>
> /me reaches for brown paper bag

No worries. Thanks for walking through it with us.
If there is any reason in the future to build an upstream valgrind please let me know. I am happy to backport any fixes to the fedora package.

[Eric Desrochers (slashd)]

-----

commit fbbb696c5d1e93d4ac6cb548c68bb3f443ceef42
Author: Mark Wielaard <email address hidden>
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

[Eric Desrochers (slashd)]

I'll build a test package and start testing soon.

[Eric Desrochers (slashd)]

[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 0xD5380000
disInstr(arm64): 1101'0101 0011'1000 0000'0000 0000'0000
==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 p...

[Eric Desrochers (slashd)]

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

[Łukasz Zemczak (sil2100)]

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.

[Eric Desrochers (slashd)]

[VERIFICAITON BIONIC]

# lscpu
Architecture: aarch64
Byte Order: Little Endian

# lsb_release -cs
bionic

# dpkg
ii valgrind 1:3.13.0-2ubuntu2.2 arm64 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

[Eric Desrochers (slashd)]

@Jeffrey Walton,

Can you test as well and confirm ?

[David Negreira (dnegreira)]

I tested on an ARM machine with the proposed package and it works fine.

[Eric Desrochers (slashd)]

Thanks David for your time testing the proposed package.

[Launchpad Janitor (janitor)]

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 <email address hidden> Wed, 11 Dec 2019 19:26:13 +0000

[Łukasz Zemczak (sil2100)]

The verification of the Stable Release Update for valgrind has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.