4 ms·
The structure may be "horrible" but why so you say it's unreliable? It's part of the kernel/user space contract. The same information is also exposed via the /
by ithkuil 3y ago
The structure may be "horrible" but why so you say it's unreliable? It's part of the kernel/user space contract.
The same information is also exposed via the /proc FS FWIW
- amluto 3y agoI’m saying you can’t reliably get the information from syscalls. The runtime (i.e. whatever implements the actual entry point declared in the ELF headers) can get it reliably, as can any other code to which the runtime gives an appropriate pointer. You can’t assume that /proc is procfs if you’re writing a low level runtime library.
- ithkuil 3y agois your concern that some code in the process has clobbered the data that lives before the top of the stack?
- amluto 3y agoIf you can find the top of the stack, you can read the contents with reasonable reliability. But the top of the stack is not at a fixed address, and if you are writing low enough level code (container manager, init, etc), poking around in /proc at startup is not a great idea. If you’re wiring a real runtime library, none of this matters: the kernel passes a pointer in a register at startup.
- ithkuil 3y agoDo whatever libc's getauxval does to find the aux vector. Then env array is just below it, and the argv is below that iirc. EDIT: I agree it's ugly, I'm just not sure if is fair to call it brittle
- amluto 3y agoThe “whatever” is that glibc is the implementation of the ELF entry point. It remembers where the data structure is.