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
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
|
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. > |
|
From: $<ri...@nt...> - 2022-06-23 10:04:51
|
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.
|
|
From: ISHIKAWA,chiaki <ish...@yk...> - 2022-05-24 04:26:52
|
John, Paul, and Mark Thank you for the information. Debian is a bit slow in updating tools. It is very conservative. Eventually, I obtained the valgrind git code. (Debian is a bit slow in updating tools. It is very conservative.) It contained the following. #if defined(VGO_linux) STRNCMP(VG_Z_LIBC_SONAME, strncmp) STRNCMP(VG_Z_LIBC_SONAME, __GI_strncmp) STRNCMP(VG_Z_LIBC_SONAME, __strncmp_sse2) STRNCMP(VG_Z_LIBC_SONAME, __strncmp_sse42) STRNCMP(VG_Z_LD_LINUX_SO_2, strncmp) <--- STRNCMP(VG_Z_LD_LINUX_X86_64_SO_2, strncmp) <--- #elif defined(VGO_freebsd) For now, with this version, I no longer get the warning for strncmp. As I looked for the false-positive warning in the new log, I have caught a real issue of my patch for thunderbird mail client. It was caused by slowdown by valgrind. This was not quite intentional, but it is surely helpful to simulate abnormal condition to trigger unforeseen uncaught error situations. The test is still running. Hopefully no more error related issues. BTW, it seemed the timing of valgrind has changed from 18.0. $ valgrind --version valgrind-3.20.0.GIT I mean valgrind may take a bit longer ? to simulate the program execution. (I am not sure. All I can is the elapsed time seems different. It may be related to the fact that false positive tracedump for strncmp is not printed any more, etc.) I probably need to tweak time out values during the test. It could be that I was not testing many smaller tests due to time out but did not realize it because I was focused on real memory errors reported by valgrind. Thank you again. Chiaki On 2022/05/21 18:42, John Reiser wrote: >> I sent a log of redirect information to both Paul and John since the >> log was too large was mailing list. >> >> I wonder what would be the preferred public sharing site for such a >> purpose these days. > > The preferred way is to create a bug report, attach the large file to > the bug report, > then post the URL of the bug report in a message to the mailing list. > > Begin at https://valgrind.org/ . In the left nav, click on "Bug > Reports", and follow > the directions on the resulting page. > > >> 143:39.43 GECKO(115765) ==115769== Invalid read of size 8 >> 143:39.64 GECKO(115765) ==115769== at 0x4021BF4: strncmp >> (strcmp.S:175) >> 143:39.64 GECKO(115765) ==115769== by 0x400655D: is_dst >> (dl-load.c:214) > > This indicates that 'strncmp' should be re-directed from > ld-linux-x86-64.so.2: > ===== > diff --git a/shared/vg_replace_strmem.c b/shared/vg_replace_strmem.c > index 3b42b3a87..8272a3ae7 100644 > --- a/shared/vg_replace_strmem.c > +++ b/shared/vg_replace_strmem.c > @@ -710,6 +710,7 @@ static inline void my_exit ( int x ) > STRNCMP(VG_Z_LIBC_SONAME, __GI_strncmp) > STRNCMP(VG_Z_LIBC_SONAME, __strncmp_sse2) > STRNCMP(VG_Z_LIBC_SONAME, __strncmp_sse42) > + STRNCMP("ld-linux*.so*", strncmp) > > #elif defined(VGO_freebsd) > STRNCMP(VG_Z_LIBC_SONAME, strncmp) > ===== > For instance, such a change is relevant to glibc-2.33-21.fc34.x86_64: > $ readelf --all /lib64/ld-linux-x86-64.so.2 | grep strncmp > 1706: 0000000000022d30 6233 FUNC LOCAL DEFAULT 13 strncmp > $ > > > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Mark W. <ma...@kl...> - 2022-05-21 10:15:45
|
Hi,
On Sat, May 21, 2022 at 02:42:22AM -0700, John Reiser wrote:
> > 143:39.43 GECKO(115765) ==115769== Invalid read of size 8
> > 143:39.64 GECKO(115765) ==115769== at 0x4021BF4: strncmp (strcmp.S:175)
> > 143:39.64 GECKO(115765) ==115769== by 0x400655D: is_dst
> > (dl-load.c:214)
>
> This indicates that 'strncmp' should be re-directed from ld-linux-x86-64.so.2:
> =====
> diff --git a/shared/vg_replace_strmem.c b/shared/vg_replace_strmem.c
> index 3b42b3a87..8272a3ae7 100644
> --- a/shared/vg_replace_strmem.c
> +++ b/shared/vg_replace_strmem.c
> @@ -710,6 +710,7 @@ static inline void my_exit ( int x )
> STRNCMP(VG_Z_LIBC_SONAME, __GI_strncmp)
> STRNCMP(VG_Z_LIBC_SONAME, __strncmp_sse2)
> STRNCMP(VG_Z_LIBC_SONAME, __strncmp_sse42)
> + STRNCMP("ld-linux*.so*", strncmp)
>
> #elif defined(VGO_freebsd)
> STRNCMP(VG_Z_LIBC_SONAME, strncmp)
This looks like https://bugs.kde.org/show_bug.cgi?id=434764
iconv_open causes ld.so v2.28+ to use optimised strncmp
Which was recently (but after 3.19.0) fixed by merging this commit:
commit 947388eb043ea1c44b37df94046e1eee790ad776
Author: Mike Crowe <ma...@mc...>
AuthorDate: Mon Sep 9 14:16:16 2019 +0100
Commit: Mark Wielaard <ma...@kl...>
CommitDate: Sat May 14 00:41:18 2022 +0200
Intercept strncmp for glibc ld.so v2.28+
In glibc 5aad5f617892e75d91d4c8fb7594ff35b610c042 (first released in
v2.28) a call to strncmp was added to dl-load.c:is_dst. This causes
valgrind to complain about glibc's highly-optimised strncmp performing
sixteen-byte reads on short strings in ld.so. Let's intercept strncmp in
ld.so too so we use valgrind's simple version to avoid this problem.
Cheers,
Mark
|
|
From: John R. <jr...@bi...> - 2022-05-21 10:13:39
|
> This looks like https://bugs.kde.org/show_bug.cgi?id=434764 > iconv_open causes ld.so v2.28+ to use optimised strncmp > > Which was recently (but after 3.19.0) fixed by merging this commit: > > commit 947388eb043ea1c44b37df94046e1eee790ad776 > Author: Mike Crowe <ma...@mc...> > AuthorDate: Mon Sep 9 14:16:16 2019 +0100 > Commit: Mark Wielaard <ma...@kl...> > CommitDate: Sat May 14 00:41:18 2022 +0200 > > Intercept strncmp for glibc ld.so v2.28+ > The C standard claims that all function names that begin with 'str' or 'mem' are reserved, and that language processors (compilers, valgrind, ...) may assume that such names designate the Standard functions. If so, then valgrind's interception code is too picky about the context for re-directing these functions; just use STRNCMP("*", strncmp) etc. to re-direct them all. |
|
From: John R. <jr...@bi...> - 2022-05-21 09:57:58
|
> This indicates that 'strncmp' should be re-directed from ld-linux-x86-64.so.2: That was done already in valgrind-3.19.0. The user problem was reported against: ----- ==4295== Memcheck, a memory error detector ==4295== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==4295== Using Valgrind-3.18.1-42b08ed5bd-20211015 and LibVEX; rerun with -h for copyright info ----- which probably does not contain the fix: $ git blame shared/vg_replace_strmem.c 947388eb04 (Mike Crowe 2019-09-09 14:16:16 +0100 713) STRNCMP(VG_Z_LD_LINUX_SO_2, strncmp) 947388eb04 (Mike Crowe 2019-09-09 14:16:16 +0100 714) STRNCMP(VG_Z_LD_LINUX_X86_64_SO_2, strncmp) |
|
From: John R. <jr...@bi...> - 2022-05-21 09:42:35
|
> I sent a log of redirect information to both Paul and John since the log was too large was mailing list. > > I wonder what would be the preferred public sharing site for such a purpose these days. The preferred way is to create a bug report, attach the large file to the bug report, then post the URL of the bug report in a message to the mailing list. Begin at https://valgrind.org/ . In the left nav, click on "Bug Reports", and follow the directions on the resulting page. > 143:39.43 GECKO(115765) ==115769== Invalid read of size 8 > 143:39.64 GECKO(115765) ==115769== at 0x4021BF4: strncmp (strcmp.S:175) > 143:39.64 GECKO(115765) ==115769== by 0x400655D: is_dst (dl-load.c:214) This indicates that 'strncmp' should be re-directed from ld-linux-x86-64.so.2: ===== diff --git a/shared/vg_replace_strmem.c b/shared/vg_replace_strmem.c index 3b42b3a87..8272a3ae7 100644 --- a/shared/vg_replace_strmem.c +++ b/shared/vg_replace_strmem.c @@ -710,6 +710,7 @@ static inline void my_exit ( int x ) STRNCMP(VG_Z_LIBC_SONAME, __GI_strncmp) STRNCMP(VG_Z_LIBC_SONAME, __strncmp_sse2) STRNCMP(VG_Z_LIBC_SONAME, __strncmp_sse42) + STRNCMP("ld-linux*.so*", strncmp) #elif defined(VGO_freebsd) STRNCMP(VG_Z_LIBC_SONAME, strncmp) ===== For instance, such a change is relevant to glibc-2.33-21.fc34.x86_64: $ readelf --all /lib64/ld-linux-x86-64.so.2 | grep strncmp 1706: 0000000000022d30 6233 FUNC LOCAL DEFAULT 13 strncmp $ |
|
From: ISHIKAWA,chiaki <ish...@yk...> - 2022-05-20 17:15:17
|
Hi, I sent a log of redirect information to both Paul and John since the log was too large was mailing list. I wonder what would be the preferred public sharing site for such a purpose these days. TIA Chiaki On 2022/05/21 0:57, John Reiser wrote: >> (Wait, I see "279:13.65 GECKO(392456) ==392459== by 0x488D2D3: >> dlopen@@GLIBC_2.2.5 (dlopen.c:87)" >> Version 2.2.5 is not the same as the version reported for glibc. Hmm? ) > > The "@@GLIBC_2.2.5" is the linking symbol version assigned by glibc. > This effectively is an ABI version, and the ABI for dlopen > has not changed for many years, even though other parts of > glibc have changed; one recent release is glibc-2.33. > > The real key to Chiaki's problem is: >> 279:13.65 GECKO(392456) ==392459== Invalid read of size 8 >> 279:13.65 GECKO(392456) ==392459== at 0x4021BF4: strncmp >> (strcmp.S:175) > which says that this 'strncmp' was not re-directed by valgrind. > Re-running valgrind with the additional command-line parameter > "--trace-redir=yes" will help provide more information. > Probably the run can be stopped after the first actual dlopen, > because that should be enough to trigger all the redirections > that matter here. > > > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: John R. <jr...@bi...> - 2022-05-20 15:57:26
|
> (Wait, I see "279:13.65 GECKO(392456) ==392459== by 0x488D2D3: dlopen@@GLIBC_2.2.5 (dlopen.c:87)" > Version 2.2.5 is not the same as the version reported for glibc. Hmm? ) The "@@GLIBC_2.2.5" is the linking symbol version assigned by glibc. This effectively is an ABI version, and the ABI for dlopen has not changed for many years, even though other parts of glibc have changed; one recent release is glibc-2.33. The real key to Chiaki's problem is: > 279:13.65 GECKO(392456) ==392459== Invalid read of size 8 > 279:13.65 GECKO(392456) ==392459== at 0x4021BF4: strncmp (strcmp.S:175) which says that this 'strncmp' was not re-directed by valgrind. Re-running valgrind with the additional command-line parameter "--trace-redir=yes" will help provide more information. Probably the run can be stopped after the first actual dlopen, because that should be enough to trigger all the redirections that matter here. |
188 messages has been excluded from this view by a project administrator.
