I'm looking to debug the malloc and free routines used by libc. In order to do that I installed the following packages.
sudo apt-get install libc6-dbg
sudo apt-get install libc6:i386
sudo apt-get install libc6-dbg:i386
I'm on a 64-bit Ubuntu 15.04 machine and I'm debugging a i386 binary. I see the post here that seems to deal with a similar problem.
Inside gdb I check the location from which debug files are loaded and get this.
(gdb) show debug-file-directory
The directory where separate debug symbols are searched for is "/usr/lib/debug".
However, there is no indication that the debug symbols are being loaded. How could I fix this?
[EDIT]
I've tried this with both amd64 and i386 binaries and the results are the same. The binaries I'm debugging themselves do not have debugging symbols installed in them.
However, there is no indication ...
What indication are you looking for?
I am guessing that you did something like:
gdb ./a.out
(gdb) list malloc # complains about "no symbols loaded"
Do this instead:
gdb ./a.out
(gdb) start
# breakpoint 1 hit
(gdb) list __libc_malloc
Explanation: libc.so.6 and its debug symbols are not loaded (and therefore not visible) until the program actually starts.
Related
I eventually want to use valgrind to find what is causing the occasional bizarre output in a C program which refines a model against experimental data using OpenMP parallel programming.
To avoid the use of the nominal gcc (ie clang) compiler, I used brew to install gcc-4.9 on my MacPro running Yosemite (OS x 10.10.5). However, when trying to compile my program with gcc-4.9, with or without -fopenmp, I get numerous error messages of the type:
/var/folders/qc/1j0gr_l48xnfd9001s6tt6f80000gn/T//ccRxnrnU.s:30597:suffix
or operands invalid for `movq'
I have no idea what the problem triggering these error messages is. Can anyone help?
The following summarises what was worked out in the comments section and did lead to the issue being resolved. Not all steps may be necessary, but most are probably good practice.
Step 1 - Clean up
If you have been trying lots of different, potentially incompatible, methods to get OpenMP set up, it is probably a good idea to clean them up first. So, something like:
brew rm --force gcc # or maybe gcc#4.9
Step 2 - Update Xcode and Command Line Tools
If you have upgraded macOS since installing Xcode, it is probably advisable to update Xcode and its "Command Line Tools"
Consider uninstalling and re-installing Xcode - it is available for free from the App Store.
Update/install the "Command Line Tools" after installing/updating with:
xcode-select --install
Step 3 - Install gcc
Now, try installing gcc afresh, ensuring that you use the --without-multilib option:
brew install gcc#4.9 --without-multilib
Hopefully you can now compile OpenMP code with:
/usr/local/bin/gcc -fopenmp program.c -o program
I am unsure exactly why the --without-multilib option is needed and prefer to quote #hristo-iliev:
Multilib usually refers to the coexistence of both 64-bit and 32-bit
versions of each library so that 32-bit software could be run on
64-bit OS. In the GCC case that probably refers to having all GCC
runtime libraries in "fat" Mach-O format, i.e. versions for both i386
and x86_64 in the same shared library file. It could be that libgomp
(the GNU OpenMP runtime library) cannot be built in such a way.
See this question.
Keywords: gcc, g++, GNU Compiler, OpenMP, fopenmp, -fopenmp, Xcode, multilib, Command Line Tools, macOS, OSX, homebrew, brew
When I try to execute a 32-bit file compiled with gcc -m32 main.c -o main on Windows Subsystem for Linux, I get the following error: bash: ./main: cannot execute binary file: Exec format error.
If I compile it without -m32 it runs.
Any solution for running 32-bit executable on WSL?
QEMU and binfmt support light the way :)
https://github.com/microsoft/wsl/issues/2468#issuecomment-374904520
After reading that the WSLInterop between WSL and Windows processes used binfmt, I was tinkering with QEMU to try some ARM development, and incidentally discovered how to get 32-bit support working.
Edit: requires "Fall Creators Update", 1709, build 16299 or newer
Install qemu and binfmt config:
sudo apt install qemu-user-static
sudo update-binfmts --install i386 /usr/bin/qemu-i386-static --magic '\x7fELF\x01\x01\x01\x03\x00\x00\x00\x00\x00\x00\x00\x00\x03\x00\x03\x00\x01\x00\x00\x00' --mask '\xff\xff\xff\xff\xff\xff\xff\xfc\xff\xff\xff\xff\xff\xff\xff\xff\xf8\xff\xff\xff\xff\xff\xff\xff'
You'll need to reactivate binfmt support every time you start WSL:
sudo service binfmt-support start
Enable i386 architecture packages:
sudo dpkg --add-architecture i386
sudo apt update
sudo apt install gcc:i386
Try it out:
$ file /usr/bin/gcc-5
/usr/bin/gcc-5: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=2637bb7cb85f8f12b40f03cd015d404930c3c790, stripped
$ /usr/bin/gcc-5 --version
gcc-5 (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
Copyright (C) 2015 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.
$ gcc helloworld.c -o helloworld
$ ./helloworld
Hello, world!
$ file helloworld
helloworld: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=3a0c7be5c6a8d45613e4ef2b7b3474df6224a5da, not stripped
And to prove it really was working, disable i386 support and try again:
$ sudo service binfmt-support stop
* Disabling additional executable binary formats binfmt-support [ OK ]
$ ./helloworld
-bash: ./helloworld: cannot execute binary file: Exec format error
32-bit ELF support isn't provided by WSL (yet). There doesn't seem to be any progress since the UserVoice was raised - you are out luck.
See UserVoice: Please add 32 bit ELF support to the kernel and Support for 32-bit i386 ELF binaries.
If possible, switch to a real Linux ;-)
Since this was originally posted, the support has been available on WSL2 which does support real Linux kernel! So that should be the preferred way.
As noted in the linked github issue, there's also qemu-user which can be used if WSL1 is still used.
WSL2 runs in a real virtual machine using a real Linux kernel, therefore it's actually possible to do anything a Linux VM can do, including running 32-bit code. Just install 32-bit libs by running
sudo dpkg --add-architecture i386
sudo apt-get update
For more information read
Announcing WSL 2
WSL 2 FAQ
I've both libc6 and libc6-dbg packages installed. What I want to do is to display the disassembly of ld.so with source interleaved. I also have the glibc source placed in a chroot, reachable at the exact location as displayed by DW_AT_comp_dir in debug symbols.
Could someone tell me--if it's possible--how to output the source-interleaved disassembly of ld.so library please? I know I could use objdump -S, but how would I point it to the separate debug symbol file available?
The best match I could find was to use GDB:
gdb /the/original/library
Use add-symbol-file command to locate the add the symbol file that was installed as part of -dbg package (use dpkg -L the-package-name-dbg to find all files installed as part of the package). This command would also need an address to load the symbols from. This address can be found out from readelf -a /the/original/library, and is most likely the load address of the text segment
Install package source with apt-get source the-package-name. This will download the source in the current working directory
Use dir command in GDB to locate the source downloaded above
Now use disas/m function_name so that GDB will display a the disassembly, ordered by source lines
I have been working with some Cortex-M4 (Freescale K60) devices with a compiled by me GCC (v4.7.2), BinUtils (v2.22), Newlib (v1.20) and GDB (v7.5). I have always been annoyed by GDB's inability to unwind from hard exceptions.
recently I had an opportunity to use FreeScale's CodeWarrior, where I loaded my binary for debug (compiled by my tools), and it could unwind the exception. It looks like CodeWarrior is running GDB v7.4.1 under the hood. Is there some patch I missed for GDB, or some configure option?
Here is the script used to build GDB:
TOOLCHAIN=gdb-7.5
mkdir -p BUILD/gdb
cd BUILD/gdb
../../${TOOLCHAIN}/configure --prefix=${PREFIX} --target=${TARGET} --enable-interwork --enable-multilib --with-expat=yes --with-python --without-auto-load-safe-path 2>&1 | tee configure.out
make all install
cd ../../
Thanks!
GDB can do Cortex M profile exception unwinding, once you tell it that the target is actually Cortex M profile using a Target Description XML with correct Feature.
This can be done via the set target tdesc <filename> command, but newer gdb servers (e.g. OpenOCD) should do so already.
I have been trying to install GDB on my new Macbook Pro running Mountain Lion. I have installed using both Macports and Brew, I have successfully code signed the binaries, but in both cases when I try to debug a simple "Hello World" application I receive a whole load of warnings similar to:
warning: `/Users/gkhanna/build/x86_64-apple-darwin13.0.0/libgfortran/.libs/_abs_c10.o': can't open to read symbols: No such file or directory.
warning: `/Users/gkhanna/build/x86_64-apple-darwin13.0.0/libgfortran/.libs/_abs_c16.o': can't open to read symbols: No such file or directory.
warning: `/Users/gkhanna/build/x86_64-apple-darwin13.0.0/libgfortran/.libs/_abs_c4.o': can't open to read symbols: No such file or directory.
warning: `/Users/gkhanna/build/x86_64-apple-darwin13.0.0/libgfortran/.libs/_abs_c8.o': can't open to read symbols: No such file or directory.
Now, my username is not gkhanna and there are no users registered on the laptop by that name. The versions of gdb I have installed are 7.6.0 and 7.6.1. Could anybody explain what has happened here and how to point GDB to the correct path?
To quiet the warnings, you can strip the debugging symbols that can't be read (since they point to files not on your machine and really shouldn't have been left in there in the first place.)
First, figure out which libgfortran dylib your gcc is using with otool -L a.out, then strip the debug symbols from that libgfortran dylib with strip -x path_to_libgfortran_dylib.