I'm trying to use GDB to debug (to find an annoying segfault). When I run:
gdb ./filename
from the command line, I get the following error:
This GDB was configured as "i686-pc-linux-
gnu"..."/path/exec": not in executable
format: File format not recognized
When I execute:
file /path/executable/
I get the following info:
ELF 64-bit LSB executable, AMD x86-64,
version 1 (SYSV), for GNU/Linux 2.4.0,
dynamically linked (uses shared libs), not stripped
I am using GDB 6.1, and the executable is compiled with gcc version 3.4.6.
I'm a little out of my water in terms of using gdb, but as far as I can tell it should be working in this instance. Any ideas what's going wrong?
The executable is 64-bit (x86-64) and the debugger is a 32 bit (i686-pc-linux) build. You may need to install a 64-bit (x86-64) version of the debugger.
I'm not sure if this is your problem, but I faced this situation very often. The executable in the build tree, build by make/automake is not a binary, but a script, so you cannot use gdb with it. Try to install the application and change the directory, because else gdb tries to debug the script.
The question refers to "./filename" and to "/path/executable". Are these the same file?
If you are doing a post-mortem analysis, you would run:
gdb executable-file core-file
If you are going to ignore the core file, you would run:
gdb executable-file
In both cases, 'executable-file' means a pathname to the binary you want to debug. Most usually, that is actually a simple filename in the current directory, since you have the source code from your debug build there.
On Solaris, a 64-bit build of GDB is supposed to be able to debug both 32-bit and 64-bit executables (though I've had some issues with recent versions of GDB). I'm not sure of the converse - that a 32-bit GDB can necessarily debug 64-bit executables.
What you need to be checking, is really the bfd library. The binary file descriptor library is what binutils / gdb uses to actually parse and handle binaries (ELF/a.out etc..).
You can see the current supported platforms via objdump;
# objdump -H
objdump: supported targets: elf32-powerpc aixcoff-rs6000 elf32-powerpcle ppcboot elf64-powerpc elf64-powerpcle elf64-little elf64-big elf32-little elf32-big srec symbolsrec tekhex binary ihex
objdump: supported architectures: rs6000:6000 rs6000:rs1 rs6000:rsc rs6000:rs2 powerpc:common powerpc:common64 powerpc:603 powerpc:EC603e powerpc:604 powerpc:403 powerpc:601 powerpc:620 powerpc:630 powerpc:a35 powerpc:rs64ii powerpc:rs64iii powerpc:7400 powerpc:e500 powerpc:MPC8XX powerpc:750
The following PPC specific disassembler options are supported for use with
the -M switch:
booke|booke32|booke64 Disassemble the BookE instructions
e300 Disassemble the e300 instructions
e500|e500x2 Disassemble the e500 instructions
efs Disassemble the EFS instructions
power4 Disassemble the Power4 instructions
power5 Disassemble the Power5 instructions
power6 Disassemble the Power6 instructions
32 Do not disassemble 64-bit instructions
64 Allow disassembly of 64-bit instructions
It seems your GNU Debugger (gdb) doesn't support x86_64 architecture.
So try LLDB Debugger (lldb) which aims to replace it. It supports i386, x86-64 and ARM instruction sets.
It's available by default on BSD/OS X, on Linux install via: sudo apt-get install lldb (or use yum).
See: gdb to lldb command map page for more info.
Related
I have installed Debian on qemu 64-bit ARM (followed this tutorial)
uname -a
Linux test 4.9.0-7-arm64 #1 SMP Debian 4.9.110-1 (2018-07-05) aarch64 GNU/Linux
and I am trying to run 32 bit elf files on it, but some work some don't:
bash: ./file_2: cannot execute binary file: Exec format error
running file command on the file that runs, I get:
file_1: ELF 32-bit LSB executable, ARM, EABI4 version 1 (SYSV), statically linked, not stripped
and the one that does not run:
file_2: ELF 32-bit LSB executable, ARM, version 1 (ARM), statically
linked, stripped
and both work on 32bit system(armv7l)
the only difference is that SYSV/ARM version.
is there any work around without recompiling the kernel?(read this post)
As the linked post suggests, this requires CONFIG_COMPAT to be enabled in the kernel. On the other hand I would be surprised if your kernel didn't have it -- the Debian 4.9.0-4 kernel I have from doing that tutorial does set CONFIG_COMPAT. You can check whether your kernel has it enabled by looking at the config file for it which will be in /boot/ in the guest. If it's missing then you need a new kernel, and nothing else will help.
However in your case you do have CONFIG_COMPAT, and some executables work. The difference between the ones that work and the ones that don't is that the working ones are EABI, and the non-working ones are OABI. OABI is an old and obsolete ABI for 32-bit Arm Linux binaries (the "O" stands for "old", and it's been a bad choice for a decade or so...) and it is not supported by the 64-bit kernel's CONFIG_COMPAT. You'll need to rebuild those binaries from source as EABI binaries if you want to run them under a 64-bit kernel.
I've installed BuildRoot, to set a SoftetherVPN.
Well, my problem is that I necessary need to install GCC, in a 32-bit ARM Architecture, (obviously I've downloaded the 32 bit version).
I looked all over the internet, because of many problems:
My first idea was to install GCC using command sudo apt-get or sudo yum, but I can only find it in Debian Linux (Buildroot kernel, and its toolchain are very reduced).
At this point I tried to cross-compiling GCC but with no results, because it produced in shell output Library errors. And I also tried to paste those missing libraries yet achieve very little.
You could download some GCC cross-compiler. For example, if your PC is running some Debian-like Linux distribution -perhaps Ubuntu- you might install some gcc-7-arm-linux-gnueabi or similar (gcc-7-arm-linux-gnueabihf ...) package.
The SDK for your board is likely to provide some cross-GCC & cross-binutils.
You could build some cross binutils then some GCC cross-compiler from their source code (this is a bit more tricky).
Your cross-compiler would compile (for ARM) on your Linux-running PC, not on your ARM circuit board.
I try to debug some native code on Android with GBD. The code wasn't created by me and is not in an Android project, so I can't use the ndk-gdb tool. I use gdbserver on the android machine and connect to it from my mac with the normal GDB program. I try to load all the libraries (which should have symbols according to objdump tool), but gdb tells me that it does not load the symbols (according to the gdb command “info sharedLibrary”). These are the steps I took:
start gdbserver on Android machine
start GDB with the debug version of the binary
gdb symbols/system/bin/mediaserver
the following commands are executed in gdb itself
tell gdb where to look for the libraries with symbols
(gdb) set solib-search-path symbols/system/lib
tell gdb where to find the source files
(gdb) directory /sources
connect to remote target (Android machine)
(gdb) target remote 192.168.1.10:5039
GDB connects successfully to the running binary and I can pause and continue the execution. But it does not show me any debug information like function names or line numbers. It only shows adresses. When I check the status of the used libraries, I see that gdb thinks, they don’t have any symbols:
command in gdb:
(gdb) info sharedLibrary
From To Syms Read Shared Object Library
0x00003700 0x0000ff0c Yes /symbols/system/bin/linker
No libc.so
No libstdc++.so
No libm.so
No liblog.so
No libcutils.so
No libspeexresampler.so
No libaudioutils.so
No libgccdemangle.so
No libamplayer.so
Now for example the last library. When I check with the file command (not in gdb), it tells me that it is a not stripped library (the library is located in the "symbols/system/lib" folder).
file libamplayer.so
Output:
libamplayer.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked, not stripped
objdump command shows a lot of symbols in it (I don’t show the output because it’s very long). So why does gdb not recognise the symbols in this libraries? I thought, at least line numbers and function names are present in not stripped versions of libraries. Or am I wrong? It would be very nice if someone could give me more insight.
Thanks!
System info:
GDB Version: 7.3.1-gg2 on Mac OS X Mavericks
The code wasn't created by me and is not in an Android project, so I can't use the ndk-gdb tool.
Your conclusion does not at all follow. ndk-gdb should be able to debug any Android program, whether created as a "project" or via other means.
I use gdbserver on the android machine and connect to it from my mac with the normal GDB program.
The normal GDB is likely not configured for cross-debugging, and thus doesn't understand ARM binaries at all. I am surprised you get as far using it as you do.
I have two binary files generated via 'objcopy -O binary' from respective ELF files. The ELF files are built with arm-none-linux-gnueabi toolchains; one is from linaro gcc 4.6.2 and other is from codesourcery gcc 4.6.3.
I load the binary files into memory via Uboot. While the one built with Linaro executes as expected the one built with codesourcery crashes (most probably as) there is no error on Uboot prompt but the program seems to hang.
Using 'arm-none-linux-gnueabi-readelf -S' from binutils of respective toolchains does not show much difference between files except for address offsets. Are there any tools/techniques that can help in this kind of situation before I attempt runtime debugging on target.
Thanks!
The difference turned out to be compiler option -munaligned-access. Code Sourcery toolchain enables this by default for ARMv6 and later architectures.
http://gcc.gnu.org/gcc-4.7/changes.html
Although this appeared in upstream gcc in 4.7 version, Code Sourcery had added this support earlier in their tool chain.
To figure this out I tracked the data abort exception and then compiled the culprit file with -save-temps options. Comparing intermediate .s file provided the hint.
What I can advice you is to compare default flags both compilers were built with:
/path/to/cross-compiler/bin/arm-*-*-gcc -Q -v
And preprocessor definitions:
/path/to/cross-compiler/bin/arm-*-*-gcc -dM -E - < /dev/null
The reason why your code compiled using Linaro GCC works is fact, that
it may have some options enabled by default, when CodeSourcery one
may have not.
I have applications which successfully compile with the -m32 switch (in DMD and/or GCC) to produce:
appname: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked
(uses shared libs), for GNU/Linux 2.6.15, not stripped
The source packages I have created work fine, on both 32 bit and 64 bit Ubuntu to build the appropriate binary .debs.
I would like to produce the i386 .deb on the same 64 bit machine i use to produce the 64 bit .deb.
Is this possible, and where should I look for instructions?
The answer depends on the complexity of your build. When the normal 64 bit userland tools suffice for a build, simply specify the architecture via -a
debuild -ai386
However, there are often cases where this doesn't work, and in these cases you'll need pbuilder. pbuilder builds a clean Debian/Ubuntu system in a chroot-ed environment. man pbuilder is a good introduction. To get started, you'll need:
sudo pbuilder --create --architecture i386
sudo pbuilder --build mypackage.dsc
It starts with calling debuild with the -ai386 option, which will
change the architecture that the package is built for.
Of course you have to ensure that the package contains the i386 build of the application.
You don't do anything thing different from building a 64bit .deb. Except that you include a 32bit build of your application.
The control file specifies the architecture, so be sure you select the correct one.