On Wednesday, August 7, 2002, at 10:36 AM, David Blanton wrote: JCW ... This is just info for you ........... Thanks. This explains what is happening: I did kmodload -v -o /tmp/sym macos/kext gdb add-symbol-file /tmp/sym gdb info func This gives you a list of *all* symbols in the kernel + loaded extensions, although it doesn't mention where the symbols are defined. and behold 000aeaa4 delete 000aeaac lseek 000aec04 olseek As it happens, and you noticed, these symbols are in the kernel. 'lseek' in this case is the *implementation* of the lseek system call; not the lseek system call itself. To simplify life for those who work down here, system call implementations are often named the same as the system call itself. This can cause confusion for the hapless novice, of course. with no reference to lseek in the kext at all so, i though great I will define the function in my kext and call it since the symbol is there and that did not work as I got kmodload: kld(): kmodload: Undefined symbols:kmodload: kmodload: _lseek__Fixi This, I'll guess, is the result of your calling 'lseek()' in your extension (which I'll also guess is an IOKit gizmo) without mentioning that it (lseek) is C, not C++ (which you might assume is covered in a header file somewhere; but that's a separate issue [that putative header file should not be included in a kernel module]). If you check the archives for this and the -developers lists, you'll see numerous threads dealing with the subject of making BSD "system calls" or libc calls from the kernel or extensions. The answer's always the same: it's A Bad Thing (TM). Don't do it: - the calling sequences aren't the same, even though the procedure names are (or may be) - the setup for calling a system call can be quite involved, and is an implementation detail subject to change - the assumptions internal to the system call implementation may not support calling from within the kernel's address space - other libc calls may make assumptions about run-time environment that are not valid when in kernel mode (and they may themselves make real system calls, which would cause breakage). When you do this, you leave yourself open for all sorts of breakage, either in the field when someone uses the system in a way you haven't tested; or at the next release, when Apple re-implements everything from the ground up, in a non-compatible way. Did I mention you should not do this? Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | When LuteFisk is outlawed | Only outlaws will have | LuteFisk *--------------------------------------*-------------------------------* _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.