4 ms·

What distinction are you making? Do you think it should be part of the kernel? I ask because ld.so (the runtime linker/loader) is part of the OS on many systems

by dap 3y ago

What distinction are you making? Do you think it should be part of the kernel? I ask because ld.so (the runtime linker/loader) is part of the OS on many systems.

userbinator 3y ago
I mean not explicitly hardcoding the path to the interpreter inside every binary. If the dynamic linker is part of the OS, then surely the OS should already know where it is?
- throwawaylinux 3y ago
  How much do you actually know about this? Have you read the ELF spec or written anything with libelf, hacked on a loader, a linker? Considered the actual problems with having this hard coded vs alternatives? I ask because ELF and unix dynamic linking is a pretty well thought out set of specifications and processes and it's a huge body of work. It can certainly be criticized, but calling it an afterthought because of .interp doesn't seem very charitable, just trying to understand if that's an informed opinion and if so it would be interesting to hear more.
- duped 3y ago
  > If the dynamic linker is part of the OS, then surely the OS should already know where it is? It's both part of the OS and the language's compiler tool chain the program was written in. For the vast majority of Linux executables that's glibc and the ld-linux.so that glibc ships. And you don't need to hard code the path inside your executable. Static PIE objects for example are dynamic elf objects without an interpreter header. The system loader is capable of launching them just fine.
- dap 3y ago
  I’m still not sure what principle you’ve got that’s being violated here? Given that one has chosen to implement part of the runtime linker/loader in userland, what’s wrong with fitting that into a more generic facility (supporting interpreters at arbitrary paths) and putting this specific implementation into a committed path?

4 ms·

What distinction are you making? Do you think it should be part of the kernel? I ask because ld.so (the runtime linker/loader) is part of the OS on many systems

by dap 3y ago

What distinction are you making? Do you think it should be part of the kernel? I ask because ld.so (the runtime linker/loader) is part of the OS on many systems.

userbinator 3y ago
I mean not explicitly hardcoding the path to the interpreter inside every binary. If the dynamic linker is part of the OS, then surely the OS should already know where it is?
- throwawaylinux 3y ago
  How much do you actually know about this? Have you read the ELF spec or written anything with libelf, hacked on a loader, a linker? Considered the actual problems with having this hard coded vs alternatives? I ask because ELF and unix dynamic linking is a pretty well thought out set of specifications and processes and it's a huge body of work. It can certainly be criticized, but calling it an afterthought because of .interp doesn't seem very charitable, just trying to understand if that's an informed opinion and if so it would be interesting to hear more.
- duped 3y ago
  > If the dynamic linker is part of the OS, then surely the OS should already know where it is? It's both part of the OS and the language's compiler tool chain the program was written in. For the vast majority of Linux executables that's glibc and the ld-linux.so that glibc ships. And you don't need to hard code the path inside your executable. Static PIE objects for example are dynamic elf objects without an interpreter header. The system loader is capable of launching them just fine.
- dap 3y ago
  I’m still not sure what principle you’ve got that’s being violated here? Given that one has chosen to implement part of the runtime linker/loader in userland, what’s wrong with fitting that into a more generic facility (supporting interpreters at arbitrary paths) and putting this specific implementation into a committed path?