Quote:
Originally Posted by MTK358
[execve(): EFAULT] What does that mean? My only guess is that it means that the "char *filename" argument points to non-allocated memory, is that right?
|
Yes, exactly.
Quote:
Originally Posted by MTK358
What is the ELF interpreter? I thought it was the kernel that read ELF files.
|
Yes, but all (non-static) ELF binaries require some linking at run time, done by an ELF dynamic linker or loader, also called the ELF interpreter. In Linux, this is usually
/lib/ld-linux.so.
The .interp section in ELF files names the (path to the) linker needed for that program. You can use
objdump -d -j .interp program to dump the contents of that section for any program. (It is just a zero-terminated string.)
Quote:
Originally Posted by MTK358
[execve(): EISDIR]
|
This happens when the linker points to a directory. For example, if /lib/ld-linux.so was a directory and not a file.
(If you decide to test that in real life, keep alternate boot media handy, or use busybox. There are only a few commands that will keep working..)
Quote:
Originally Posted by MTK358
[execve(): ENOTDIR]
|
This happens when you have a path where one of the parents is a file and not a directory. For example, if /lib was a file and not a directory.
Quote:
Originally Posted by MTK358
And finally, what error code is used if the interpreter specified in a shebang line doesn't exist or can't be executed for some reason?
|
ENOENT for the former, EACCES for the latter.
Script files with a shebang line are handled in a manner that reminds me of symlinks: the kernel inspects the shebang line (or more of the file, if binfmt_misc kernel module is used), and continues as if the first parameter (file name) specified in the execve() call had been the named interpreter instead. In that way, the error codes make sense: ENOENT, because later on the kernel finds that the file name specified does not exist, and EACCES because it cannot be executed.
