5.2-CURRENT: ldd /boot/kernel/kernel generates signal 6 (ABRT) ?

Doug White dwhite at gumbysoft.com
Wed Dec 17 16:37:58 PST 2003


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 <scratch, scratch>, 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 at gumbysoft.com          |  www.FreeBSD.org


More information about the freebsd-current mailing list