terrible process getter
this gets the information contained in /proc/pid/cmdline, which is what ps uses when it prints a filename.
When a process is loaded into memory for execution, the filename, environment, and argv are saved at the bottom new process's stack.
/proc gives you a read-only copy of the process's data, and a map that tells you where the stack is :).
Getting position of the stack from /proc/8342/maps
Found the hex range ffd02000-ffd23000, converted to decimal range 4291829760-4291964928
Grabbing the stack from /proc/8342/mem, from 4291829760 up to 4291964928
Got the stack, it's 135168 bytes long. Starting to read from the end
Skipping the last nine bytes since they're nulls
Got the interpreter, it's /usr/bin/tail. Moving onto the environment
Getting the length of the environment of pid 8342 by checking /proc/8342/environ
Environment is 2955 bytes long
Getting the invocation by going backwards until two nulls happen in a row
The invocation is 35 bytes long. Replacing nulls with spaces
Some files don't have stack entries, but only have thread stack entries. Need to investigate that more
The kernel source specifies the offset from the bottom of the stack to essentially be (the bottom - sizeof(void*)). I don't know why they subtract the space for the pointer. Maybe it's used in a special marking way somewhere else?
It would be neat to parse /proc/kcore somehow (get the offsets? is it possible?)
I don't believe this works for a.out files, need to verify/check the kernel source
I should be ptrace-attaching before reading /mem