My aim is to run cross compiled valgrind on an arm emulated environment.
I have cross-compiled valgrind 3.13 using the arm-linaro toolchain(http://releases.linaro.org/components/toolchain/binaries/4.9-2016.02/arm-linux-gnueabi/) with command:
./configure --target=arm-none-linux-gnueabi --host=armv7-none-linux-gnueabi --prefix=/home/karan/valgrind/build CFLAGS=-static CPPFLAGS=-fPIC CFLAGS=-fPIC
make && make install
I have transferred the valgrind build folder on the docker container( docker image: https://hub.docker.com/r/arm32v7/ubuntu
in directory= /root/valgrind/build) and exported the PATH environment variable as well as VALGRIND_LIB variable.
After this when I try to run valgrind I get the output:
valgrind: no program specified
valgrind: Use --help for more information.
I created a simple demo file(try.cpp) which prints a string and compiled it on the docker itself with command = g++ try.cpp
//try.cpp
#include<iostream>
int main()
{
std::cout<<"HELLO";
return 0;
}
the linker used is the default one and the output of command = ldd a.out is
root#d170b9f5fc84:~# ldd a.out
libstdc++.so.6 => /lib/arm-linux-gnueabihf/libstdc++.so.6 (0xfe664000)
libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xfe63b000)
libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xfe53d000)
libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xfe4d4000)
/lib/ld-linux-armhf.so.3 (0xfefc5000)
However on running valgrind on this simple demo file, I get the error:
root#d170b9f5fc84:~# valgrind ./a.out
==4064== Memcheck, a memory error detector
==4064== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==4064== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==4064== Command: ./a.out
==4064==
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: strcmp
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
valgrind:
valgrind: Possible fixes: (1, short term): install glibc's debuginfo
valgrind: package on this machine. (2, longer term): ask the packagers
valgrind: for your Linux distribution to please in future ship a non-
valgrind: stripped ld.so (or whatever the dynamic linker .so is called)
valgrind: that exports the above-named function using the standard
valgrind: calling conventions for this platform. The package you need
valgrind: to install for fix (1) is called
valgrind:
valgrind: On Debian, Ubuntu: libc6-dbg
valgrind: On SuSE, openSuSE, Fedora, RHEL: glibc-debuginfo
valgrind:
valgrind: Note that if you are debugging a 32 bit process on a
valgrind: 64 bit system, you will need a corresponding 32 bit debuginfo
valgrind: package (e.g. libc6-dbg:i386).
valgrind:
valgrind: Cannot continue -- exiting now. Sorry.
I installed libc6-dbg ( command apt-get install libc6-dbg) but to no avail. I am still getting the same error. I thought of replacing the default linker in /lib/ directory (ld-linux-armhf.so.3 -> ld-2.31.so) with the linker provided in toolchain because it had the .symtab section but that broke the OS itself and then I couldn't run any commands on bash.
Could someone tell me how to run valgrind on the arm docker.? I believe My replacement of loader is not correct or incomplete.
Related
Here is the brief log:
# valgrind --error-limit=no --leak-check=full --tool=memcheck /mnt/aarch64/ld-linux-aarch64.so.1 ./program
==12104== Memcheck, a memory error detector
==12104== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==12104== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==12104== Command: /mnt/aarch64/ld-linux-aarch64.so.1 ./program
==12104==
vex: priv/host_arm64_defs.c:2796 (genSpill_ARM64): Assertion `offsetB < 4096' failed.
vex storage: T total 4207069920 bytes allocated
vex storage: P total 0 bytes allocated
valgrind: the 'impossible' happened:
LibVEX called failure_exit().
host stacktrace:
==12104== at 0x5803F488: show_sched_status_wrk (m_libcassert.c:406)
==12104== by 0x5803F5C7: report_and_quit (m_libcassert.c:477)
==12104== by 0x5803F7FB: panic (m_libcassert.c:553)
==12104== by 0x5803F7FB: vgPlain_core_panic_at (m_libcassert.c:558)
==12104== by 0x5803F81F: vgPlain_core_panic (m_libcassert.c:563)
==12104== by 0x5805481B: failure_exit (m_translate.c:761)
==12104== by 0x5811E043: vex_assert_fail (main_util.c:245)
==12104== by 0x5817A897: genSpill_ARM64 (host_arm64_defs.c:2796)
==12104== by 0x58172217: spill_vreg (host_generic_reg_alloc3.c:338)
==12104== by 0x5817324F: doRegisterAllocation_v3 (host_generic_reg_alloc3.c:1280)
==12104== by 0x5811CD97: libvex_BackEnd (main_main.c:1133)
==12104== by 0x5811CD97: LibVEX_Translate (main_main.c:1236)
==12104== by 0x58056FCB: vgPlain_translate (m_translate.c:1830)
==12104== by 0x58092A27: handle_chain_me (scheduler.c:1169)
==12104== by 0x580954A7: vgPlain_scheduler (scheduler.c:1514)
==12104== by 0x580D8E8F: thread_wrapper (syswrap-linux.c:101)
==12104== by 0x580D8E8F: run_a_thread_NORETURN (syswrap-linux.c:154)
==12104== by 0x580D916F: vgModuleLocal_start_thread_NORETURN (syswrap-linux.c:328)
==12104== by 0x580A68D3: ??? (in /mnt/aarch64/lib/valgrind/memcheck-arm64-linux)
sched status:
running_tid=3
I want to known whether the reset output of valgrind is still meaningful for pointing out the memory leak in the program when it reports the said error(i.e. the 'impossible' happened: LibVEX called failure_exit())
Updated:
The program does run, I can see many stack strace,e.g:
Thread 1: status = VgTs_WaitSys syscall 98 (lwpid 12168)
==12168== at 0x6E85274: syscall (in /lib/libc-2.31.so)
==12168== by 0x6B99FF3: std::__atomic_futex_unsigned_base
...
Thread 2:
...
In general, if Valgrind reports some errors and then encounters an internal error, those initial reports should be valid.
In the case of the message that you show, the first report is an internal error related to the virtualization of the ARM aarch64 CPU. That's only useful for Valgrind developers.
Try running Valgrind with -d -v. There will be a lot of output, but you should see
syswrap- run_a_thread_NORETURN(tid=1): pre-thread_wrapper that is the guest executable starting
a load of gdbsrv messages
a mix of REDIR and mallocrf/hashtbl messages as the guest startup code invokes ld.so to load shared libraries
I can't tell where you get the subsequent traces from - could be trace options, more likely from the assert.
I have a sample C++ program that would cause an obvious segmentation fault.
test.cxx:
int main()
{
int* ptr{nullptr};
*ptr = 3;
}
So I am using address sanitizer to debug it:
metal888#ThinkPad:~$ clang++ -g -fsanitize=address -fno-omit-frame-pointer -gz=zlib test.cxx -o vimbin && ./vimbin
clang-14: warning: cannot compress debug sections (zlib not installed) [-Wdebug-compression-unavailable]
AddressSanitizer:DEADLYSIGNAL
=================================================================
==42036==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x0000004dbeb1 bp 0x7ffd802e9310 sp 0x7ffd802e92f0 T0)
==42036==The signal is caused by a WRITE memory access.
==42036==Hint: address points to the zero page.
error: failed to decompress '.debug_aranges', zlib is not available
error: failed to decompress '.debug_info', zlib is not available
error: failed to decompress '.debug_abbrev', zlib is not available
error: failed to decompress '.debug_line', zlib is not available
error: failed to decompress '.debug_str', zlib is not available
error: failed to decompress '.debug_addr', zlib is not available
error: failed to decompress '.debug_line_str', zlib is not available
error: failed to decompress '.debug_rnglists', zlib is not available
error: failed to decompress '.debug_str_offsets', zlib is not available
error: failed to decompress '.debug_aranges', zlib is not available
error: failed to decompress '.debug_info', zlib is not available
error: failed to decompress '.debug_abbrev', zlib is not available
error: failed to decompress '.debug_line', zlib is not available
error: failed to decompress '.debug_str', zlib is not available
error: failed to decompress '.debug_loc', zlib is not available
error: failed to decompress '.debug_ranges', zlib is not available
#0 0x4dbeb1 in main (/home/metal888/vimbin+0x4dbeb1)
#1 0x7f5165493082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId: 1878e6b475720c7c51969e69ab2d276fae6d1dee)
#2 0x41c30d in _start (/home/metal888/vimbin+0x41c30d)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/home/metal888/vimbin+0x4dbeb1) in main
==42036==ABORTING
So it says zlib is not installed. So I tried to install zlib. It produces this result:
metal888#ThinkPad:~$ sudo apt install zlib1g zlib1g-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
zlib1g is already the newest version (1:1.2.11.dfsg-2ubuntu1.3).
zlib1g-dev is already the newest version (1:1.2.11.dfsg-2ubuntu1.3).
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
So that means zlib is actually installed but clang cannot find it. This is my clang version:
metal888#ThinkPad:~$ clang --version
clang version 14.0.0
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /opt/clang14/bin
So how can I tell clang how and where to find zlib? I installed clang by downloading binary release of clang-14 from llvm-releases.
Note that the zlib related errors don't occur if I use g++ instead of clang++.
metal888#ThinkPad:~$ g++ -g -fsanitize=address -fno-omit-frame-pointer -gz=zlib test.cxx -o vimbin && ./vimbin
AddressSanitizer:DEADLYSIGNAL
=================================================================
==44183==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x5601ea2f41d8 bp 0x7ffc8f97d9d0 sp 0x7ffc8f97d9c0 T0)
==44183==The signal is caused by a WRITE memory access.
==44183==Hint: address points to the zero page.
#0 0x5601ea2f41d7 in main /home/metal888/test.cxx:4
#1 0x7fb073a17082 in __libc_start_main ../csu/libc-start.c:308
#2 0x5601ea2f40cd in _start (/home/metal888/vimbin+0x10cd)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /home/metal888/test.cxx:4 in main
==44183==ABORTING
What I found out is that the prebuilt versions of clang-14 (and versions that came later) that's found in the LLVM download page are not built properly. The -g compiler flag doesn't include any debug symbols in the binary. And sanitizer needs debug symbols to work. That's why I was getting those errors. So you have 3 options left if you want to use the latest clang release that works perfectly.
Download clang+llvm-13.0.0 if you are on ubuntu 20.04. This one works just fine.
Build LLVM and clang (and lldb etc etc, all that you find necessary) in your machine yourself like I did.
Install clang from the official package repository. Although currently clang-12 is the most latest one that's available.
My OS: CentOS Linux release 7.9.2009 (Core)
I am debugging a c++ program with:
gdb demo_test
But I got an error:
Breakpoint 1, Log (level=2, msg=0x7ffff79df035 "[%s]:default model:%s") at ./api/test/test.cpp:16
16 va_start(ap, msg);
Missing separate debuginfos, use: debuginfo-install glibc-2.17-324.el7_9.x86_64 libgcc-4.8.5-44.el7.x86_64 libstdc++-4.8.5-44.el7.x86_64
Then I did:
yum install yum-utils
Loaded plugins: langpacks, product-id, search-disabled-repos
Package yum-utils-1.1.31-54.el7_8.noarch already installed and latest version
Nothing to do
Then I did:
# debuginfo-install glibc
Loaded plugins: langpacks, product-id
Could not find debuginfo for main pkg: glibc-2.17-324.el7_9.x86_64
Could not find debuginfo pkg for dependency package nss-softokn-freebl-3.53.1-6.el7_9.x86_64
No debuginfo packages available to install
This doesn't fix the issue. I also tried to remove the -02 flag from the g++:
g++ -g -Wall -O2 ./api/test/test.cpp ./${NAME}.so -o demo_test $(CINCLUDE) $(CLIB)
But it doesn't help either. How can I possibly fix the issue? Really thanks in advance.
I'm trying to install Quantum ESPRESSO on my computer and have run into an issue when using the ./configure command in the unpacked directory.
$ ./configure
checking build system type... x86_64-apple-darwin21.2.0
checking ARCH... mac686
checking setting AR... ... ar
checking setting ARFLAGS... ... ruv
checking for gfortran... gfortran
checking whether the Fortran compiler works... no
configure: error: in `/Users/myname/winter/q-e-qe-6.8':
configure: error: Fortran compiler cannot create executables
See `config.log' for more details
I just updated to macOS Monterey and have GNU Fortran (Homebrew GCC 11.2.0_3) 11.2.0 installed.
When trying to debug this, I looked at the config.log file and looked at similar googled questions. They all point me to updating or reinstalling things, like gcc, which I subsequently did.
Does the problem have to do with this:
$ gcc --version
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 11.0.0 (clang-1100.0.33.12)
Target: x86_64-apple-darwin21.2.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
I can see that the version is 4.2.1, but I'm unaware of what Apple clang is. Is it a PATH issue?
I'd appreciate any help.
P.S. Please choose to be kind in responses.
Here is part of the config.log:
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (Homebrew GCC 11.2.0_3)
configure:2542: $? = 0
configure:2531: gfortran -V >&5
gfortran: error: unrecognized command-line option '-V'
gfortran: fatal error: no input files
compilation terminated.
configure:2542: $? = 1
configure:2531: gfortran -qversion >&5
gfortran: error: unrecognized command-line option '-qversion'; did you mean '--version'?
gfortran: fatal error: no input files
compilation terminated.
configure:2542: $? = 1
configure:2557: checking whether the Fortran compiler works
configure:2579: gfortran conftest.f >&5
clang: error: invalid version number in '-mmacosx-version-min=12.1'
configure:2583: $? = 1
configure:2621: result: no
configure: failed program was:
| program main
For reference:
$ gfortran --version
GNU Fortran (Homebrew GCC 11.2.0_3) 11.2.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.```
I had the same issue and I solved by doing the following:
Removing the old tools
($ sudo rm -rf /Library/Developer/CommandLineTools).
Installing xcode command line tools again
($ xcode-select --install).
It was retrieved from:
How to update Xcode from command line
I try to use gdb to debug code with coredump, but I met:
Missing separate debuginfo for /lib/libc.so.6
Try: zypper install -C "debuginfo(build-id)=c4b9060b36834391b7b73976d38302a7584ae40e"
Missing separate debuginfo for /lib/ld-linux.so.2
Try: zypper install -C "debuginfo(build-id)=39c1043d2fcf5b72a2199cfb765d020b1faeb863"
Missing separate debuginfo for
Try: zypper install -C "debuginfo(build-id)=753a47afb9757471dc4823893adf607eb014b82f"
Missing separate debuginfo for /lib/libc.so.6
Try: zypper install -C "debuginfo(build-id)=c4b9060b36834391b7b73976d38302a7584ae40e"
Missing separate debuginfo for /lib/ld-linux.so.2
Try: zypper install -C "debuginfo(build-id)=39c1043d2fcf5b72a2199cfb765d020b1faeb863"
Then I installed debuginfo for glibc and update glibc to latest version, I try gdb again, it still has one information:
Missing separate debuginfo for
Try: zypper install -C "debuginfo(build-id)=753a47afb9757471dc4823893adf607eb014b82f"
But it doesn't mention which part is missed.
My GDB version is:
-> gdb --version
GNU gdb (GDB) SUSE (7.3-41.1.2)
Copyright (C) 2011 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 "i586-suse-linux".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
OS is:
Linux OpenSUSE-12.1
Add these repositories to the Zypper repositories list:
sudo zypper ar -f -n "openSUSE-Debug" http://download.opensuse.org/debug/distribution/12.1/repo/oss/ repo-debug
sudo zypper ar -f -n "openSUSE-Update-Debug" http://download.opensuse.org/debug/update/12.1/ repo-debug-update
After this, refresh and upgrade repositories:
sudo zypper ref
sudo zypper dup
Then, if necessary (you may get a message suggesting run zypper ps) restart you computer and install debuginfo for gdb:
sudo zypper in glibc-debuginfo
Add these repos:
http://download.opensuse.org/debug/distribution/XX/repo/oss/
http://download.opensuse.org/debug/update/XX/
Where XX is number of your OpenSUSE version.
Make sure they are active:
zypper lr
Then
sudo zypper in glibc-debuginfo