From owner-freebsd-current@FreeBSD.ORG Wed Dec 17 16:37:58 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C23E16A4CE for ; Wed, 17 Dec 2003 16:37:58 -0800 (PST) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3480D43D1F for ; Wed, 17 Dec 2003 16:37:57 -0800 (PST) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 283EC72DB5; Wed, 17 Dec 2003 16:37:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 2633672DAD; Wed, 17 Dec 2003 16:37:57 -0800 (PST) Date: Wed, 17 Dec 2003 16:37:57 -0800 (PST) From: Doug White To: Dorin H In-Reply-To: <20031217194843.4674.qmail@span.corp.yahoo.com> Message-ID: <20031217163109.K15803@carver.gumbysoft.com> References: <20031217194843.4674.qmail@span.corp.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: 5.2-CURRENT: ldd /boot/kernel/kernel generates signal 6 (ABRT) ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2003 00:37:58 -0000 On Wed, 17 Dec 2003, Dorin H wrote: > > I think it s a peculiarity of how ldd works. It > > appears to execve() the > > binary in order to get ld.so to look at it, but > > since the kernel binary > > specifies it own loader (for the in-kernel linker) > > it bails. > > > Ok, I agree, but nevetheless, an abort ? :) Could be something more > explicit, but being the only exception (plus the modules), maybe it is > not relevant and the complications heavier than the user comfort. I don't think there's a lot you can do at this point. Peter filled me in on some details. The kernel actually has a bogus loader, /red/herring, specified. The kernel ELF image activator sees this and tries to execute /red/herring to continue loading the binary. When that fails due to ENOENT it has no choice but to kill the offending executable, and the most expeident way is to use SIGABRT. I suppose you could add a kernel printf complaining about an invalid binary execution, but this should only happen if the binary is configured in precisely this way (valid ELF header but bogus loader). Usually invalid binaries won't have a correct ELF header and will error out with and error like "Could not execute binary. Invalid Architecture" or some such. > > The kernel isn't dynamically linked to any libraries > > (how would it load > > them!?!) so this wouldn't return anything anyway. > > > > Hm , so you map dynamic libraries to > user vm spaces, while when they are loaded in kernel > space, we "call" them kld modules ? They aren't the same thing, and do not have the same functionality. Calling them both libraries would be confusing. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org