gdb fails to run ELF 64-bit program with "File format not recognized"

29,082

Solution 1

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.

Solution 2

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.

Solution 3

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.

Solution 4

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

Solution 5

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.

Share:
29,082
pbh101
Author by

pbh101

Software developer at IMC Financial Markets. Primarily work in Java and Bash, with Python and C++ distant seconds.

Updated on July 09, 2022

Comments

  • pbh101
    pbh101 almost 2 years

    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?

  • pbh101
    pbh101 over 15 years
    thanks. i thought this might be the issue, and it turns out there is a 64-bit version of gdb installed in a more obscure path on the same machine.
  • pbh101
    pbh101 over 15 years
    This isn't my issue, but it is something I checked for. Thanks for the help. From what I can tell, you can run file on the executable to see if it's a binary.
  • frankster
    frankster about 10 years
    Thanks - I had this issue to after installing the debian gdb:i386 package and some others a few days ago in order to avoid creating a chroot to build an i386 version of a debian package.
  • Hady Elsahar
    Hady Elsahar almost 9 years
    @quinmars can you explain a bit more what u mean by Try to install the application and change the directory , i have just had the same problem, when checking the file type it was POSIX shell script
  • quinmars
    quinmars almost 9 years
    @HadyElsahar With install I meant make install. But an installation ist actually not needed. Follow the explanation here: sourceware.org/autobook/autobook/…
  • Hady Elsahar
    Hady Elsahar almost 9 years
    @quinmars , when executed libtool --mode=execute gdb th it still give the same error . i have moved the question to another thread here stackoverflow.com/questions/30663780/…
  • rightaway717
    rightaway717 almost 9 years
    That was a pretty same thing for me when I couldn't debug an android app from QtCreator. 32bit gdbserver was used while I had 64 bit android device