|
From: Mathieu M. <ma...@de...> - 2022-06-28 07:42:56
|
Dear all, I am trying to track down Debian issue #928224. Here is what i did: % dpkg --print-architecture armhf % cat /proc/cpuinfo | grep vfpv3 | head -1 Features : half thumb fastmult vfp edsp thumbee vfpv3 tls idiva idivt vfpd32 lpae % wget https://sourceware.org/pub/valgrind/valgrind-3.19.0.tar.bz2 % sha1sum valgrind-3.19.0.tar.bz2 294c341b421b4d9534e42e8125f509c148f48c17 valgrind-3.19.0.tar.bz2 % tar xf valgrind-3.19.0.tar.bz2 % cd valgrind-3.19.0 % ./configure % make % file ./memcheck/memcheck-arm-linux ./memcheck/memcheck-arm-linux: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, BuildID[sha1]=2babd38ca38e37093356f19df2485f4caf8eb1a0, with debug_info, not stripped % strace ./memcheck/memcheck-arm-linux execve("./memcheck/memcheck-arm-linux", ["./memcheck/memcheck-arm-linux"], 0xbe962730 /* 19 vars */) = 0 --- SIGILL {si_signo=SIGILL, si_code=ILL_ILLOPC, si_addr=0x58072020} --- +++ killed by SIGILL +++ zsh: illegal hardware instruction strace ./memcheck/memcheck-arm-linux Could someone confirm arm32/linux is supported in the latest release ? This is a Debian/sid system. Thanks much, |
|
From: John R. <jr...@bi...> - 2022-06-28 11:16:31
|
On 6/28/22, Mathieu Malaterre wrote:
> % strace ./memcheck/memcheck-arm-linux
> execve("./memcheck/memcheck-arm-linux",
> ["./memcheck/memcheck-arm-linux"], 0xbe962730 /* 19 vars */) = 0
> --- SIGILL {si_signo=SIGILL, si_code=ILL_ILLOPC, si_addr=0x58072020} ---
> +++ killed by SIGILL +++
> zsh: illegal hardware instruction strace ./memcheck/memcheck-arm-linux
memcheck wants determine the actual hardware capabilities.
The description given by AT_PLATFORM, AT_HWCAP, AT_HWCAP2
has not always been complete and correct, so memcheck
tries the hardware instructions that matter, and memcheck
is prepared to handle SIGILL if it occurs. Thus there
are likely to be a few deliberate SIGILL near the beginning.
If strace always halts upon SIGILL, without letting
memcheck's handler catch the SIGILL and recover from it,
then strace is too eager. For instance, on x86_64
strace always aborts on 'int3' regardless of signal handlers.
What happens without using 'strace'?
|
|
From: Mathieu M. <ma...@de...> - 2022-06-28 11:36:44
|
Hi John !
On Tue, Jun 28, 2022 at 1:16 PM John Reiser <jr...@bi...> wrote:
>
> On 6/28/22, Mathieu Malaterre wrote:
> > % strace ./memcheck/memcheck-arm-linux
> > execve("./memcheck/memcheck-arm-linux",
> > ["./memcheck/memcheck-arm-linux"], 0xbe962730 /* 19 vars */) = 0
> > --- SIGILL {si_signo=SIGILL, si_code=ILL_ILLOPC, si_addr=0x58072020} ---
> > +++ killed by SIGILL +++
> > zsh: illegal hardware instruction strace ./memcheck/memcheck-arm-linux
>
> memcheck wants determine the actual hardware capabilities.
> The description given by AT_PLATFORM, AT_HWCAP, AT_HWCAP2
> has not always been complete and correct, so memcheck
> tries the hardware instructions that matter, and memcheck
> is prepared to handle SIGILL if it occurs. Thus there
> are likely to be a few deliberate SIGILL near the beginning.
> If strace always halts upon SIGILL, without letting
> memcheck's handler catch the SIGILL and recover from it,
> then strace is too eager. For instance, on x86_64
> strace always aborts on 'int3' regardless of signal handlers.
Thanks for the detailed explanation. I must admit this is way too low
level stuff for me.
> What happens without using 'strace'?
Same symptoms (AFAIK):
% ./memcheck/memcheck-arm-linux
zsh: illegal hardware instruction ./memcheck/memcheck-arm-linux
Just in case that help, here is the gdb output (*)
Let me know if you need more output.
(*)
% gdb ./memcheck/memcheck-arm-linux
GNU gdb (Debian 12.1-2) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./memcheck/memcheck-arm-linux...
(gdb) r
Starting program: /home/malat/valgrind-3.19.0/memcheck/memcheck-arm-linux
Program received signal SIGILL, Illegal instruction.
vgPlain_am_startup (sp_at_startup=3204445840) at
m_aspacemgr/aspacemgr-linux.c:1626
1626 init_nsegment(&seg);
(gdb) bt full
#0 vgPlain_am_startup (sp_at_startup=3204445840) at
m_aspacemgr/aspacemgr-linux.c:1626
seg = {kind = 0, start = 0, end = 0, smode = SmLower, dev = 0,
ino = 0, offset = 5378467285696512, mode = 3204445844, fnIdx =
-1090521456, hasR = 0 '\000', hasW = 0 '\000', hasX = 38 '&',
hasT = 88 'X', isCH = 164 '\244'}
suggested_clstack_end = <optimized out>
__PRETTY_FUNCTION__ = "vgPlain_am_startup"
#1 0x580ccec4 in valgrind_main (envp=0xbefff69c, argv=0xbefff694,
argc=1) at m_main.c:1431
loglevel = <optimized out>
i = <optimized out>
vex_archinfo = {hwcaps = 1482711920, endness = 0, hwcache_info
= {num_levels = 0, num_caches = 0, caches = 0x0,
icaches_maintain_coherence = 0 '\000'}, ppc_icache_line_szB = 0,
ppc_dcbz_szB = 0,
ppc_scv_supported = 0 '\000', ppc_dcbzl_szB = 0,
arm64_dMinLine_lg2_szB = 0, arm64_iMinLine_lg2_szB = 0,
arm64_requires_fallback_LLSC = 0 '\000'}
need_help = <optimized out>
tid_main = 0
addr2dihandle = 0x0
wd = <optimized out>
need_help = <optimized out>
tid_main = <optimized out>
loglevel = <optimized out>
i = <optimized out>
addr2dihandle = <optimized out>
__PRETTY_FUNCTION__ = "valgrind_main"
vex_archinfo = <optimized out>
wd = <optimized out>
tmp_str = <optimized out>
res = <optimized out>
val = <optimized out>
res = <optimized out>
val = <optimized out>
s = <optimized out>
n = <optimized out>
res = <optimized out>
val = <optimized out>
s = <optimized out>
n = <optimized out>
val = <optimized out>
ok = <optimized out>
errmsg = <optimized out>
limLo = <optimized out>
limHi = <optimized out>
aLocal = <optimized out>
p = <optimized out>
cp = <optimized out>
vex_arch = <optimized out>
ok = <optimized out>
buf = <optimized out>
buf2 = <optimized out>
fd = <optimized out>
r = <optimized out>
nul = <optimized out>
exename = <optimized out>
client_auxv = <optimized out>
client_auxv_len = <optimized out>
--Type <RET> for more, q to quit, c to continue without paging--
arg = <optimized out>
s = <optimized out>
ok = <optimized out>
seg_starts = <optimized out>
n_seg_starts = <optimized out>
anu = <optimized out>
change_ownership_v_c_OK = <optimized out>
co_start = <optimized out>
co_endPlus = <optimized out>
buf = <optimized out>
seg_starts = <optimized out>
n_seg_starts = <optimized out>
j = <optimized out>
n = <optimized out>
seg = <optimized out>
anl = <optimized out>
inaccessible_len = <optimized out>
seg = <optimized out>
seg = <optimized out>
#2 _start_in_C_linux (pArgc=0xbefff690) at m_main.c:3125
r = <optimized out>
argc = 1
argv = 0xbefff694
envp = 0xbefff69c
#3 0x00000000 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
|
|
From: John R. <jr...@bi...> - 2022-06-28 14:53:54
|
track down Debian issue https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928224 which is 3 years old: ----- Installed libc6 version: libc6-dgb:armhf 2.28-8 valgrind /bin/true ==12463== Memcheck, a memory error detector ==12463== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==12463== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info valgrind: Fatal error at startup: a function redirection valgrind: which is mandatory for this platform-tool combination valgrind: cannot be set up. Details of the redirection are: valgrind: valgrind: A must-be-redirected function valgrind: whose name matches the pattern: index valgrind: in an object with soname matching: ld-linux-armhf.so.3 valgrind: was not found whilst processing valgrind: symbols from the object with soname: ld-linux-armhf.so.3 ----- Using valgrind 3.19.0 on Debian/sid : % dpkg --print-architecture armhf % cat /proc/cpuinfo | grep vfpv3 | head -1 Features : half thumb fastmult vfp edsp thumbee vfpv3 tls idiva idivt vfpd32 lpae > % ./memcheck/memcheck-arm-linux > zsh: illegal hardware instruction ./memcheck/memcheck-arm-linux > > Just in case that help, here is the gdb output (*) > > Let me know if you need more output. > > (*) > % gdb ./memcheck/memcheck-arm-linux > GNU gdb (Debian 12.1-2) 12.1 > (gdb) r > Starting program: /home/malat/valgrind-3.19.0/memcheck/memcheck-arm-linux > > Program received signal SIGILL, Illegal instruction. > vgPlain_am_startup (sp_at_startup=3204445840) at > m_aspacemgr/aspacemgr-linux.c:1626 > 1626 init_nsegment(&seg); > (gdb) bt full > #0 vgPlain_am_startup (sp_at_startup=3204445840) at > m_aspacemgr/aspacemgr-linux.c:1626 > seg = {kind = 0, start = 0, end = 0, smode = SmLower, dev = 0, > ino = 0, offset = 5378467285696512, mode = 3204445844, fnIdx = > -1090521456, hasR = 0 '\000', hasW = 0 '\000', hasX = 38 '&', > hasT = 88 'X', isCH = 164 '\244'} > suggested_clstack_end = <optimized out> > __PRETTY_FUNCTION__ = "vgPlain_am_startup" I tried to reproduce the reported behavior of valgrind-3.19.0 on my system : ----- /proc/cpuinfo model name : ARMv7 Processor rev 4 (v7l) BogoMIPS : 51.20 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 4 ----- $ uname -a Linux f33arm32 5.9.14-200.fc33.armv7hl #1 SMP Fri Dec 11 15:02:36 UTC 2020 armv7l armv7l armv7l GNU/Linux $ ldd /bin/date libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb6f6a000) libc.so.6 => /lib/libc.so.6 (0xb6e14000) /lib/ld-linux-armhf.so.3 (0xb6fbe000) So the name of ld-linux contains 'armhf', although the Linux kernel is 'armv7l'. The Features line of /proc/cpuinfo is not quite equivalent: Mathieu's: half thumb fastmult vfp edsp thumbee vfpv3 tls idiva idivt vfpd32 lpae mine: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 Re-building the software: ----- $ wget https://sourceware.org/pub/valgrind/valgrind-3.19.0.tar.bz2 $ tar xf valgrind-3.19.0.tar.bz2 $ cd valgrind-3.19.0 $ ./configure $ make -j4 $ file ./memcheck/memcheck-arm-linux ./memcheck/memcheck-arm-linux: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, BuildID[sha1]=2880b8ee178c482a9de58e83b161a0b38ca008ff, with debug_info, not stripped $ ./memcheck/memcheck-arm-linux valgrind: You cannot run './memcheck/memcheck-arm-linux' directly. valgrind: You should use $prefix/bin/valgrind. $ sudo make install $ /usr/local/bin/valgrind --version valgrind-3.19.0 $ /usr/local/bin/valgrind /bin/date ==14541== Memcheck, a memory error detector ==14541== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==14541== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info ==14541== Command: /bin/date ==14541== Tue Jun 28 07:40:14 AM PDT 2022 ==14541== ==14541== HEAP SUMMARY: ==14541== in use at exit: 0 bytes in 0 blocks ==14541== total heap usage: 427 allocs, 427 frees, 30,017 bytes allocated ==14541== ==14541== All heap blocks were freed -- no leaks are possible ==14541== ==14541== For lists of detected and suppressed errors, rerun with: -s ==14541== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) $ ----- So, valgrind-3.19.0 works for me. I cannot reproduce the original bad behavior, nor the SIGILL, on my hardware running 5.9.14-200.fc33.armv7hl. If you believe that my Fedora33 environment is not close enough to your Debian/sid, then please give the URL of a raw image for RaspberryPi Model 3 V1.2 that I can install on a 32GB SDHC card. |
|
From: Mathieu M. <ma...@de...> - 2022-06-28 15:05:42
|
On Tue, Jun 28, 2022 at 4:54 PM John Reiser <jr...@bi...> wrote: > > track down Debian issue https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928224 > which is 3 years old: > ----- > Installed libc6 version: libc6-dgb:armhf 2.28-8 > > valgrind /bin/true > > ==12463== Memcheck, a memory error detector > ==12463== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. > ==12463== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info > valgrind: Fatal error at startup: a function redirection > valgrind: which is mandatory for this platform-tool combination > valgrind: cannot be set up. Details of the redirection are: > valgrind: > valgrind: A must-be-redirected function > valgrind: whose name matches the pattern: index > valgrind: in an object with soname matching: ld-linux-armhf.so.3 > valgrind: was not found whilst processing > valgrind: symbols from the object with soname: ld-linux-armhf.so.3 > ----- > > Using valgrind 3.19.0 on Debian/sid : > % dpkg --print-architecture > armhf > % cat /proc/cpuinfo | grep vfpv3 | head -1 > Features : half thumb fastmult vfp edsp thumbee vfpv3 tls idiva > idivt vfpd32 lpae > > % ./memcheck/memcheck-arm-linux > > zsh: illegal hardware instruction ./memcheck/memcheck-arm-linux > > > > Just in case that help, here is the gdb output (*) > > > > Let me know if you need more output. > > > > (*) > > % gdb ./memcheck/memcheck-arm-linux > > GNU gdb (Debian 12.1-2) 12.1 > > > (gdb) r > > Starting program: /home/malat/valgrind-3.19.0/memcheck/memcheck-arm-linux > > > > Program received signal SIGILL, Illegal instruction. > > vgPlain_am_startup (sp_at_startup=3204445840) at > > m_aspacemgr/aspacemgr-linux.c:1626 > > 1626 init_nsegment(&seg); > > (gdb) bt full > > #0 vgPlain_am_startup (sp_at_startup=3204445840) at > > m_aspacemgr/aspacemgr-linux.c:1626 > > seg = {kind = 0, start = 0, end = 0, smode = SmLower, dev = 0, > > ino = 0, offset = 5378467285696512, mode = 3204445844, fnIdx = > > -1090521456, hasR = 0 '\000', hasW = 0 '\000', hasX = 38 '&', > > hasT = 88 'X', isCH = 164 '\244'} > > suggested_clstack_end = <optimized out> > > __PRETTY_FUNCTION__ = "vgPlain_am_startup" > > > I tried to reproduce the reported behavior of valgrind-3.19.0 on my system : > ----- /proc/cpuinfo > model name : ARMv7 Processor rev 4 (v7l) > BogoMIPS : 51.20 > Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 > CPU implementer : 0x41 > CPU architecture: 7 > CPU variant : 0x0 > CPU part : 0xd03 > CPU revision : 4 > ----- > $ uname -a > Linux f33arm32 5.9.14-200.fc33.armv7hl #1 SMP Fri Dec 11 15:02:36 UTC 2020 armv7l armv7l armv7l GNU/Linux > $ ldd /bin/date > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb6f6a000) > libc.so.6 => /lib/libc.so.6 (0xb6e14000) > /lib/ld-linux-armhf.so.3 (0xb6fbe000) > > So the name of ld-linux contains 'armhf', although the Linux kernel is 'armv7l'. > The Features line of /proc/cpuinfo is not quite equivalent: > Mathieu's: half thumb fastmult vfp edsp thumbee vfpv3 tls idiva idivt vfpd32 lpae > mine: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 > > Re-building the software: > ----- > $ wget https://sourceware.org/pub/valgrind/valgrind-3.19.0.tar.bz2 > $ tar xf valgrind-3.19.0.tar.bz2 > $ cd valgrind-3.19.0 > $ ./configure > $ make -j4 > $ file ./memcheck/memcheck-arm-linux > ./memcheck/memcheck-arm-linux: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, BuildID[sha1]=2880b8ee178c482a9de58e83b161a0b38ca008ff, with debug_info, not stripped > $ ./memcheck/memcheck-arm-linux > valgrind: You cannot run './memcheck/memcheck-arm-linux' directly. > valgrind: You should use $prefix/bin/valgrind. > $ sudo make install > $ /usr/local/bin/valgrind --version > valgrind-3.19.0 > $ /usr/local/bin/valgrind /bin/date > ==14541== Memcheck, a memory error detector > ==14541== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. > ==14541== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info > ==14541== Command: /bin/date > ==14541== > Tue Jun 28 07:40:14 AM PDT 2022 > ==14541== > ==14541== HEAP SUMMARY: > ==14541== in use at exit: 0 bytes in 0 blocks > ==14541== total heap usage: 427 allocs, 427 frees, 30,017 bytes allocated > ==14541== > ==14541== All heap blocks were freed -- no leaks are possible > ==14541== > ==14541== For lists of detected and suppressed errors, rerun with: -s > ==14541== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) > $ > ----- > > So, valgrind-3.19.0 works for me. I cannot reproduce the original bad behavior, nor the SIGILL, > on my hardware running 5.9.14-200.fc33.armv7hl. Ok, thanks for the quick answer. I discovered that I was supposed to run 'vg-in-place' when not using make install. Here is my strace output (*) > If you believe that my Fedora33 environment is not close enough to your Debian/sid, > then please give the URL of a raw image for RaspberryPi Model 3 V1.2 that I can install > on a 32GB SDHC card. Can you try: $ export RPI_MODEL=3 $ export DEBIAN_RELEASE=bullseye $ wget https://raspi.debian.net/daily/raspi_${RPI_MODEL}_${DEBIAN_RELEASE}.img.xz See complete instructions at: https://wiki.debian.org/RaspberryPiImages Thanks -again- (*) this is from a git/master as of today: % strace ./vg-in-place execve("./vg-in-place", ["./vg-in-place"], 0xbe95c740 /* 19 vars */) = 0 brk(NULL) = 0x1bbd000 uname({sysname="Linux", nodename="abel", ...}) = 0 mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6fbb000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 statx(3, "", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT|AT_EMPTY_PATH, STATX_BASIC_STATS, {stx_mask=STATX_ALL, stx_attributes=0, stx_mode=S_IFREG|0644, stx_size=17519, ...}) = 0 mmap2(NULL, 17519, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb6fb6000 close(3) = 0 openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libc.so.6", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0y}\1\0004\0\0\0"..., 512) = 512 statx(3, "", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT|AT_EMPTY_PATH, STATX_BASIC_STATS, {stx_mask=STATX_ALL, stx_attributes=0, stx_mode=S_IFREG|0755, stx_size=983540, ...}) = 0 mmap2(NULL, 1073552, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6e8a000 mprotect(0xb6f77000, 61440, PROT_NONE) = 0 mmap2(0xb6f86000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xec000) = 0xb6f86000 mmap2(0xb6f89000, 29072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb6f89000 close(3) = 0 set_tls(0xb6fbbe20) = 0 mprotect(0xb6f86000, 8192, PROT_READ) = 0 mprotect(0x4ee000, 4096, PROT_READ) = 0 mprotect(0xb6fbd000, 4096, PROT_READ) = 0 munmap(0xb6fb6000, 17519) = 0 getuid32() = 3180 getgid32() = 3180 getpid() = 7762 rt_sigaction(SIGCHLD, {sa_handler=0x4d9db9, sa_mask=~[RTMIN RT_1], sa_flags=SA_RESTORER, sa_restorer=0xb6eb1fd1}, NULL, 8) = 0 geteuid32() = 3180 brk(NULL) = 0x1bbd000 brk(0x1bde000) = 0x1bde000 getppid() = 7759 statx(AT_FDCWD, "/home/malat/valgrind", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT, STATX_BASIC_STATS, {stx_mask=STATX_ALL, stx_attributes=0, stx_mode=S_IFDIR|0755, stx_size=4096, ...}) = 0 statx(AT_FDCWD, ".", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT, STATX_BASIC_STATS, {stx_mask=STATX_ALL, stx_attributes=0, stx_mode=S_IFDIR|0755, stx_size=4096, ...}) = 0 openat(AT_FDCWD, "./vg-in-place", O_RDONLY|O_LARGEFILE) = 3 fcntl64(3, F_DUPFD, 10) = 10 close(3) = 0 fcntl64(10, F_SETFD, FD_CLOEXEC) = 0 geteuid32() = 3180 getegid32() = 3180 rt_sigaction(SIGINT, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0 rt_sigaction(SIGINT, {sa_handler=0x4d9db9, sa_mask=~[RTMIN RT_1], sa_flags=SA_RESTORER, sa_restorer=0xb6eb1fd1}, NULL, 8) = 0 rt_sigaction(SIGQUIT, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0 rt_sigaction(SIGQUIT, {sa_handler=SIG_DFL, sa_mask=~[RTMIN RT_1], sa_flags=SA_RESTORER, sa_restorer=0xb6eb1fd1}, NULL, 8) = 0 rt_sigaction(SIGTERM, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0 rt_sigaction(SIGTERM, {sa_handler=SIG_DFL, sa_mask=~[RTMIN RT_1], sa_flags=SA_RESTORER, sa_restorer=0xb6eb1fd1}, NULL, 8) = 0 read(10, "#!/bin/sh\n\n# Figure out an absol"..., 8192) = 691 statx(AT_FDCWD, "./vg-in-place", AT_STATX_SYNC_AS_STAT|AT_SYMLINK_NOFOLLOW|AT_NO_AUTOMOUNT, STATX_BASIC_STATS, {stx_mask=STATX_ALL, stx_attributes=0, stx_mode=S_IFREG|0755, stx_size=691, ...}) = 0 pipe([3, 4]) = 0 clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb6fbb948) = 7763 close(4) = 0 read(3, "/home/malat/valgrind/.\n", 128) = 23 read(3, "", 128) = 0 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=7763, si_uid=3180, si_status=0, si_utime=0, si_stime=0} --- sigreturn({mask=[]}) = 0 close(3) = 0 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 7763 wait4(-1, 0xbeeca264, WNOHANG, NULL) = -1 ECHILD (No child processes) rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], NULL, 8) = 0 vfork() = 7764 rt_sigprocmask(SIG_SETMASK, [], ~[KILL STOP RTMIN RT_1], 8) = 0 wait4(-1, [{WIFSIGNALED(s) && WTERMSIG(s) == SIGILL}], 0, NULL) = 7764 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=7764, si_uid=3180, si_status=SIGILL, si_utime=0, si_stime=0} --- sigreturn({mask=[]}) = 7764 write(2, "Illegal instruction\n", 20Illegal instruction ) = 20 wait4(-1, 0xbeeca394, WNOHANG, NULL) = -1 ECHILD (No child processes) read(10, "", 8192) = 0 exit_group(132) = ? +++ exited with 132 +++ |
|
From: John R. <jr...@bi...> - 2022-06-28 16:32:09
|
> $ export RPI_MODEL=3 > $ export DEBIAN_RELEASE=bullseye > $ wgethttps://raspi.debian.net/daily/raspi_${RPI_MODEL}_${DEBIAN_RELEASE}.img.xz That gives arm64, not armhf (32-bit). |
|
From: John R. <jr...@bi...> - 2022-06-28 18:54:29
|
>> $ export RPI_MODEL=3 >> $ export DEBIAN_RELEASE=bullseye >> $ wgethttps://raspi.debian.net/daily/raspi_${RPI_MODEL}_${DEBIAN_RELEASE}.img.xz > > That gives arm64, not armhf (32-bit). Choosing https://raspi.debian.net/tested/20220121_raspi_2_bullseye.img.xz and running 5.10.0-15-armmp #1 SMP Debian 5.10.120-1 (2022-06-09) armv7l GNU/Linux on an old RaspberryPi Model 2B (32 bit, 1GB RAM, 4 CPU): ----- model name : ARMv7 Processor rev 5 (v7l) BogoMIPS : 44.80 Features : half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xc07 CPU revision : 5 ----- with valgrind source ----- commit 022dfeee73726d92ecc0349ebe42d7b52132b8e5 (HEAD -> master, origin/master, origin/HEAD) Author: Mark Wielaard <snip> Date: Sat Jun 18 15:30:54 2022 +0200 ----- and ignoring a build failure ----- Making install in tests make[3]: Entering directory '.../valgrind/cachegrind/tests' make[3]: *** No rule to make target 'install'. Stop. ----- then I see: ----- $ ldd /bin/date linux-vdso.so.1 (0xbeed6000) libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6e7a000) /lib/ld-linux-armhf.so.3 (0xb6f9c000) $ type valgrind valgrind is hashed (/usr/local/bin/valgrind) $ valgrind --version valgrind-3.20.0.GIT $ valgrind /bin/date ==32179== Memcheck, a memory error detector ==32179== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==32179== Using Valgrind-3.20.0.GIT and LibVEX; rerun with -h for copyright info ==32179== Command: /bin/date ==32179== Tue Jun 28 18:50:27 UTC 2022 ==32179== ==32179== HEAP SUMMARY: ==32179== in use at exit: 64 bytes in 1 blocks ==32179== total heap usage: 9 allocs, 8 frees, 5,572 bytes allocated ==32179== ==32179== LEAK SUMMARY: ==32179== definitely lost: 64 bytes in 1 blocks ==32179== indirectly lost: 0 bytes in 0 blocks ==32179== possibly lost: 0 bytes in 0 blocks ==32179== still reachable: 0 bytes in 0 blocks ==32179== suppressed: 0 bytes in 0 blocks ==32179== Rerun with --leak-check=full to see details of leaked memory ==32179== ==32179== For lists of detected and suppressed errors, rerun with: -s ==32179== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) $ ----- So YES, current valgrind does support armhf (armv7l: 32-bit, hard floating point). |
|
From: Mathieu M. <ma...@de...> - 2022-06-29 10:09:39
|
On Tue, Jun 28, 2022 at 8:55 PM John Reiser <jr...@bi...> wrote: > > >> $ export RPI_MODEL=3 > >> $ export DEBIAN_RELEASE=bullseye > >> $ wgethttps://raspi.debian.net/daily/raspi_${RPI_MODEL}_${DEBIAN_RELEASE}.img.xz > > > > That gives arm64, not armhf (32-bit). > > Choosing https://raspi.debian.net/tested/20220121_raspi_2_bullseye.img.xz > and running 5.10.0-15-armmp #1 SMP Debian 5.10.120-1 (2022-06-09) armv7l GNU/Linux > on an old RaspberryPi Model 2B (32 bit, 1GB RAM, 4 CPU): > ----- > model name : ARMv7 Processor rev 5 (v7l) > BogoMIPS : 44.80 > Features : half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm > CPU implementer : 0x41 > CPU architecture: 7 > CPU variant : 0x0 > CPU part : 0xc07 > CPU revision : 5 > ----- > with valgrind source > ----- > commit 022dfeee73726d92ecc0349ebe42d7b52132b8e5 (HEAD -> master, origin/master, origin/HEAD) > Author: Mark Wielaard <snip> > Date: Sat Jun 18 15:30:54 2022 +0200 > ----- > and ignoring a build failure > ----- > Making install in tests > make[3]: Entering directory '.../valgrind/cachegrind/tests' > make[3]: *** No rule to make target 'install'. Stop. > ----- > then I see: > ----- > $ ldd /bin/date > linux-vdso.so.1 (0xbeed6000) > libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6e7a000) > /lib/ld-linux-armhf.so.3 (0xb6f9c000) > $ type valgrind > valgrind is hashed (/usr/local/bin/valgrind) > $ valgrind --version > valgrind-3.20.0.GIT > $ valgrind /bin/date > ==32179== Memcheck, a memory error detector > ==32179== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. > ==32179== Using Valgrind-3.20.0.GIT and LibVEX; rerun with -h for copyright info > ==32179== Command: /bin/date > ==32179== > Tue Jun 28 18:50:27 UTC 2022 > ==32179== > ==32179== HEAP SUMMARY: > ==32179== in use at exit: 64 bytes in 1 blocks > ==32179== total heap usage: 9 allocs, 8 frees, 5,572 bytes allocated > ==32179== > ==32179== LEAK SUMMARY: > ==32179== definitely lost: 64 bytes in 1 blocks > ==32179== indirectly lost: 0 bytes in 0 blocks > ==32179== possibly lost: 0 bytes in 0 blocks > ==32179== still reachable: 0 bytes in 0 blocks > ==32179== suppressed: 0 bytes in 0 blocks > ==32179== Rerun with --leak-check=full to see details of leaked memory > ==32179== > ==32179== For lists of detected and suppressed errors, rerun with: -s > ==32179== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) > $ > ----- Point taken, I did not do my homework correctly, sorry for losing your time. > So YES, current valgrind does support armhf (armv7l: 32-bit, hard floating point). I did not make up those strace logs in my head, all I am trying to do is Debian bug triaging. Turns out I did a pretty bad job at it: 1. The original Debian bug report seems to be PEBCAK, and I'll close the bug as wontfix ASAP, 2. I was not paying attention to the gcc version I was using. So if my understanding is correct I can make valgrind produce this "Illegal instruction" using either gcc-11 or gcc-12 (Debian package from sid), BUT I can make valgrind run using gcc-10 (again Debian package from sid). This also seems to be hardware specific since armhf binary + gcc-12 runs properly on arm64 (armhf chroot). Would you kindly indicate if you believe the bug should be reported back to valgrind bug tracker or gcc bug tracker ? If that matters, clang 13.0 seems to also mess up valgrind code and binaries produced return this "Illegal instruction". Thanks for your time |
|
From: John R. <jr...@bi...> - 2022-06-29 14:27:31
|
> I did not make up those strace logs in my head, all I am trying to do > is Debian bug triaging. Turns out I did a pretty bad job at it: > > 1. The original Debian bug report seems to be PEBCAK, and I'll close > the bug as wontfix ASAP, > 2. I was not paying attention to the gcc version I was using. The original bug report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928224 specified the reproducing case "valgrind /bin/true". That now works for me: ----- $ valgrind /bin/true ==399== Memcheck, a memory error detector ==399== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==399== Using Valgrind-3.20.0.GIT and LibVEX; rerun with -h for copyright info ==399== Command: /bin/true ==399== ==399== ==399== HEAP SUMMARY: ==399== in use at exit: 0 bytes in 0 blocks ==399== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==399== ==399== All heap blocks were freed -- no leaks are possible ==399== ==399== For lists of detected and suppressed errors, rerun with: -s ==399== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) ----- in the environment: ----- $ valgrind --version valgrind-3.20.0.GIT $ gcc --version gcc (Debian 10.2.1-6) 10.2.1 20210110 $ uname -a Linux rpi2-20220121 5.10.0-15-armmp #1 SMP Debian 5.10.120-1 (2022-06-09) armv7l GNU/Linux ----- so the original bug report can be closed with "fixed in newer version" or something like that. > So if my understanding is correct I can make valgrind produce this > "Illegal instruction" using either gcc-11 or gcc-12 (Debian package > from sid), BUT I can make valgrind run using gcc-10 (again Debian > package from sid). This also seems to be hardware specific since armhf > binary + gcc-12 runs properly on arm64 (armhf chroot). Is it easy to install several versions (gcc-10, gcc-11, gcc-12, clang-13) at the same time, and switch among them by using something like CC=/path/to/gcc-12 ./configure Where can I find hints about this? > > Would you kindly indicate if you believe the bug should be reported > back to valgrind bug tracker or gcc bug tracker ? If that matters, > clang 13.0 seems to also mess up valgrind code and binaries produced > return this "Illegal instruction". SIGILL should be diagnosed using gdb to print the instruction stream and register contents ----- (gdb) run args... Program received signal SIGILL, Illegal instruction. (gdb) x/i $pc ## the faulting instruction (gdb) x/12i pc-6*4 ## disassemble the surrounding instructions (Gdb) x/12xw $pc-6*4 ## and in 32-bit raw hexadecimal (gdb) info reg ## content of all registers (gdb) x/16xw $sp ## dump the active end of the stack (gdb) bt ## source-level backtrace ----- But with valgrind you must just "continue" the deliberate SIGILL and SIGSEGV that valgrind uses. Here is an actual run: ----- $ gdb valgrind GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git Reading symbols from valgrind... (gdb) run /bin/true Starting program: /usr/local/bin/valgrind /bin/true process 426 is executing new program: /usr/local/libexec/valgrind/memcheck-arm-linux Program received signal SIGILL, Illegal instruction. vgPlain_machine_get_hwcaps () at m_machine.c:1719 1719 __asm__ __volatile__(".word 0xF3044F54"); /* VMAXNM.F32 q2,q2,q2 */ ## Notice that this SIGILL is from valgrind trying to determine ## the actual hardware capabilities. Valgrind knows what it is doing, ## so just 'continue' to let valgrind handle the SIGILL. (gdb) c Continuing. ==426== Memcheck, a memory error detector ==426== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==426== Using Valgrind-3.20.0.GIT and LibVEX; rerun with -h for copyright info ==426== Command: /bin/true ==426== Program received signal SIGSEGV, Segmentation fault. ## valgrind deliberate 0x62c68cc0 in ?? () (gdb) x/i $pc => 0x62c68cc0: str r3, [r9] (gdb) p $r9 $1 = 3187663772 (gdb) p/x $r9 $2 = 0xbdffe39c (gdb) x/12i $pc-6*4 0x62c68ca8: ldr r3, [r8, #424] ; 0x1a8 0x62c68cac: mov r1, r3 0x62c68cb0: movw r2, #62156 ; 0xf2cc 0x62c68cb4: movt r2, #22528 ; 0x5800 0x62c68cb8: blx r2 0x62c68cbc: ldr r3, [r8, #24] => 0x62c68cc0: str r3, [r9] 0x62c68cc4: add r7, r9, #4 0x62c68cc8: mov r0, r7 0x62c68ccc: ldr r3, [r8, #428] ; 0x1ac 0x62c68cd0: mov r1, r3 0x62c68cd4: movw r2, #62156 ; 0xf2cc (gdb) c Continuing. Program received signal SIGSEGV, Segmentation fault. ## valgrind deliberate 0x62c6cc0c in ?? () (gdb) x/i $pc => 0x62c6cc0c: str r9, [r11] (gdb) x/12i $pc-6*4 0x62c6cbf4: ldr r9, [r8, #416] ; 0x1a0 0x62c6cbf8: mov r1, r9 0x62c6cbfc: movw r2, #62156 ; 0xf2cc 0x62c6cc00: movt r2, #22528 ; 0x5800 0x62c6cc04: blx r2 0x62c6cc08: ldr r9, [r8, #16] => 0x62c6cc0c: str r9, [r11] 0x62c6cc10: add r9, r11, #4 0x62c6cc14: mov r0, r9 0x62c6cc18: ldr r3, [r8, #420] ; 0x1a4 0x62c6cc1c: mov r1, r3 0x62c6cc20: movw r2, #62156 ; 0xf2cc (gdb) c Continuing. ==426== ==426== HEAP SUMMARY: ==426== in use at exit: 0 bytes in 0 blocks ==426== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==426== ==426== All heap blocks were freed -- no leaks are possible ==426== ==426== For lists of detected and suppressed errors, rerun with: -s ==426== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) [Inferior 1 (process 426) exited normally] ----- You also can use something like objdump --disassemble=subroutine_name to be sure that the executing process matches the built software file. Right now I cannot reproduce SIGILL, so I cannot dig in further. Based on the software that I built and ran: valgrind is not to blame; the problem lies with the compiler, operating system, or hardware. (In the last two months I have had four hardware failures: a 5-port ethernet switch, the sound output on a 12-year old consumer desktop PC, the sound output on a 5-year old self-built x86_64 desktop, and the power brick for a RaspberryPi.) |
|
From: Mathieu M. <ma...@de...> - 2022-06-29 14:50:17
|
On Wed, Jun 29, 2022 at 4:27 PM John Reiser <jr...@bi...> wrote:
> -----
> (gdb) run args...
> Program received signal SIGILL, Illegal instruction.
> (gdb) x/i $pc ## the faulting instruction
> (gdb) x/12i pc-6*4 ## disassemble the surrounding instructions
> (Gdb) x/12xw $pc-6*4 ## and in 32-bit raw hexadecimal
> (gdb) info reg ## content of all registers
> (gdb) x/16xw $sp ## dump the active end of the stack
> (gdb) bt ## source-level backtrace
> -----
Here is what I get on first try:
Program received signal SIGILL, Illegal instruction.
vgPlain_am_startup (sp_at_startup=3204445696) at
m_aspacemgr/aspacemgr-linux.c:1626
1626 init_nsegment(&seg);
(gdb) x/i $pc
=> 0x58071090 <vgPlain_am_startup+20>: vmov.i32 d16, #0 ; 0x00000000
(gdb) x/12i $pc-6*4
0x58071078 <vgPlain_am_is_valid_for_aspacem_minAddr+236>: eoreq
r6, lr, r4, lsr #6
0x5807107c <vgPlain_am_startup>: push {r4, r5, r6, r7, r8,
r9, r10, r11, lr}
0x58071080 <vgPlain_am_startup+4>: sub sp, sp, #68 ; 0x44
0x58071084 <vgPlain_am_startup+8>: add r8, sp, #8
0x58071088 <vgPlain_am_startup+12>: mov r4, r0
0x5807108c <vgPlain_am_startup+16>: bl 0x5807611c
<vgModuleLocal_am_segnames_init>
=> 0x58071090 <vgPlain_am_startup+20>: vmov.i32 d16, #0 ; 0x00000000
0x58071094 <vgPlain_am_startup+24>: mov lr, r8
0x58071098 <vgPlain_am_startup+28>: mov r3, #0
0x5807109c <vgPlain_am_startup+32>: mov r10, #1
0x580710a0 <vgPlain_am_startup+36>: str r3, [sp, #56] ; 0x38
0x580710a4 <vgPlain_am_startup+40>: mvn r2, #0
(gdb) x/12xw $pc-6*4
0x58071078 <vgPlain_am_is_valid_for_aspacem_minAddr+236>:
0x002e6324 0xe92d4ff0 0xe24dd044 0xe28d8008
0x58071088 <vgPlain_am_startup+12>: 0xe1a04000 0xeb001422
0xf2c00010 0xe1a0e008
0x58071098 <vgPlain_am_startup+28>: 0xe3a03000 0xe3a0a001
0xe58d3038 0xe3e02000
(gdb) info reg
r0 0x4 4
r1 0x0 0
r2 0x5850a0e8 1481679080
r3 0x5850a0f8 1481679096
r4 0xbefff600 3204445696
r5 0x58606388 1482711944
r6 0xbefff600 3204445696
r7 0x58260000 1478885376
r8 0x58708258 1483768408
r9 0x58708354 1483768660
r10 0x0 0
r11 0x587083ac 1483768748
r12 0x5870a3b4 1483776948
sp 0x58708250 0x58708250 <vgPlain_interim_stack+1056416>
lr 0x58071090 1476858000
pc 0x58071090 0x58071090 <vgPlain_am_startup+20>
cpsr 0x80000010 -2147483632
fpscr 0x0 0
(gdb) x/16xw $sp
0x58708250 <vgPlain_interim_stack+1056416>: 0x00000000
0x00000000 0x00000000 0x00000000
0x58708260 <vgPlain_interim_stack+1056432>: 0x00000000
0x00000000 0x00000000 0x00000000
0x58708270 <vgPlain_interim_stack+1056448>: 0x00000000
0x00000000 0x00000000 0x0013296c
0x58708280 <vgPlain_interim_stack+1056464>: 0xbefff604
0xbefff600 0x58260000 0x581fea9c
As a reminder I do not have neon on this machine:
Features : half thumb fastmult vfp edsp thumbee vfpv3 tls idiva
idivt vfpd32 lpae
Also as a reminder, I cannot reproduce the above symptoms on a
different machine (with neon):
Features : half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpd32
Thanks again for your kind help,
|
|
From: Tom H. <to...@co...> - 2022-06-29 15:06:06
|
On 29/06/2022 15:49, Mathieu Malaterre wrote:
> Here is what I get on first try:
>
> Program received signal SIGILL, Illegal instruction.
> vgPlain_am_startup (sp_at_startup=3204445696) at
> m_aspacemgr/aspacemgr-linux.c:1626
> 1626 init_nsegment(&seg);
> (gdb) x/i $pc
> => 0x58071090 <vgPlain_am_startup+20>: vmov.i32 d16, #0 ; 0x00000000
> (gdb) x/12i $pc-6*4
> 0x58071078 <vgPlain_am_is_valid_for_aspacem_minAddr+236>: eoreq
> r6, lr, r4, lsr #6
> 0x5807107c <vgPlain_am_startup>: push {r4, r5, r6, r7, r8,
> r9, r10, r11, lr}
> 0x58071080 <vgPlain_am_startup+4>: sub sp, sp, #68 ; 0x44
> 0x58071084 <vgPlain_am_startup+8>: add r8, sp, #8
> 0x58071088 <vgPlain_am_startup+12>: mov r4, r0
> 0x5807108c <vgPlain_am_startup+16>: bl 0x5807611c
> <vgModuleLocal_am_segnames_init>
> => 0x58071090 <vgPlain_am_startup+20>: vmov.i32 d16, #0 ; 0x00000000
> 0x58071094 <vgPlain_am_startup+24>: mov lr, r8
> 0x58071098 <vgPlain_am_startup+28>: mov r3, #0
> 0x5807109c <vgPlain_am_startup+32>: mov r10, #1
> 0x580710a0 <vgPlain_am_startup+36>: str r3, [sp, #56] ; 0x38
> 0x580710a4 <vgPlain_am_startup+40>: mvn r2, #0
> (gdb) x/12xw $pc-6*4
> 0x58071078 <vgPlain_am_is_valid_for_aspacem_minAddr+236>:
> 0x002e6324 0xe92d4ff0 0xe24dd044 0xe28d8008
> 0x58071088 <vgPlain_am_startup+12>: 0xe1a04000 0xeb001422
> 0xf2c00010 0xe1a0e008
> 0x58071098 <vgPlain_am_startup+28>: 0xe3a03000 0xe3a0a001
> 0xe58d3038 0xe3e02000
> (gdb) info reg
> r0 0x4 4
> r1 0x0 0
> r2 0x5850a0e8 1481679080
> r3 0x5850a0f8 1481679096
> r4 0xbefff600 3204445696
> r5 0x58606388 1482711944
> r6 0xbefff600 3204445696
> r7 0x58260000 1478885376
> r8 0x58708258 1483768408
> r9 0x58708354 1483768660
> r10 0x0 0
> r11 0x587083ac 1483768748
> r12 0x5870a3b4 1483776948
> sp 0x58708250 0x58708250 <vgPlain_interim_stack+1056416>
> lr 0x58071090 1476858000
> pc 0x58071090 0x58071090 <vgPlain_am_startup+20>
> cpsr 0x80000010 -2147483632
> fpscr 0x0 0
> (gdb) x/16xw $sp
> 0x58708250 <vgPlain_interim_stack+1056416>: 0x00000000
> 0x00000000 0x00000000 0x00000000
> 0x58708260 <vgPlain_interim_stack+1056432>: 0x00000000
> 0x00000000 0x00000000 0x00000000
> 0x58708270 <vgPlain_interim_stack+1056448>: 0x00000000
> 0x00000000 0x00000000 0x0013296c
> 0x58708280 <vgPlain_interim_stack+1056464>: 0xbefff604
> 0xbefff600 0x58260000 0x581fea9c
>
> As a reminder I do not have neon on this machine:
>
> Features : half thumb fastmult vfp edsp thumbee vfpv3 tls idiva
> idivt vfpd32 lpae
Right but you are apparently using a valgrind that was compiled
to target a machine that does have neon, hence your problem.
If you compiled it yourself then you need to change your compiler
options to correctly target the architecture you are running on
and if you got precompiled binaries from somewhere then I'm afraid
they're not compatible with your machine.
Tom
--
Tom Hughes (to...@co...)
http://compton.nu/
|
|
From: John R. <jr...@bi...> - 2022-06-29 18:48:33
|
> Program received signal SIGILL, Illegal instruction. > vgPlain_am_startup (sp_at_startup=3204445696) at > m_aspacemgr/aspacemgr-linux.c:1626 > 1626 init_nsegment(&seg); > (gdb) x/i $pc > => 0x58071090 <vgPlain_am_startup+20>: vmov.i32 d16, #0 ; 0x00000000 > As a reminder I do not have neon on this machine: > > Features : half thumb fastmult vfp edsp thumbee vfpv3 tls idiva > idivt vfpd32 lpae Therefore this is a gcc configuration problem. Whoever configured the gcc that was used to compile your valgrind assumed that neon would be present, but your machine lacks neon. Run "gcc --verbose". On my RaspberryPi Model 2B I get (wrapped by hand to reasonable line length): ----- Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/10/lto-wrapper Target: arm-linux-gnueabihf Configured with: ../src/configure -v --with-pkgversion='Debian 10.2.1-6' \ --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs \ --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr \ --with-gcc-major-version-only --program-suffix=-10 --program-prefix=arm-linux-gnueabihf- \ --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext \ --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu \ --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new \ --enable-gnu-unique-object --disable-libitm --disable-libquadmath --disable-libquadmath-support \ --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release \ --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-sjlj-exceptions \ --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --disable-werror \ --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf \ --target=arm-linux-gnueabihf Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.2.1 20210110 (Debian 10.2.1-6) ----- where the important part now is "--with-arch=armv7-a --with-fpu=vfpv3-d16" for which the "-d16" part restricts gcc to 16 double precision registers even though my hardware has "vfpd32". Consulting "info gcc", then searching for "neon", and examining "ARM Options", it seems to me that the fix for gcc to assume vfp3 floating point with 32 double- precision registers and the half-precision floating-point conversion operations, but omit neon, is the gcc command-line parameter "-march=armv7-a+vfpv3-fp16+nosimd". You may want to use "-d16" somewhere, too. |
|
From: Mathieu M. <ma...@de...> - 2022-07-01 10:17:42
|
On Wed, Jun 29, 2022 at 8:49 PM John Reiser <jr...@bi...> wrote: > > > Program received signal SIGILL, Illegal instruction. > > vgPlain_am_startup (sp_at_startup=3204445696) at > > m_aspacemgr/aspacemgr-linux.c:1626 > > 1626 init_nsegment(&seg); > > (gdb) x/i $pc > > => 0x58071090 <vgPlain_am_startup+20>: vmov.i32 d16, #0 ; 0x00000000 > > > As a reminder I do not have neon on this machine: > > > > Features : half thumb fastmult vfp edsp thumbee vfpv3 tls idiva > > idivt vfpd32 lpae > > Therefore this is a gcc configuration problem. Whoever configured the gcc > that was used to compile your valgrind assumed that neon would be present, > but your machine lacks neon. > > Run "gcc --verbose". On my RaspberryPi Model 2B I get (wrapped by hand > to reasonable line length): > ----- > Using built-in specs. > COLLECT_GCC=gcc > COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/10/lto-wrapper > Target: arm-linux-gnueabihf > Configured with: ../src/configure -v --with-pkgversion='Debian 10.2.1-6' \ > --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs \ > --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr \ > --with-gcc-major-version-only --program-suffix=-10 --program-prefix=arm-linux-gnueabihf- \ > --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext \ > --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu \ > --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new \ > --enable-gnu-unique-object --disable-libitm --disable-libquadmath --disable-libquadmath-support \ > --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release \ > --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-sjlj-exceptions \ > --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --disable-werror \ > --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf \ > --target=arm-linux-gnueabihf > Thread model: posix > Supported LTO compression algorithms: zlib zstd > gcc version 10.2.1 20210110 (Debian 10.2.1-6) > ----- > where the important part now is "--with-arch=armv7-a --with-fpu=vfpv3-d16" > for which the "-d16" part restricts gcc to 16 double precision registers > even though my hardware has "vfpd32". > > Consulting "info gcc", then searching for "neon", and examining "ARM Options", > it seems to me that the fix for gcc to assume vfp3 floating point with 32 double- > precision registers and the half-precision floating-point conversion operations, > but omit neon, is the gcc command-line parameter "-march=armv7-a+vfpv3-fp16+nosimd". > You may want to use "-d16" somewhere, too. Discussing the issue with Debian/gcc/armhf maintainer resulted in: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014091#12 So here is my suggested patch for valgrind: https://bugs.kde.org/show_bug.cgi?id=456200#c1 Thanks everyone for your help ! |