How can I get information about a binary file that won't execute?

Question

When I run one of my user's applications named "myfile".

$ ./myfile

I receive the following output

bash: ./myfile: cannot execute binary file

My user expects the binary file to run. I assume this is a compilation error but am unable to confirm it. I ran the file command

$ file myfile
myfile: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped

My RHEL6 OS is 64-bit

$ uname -p -o
x86_64 GNU/Linux

So it looks to me like it was complied for the right architecture. I don't understand what "relocatable" means in the file command's output and was not able to get an explanation form the man pages.

For good measure I checked for Shared Library Dependencies

$ ldd myfile 
not a dynamic executable

Is there any way I can get this file to run or give my user some constructive information about why it won't run (such as he needs to recompile using x)?

Strace

$ strace ./myfile
execve("./myfile", ["./myfile"], [/* 22 vars */]) = -1 ENOEXEC (Exec format error)
dup(2)                                  = 3
fcntl(3, F_GETFL)                       = 0x8002 (flags O_RDWR|O_LARGEFILE)
fstat(3, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f7a9fc93000
lseek(3, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal seek)
write(3, "strace: exec: Exec format error\n", 32strace: exec: Exec format error
) = 32
close(3)                                = 0
munmap(0x7f7a9fc93000, 4096)            = 0
exit_group(1)                           = ?

readelf output

readelf -S ./myfile    There are 13 section headers, starting at offset 0x1e8:

Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [ 0]                   NULL             0000000000000000  00000000
       0000000000000000  0000000000000000           0     0     0
  [ 1] .text             PROGBITS         0000000000000000  00000040
       0000000000000098  0000000000000000  AX       0     0     4
  [ 2] .rela.text        RELA             0000000000000000  000006e0
       0000000000000120  0000000000000018          11     1     8
  [ 3] .data             PROGBITS         0000000000000000  000000d8
       0000000000000010  0000000000000000  WA       0     0     4
  [ 4] .bss              NOBITS           0000000000000000  000000e8
       0000000000000000  0000000000000000  WA       0     0     4
  [ 5] .rodata           PROGBITS         0000000000000000  000000e8
       0000000000000033  0000000000000000   A       0     0     1
  [ 6] .comment          PROGBITS         0000000000000000  0000011b
       000000000000002d  0000000000000001  MS       0     0     1
  [ 7] .note.GNU-stack   PROGBITS         0000000000000000  00000148
       0000000000000000  0000000000000000           0     0     1
  [ 8] .eh_frame         PROGBITS         0000000000000000  00000148
       0000000000000038  0000000000000000   A       0     0     8
  [ 9] .rela.eh_frame    RELA             0000000000000000  00000800
       0000000000000018  0000000000000018          11     8     8
  [10] .shstrtab         STRTAB           0000000000000000  00000180
       0000000000000061  0000000000000000           0     0     1
  [11] .symtab           SYMTAB           0000000000000000  00000528
       0000000000000180  0000000000000018          12     9     8
  [12] .strtab           STRTAB           0000000000000000  000006a8
       0000000000000037  0000000000000000           0     0     1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

Solution

It sounds like relocatable has to do with an object file that is not an executable.

Executables should look like this

ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=a8ff57737fe60fba639d91d603253f4cdc6eb9f7, stripped

Object files look like this

# file /usr/lib/x86_64-linux-gnu/crtn.o
/usr/lib/x86_64-linux-gnu/crtn.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped

If needed, you can also get more information this way

# objdump -x myfile

Or disassemble

# objdump -d myfile

List symbols from a object file (not stripped)

# nm /usr/lib/x86_64-linux-gnu/gcrt1.o
                 U atexit
0000000000000000 b called.4237
0000000000000000 D __data_start
0000000000000000 W data_start
                 U etext
0000000000000030 T __gmon_start__
0000000000000000 R _IO_stdin_used
                 U __libc_csu_fini
                 U __libc_csu_init
                 U __libc_start_main
                 U main
                 U _mcleanup
                 U __monstartup
0000000000000000 T _start

Trying to list symbols from executable (stripped)

# nm /bin/bash
nm: /bin/bash: no symbols

Comments

[Eric]

@JamesSneeringer Thanks I added the Strace output.

[Matthew Ife]

It looks to be missing its interpreter. What happens if you run it like /lib64/ld-linux-x86-64.so.2 ./executable?

[Eric]

@MatthewIfe The file isn't a shared library executable. The resulting error of the command you suggested is "only ET_DYN and ET_EXEC can be loaded" This provides further evidence that this file is not an executable file.

[Matthew Ife]

Please provide the output of readelf -S ./executable

[Eric]

@MatthewIfe I added the readelf output

[Michael Hampton]

Are you trying to work with myfile or myFile? These are different.

[Eric]

updated casing in question to be consistently myfile

[James Sneeringer]

You're running ./myfile but the error says ./strcmp. Are there two separate files?

[Eric]

Am I jumping to conclusions by saying anytime relocatable is in the file output the file is an Object file and not an executable file?

[Ryan Babchishin]

Maybe :). I'm going by what people on google say and by what files on my system report.

[James Sneeringer]

Relevant Ubuntu forums thread. I agree with Ryan, myfile appears to be an object file and not an executable, and just lacks the usual .o extension. Your user may simply have inadvertently compiled their program as an object (e.g. using -c with gcc when they shouldn't have).