this post was submitted on 28 May 2025
731 points (96.3% liked)
Programmer Humor
24389 readers
972 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
How does that work? There must be something above
ld.so
, maybe the OS? Because looking at the ELF header,ld.so
is a shared library "Type: DYN (Shared object file)"The program headers don't have interpreter information either. Compare that to
ls
"Type: EXEC (Executable file)".It feels like somewhere in the flow there is the same thing that's happening in python just more hidden. Python seems to expose it because a file can be a library and an executable at the same time.
Anti Commercial-AI license
~~Your ld.so contains:~~
EDIT: ...with which I meant, modulo brainfart: My
libc.so.6
contains a proper entry address, while other libraries are pointing at0x0
and coredump when executed.libc.so
is a linker script, presumably because GNU compulsively overcomplicates everything....I guess that's enough for the kernel. It might be a linux-only thing, maybe even unintended and well linux doesn't break userspace.
Speaking of, I was playing it a bit fast and loose:
_start
is merely the default symbol name for the entry label, I'm sure nasm and/or ld have ways to set it to something different.Btw,
ld.so
is a symlink told-linux-x86-64.so.2
at least on my system. It is an statically linked executable. Theld.so
is, in simpler words, an interpreter for the ELF format and you can run it:Which seems to be contained in the only executable ~~section~~ segment of
ld.so
Edit: My understanding of this quite shallow; the above is a segment that in this case contains the entirety of the
.text
section.