execve() returns ENOENT when ld-linux.so isn't found
in [Kernel]
|
From: Olaf van der Spek on 25 Mar 2010 15:30 On Wed, Mar 24, 2010 at 11:45 PM, <drepper(a)gmail.com> wrote: > On Wed, Mar 24, 2010 at 15:37, Olaf van der Spek <olafvdspek(a)gmail.com> > wrote: >> >> Why not? >> It's an improvement IMO, although it could be better. > > It's blatantly wrong. There is no dynamic linker. ENOEXEC means the file > exists but is not of the right format. That sounds closer to the actual error than ENOENT. ENOENT: The file filename or a script or ELF interpreter does not exist, or a shared library needed for file or interpreter cannot be found. ENOEXEC: An executable is not in a recognized format, is for the wrong architecture, or has some other format error that means it cannot be executed. ENOENT shouldn't be overloaded like this, as it's common meaning is: file not found. So it shouldn't be returned if the argument to execve is actually found. Olaf -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Luca Barbieri on 25 Mar 2010 17:10 POSIX 2008 says, for exec*: [ENOENT] A component of path or file does not name an existing file or path or file is an empty string. [ENOEXEC] The new process image file has the appropriate access permission but has an unrecognized format. [EINVAL] The new process image file has appropriate privileges and has a recognized executable binary format, but the system does not support execution of a file with this format. None of these perfectly fit, but EINVAL seems the closest. Note that ENOENT only specifies that the error happens for "not found" problems in the function argument itself, so it is not really more correct than the others. Linux also defines ELIBACC (for a.out I believe): #define ELIBACC 79 /* Can not access a needed shared library */ This also seems a possible candidate. Not sure if it is safe to change this though, or what other systems do. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ulrich Drepper on 26 Mar 2010 08:00 On Thu, Mar 25, 2010 at 14:00, Luca Barbieri <luca.barbieri(a)gmail.com> wrote: > None of these perfectly fit, but EINVAL seems the closest. No. ENOENT is the right value. Once again, read my first message. The shell cannot just report the error anyway since there can be many different reasons for the problem. If the dynamic linker is missing it has to be discovered and then reported. In that message the correct error code is ENOENT. Don't try to change things which are as good as any other solution. The error message alone is in no case sufficient. Fix your shells. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Olaf van der Spek on 26 Mar 2010 14:50 On Fri, Mar 26, 2010 at 12:56 PM, Ulrich Drepper <drepper(a)gmail.com> wrote: > No. ENOENT is the right value. > > Once again, read my first message. The shell cannot just report the > error anyway since there can be many different reasons for the > problem. If the dynamic linker is missing it has to be discovered and > then reported. In that message the correct error code is ENOENT. > > Don't try to change things which are as good as any other solution. > The error message alone is in no case sufficient. Fix your shells. What about other apps that call execve? Sounds like a lot of code duplication is needed. Olaf -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Luca Barbieri on 26 Mar 2010 17:10 >> None of these perfectly fit, but EINVAL seems the closest. > > No. �ENOENT is the right value. Not according to POSIX 2008, which does not explicitly specify this case. Again, it says: [ENOENT] A component of <i>path</i> or <i>file</i> does not name an existing file or <i>path</i> or <i>file</i> is an empty string. Here "path" and "file" refer to the argument to the C function and "component" refers to the tokens obtained after splitting using "/" as a separator. POSIX 2008 doesn't talk at all about dependencies of the executables. POSIX 2008 mandates EINVAL if you interpret "executable format" as being "ELF executable with interpreter /lib/FOO" as opposed to just "ELF", or if you interpret "architecture" as including the ELF interpreter name in addition to the machine type. By the way, is there any way to do this in the shell other than including an ELF parser or assuming the ELF interpreter is missing if the kernel returns ENOENT but the file exists and has an ELF signature? (both of these solutions seem quite unsatisfactory) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 Prev: Fwd: Re: Boot failure 2.6.33 - 2.6.33-git12 inclusive Next: Convert alpha to use clocksource |