June 2009 - Darwin-kernel - lists.apple.com

Re: x87 status word size
by Jonas Maebe 15 Jun '09

15 Jun '09

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On 15 Jun 2009, at 23:58, Terry Lambert wrote: Right, I should have known that this would be the reason :) Jonas _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… On Jun 15, 2009, at 11:11 AM, Jonas Maebe <jonas.maebe(a)elis.ugent.be> wrote: Why is the x87 tag word field (__fpu_ftw) in _STRUCT_X86_FLOAT_STATE32 in osfmk/mach/i386/_structs.h only 8 bits? The hardware tag word is 16 bit. I guess it "overflows" into the next "__fpu_rsrv1" field when saving/restoring the fpu state, so in practice it probably doesn't really matter as long as you don't directly access it (but I would like to do so, to reset the fpu state within a signal handler). Generally, it's to make it a pain to do what you are trying to do so that you will reconsider and not do it. x87 exceptions are not definite exceptions, so the state that you will be mucking with after a SIGFPE is thrown is the state some time past the point of the exception that caused it to be raised. I know, but that's not a problem: I'm doing a complete reset of the x87 state inside the signal handler and then jump to my language run time's exception handler (by setting the eip in the thread context to that routine's address). I'm not doing a siglongjmp to my handler because of earlier bad experiences on ppc (see http://lists.apple.com/archives/darwin-dev/2008/Nov/msg00086.html) I haven't gotten around yet to converting our unix signal handlers into mach signal handlers... You should really be using fegetexceptflag/fetestexcept/ feclearexcept et. al Are those perhaps new in Snow Leopard? "apropos" on Leopard doesn't turn up anything for those functions. And are these usable inside a SIGFPE exception handler to reset the "fpu stack pointer" of the current context? The problem I have is that a) a value is loaded on the fpu stack b) an invalid operation is performed on that value, resulting in a SIGFPE c) the signal handler clears all "exception happened" flags in the fpscr d) the signal handler returns to the language run time signal handler, which converts the signal into a language exception As a result, the value loaded in step a) remains on the fpu stack, so after 7 exceptions the fpu stack is permanently full. Maybe the best solution is simply to perform an fninit in the language run time signal handler of step d) for darwin/x86, but that would introduce an OS/cpu-dependency in code that is currently completely OS and cpu neutral. to make your code processor neutral, rather that bit-banging on the current thread state (the only exception to this would be if you were writing a debugger), since we won't promise to not change the context layout or contents at some future date. I'm not writing a debugger. This code is for the run time library of our compiler (this obviously only makes it worse, because it means that there are already quite a few apps out there that may break when such a change occurs). This email sent to site_archiver(a)lists.apple.com

1 0

Re: x87 status word size
by Terry Lambert 15 Jun '09

15 Jun '09

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Hello, Thanks, Jonas -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… On Jun 15, 2009, at 11:11 AM, Jonas Maebe <jonas.maebe(a)elis.ugent.be> wrote: Why is the x87 tag word field (__fpu_ftw) in _STRUCT_X86_FLOAT_STATE32 in osfmk/mach/i386/_structs.h only 8 bits? The hardware tag word is 16 bit. I guess it "overflows" into the next "__fpu_rsrv1" field when saving/restoring the fpu state, so in practice it probably doesn't really matter as long as you don't directly access it (but I would like to do so, to reset the fpu state within a signal handler). (I asked this question 2 months back on darwin-dev, but didn't get a reply; maybe someone here knows) Generally, it's to make it a pain to do what you are trying to do so that you will reconsider and not do it. x87 exceptions are not definite exceptions, so the state that you will be mucking with after a SIGFPE is thrown is the state some time past the point of the exception that caused it to be raised. You should really be using fegetexceptflag/fetestexcept/feclearexcept et. al to make your code processor neutral, rather that bit-banging on the current thread state (the only exception to this would be if you were writing a debugger), since we won't promise to not change the context layout or contents at some future date. This email sent to site_archiver(a)lists.apple.com

1 0

x87 status word size
by Jonas Maebe 15 Jun '09

15 Jun '09

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Hello, Thanks, Jonas _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… Why is the x87 tag word field (__fpu_ftw) in _STRUCT_X86_FLOAT_STATE32 in osfmk/mach/i386/_structs.h only 8 bits? The hardware tag word is 16 bit. I guess it "overflows" into the next "__fpu_rsrv1" field when saving/restoring the fpu state, so in practice it probably doesn't really matter as long as you don't directly access it (but I would like to do so, to reset the fpu state within a signal handler). (I asked this question 2 months back on darwin-dev, but didn't get a reply; maybe someone here knows) This email sent to site_archiver(a)lists.apple.com

1 0

Re: Understanding kexts in the early boot process
by Andrew Myrick 15 Jun '09

15 Jun '09

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Understanding kexts in the early boot process
by mm w 15 Jun '09

15 Jun '09

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=w+4kmyuiH6h1oCHi7cKr6qOhRujvlEbZGX5lJrEyf1k=; b=orCf1dvDRS3ELEYgn1Ui464sLwfCUQn2yir1OVfXKMdc8yhWF3RIF2AZiYT8FdZsYZ u/RcuD5NPwevsvbDp4NuVYSua8Up+sFeWsP4KLr+7/gpB4f6yL5llFVBQInvrznbnmYb UErVFjrk91xoSwkWATs/OhEZI8ihQ1nONWejc= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=VIJou41cFDF5EhqHUIzsx+f0Q0yUy78d8elAMt9q/zVrrm9J0DXoGO4zUGn+HB0k+2 osSWtVm+SN1Fs+ScdfmcOuHQ1QYFXcAGbTZbHsObv/ioausJqed/vmcpF+zebONU5TMM L1AoHorhQIO1SaT4ZK8/ch1unOZuaHcN3U3nI= open /usr/standalone/bootcaches.plist -> PostBootPaths somehow, yes, a bootloader is not made check the integrity of a system, bootloader steps: power on, list table, read On Mon, Jun 15, 2009 at 10:55 AM, Thomas Tempelmann<tempelmann(a)gmail.com> wrote: > Nik, > >> Again some confusion in terminology. The boot loader copies kexts into >> memory that the kernel knows how to find, it does not load kexts (in the >> sense of getting them actually running, as it does for the kernel). To "load >> a kext" is a pretty involved process, which varies between early boot and >> when kextd starts, of which linking is only a part. > > I meant "load" in its more raw sense, i.e. read from disk into memory. > > So, if I understand you right, the boot loader reads the kexts into > memory and passes a pointer to them to the kernel. The kernel then > iterates over the kexts, executing their code. > > I just try to understand when the files get read and when they get > executed. If it is how I just suggested, then this means that the boot > loader is the authority in selecting all the kexts for the kernel, and > the kernel has no choice than to work with those - if they're not > sufficient, the kernel may fail to boot because the kernel does _not_ > read essential kexts on its own. Correct? > > -- > Thomas Tempelmann, http://www.tempel.org/ > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/darwin-kernel/0xcafefeed%40gmail.com > > This email sent to 0xcafefeed(a)gmail.com > _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Understanding kexts in the early boot process
by Thomas Tempelmann 15 Jun '09

15 Jun '09

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/zu4Acc/xe5W5OB3/bvVFw53mXJJUee85nb7/DgOZJI=; b=B8CRRAKi1nZznN0PYVjs7pUeNYuVWUA6wGiCf8jdYr6tkhSBDUqsfMFy/0Eo8EbqS7 8+E8lARjMyYujaBM3d6FU2athDd3tkz2td2aeFI6+vhr4b5j43I95Xypn5n1XfbwFeXS GRrHrIK6Ozd5nEcgRU+7RxFOz45apNRsTNs1w= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=i2ZzHGfVP/gKn+npMMaD1E/48eFB1Nw5yWQjaSz7hRTobPb+hVlPlcCaqrsxMmKCH7 TSis0i/RLzXUNGBzAS7+sqhFvJ0BKNxTKqThRrpSVceCIQKoqs/TfyPYAqvaqpz+5hzl 0gyH1g0nqk4VuAXdByPkxAR+ujIMD5AHDHKdE= Nik, > Again some confusion in terminology. The boot loader copies kexts into > memory that the kernel knows how to find, it does not load kexts (in the > sense of getting them actually running, as it does for the kernel). To "load > a kext" is a pretty involved process, which varies between early boot and > when kextd starts, of which linking is only a part. I meant "load" in its more raw sense, i.e. read from disk into memory. So, if I understand you right, the boot loader reads the kexts into memory and passes a pointer to them to the kernel. The kernel then iterates over the kexts, executing their code. I just try to understand when the files get read and when they get executed. If it is how I just suggested, then this means that the boot loader is the authority in selecting all the kexts for the kernel, and the kernel has no choice than to work with those - if they're not sufficient, the kernel may fail to boot because the kernel does _not_ read essential kexts on its own. Correct? -- Thomas Tempelmann, http://www.tempel.org/ _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Understanding kexts in the early boot process
by Nik Gervae 15 Jun '09

15 Jun '09

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Question 4: How does the mkext, if loaded separately, get linked to the kernel? (i.e. does the boot loader contain a linker that works like the kextcache command?) If the kernel contains a linker to link in the kexts, that means that it's also the kernel that initializes them, I suppose. Correct? However, on q 2 you replied that the bootloader parses kexts. What I haven't seen yet is the part that links the kexts (apparently loaded by the boot loader) to the kernel. Does the boot_args struct have a new parameter (not doc'd in Amit's book) which passes a pointer to a list of loaded kexts to the kernel, or how does this work? Background is this: It appears that a 3rd party boot loader is able to load two sets of kexts from different locations and get them used by the kernel. I try to understand how that works, because so far all I learned was that there's only one single group of kexts that the kernel sees, not several. --Nik _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… On 14 Jun, 2009, at 14:38, Thomas Tempelmann wrote: The kernel contains a linker that handles this. Perhaps there's some confusion over what you mean by "initialize" here. Initialization would be one step in loading a kext, which happens after linking. Again some confusion in terminology. The boot loader copies kexts into memory that the kernel knows how to find, it does not load kexts (in the sense of getting them actually running, as it does for the kernel). To "load a kext" is a pretty involved process, which varies between early boot and when kextd starts, of which linking is only a part. Shantonu's reference to the libsa/catalogue.cpp file definitely where you want to start. I have no idea what they are doing in their boot loader; as Shantonu said, you'll have to ask them. I'm a bit of a stickler on terminology as one of the implementers of the kext loading stack, and people often come to me with questions about many distinct things using the single word "load" for them all. :-) This email sent to site_archiver(a)lists.apple.com

1 0

Re: Understanding kexts in the early boot process
by Shantonu Sen 14 Jun '09

14 Jun '09

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Understanding kexts in the early boot process
by Thomas Tempelmann 14 Jun '09

14 Jun '09

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=isRS8j6NdJ2o02NY/tSL7BSEjS8y0jyPIv9UrbgZgLA=; b=q74kdaeAAIjDILzGod96IKnEV7YpLfI+H9rQ1JcHewdcLS7zfPmwQ/NsUAa04WY13v +8zBlgav1RCl2YQH1Nokd1j/ILcVfnSUrC9zpEwDHIMT/xhPVJR2Zwlo26gwXdymA+66 Rm5VpLdmavh1CYTYTyYqlh887H2i6PyHYH33g= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=PDky1lRsLrhK3V1qS6kyQALSWVfuSIzqOHxP4vqxFVP1E5PY+2gmjrt2bmUEhV8Lwr 59vtQg6kuLuoFQCy8xG5uYKNTIe0UAm2XJXHBfd7wYXkUY8tYqSEuRhMExPj4ESSL2TC JnhTdrnheY2wZHtdkkkjj4jUnI3pag39Kw/qk= Michael, thank you for helping me out here. There's one thing left I don't understand yet: >> Question 2: What if this file does not exist, can the system still >> boot, and which component is then taking care of finding the kexts >> (e.g. is it boot.efi or the kernel or what?) > > The bootloader is capable of parsing extension plists. >> Question 4: How does the mkext, if loaded separately, get linked to >> the kernel? (i.e. does the boot loader contain a linker that works >> like the kextcache command?) > > The kernel contains a linker that handles this. If the kernel contains a linker to link in the kexts, that means that it's also the kernel that initializes them, I suppose. Correct? However, on q 2 you replied that the bootloader parses kexts. What I haven't seen yet is the part that links the kexts (apparently loaded by the boot loader) to the kernel. Does the boot_args struct have a new parameter (not doc'd in Amit's book) which passes a pointer to a list of loaded kexts to the kernel, or how does this work? Background is this: It appears that a 3rd party boot loader is able to load two sets of kexts from different locations and get them used by the kernel. I try to understand how that works, because so far all I learned was that there's only one single group of kexts that the kernel sees, not several. -- Thomas Tempelmann, http://www.tempel.org/ _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Understanding kexts in the early boot process
by Michael Smith 14 Jun '09

14 Jun '09

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0