| Message ID | 1345827353-17112-1-git-send-email-peter.maydell@linaro.org |
|---|---|
| State | Accepted |
| Commit | 885c1d10b803fc37e6656e733ba916c702b6f515 |
| Headers | show |
On Fri, 24 Aug 2012, Peter Maydell wrote: > If the attempt to load the guest executable fails, print the > error message as a string, not a number. This requires us to > fix a couple of places in loader_exec() where we were returning > -1 instead of a valid negative errno. > > The change allows us to drop the "Unknown binary format" message > because the strerror-enhanced message is now a more self-explanatory > "Error while loading $guest-binary: Exec format error". Double edged sword: a. Localized strings that is near impossible to map back to anything useful b. Codes whose meaning is overloaded beyond repair Sometimes sticking to plain numbers works better. [..snip..]
Am 24.08.2012 20:07, schrieb malc: > On Fri, 24 Aug 2012, Peter Maydell wrote: > >> If the attempt to load the guest executable fails, print the >> error message as a string, not a number. This requires us to >> fix a couple of places in loader_exec() where we were returning >> -1 instead of a valid negative errno. >> >> The change allows us to drop the "Unknown binary format" message >> because the strerror-enhanced message is now a more self-explanatory >> "Error while loading $guest-binary: Exec format error". > > Double edged sword: > > a. Localized strings that is near impossible to map back to anything > useful > b. Codes whose meaning is overloaded beyond repair > > Sometimes sticking to plain numbers works better. I ran into the same issue some time ago and was lucky to have pm215 on #qemu knowing what was causing this. A pure number (or number translated to E*) is not so telling. Could the diplomatic solution be to include the number in the error message? :) Andreas
diff --git a/linux-user/linuxload.c b/linux-user/linuxload.c index b47025f..381ab89 100644 --- a/linux-user/linuxload.c +++ b/linux-user/linuxload.c @@ -140,8 +140,9 @@ int loader_exec(const char * filename, char ** argv, char ** envp, bprm->p = TARGET_PAGE_SIZE*MAX_ARG_PAGES-sizeof(unsigned int); memset(bprm->page, 0, sizeof(bprm->page)); retval = open(filename, O_RDONLY); - if (retval < 0) - return retval; + if (retval < 0) { + return -errno; + } bprm->fd = retval; bprm->filename = (char *)filename; bprm->argc = count(argv); @@ -165,8 +166,7 @@ int loader_exec(const char * filename, char ** argv, char ** envp, retval = load_flt_binary(bprm,regs,infop); #endif } else { - fprintf(stderr, "Unknown binary format\n"); - return -1; + return -ENOEXEC; } } diff --git a/linux-user/main.c b/linux-user/main.c index 7dea084..ae0de9a 100644 --- a/linux-user/main.c +++ b/linux-user/main.c @@ -3581,7 +3581,7 @@ int main(int argc, char **argv, char **envp) ret = loader_exec(filename, target_argv, target_environ, regs, info, &bprm); if (ret != 0) { - printf("Error %d while loading %s\n", ret, filename); + printf("Error while loading %s: %s\n", filename, strerror(-ret)); _exit(1); }
If the attempt to load the guest executable fails, print the error message as a string, not a number. This requires us to fix a couple of places in loader_exec() where we were returning -1 instead of a valid negative errno. The change allows us to drop the "Unknown binary format" message because the strerror-enhanced message is now a more self-explanatory "Error while loading $guest-binary: Exec format error". Signed-off-by: Peter Maydell <peter.maydell@linaro.org> --- My motivation here was that "user downloads guest binary from somewhere and it ends up without exec permissions" is quite a common mistake, and "Error -13 while loading my-program" is not a very helpful way to report this... linux-user/linuxload.c | 8 ++++---- linux-user/main.c | 2 +- 2 files changed, 5 insertions(+), 5 deletions(-)