Mailing Lists: Apple Mailing Lists

Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Kernel Symbol Clarification



On Jul 18, 2007, at 11:35 AM, Andrew Gallatin wrote:
Garth Cummings writes:
Hi Duane,

On Jul 18, 2007, at 8:43 AM, Duane Murphy wrote:

I wanted to make sure I understood how symbols interact in kext's.
If I
use a generally available library and another kext also uses that
library, will those symbols interact with each other when the kext are
loaded? That is it possible that my kext will accidentally link to the
symbols in the other kext using a the same library?

Not sure what you mean by "interact", but I'll take a stab at answering the question I think you're asking.

The kernel is one big monolithic namespace. All symbols in KEXTs must
be unique across the system as they are linked into that one
namespace. If a KEXT defines a symbol that already exists, the KEXT
will not load.

Are you really sure about this? I thought the relocations were done by kextload in userspace, and the only namespaces that are shared are those of your kext and what it depends on.

If there is truely a master list of all loaded symbols and their
locations, can it be accessed for debugging purposes rather than
using kextload -s and add-symbol-file?

No, your initial assumption is correct.

The problem Duane is attempting to address is best addressed by putting the library information into a KEXT, and then causing all the KEXTs that need the library to depend on the "library" KEXT.

Everyone needs to stop thinking in terms of shared libraries when it comes to KEXTs; KEXTs are PIC (Position Independent Code) which are loaded into a specific (available) kernel virtual address space location by kextload.

The symbolic information for KEXTs is available to the kernel in the KEXTcache symbol information on first load, but this is discarded from the kernel address space very early on after boot to save on wired memory, after which the kernel itself is no longer capable of loading KEXTs, and must rely on user space to do the work for it. That means it's also not available for debugging (we can't even keep a mapping for it, since if it came from the cache from a netboot, there is no vnode handle from which to page in the data, even if we were to free up the physical pages -- besides which, a mapping would also eat kernel virtual address space).

For Duane and everyone else, I believe Amit covers everything anyone wanted to know about KEXT loading in his book...

-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/darwin-dev/email@hidden

This email sent to email@hidden
References: 
 >Kernel Symbol Clarification (From: "Duane Murphy" <email@hidden>)
 >Re: Kernel Symbol Clarification (From: Garth Cummings <email@hidden>)
 >Re: Kernel Symbol Clarification (From: Andrew Gallatin <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.