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.orgReceived on Wed Dec 17 2003 - 15:37:58 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:34 UTC