6

Alright, as far as I know ET_EXEC is used to indicate that the file is an executable whereas ET_DYN indicates that the file is a shared library. So to be sure I wrote a simple program in C, the problem however is that readelf -h is yielding the following:

ELF Header:
Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
Class:                             ELF64
Data:                              2's complement, little endian
Version:                           1 (current)
OS/ABI:                            UNIX - System V
ABI Version:                       0
Type:                              DYN (Shared object file)
  .
  .
  .

I thought this had something to do with the compiler I used so I did the same with some utilities in /bin but unfortunately got the same results. So here's the question: Why is readelf identifying executables as shared libraries?

Employed Russian
  • 199,314
  • 34
  • 295
  • 362
Trey
  • 474
  • 2
  • 9
  • 32
  • 1
    Use `-static` to generate an `ET_EXEC`, by default GCC generates shared objects so they can be relocated. This entangles with PIE, x86_64 and, a bit, ASRL. – Margaret Bloom May 12 '18 at 07:40
  • 1
    @MargaretBloom: even `gcc -no-pie` makes an ELF executable rather than shared object, because ASLR for executables is sort of a hack using existing capabilities of the dynamic linker to deal with shared objects that have an ELF entry point. – Peter Cordes May 13 '18 at 01:39

1 Answers1

5

Why is readelf identifying executables as shared libraries?

Because it is (a special kind of) shared library. See also this answer.

Employed Russian
  • 199,314
  • 34
  • 295
  • 362
  • 1
    I also wrote an answer with some details about PIE executables, at [32-bit absolute addresses no longer allowed in x86-64 Linux?](https://stackoverflow.com/q/43367427), but I did mention that `file a.out` shows "executable" for `gcc -no-pie` but "shared object" for PIE executables, because that's what they are. – Peter Cordes May 13 '18 at 01:40