-1

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)

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
David542
  • 104,438
  • 178
  • 489
  • 842
  • 3
    A simplified view: `ET_REL` => Object files `ET_EXEC` => non PIE executables (fixed loading base), `ET_DYN` => shared libraries and PIE execs, `ET_CORE` => core dump?, `ET_LOPROC`-`ET_HIPROC` => defined by the ELF supplument of a specific processor (AFAIK, x86, ARM, powerPc, IBM zseries and PA-RISC define no specific types, so far). – Margaret Bloom Sep 14 '20 at 07:23
  • 1
    The part about `ls` is a duplicate of [Why does GCC create a shared object instead of an executable binary according to file?](https://stackoverflow.com/q/34519521). The part about why `ls` is ET_DYN already exists as a separate question. – Peter Cordes Sep 14 '20 at 10:40
  • @MargaretBloom I see so doing `as file.s` would create an `ET_REL` file (object file), and then doing `ld file.o` would create the `ET_EXEC` (executable). Is that more or less correct? – David542 Sep 16 '20 at 19:27

1 Answers1

4

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.

Diego Elio Pettenò
  • 3,152
  • 12
  • 15
  • 2
    It would be more accurate to describe the history of PIE as ET_DYN as: historically, ld.so supported executing a shared object with an entry point. This existing quirk of functionality was what PIE executables were built on top of, instead of requiring whole new functionality that would be backwards compatible, as a way to get ASLR for executables. – Peter Cordes Sep 14 '20 at 09:59
  • 1
    (see [32-bit absolute addresses no longer allowed in x86-64 Linux?](https://stackoverflow.com/q/43367427) and for more about PIE on x86-64. Also [What's the difference between "statically linked" and "not a dynamic executable" from Linux ldd?](https://stackoverflow.com/q/61553723) for "static PIE". [What is the -fPIE option for position-independent executables in gcc and ld?](https://stackoverflow.com/q/2463150) for some general basics on PIEs. – Peter Cordes Sep 14 '20 at 10:38
  • @PeterCordes yep I was (over)simplifying for the sake of giving an answer to the single question. But point taken. – Diego Elio Pettenò Sep 14 '20 at 11:39