Hi,
Oh you poor lad. If there's something you can't image, then that's impossible? Your way is the only way?
I feel sorry for you, so I try to explain this one last time. What ELFs are capable of, and what and how one particular dynamic linker for SysV ABI has implemented are two totally different things. Do not confuse those.
Korona wrote:
I never said dlopen() cannot load PE, I said it cannot load PE according to spec.
You refuse to see that you're stuck with one spec, the SysV ABI psABI-x86_64. That's not the only way to do things, MINGW developers have done it differently, they can load PE with dlopen() for example.
ELF != SysV ABI, but even with SysV ABI, you have several ways how to do things, and it doesn't matter as long as the interface you show towards the executables meets their expectations, the executable wouldn't know. As a matter of fact, according to the spec, dynamic linker must be TRANSPARENT ("Transferring control to the program,
making it look as if the program had received control directly from exec(BA_OS)."), meaning there's no required interface at all. An executable wouldn't call the dynamic linker directly ever. And if you dig deeper, you'll find that late-binding must be also transparent to the application. (And no, dlopen() doesn't count because it's entry point is in a shared library, and not in ld.so).
Korona wrote:
Indeed, glibc (that you're talking about when you post the ldd trace) implements dlopen() as a call to _dlfcn_hook->dlopen, where _dlfcn_hook is a vtable provdied by ld.so.
Can you use dlopen() without libdl.so on Linux? No. Can you implement dlopen() without _dlfcn_hook? Yes. Please note the "should", "must" and "how one particular implementation does" are different things.
Korona wrote:
Yes, the default linker script has a fixed base address. However, did you try changing it? If you change it, ld.so still works!
So does my dynamic linker. And? This does not prove that there are no alternatives to auxvector!
Korona wrote:
What AT_SECURE does is well-documented. I refer to the man page of glibc's ld.so.
Interesting, that man page does not say ELF auxvector must be placed on the stack. It only mentions that on Linux, secure-execution mode is queried with
getauxval, which in turn does not say nothing about stacks either, but it clearly states that "
This function is a nonstandard glibc extension.". The emphasis is on the word "nonstandard" here.
Korona wrote:
ELF is almost only about the SysV ABI. All other ABIs are variations of the SysV one (i.e. the SysV ABI has index zero for a reason). Which OS uses a fundamentally different ELF ABI?
One last time, ELF != SysV ABI. Think about GNUEFI. Their build system does not link PEs. Instead, they create an ELF with UEFI ABI, and they convert that into a PE as a last step. They can do that despite there's no ELF_OSABI_UEFIABI specified in the ELF spec. Yet it is possible, and GNUEFI works remarkably well.
Please think about what I've said. There are plenty of evidence that your way is not the only way. Try to accept that.
I'd like to encourage hobby OS developers not to follow the half-century old path. The whole reason for hobby OS developement is education and to go boldly where no OSdev has gone before.
Cheers,
bzt