Menu
▾
▴
valgrind-users — General discussion list for Valgrind users
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
(12) |
Oct
(16) |
Nov
(1) |
Dec
|
| 2024 |
Jan
(4) |
Feb
(3) |
Mar
(6) |
Apr
(17) |
May
(2) |
Jun
(33) |
Jul
(13) |
Aug
(1) |
Sep
(6) |
Oct
(8) |
Nov
(6) |
Dec
(15) |
| 2025 |
Jan
(5) |
Feb
(11) |
Mar
(8) |
Apr
(20) |
May
(1) |
Jun
|
Jul
|
Aug
(9) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
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: 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: 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 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-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: 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: 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 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 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 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 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: $<ri...@nt...> - 2022-06-27 15:39:40
|
Used https://dl.google.com/android/repository/android-ndk-r10e-linux-x86_64.zip version where I am able to cross compile valgrind version 3.19.0 version without any problem. On Mon, Jun 27, 2022, 7:32 PM John Reiser <jr...@bi...> wrote: > On 6/27/22, $rik@nth wrote: > > Things got resolved after moving to older ndk where it supports gcc. > > Please state exactly which older version worked for you. > This will help other valgrind developers now, and encourage > maintainers to enhance future support so that the underlying > problem gets fixed. > > > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: John R. <jr...@bi...> - 2022-06-27 14:00:23
|
On 6/27/22, $rik@nth wrote: > Things got resolved after moving to older ndk where it supports gcc. Please state exactly which older version worked for you. This will help other valgrind developers now, and encourage maintainers to enhance future support so that the underlying problem gets fixed. |
|
From: $<ri...@nt...> - 2022-06-27 13:50:07
|
Things got resolved after moving to older ndk where it supports gcc. On Mon, Jun 27, 2022, 4:04 AM John Reiser <jr...@bi...> wrote: > > Upon moving to next. It landed into another issue. seems it is not easy > to cross compile the valgrind to Android as they mentioned > https://valgrind.org/docs/manual/dist.readme-android.html < > https://valgrind.org/docs/manual/dist.readme-android.html> > > > > Should i need to contact valgrind developers list to support. > > > > ../coregrind/link_tool_exe_linux 0x58000000 > /local/mnt/workspace/Android_ndk/android-ndk-r23c/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android31-clang > -O3 --target=aarch64-linux-android31-clang > > > --gcc-toolchain=/local/mnt/workspace/Android_ndk/android-ndk-r23c/toolchains/llvm/prebuilt/linux-x86_64/bin/ > --sysroot=/local/mnt/workspace/Android_ndk/android-ndk-r23c/toolchains/llvm/prebuilt/linux-x86_64/sysroot > -o memcheck-arm-linux -m32 -O2 -g -Wall -Wmissing-prototypes -Wshadow > > -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wcast-qual > -Wwrite-strings -Wempty-body -Wformat -Wformat-security > -Wignored-qualifiers -Wenum-conversion -finline-functions > -fno-stack-protector -fno-strict-aliasing -fno-builtin -Wno-cast-align > -Wno-self-assign -Wno-tautological-compare > > -marm -mcpu=cortex-a8 -O2 -static -nodefaultlibs -nostartfiles -u > _start -m32 -Wl,-z,noexecstack memcheck_arm_linux-mc_leakcheck.o > memcheck_arm_linux-mc_malloc_wrappers.o memcheck_arm_linux-mc_main.o > memcheck_arm_linux-mc_main_asm.o memcheck_arm_linux-mc_translate.o > > memcheck_arm_linux-mc_machine.o memcheck_arm_linux-mc_errors.o > ../coregrind/libcoregrind-arm-linux.a ../VEX/libvex-arm-linux.a > > ld: error: undefined symbol: __aeabi_uidivmod > > >>> referenced by mc_leakcheck.c:837 > > >>> > memcheck_arm_linux-mc_leakcheck.o:(heuristic_reachedness) > > >>> referenced by m_execontext.c:346 > > >>> > libcoregrind_arm_linux_a-m_execontext.o:(record_ExeContext_wrk2) in archive > ../coregrind/libcoregrind-arm-linux.a > > >>> referenced by m_execontext.c:346 > > >>> > libcoregrind_arm_linux_a-m_execontext.o:(record_ExeContext_wrk2) in archive > ../coregrind/libcoregrind-arm-linux.a > > >>> referenced 11 more times > > > [[snip]] > > You should contact whoever supports aarch64-linux-android31-clang and > complaln > that their linker step for static linking forgets to reference a static > library > that contains __aeabi_uidivmod, __aeabi_d2ulz, __aeabi_ul2d, > __aeabi_uldivmod, > __aeabi_uidiv, __aeabi_idiv, __aeabi_idivmod, and __aeabi_ldivmod . > > I found them in: > ----- > $ nm -gop --defined-only $(find . -name '*.a' 2>/dev/null) | grep > __aeabi_uidivmod > ./Android/Sdk/build-tools/32.0.0/renderscript/lib/intermediates/armeabi-v7a/libcompiler_rt.a:aeabi_uidivmod.o:00000000 > T __aeabi_uidivmod > ./Android/Sdk/build-tools/32.1.0-rc1/renderscript/lib/intermediates/armeabi-v7a/libcompiler_rt.a:aeabi_uidivmod.o:00000000 > T __aeabi_uidivmod > ./Android/Sdk/build-tools/30.0.3/renderscript/lib/intermediates/armeabi-v7a/libcompiler_rt.a:aeabi_uidivmod.o:00000000 > T __aeabi_uidivmod > $ > ----- > and similarly for the other undefined symbols. > > Therefore a workaround is to append explicit names for the files that > contain > those runtime symbols that you desire. > > The hint on how to investigate this problem is in > valgrind/coregrind/link_tool_exe_linux > which is a well-documented perl script that contains > ----- > # So: what we actually do: > # > # pass the specified command to the linker as-is, except, ... > > my $cmd = join(" ", @ARGV, "-static -Wl,-Ttext-segment=$ala"); > > #print "link_tool_exe_linux: $cmd\n"; > > > # Execute the command: > my $r = system($cmd); > ----- > which shows that aarch64-linux-android31-clang is at fault when static > linking. > (Forgetting the case of static linking is a common error in cross-building > systems.) > > > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: John R. <jr...@bi...> - 2022-06-26 22:32:23
|
> Upon moving to next. It landed into another issue. seems it is not easy to cross compile the valgrind to Android as they mentioned https://valgrind.org/docs/manual/dist.readme-android.html <https://valgrind.org/docs/manual/dist.readme-android.html> > > Should i need to contact valgrind developers list to support. > > ../coregrind/link_tool_exe_linux 0x58000000 /local/mnt/workspace/Android_ndk/android-ndk-r23c/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android31-clang -O3 --target=aarch64-linux-android31-clang > --gcc-toolchain=/local/mnt/workspace/Android_ndk/android-ndk-r23c/toolchains/llvm/prebuilt/linux-x86_64/bin/ --sysroot=/local/mnt/workspace/Android_ndk/android-ndk-r23c/toolchains/llvm/prebuilt/linux-x86_64/sysroot -o memcheck-arm-linux -m32 -O2 -g -Wall -Wmissing-prototypes -Wshadow > -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wcast-qual -Wwrite-strings -Wempty-body -Wformat -Wformat-security -Wignored-qualifiers -Wenum-conversion -finline-functions -fno-stack-protector -fno-strict-aliasing -fno-builtin -Wno-cast-align -Wno-self-assign -Wno-tautological-compare > -marm -mcpu=cortex-a8 -O2 -static -nodefaultlibs -nostartfiles -u _start -m32 -Wl,-z,noexecstack memcheck_arm_linux-mc_leakcheck.o memcheck_arm_linux-mc_malloc_wrappers.o memcheck_arm_linux-mc_main.o memcheck_arm_linux-mc_main_asm.o memcheck_arm_linux-mc_translate.o > memcheck_arm_linux-mc_machine.o memcheck_arm_linux-mc_errors.o ../coregrind/libcoregrind-arm-linux.a ../VEX/libvex-arm-linux.a > ld: error: undefined symbol: __aeabi_uidivmod > >>> referenced by mc_leakcheck.c:837 > >>> memcheck_arm_linux-mc_leakcheck.o:(heuristic_reachedness) > >>> referenced by m_execontext.c:346 > >>> libcoregrind_arm_linux_a-m_execontext.o:(record_ExeContext_wrk2) in archive ../coregrind/libcoregrind-arm-linux.a > >>> referenced by m_execontext.c:346 > >>> libcoregrind_arm_linux_a-m_execontext.o:(record_ExeContext_wrk2) in archive ../coregrind/libcoregrind-arm-linux.a > >>> referenced 11 more times > > [[snip]] You should contact whoever supports aarch64-linux-android31-clang and complaln that their linker step for static linking forgets to reference a static library that contains __aeabi_uidivmod, __aeabi_d2ulz, __aeabi_ul2d, __aeabi_uldivmod, __aeabi_uidiv, __aeabi_idiv, __aeabi_idivmod, and __aeabi_ldivmod . I found them in: ----- $ nm -gop --defined-only $(find . -name '*.a' 2>/dev/null) | grep __aeabi_uidivmod ./Android/Sdk/build-tools/32.0.0/renderscript/lib/intermediates/armeabi-v7a/libcompiler_rt.a:aeabi_uidivmod.o:00000000 T __aeabi_uidivmod ./Android/Sdk/build-tools/32.1.0-rc1/renderscript/lib/intermediates/armeabi-v7a/libcompiler_rt.a:aeabi_uidivmod.o:00000000 T __aeabi_uidivmod ./Android/Sdk/build-tools/30.0.3/renderscript/lib/intermediates/armeabi-v7a/libcompiler_rt.a:aeabi_uidivmod.o:00000000 T __aeabi_uidivmod $ ----- and similarly for the other undefined symbols. Therefore a workaround is to append explicit names for the files that contain those runtime symbols that you desire. The hint on how to investigate this problem is in valgrind/coregrind/link_tool_exe_linux which is a well-documented perl script that contains ----- # So: what we actually do: # # pass the specified command to the linker as-is, except, ... my $cmd = join(" ", @ARGV, "-static -Wl,-Ttext-segment=$ala"); #print "link_tool_exe_linux: $cmd\n"; # Execute the command: my $r = system($cmd); ----- which shows that aarch64-linux-android31-clang is at fault when static linking. (Forgetting the case of static linking is a common error in cross-building systems.) |
|
From: ellie <el...@ho...> - 2022-06-26 10:48:18
|
Oh I'm so silly, it appears I simply canceled the program seeing the SIGILL warning assuming it was just about to crash when I just would have needed to let it run. Thanks so much for explaining :-) For what it's worth, this is on an ARM64 Allwinner/PinePhone 1.2 CE 3GB RAM edition, so an early ARM64 architecture. I usually only use valgrind on my x64 desktop where there isn't any such SIGILL stuff, so that's why I'm not very familiar with it. On 6/26/22 10:52 AM, Tom Hughes wrote: > On 26/06/2022 09:13, ellie wrote: > >> How do I run openssl programs in valgrind on processors where it >> causes SIGILL? https://www.openssl.org/docs/faq.html#PROG17 > > In what way is it not working? > > When valgrind encounters an instruction it doesn't understand it > logs the details and then passes the SIGILL to and signal handler > which the application has registered exactly as openssl appears > to be expecting. > > Are you sure the SIGILL you're seeing is caused by openssl processor > feature detection and isn't just some other random instruction that > valgrind doesn't implement yet? What architecture is this? > > Tom > |
|
From: Mark W. <ma...@kl...> - 2022-06-26 10:16:45
|
Hi Ellie, On Sun, Jun 26, 2022 at 10:13:37AM +0200, ellie wrote: > How do I run openssl programs in valgrind on processors where it causes > SIGILL? https://www.openssl.org/docs/faq.html#PROG17 > > They recommend to use handle SIGILL nostop, but the only mention in the > valgrind documentation of that seems to be how to do this in gdb, not how to > do this in valgrind itself. Valgrind has (see the man page or manual): --sigill-diagnostics=<yes|no> [default: yes] Enable/disable printing of illegal instruction diagnostics. Enabled by default, but defaults to disabled when --quiet is given. The default can always be explicitly overridden by giving this option. When enabled, a warning message will be printed, along with some diagnostics, whenever an instruction is encountered that Valgrind cannot decode or translate, before the program is given a SIGILL signal. Often an illegal instruction indicates a bug in the program or missing support for the particular instruction in Valgrind. But some programs do deliberately try to execute an instruction that might be missing and trap the SIGILL signal to detect processor features. Using this flag makes it possible to avoid the diagnostic output that you would otherwise get in such cases. Hope that helps. Cheers, Mark |
|
From: Tom H. <to...@co...> - 2022-06-26 09:33:35
|
On 26/06/2022 09:13, ellie wrote: > How do I run openssl programs in valgrind on processors where it causes > SIGILL? https://www.openssl.org/docs/faq.html#PROG17 In what way is it not working? When valgrind encounters an instruction it doesn't understand it logs the details and then passes the SIGILL to and signal handler which the application has registered exactly as openssl appears to be expecting. Are you sure the SIGILL you're seeing is caused by openssl processor feature detection and isn't just some other random instruction that valgrind doesn't implement yet? What architecture is this? Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: ellie <el...@ho...> - 2022-06-26 08:29:54
|
Hi everyone, How do I run openssl programs in valgrind on processors where it causes SIGILL? https://www.openssl.org/docs/faq.html#PROG17 They recommend to use handle SIGILL nostop, but the only mention in the valgrind documentation of that seems to be how to do this in gdb, not how to do this in valgrind itself. Regards, ellie |
|
From: $<ri...@nt...> - 2022-06-25 06:37:33
|
Upon moving to next. It landed into another issue. seems it is not easy to cross compile the valgrind to Android as they mentioned https://valgrind.org/docs/manual/dist.readme-android.html Should i need to contact valgrind developers list to support. ../coregrind/link_tool_exe_linux 0x58000000 /local/mnt/workspace/Android_ndk/android-ndk-r23c/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android31-clang -O3 --target=aarch64-linux-android31-clang --gcc-toolchain=/local/mnt/workspace/Android_ndk/android-ndk-r23c/toolchains/llvm/prebuilt/linux-x86_64/bin/ --sysroot=/local/mnt/workspace/Android_ndk/android-ndk-r23c/toolchains/llvm/prebuilt/linux-x86_64/sysroot -o memcheck-arm-linux -m32 -O2 -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wcast-qual -Wwrite-strings -Wempty-body -Wformat -Wformat-security -Wignored-qualifiers -Wenum-conversion -finline-functions -fno-stack-protector -fno-strict-aliasing -fno-builtin -Wno-cast-align -Wno-self-assign -Wno-tautological-compare -marm -mcpu=cortex-a8 -O2 -static -nodefaultlibs -nostartfiles -u _start -m32 -Wl,-z,noexecstack memcheck_arm_linux-mc_leakcheck.o memcheck_arm_linux-mc_malloc_wrappers.o memcheck_arm_linux-mc_main.o memcheck_arm_linux-mc_main_asm.o memcheck_arm_linux-mc_translate.o memcheck_arm_linux-mc_machine.o memcheck_arm_linux-mc_errors.o ../coregrind/libcoregrind-arm-linux.a ../VEX/libvex-arm-linux.a ld: error: undefined symbol: __aeabi_uidivmod >>> referenced by mc_leakcheck.c:837 >>> memcheck_arm_linux-mc_leakcheck.o:(heuristic_reachedness) >>> referenced by m_execontext.c:346 >>> libcoregrind_arm_linux_a-m_execontext.o:(record_ExeContext_wrk2) in archive ../coregrind/libcoregrind-arm-linux.a >>> referenced by m_execontext.c:346 >>> libcoregrind_arm_linux_a-m_execontext.o:(record_ExeContext_wrk2) in archive ../coregrind/libcoregrind-arm-linux.a >>> referenced 11 more times ld: error: undefined symbol: __aeabi_d2ulz >>> referenced by m_debuglog.c:1137 >>> libcoregrind_arm_linux_a-m_debuglog.o:(vgPlain_debugLog_vprintf) in archive ../coregrind/libcoregrind-arm-linux.a >>> referenced by m_debuglog.c:1149 >>> libcoregrind_arm_linux_a-m_debuglog.o:(vgPlain_debugLog_vprintf) in archive ../coregrind/libcoregrind-arm-linux.a >>> referenced by m_xtree.c:969 >>> libcoregrind_arm_linux_a-m_xtree.o:(vgPlain_XT_massif_print) in archive ../coregrind/libcoregrind-arm-linux.a ld: error: undefined symbol: __aeabi_ul2d >>> referenced by m_debuglog.c:1138 >>> libcoregrind_arm_linux_a-m_debuglog.o:(vgPlain_debugLog_vprintf) in archive ../coregrind/libcoregrind-arm-linux.a >>> referenced by m_debuglog.c:1149 >>> libcoregrind_arm_linux_a-m_debuglog.o:(vgPlain_debugLog_vprintf) in archive ../coregrind/libcoregrind-arm-linux.a >>> referenced by m_debuglog.c:1150 >>> libcoregrind_arm_linux_a-m_debuglog.o:(vgPlain_debugLog_vprintf) in archive ../coregrind/libcoregrind-arm-linux.a >>> referenced 18 more times ld: error: undefined symbol: __aeabi_uldivmod >>> referenced by m_debuglog.c:1155 >>> libcoregrind_arm_linux_a-m_debuglog.o:(vgPlain_debugLog_vprintf) in archive ../coregrind/libcoregrind-arm-linux.a >>> referenced by m_debuglog.c:877 >>> libcoregrind_arm_linux_a-m_debuglog.o:(myvprintf_int64) in archive ../coregrind/libcoregrind-arm-linux.a >>> referenced by m_debuglog.c:877 >>> libcoregrind_arm_linux_a-m_debuglog.o:(myvprintf_int64) in archive ../coregrind/libcoregrind-arm-linux.a >>> referenced 13 more times ld: error: undefined symbol: __aeabi_uidiv >>> referenced by m_libcbase.c:925 >>> libcoregrind_arm_linux_a-m_libcbase.o:(bm_qsort) in archive ../coregrind/libcoregrind-arm-linux.a >>> referenced by m_libcbase.c:929 >>> libcoregrind_arm_linux_a-m_libcbase.o:(bm_qsort) in archive ../coregrind/libcoregrind-arm-linux.a >>> referenced by m_libcbase.c:916 >>> libcoregrind_arm_linux_a-m_libcbase.o:(bm_qsort) in archive ../coregrind/libcoregrind-arm-linux.a >>> referenced 17 more times ld: error: undefined symbol: __aeabi_idiv >>> referenced by m_transtab.c:1789 >>> libcoregrind_arm_linux_a-m_transtab.o:(vgPlain_add_to_transtab) in archive ../coregrind/libcoregrind-arm-linux.a >>> referenced by m_transtab.c:1795 >>> libcoregrind_arm_linux_a-m_transtab.o:(vgPlain_add_to_transtab) in archive ../coregrind/libcoregrind-arm-linux.a >>> referenced by d3basics.c:899 (m_debuginfo/d3basics.c:899) >>> libcoregrind_arm_linux_a-d3basics.o:(vgModuleLocal_evaluate_Dwarf3_Expr) in archive ../coregrind/libcoregrind-arm-linux.a >>> referenced 3 more times ld: error: undefined symbol: __aeabi_idivmod >>> referenced by readdwarf3.c:5529 (m_debuginfo/readdwarf3.c:5529) >>> libcoregrind_arm_linux_a-readdwarf3.o:(new_dwarf3_reader_wrk) in archive ../coregrind/libcoregrind-arm-linux.a >>> referenced by readdwarf3.c:5532 (m_debuginfo/readdwarf3.c:5532) >>> libcoregrind_arm_linux_a-readdwarf3.o:(new_dwarf3_reader_wrk) in archive ../coregrind/libcoregrind-arm-linux.a >>> referenced by ir_opt.c:3426 (priv/ir_opt.c:3426) >>> libvex_arm_linux_a-ir_opt.o:(getAliasingRelation_II) in archive ../VEX/libvex-arm-linux.a >>> referenced 1 more times ld: error: undefined symbol: __aeabi_ldivmod >>> referenced by host_generic_simd64.c:1627 (priv/host_generic_simd64.c:1627) >>> libvex_arm_linux_a-host_generic_simd64.o:(h_calc_sdiv64_w_arm_semantics) in archive ../VEX/libvex-arm-linux.a clang-12: error: linker command failed with exit code 1 (use -v to see invocation) Makefile:1111: recipe for target 'memcheck-arm-linux' failed make[3]: *** [memcheck-arm-linux] Error 1 make[3]: Leaving directory '/local/mnt/workspace/valgrind/valgrind-3.19.0/memcheck' Makefile:1423: recipe for target 'all-recursive' failed make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory '/local/mnt/workspace/valgrind/valgrind-3.19.0/memcheck' Makefile:896: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/local/mnt/workspace/valgrind/valgrind-3.19.0' Makefile:759: recipe for target 'all' failed make: *** [all] Error 2 On Fri, Jun 24, 2022 at 6:24 PM Floyd, Paul <pj...@wa...> wrote: > > > On 2022-06-24 05:41, $rik@nth wrote: > > Hello Paul, > > > > Seems even after removing -lgcc from Makefile.tool.am > > <http://Makefile.tool.am> compilation is still failing because of other > > dependencies on libgcc. > > > ../coregrind/libgcc-sup-arm64-linux.a > > ld: error: undefined symbol: __aeabi_uidivmod > > >>> referenced by mc_leakcheck.c:837 > > >>> > memcheck_arm_linux-mc_leakcheck.o:(heuristic_reachedness) > > >>> referenced by m_execontext.c:346 > > >>> > > The source line is just > > > if (nr_elts > 0 && (ch->szB - sizeof(SizeT)) % nr_elts == 0) { > > and I presume that is the modulus operator that is bringing in > __aeabi_uidivmod > > According to https://clang.llvm.org/docs/ClangCommandLineReference.html > there may be a clang runtime library libclang_rt.builtins.*.a > > If you have that could you try linking with it (instead of libgcc.a)? > > A+ > Paul > > > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > -- Thanks & Regards, M.Srikanth Kumar. |
|
From: Floyd, P. <pj...@wa...> - 2022-06-24 12:53:09
|
On 2022-06-24 05:41, $rik@nth wrote: > Hello Paul, > > Seems even after removing -lgcc from Makefile.tool.am > <http://Makefile.tool.am> compilation is still failing because of other > dependencies on libgcc. > ../coregrind/libgcc-sup-arm64-linux.a > ld: error: undefined symbol: __aeabi_uidivmod > >>> referenced by mc_leakcheck.c:837 > >>> memcheck_arm_linux-mc_leakcheck.o:(heuristic_reachedness) > >>> referenced by m_execontext.c:346 > >>> The source line is just if (nr_elts > 0 && (ch->szB - sizeof(SizeT)) % nr_elts == 0) { and I presume that is the modulus operator that is bringing in __aeabi_uidivmod According to https://clang.llvm.org/docs/ClangCommandLineReference.html there may be a clang runtime library libclang_rt.builtins.*.a If you have that could you try linking with it (instead of libgcc.a)? A+ Paul |
|
From: $<ri...@nt...> - 2022-06-24 05:28:43
|
Hello Paul,
Seems even after removing -lgcc from Makefile.tool.am compilation is still
failing because of other dependencies on libgcc.
==================================================================================
TOOL_LDADD_COMMON = \
$(top_builddir)/coregrind/libgcc-sup-@VGCONF_ARCH_PRI@-@VGCONF_OS@.a
TOOL_LDADD_@VGCONF_PLATFORM_PRI_CAPS@ = \
$(TOOL_DEPENDENCIES_@VGCONF_PLATFORM_PRI_CAPS@) $(TOOL_LDADD_COMMON)
if VGCONF_HAVE_PLATFORM_SEC
TOOL_LDADD_@VGCONF_PLATFORM_SEC_CAPS@ = \
$(TOOL_DEPENDENCIES_@VGCONF_PLATFORM_SEC_CAPS@) $(TOOL_LDADD_COMMON)
endif
==================================================================================
../coregrind/link_tool_exe_linux 0x58000000
/local/mnt/workspace/Android_ndk/android-ndk-r23c/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android31-clang
-O3 --target=aarch64-linux-android31-clang
--gcc-toolchain=/local/mnt/workspace/Android_ndk/android-ndk-r23c/toolchains/llvm/prebuilt/linux-x86_64/bin/
--sysroot=/local/mnt/workspace/Android_ndk/android-ndk-r23c/toolchains/llvm/prebuilt/linux-x86_64/sysroot
-o memcheck-arm-linux -m32 -O2 -g -Wall -Wmissing-prototypes -Wshadow
-Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wcast-align
-Wcast-qual -Wwrite-strings -Wempty-body -Wformat -Wformat-security
-Wignored-qualifiers -Wenum-conversion -finline-functions
-fno-stack-protector -fno-strict-aliasing -fno-builtin -Wno-cast-align
-Wno-self-assign -Wno-tautological-compare -marm -mcpu=cortex-a8 -O2
-static -nodefaultlibs -nostartfiles -u _start -m32 -Wl,-z,noexecstack
memcheck_arm_linux-mc_leakcheck.o memcheck_arm_linux-mc_malloc_wrappers.o
memcheck_arm_linux-mc_main.o memcheck_arm_linux-mc_main_asm.o
memcheck_arm_linux-mc_translate.o memcheck_arm_linux-mc_machine.o
memcheck_arm_linux-mc_errors.o ../coregrind/libcoregrind-arm-linux.a
../VEX/libvex-arm-linux.a ../coregrind/libgcc-sup-arm64-linux.a
ld: error: undefined symbol: __aeabi_uidivmod
>>> referenced by mc_leakcheck.c:837
>>> memcheck_arm_linux-mc_leakcheck.o:(heuristic_reachedness)
>>> referenced by m_execontext.c:346
>>>
libcoregrind_arm_linux_a-m_execontext.o:(record_ExeContext_wrk2) in archive
../coregrind/libcoregrind-arm-linux.a
>>> referenced by m_execontext.c:346
>>>
libcoregrind_arm_linux_a-m_execontext.o:(record_ExeContext_wrk2) in archive
../coregrind/libcoregrind-arm-linux.a
>>> referenced 11 more times
ld: error: undefined symbol: __aeabi_d2ulz
>>> referenced by m_debuglog.c:1137
>>>
libcoregrind_arm_linux_a-m_debuglog.o:(vgPlain_debugLog_vprintf) in archive
../coregrind/libcoregrind-arm-linux.a
>>> referenced by m_debuglog.c:1149
>>>
libcoregrind_arm_linux_a-m_debuglog.o:(vgPlain_debugLog_vprintf) in archive
../coregrind/libcoregrind-arm-linux.a
>>> referenced by m_xtree.c:969
>>>
libcoregrind_arm_linux_a-m_xtree.o:(vgPlain_XT_massif_print) in archive
../coregrind/libcoregrind-arm-linux.a
ld: error: undefined symbol: __aeabi_ul2d
>>> referenced by m_debuglog.c:1138
>>>
libcoregrind_arm_linux_a-m_debuglog.o:(vgPlain_debugLog_vprintf) in archive
../coregrind/libcoregrind-arm-linux.a
>>> referenced by m_debuglog.c:1149
>>>
libcoregrind_arm_linux_a-m_debuglog.o:(vgPlain_debugLog_vprintf) in archive
../coregrind/libcoregrind-arm-linux.a
>>> referenced by m_debuglog.c:1150
>>>
libcoregrind_arm_linux_a-m_debuglog.o:(vgPlain_debugLog_vprintf) in archive
../coregrind/libcoregrind-arm-linux.a
>>> referenced 18 more times
ld: error: undefined symbol: __aeabi_uldivmod
>>> referenced by m_debuglog.c:1155
>>>
libcoregrind_arm_linux_a-m_debuglog.o:(vgPlain_debugLog_vprintf) in archive
../coregrind/libcoregrind-arm-linux.a
>>> referenced by m_debuglog.c:877
>>> libcoregrind_arm_linux_a-m_debuglog.o:(myvprintf_int64)
in archive ../coregrind/libcoregrind-arm-linux.a
>>> referenced by m_debuglog.c:877
>>> libcoregrind_arm_linux_a-m_debuglog.o:(myvprintf_int64)
in archive ../coregrind/libcoregrind-arm-linux.a
>>> referenced 13 more times
ld: error: undefined symbol: __aeabi_uidiv
>>> referenced by m_libcbase.c:925
>>> libcoregrind_arm_linux_a-m_libcbase.o:(bm_qsort) in
archive ../coregrind/libcoregrind-arm-linux.a
>>> referenced by m_libcbase.c:929
>>> libcoregrind_arm_linux_a-m_libcbase.o:(bm_qsort) in
archive ../coregrind/libcoregrind-arm-linux.a
>>> referenced by m_libcbase.c:916
>>> libcoregrind_arm_linux_a-m_libcbase.o:(bm_qsort) in
archive ../coregrind/libcoregrind-arm-linux.a
>>> referenced 17 more times
ld: error: undefined symbol: __aeabi_idiv
>>> referenced by m_transtab.c:1789
>>>
libcoregrind_arm_linux_a-m_transtab.o:(vgPlain_add_to_transtab) in archive
../coregrind/libcoregrind-arm-linux.a
>>> referenced by m_transtab.c:1795
>>>
libcoregrind_arm_linux_a-m_transtab.o:(vgPlain_add_to_transtab) in archive
../coregrind/libcoregrind-arm-linux.a
>>> referenced by d3basics.c:899 (m_debuginfo/d3basics.c:899)
>>>
libcoregrind_arm_linux_a-d3basics.o:(vgModuleLocal_evaluate_Dwarf3_Expr) in
archive ../coregrind/libcoregrind-arm-linux.a
>>> referenced 3 more times
ld: error: undefined symbol: __aeabi_idivmod
>>> referenced by readdwarf3.c:5529 (m_debuginfo/readdwarf3.c:5529)
>>>
libcoregrind_arm_linux_a-readdwarf3.o:(new_dwarf3_reader_wrk) in archive
../coregrind/libcoregrind-arm-linux.a
>>> referenced by readdwarf3.c:5532 (m_debuginfo/readdwarf3.c:5532)
>>>
libcoregrind_arm_linux_a-readdwarf3.o:(new_dwarf3_reader_wrk) in archive
../coregrind/libcoregrind-arm-linux.a
>>> referenced by ir_opt.c:3426 (priv/ir_opt.c:3426)
>>> libvex_arm_linux_a-ir_opt.o:(getAliasingRelation_II) in
archive ../VEX/libvex-arm-linux.a
>>> referenced 1 more times
ld: error: undefined symbol: __aeabi_ldivmod
>>> referenced by host_generic_simd64.c:1627
(priv/host_generic_simd64.c:1627)
>>>
libvex_arm_linux_a-host_generic_simd64.o:(h_calc_sdiv64_w_arm_semantics) in
archive ../VEX/libvex-arm-linux.a
clang-12: error: linker command failed with exit code 1 (use -v to see
invocation)
Makefile:1099: recipe for target 'memcheck-arm-linux' failed
make[3]: *** [memcheck-arm-linux] Error 1
make[3]: Leaving directory
'/local/mnt/workspace/valgrind/valgrind-3.19.0/memcheck'
Makefile:1401: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
'/local/mnt/workspace/valgrind/valgrind-3.19.0/memcheck'
Makefile:896: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/local/mnt/workspace/valgrind/valgrind-3.19.0'
Makefile:759: recipe for target 'all' failed
make: *** [all] Error 2
On Thu, Jun 23, 2022 at 8:56 PM Floyd, Paul <pj...@wa...> wrote:
>
>
> On 2022-06-23 12:04, $rik@nth wrote:
> > Hello Valgrind Users,
> >
> > I am trying to cross compile the valgrind for Android using NDK. But I
> > am seeing the compilation error. Has anyone faced a similar issue?
>
> Hi
>
> I did touch this recently (on FreeBSD which uses clang as system
> compiler). I did try removing this dependency, but it caused some
> failures due to the use of intrinsics in libgcc. So I kept it - libgcc
> is available on stock FreeBSD.
>
> It's quite easy to fix.
>
> Edit Makefile.tool.am in the root Valgrind source directory and just
> remove -lgcc from TOOL_LDADD_COMMON
>
> Rerun autogen.sh and configure.
>
>
> A+
> Paul
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
--
Thanks & Regards,
M.Srikanth Kumar.
|
|
From: Dallman, J. <joh...@si...> - 2022-06-23 15:51:09
|
NDK23c does not provide any libgcc libraries. This is reasonable, since it also does not provide a gcc: it uses clang instead. I’ve never tried to build Valgrind for Android, but hopefully someone else can tell you how to do it with a modern NDK. -- John Dallman From: $rik@nth <sri...@gm...> Sent: 23 June 2022 11:05 To: val...@li... Subject: [Valgrind-users] Cross compilation issue for Android Hello Valgrind Users, I am trying to cross compile the valgrind for Android using NDK. But I am seeing the compilation error. Has anyone faced a similar issue? ../coregrind/link_tool_exe_linux 0x58000000 /local/mnt/workspace/Android_ndk/android-ndk-r23c/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android31-clang -o memcheck-arm64-linux -m64 -O2 -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wcast-align -Wcast-qual -Wwrite-strings -Wempty-body -Wformat -Wformat-security -Wignored-qualifiers -Wenum-conversion -finline-functions -fno-stack-protector -fno-strict-aliasing -fno-builtin -Wno-cast-align -Wno-self-assign -Wno-tautological-compare -O2 -static -nodefaultlibs -nostartfiles -u _start -m64 memcheck_arm64_linux-mc_leakcheck.o memcheck_arm64_linux-mc_malloc_wrappers.o memcheck_arm64_linux-mc_main.o memcheck_arm64_linux-mc_main_asm.o memcheck_arm64_linux-mc_translate.o memcheck_arm64_linux-mc_machine.o memcheck_arm64_linux-mc_errors.o ../coregrind/libcoregrind-arm64-linux.a ../VEX/libvex-arm64-linux.a -lgcc ../coregrind/libgcc-sup-arm64-linux.a ld: error: unable to find library -lgcc clang-12: error: linker command failed with exit code 1 (use -v to see invocation) Makefile:1111: recipe for target 'memcheck-arm64-linux' failed make[3]: *** [memcheck-arm64-linux] Error 1 make[3]: Leaving directory '/local/mnt/workspace/valgrind/valgrind-3.19.0/memcheck' Makefile:1423: recipe for target 'all-recursive' failed make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory '/local/mnt/workspace/valgrind/valgrind-3.19.0/memcheck' Makefile:896: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/local/mnt/workspace/valgrind/valgrind-3.19.0' Makefile:759: recipe for target 'all' failed make: *** [all] Error 2 -- Thanks & Regards, M.Srikanth Kumar. ----------------- Siemens Industry Software Limited is a limited company registered in England and Wales. Registered number: 3476850. Registered office: Pinehurst 2, Pinehurst Road, Farnborough, Hampshire, GU14 7BF. |
|
From: Floyd, P. <pj...@wa...> - 2022-06-23 15:25:10
|
On 2022-06-23 12:04, $rik@nth wrote: > Hello Valgrind Users, > > I am trying to cross compile the valgrind for Android using NDK. But I > am seeing the compilation error. Has anyone faced a similar issue? Hi I did touch this recently (on FreeBSD which uses clang as system compiler). I did try removing this dependency, but it caused some failures due to the use of intrinsics in libgcc. So I kept it - libgcc is available on stock FreeBSD. It's quite easy to fix. Edit Makefile.tool.am in the root Valgrind source directory and just remove -lgcc from TOOL_LDADD_COMMON Rerun autogen.sh and configure. A+ Paul |
|
From: $<ri...@nt...> - 2022-06-23 15:14:43
|
Ok, thanks for the reply. Anyone else in the group have ever tried cross compiling and get success with this? On Thu, Jun 23, 2022, 8:40 PM Dallman, John <joh...@si...> wrote: > NDK23c does not provide any libgcc libraries. This is reasonable, since it > also does not provide a gcc: it uses clang instead. I’ve never tried to > build Valgrind for Android, but hopefully someone else can tell you how to > do it with a modern NDK. > > > > -- > > John Dallman > > > > *From:* $rik@nth <sri...@gm...> > *Sent:* 23 June 2022 11:05 > *To:* val...@li... > *Subject:* [Valgrind-users] Cross compilation issue for Android > > > > Hello Valgrind Users, > > > > I am trying to cross compile the valgrind for Android using NDK. But I am > seeing the compilation error. Has anyone faced a similar issue? > > > > ../coregrind/link_tool_exe_linux 0x58000000 > /local/mnt/workspace/Android_ndk/android-ndk-r23c/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android31-clang > -o memcheck-arm64-linux -m64 -O2 -g -Wall -Wmissing-prototypes > -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations > -Wcast-align -Wcast-qual -Wwrite-strings -Wempty-body -Wformat > -Wformat-security -Wignored-qualifiers -Wenum-conversion -finline-functions > -fno-stack-protector -fno-strict-aliasing -fno-builtin -Wno-cast-align > -Wno-self-assign -Wno-tautological-compare -O2 -static -nodefaultlibs > -nostartfiles -u _start -m64 memcheck_arm64_linux-mc_leakcheck.o > memcheck_arm64_linux-mc_malloc_wrappers.o memcheck_arm64_linux-mc_main.o > memcheck_arm64_linux-mc_main_asm.o memcheck_arm64_linux-mc_translate.o > memcheck_arm64_linux-mc_machine.o memcheck_arm64_linux-mc_errors.o > ../coregrind/libcoregrind-arm64-linux.a ../VEX/libvex-arm64-linux.a -lgcc > ../coregrind/libgcc-sup-arm64-linux.a > ld: error: unable to find library -lgcc > clang-12: error: linker command failed with exit code 1 (use -v to see > invocation) > Makefile:1111: recipe for target 'memcheck-arm64-linux' failed > make[3]: *** [memcheck-arm64-linux] Error 1 > make[3]: Leaving directory > '/local/mnt/workspace/valgrind/valgrind-3.19.0/memcheck' > Makefile:1423: recipe for target 'all-recursive' failed > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory > '/local/mnt/workspace/valgrind/valgrind-3.19.0/memcheck' > Makefile:896: recipe for target 'all-recursive' failed > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory '/local/mnt/workspace/valgrind/valgrind-3.19.0' > Makefile:759: recipe for target 'all' failed > make: *** [all] Error 2 > > > > > > -- > > Thanks & Regards, > M.Srikanth Kumar. > > ----------------- > Siemens Industry Software Limited is a limited company registered in > England and Wales. > Registered number: 3476850. > Registered office: Pinehurst 2, Pinehurst Road, Farnborough, Hampshire, > GU14 7BF. > |
188 messages has been excluded from this view by a project administrator.
