this post was submitted on 28 May 2025
733 points (96.3% liked)
Programmer Humor
27048 readers
691 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.sois 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.6contains a proper entry address, while other libraries are pointing at0x0and coredump when executed.libc.sois 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:
_startis 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.sois a symlink told-linux-x86-64.so.2at least on my system. It is an statically linked executable. Theld.sois, 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.soEdit: My understanding of this quite shallow; the above is a segment that in this case contains the entirety of the
.textsection.