Different types of object files

Question

The e_type in the ELF document lists the following available object file types:

Name       Value     Meaning
ET_NONE    0         No file type
ET_REL     1         Relocatable file
ET_EXEC    2         Executable file
ET_DYN     3         Shared object file
ET_CORE    4         Core file
ET_LOPROC  0xff00    Processor-specific
ET_HIPROC  0xffff    Processor-specific

Where can I learn more about what each of these file types are? For example, I've never heard of a "Processor-specific" file: what would be an example of that?

---

And in doing $ xxd -l 32 /bin/ls , the object type is ET_DYN:

00000000: 7f45 4c46 0201 0100 0000 0000 0000 0000  .ELF............
00000010: 0300 <-- object type = 3 or "shared object file"

Why is ls not considered an executable, but a Shared object? (editor's note: this part is a duplicate of Why does GCC create a shared object instead of an executable binary according to file? Also, readelf -h /bin/ls is an easier way to decode the ELF header, including the ELF type)

---

And finally, what is a core file? Is this like a stacktrace? http://man.netbsd.org/core.5 , Get the address that caused segmentation fault from core dump using C .

(Editor's note: this part is a duplicate of What is a core dump file in Linux? What information does it provide? . Unfortunately this is 3 questions in 1 post so can't easily be marked as duplicates while answering the non-duplicate part)

Answer 1

There's two parts to your question:

Processor-specific types

These are left as "extension points" if a future CPU family wanted to define a new type of file. None of the main processor families ever used something from that range, so there's no example I can come up with even with a bit of searching.

ls is ET_DYN

The ET_DYN constant just means that the object is runtime-relocatable. Classically, this has been used for Shared Objects ( .so ), but for Position-Independent Executables (PIE) in glibc, they reused the same compiler and loader code as the shared objects to do the runtime-relocation, leading to this confusing situation where executables are reported as shared objects.