From owner-svn-src-all@freebsd.org Tue Dec 22 21:30:57 2015 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4EA3DA4F386; Tue, 22 Dec 2015 21:30:57 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 182F6107E; Tue, 22 Dec 2015 21:30:56 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c211-30-166-197.carlnfd1.nsw.optusnet.com.au (c211-30-166-197.carlnfd1.nsw.optusnet.com.au [211.30.166.197]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id E85C94281B9; Wed, 23 Dec 2015 08:02:11 +1100 (AEDT) Date: Wed, 23 Dec 2015 08:02:10 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Konstantin Belousov cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r292620 - head/sys/kern In-Reply-To: <201512222012.tBMKCqqg039018@repo.freebsd.org> Message-ID: <20151223073258.M993@besplex.bde.org> References: <201512222012.tBMKCqqg039018@repo.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=PfoC/XVd c=1 sm=1 tr=0 a=KA6XNC2GZCFrdESI5ZmdjQ==:117 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=kj9zAlcOel0A:10 a=g1POIRE1eMl8mroPKJgA:9 a=CjuIK1q_8ugA:10 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2015 21:30:57 -0000 On Tue, 22 Dec 2015, Konstantin Belousov wrote: > Log: > If we annoy user with the terminal output due to failed load of > interpreter, also show the actual error code instead of some > interpretation. This and nearby messages are of annoyingly low quality. They don't even print the program name(s). I use the following partial fixes. I forget if they print the program name or the interpeter name. X Index: imgact_elf.c X =================================================================== X RCS file: /home/ncvs/src/sys/kern/imgact_elf.c,v X retrieving revision 1.151 X diff -u -2 -r1.151 imgact_elf.c X --- imgact_elf.c 5 Jun 2004 02:18:28 -0000 1.151 X +++ imgact_elf.c 5 Jun 2004 06:51:25 -0000 X @@ -694,6 +693,6 @@ X brand_info = __elfN(get_brandinfo)(hdr, interp); X if (brand_info == NULL) { X - uprintf("ELF binary type \"%u\" not known.\n", X - hdr->e_ident[EI_OSABI]); X + uprintf("%s: ELF binary type \"%u\" not known.\n", X + imgp->stringbase, hdr->e_ident[EI_OSABI]); X error = ENOEXEC; X goto fail; X @@ -828,5 +827,6 @@ X &imgp->entry_addr, sv->sv_pagesize); X if (error != 0) { X - uprintf("ELF interpreter %s not found\n", interp); X + uprintf("%s: ELF interpreter %s not found\n", X + imgp->stringbase, interp); X goto fail; X } Other uprintf()s in imgact_elf.c are worse -- they print a fixed string that gives no hint about the intepreter either (except it sometimes says ELF or elf or PT_). Y uprintf("elf_load_section: truncated ELF file\n"); Y uprintf("Program headers not in the first page\n"); Y uprintf("Unaligned program headers\n"); Y uprintf("Invalid PT_INTERP\n"); Y uprintf("i/o error PT_INTERP\n"); Y uprintf("Cannot execute shared object\n"); Y uprintf("%s\n", err_str); Y uprintf("ELF interpreter %s not found\n", interp); Y uprintf("i/o error PT_NOTE\n"); The "ELF binary type \"%u\" not known.\n", message is the only one with the style bug of a terminating ".". My patch is missing the fix for this. "elf_load_section: truncated ELF file\n" messages is the only one that prints the function name. This is not very useful for users. All kernel printfs and KASSERT()s in the file use __func__ to obfuscate the function name and have many other style bugs. uprintf() is rarely used. Aproximately 100 times. Most uses don't print enough context. In kern_exec.c there is a related one that prints a pathname, but not in err() format with the name first. The problematic pathname or interpreter name may be nested. I'm not sure how to find the complete sequence of names. tprintf() is only used 7 times. Some uprintf()s should probably be tprintf()s to get them logged. Bruce