Date: Thu, 6 Jan 2005 18:21:54 -0800 From: Pascal Hofstee <caelian@gmail.com> To: freebsd-hackers@freebsd.org Cc: Dirk Meyer <dinoex@freebsd.org> Subject: GNUstep and libkvm Message-ID: <d8a0b76205010618212e484cf4@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
For the last couple of days i have been looking into why the gnustep-gui-port actually Needs procfs mounted in order to successfully build and i managed to track the problem down to being inside libkvm. I am however no kernel hacker and my gdb-skills have left me hanging at a point where i simply can't manage to actually debug the libkvm code itself. (NSProcessInfo is compiled using libkvm instead of the procfs code) If somebody could have a closer look at this for me ... or provide me some more details on how i can go about actually getting gdb to let me debug Inside libkvm so i can gather some additional details that would be highly appreciated. The actual nature of the problem turns out to be the following however: GNUstep apparently uses a gcc-extension to load certain code before the program actually reaches its "main()" function ... it uses this to allow GNUstep's NSProcessInfo class to gather a program's environment and commandline arguments before its main() routine gets a chance at potentially clobering this information. The function that does this +[NSProcessInfo load] is in itself straight C, so you shouldn't need any actual Objective-C knowledge. (+[NSProcessInfo load] means the class-method load (indicated by the +) of class NSProcessInfo) The following URL is a link to the relevant revision in gnustep's cvs-tree of the NSProcessInfo class [ http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/base/Source/NSProcessInfo.m?rev=1.101&content-type=text/vnd.viewcvs-markup ] The function-call inside the load-method that actually triggers the /proc groveling seems to be kvm_getargv (at line 406). According to the kvm_getprocs, kvm_getargv and kvm_getenvv only kvm_getenvv depends on a working /proc ... however from my own observations both kvm_getenvv and kvm_argvv return the result of kvm_doargv() ... which under certain conditions seems to call kvm_uread() which in turn is responsible for the observed /proc groveling. What i have been able to establish for any GNUstep-application so far is that the second the size of its "command" + "length of its argument list" (not including the whitespace between command and start of argument list) exceeds 242 bytes ... the /proc groveling occurs ... which most likely means the conditional under which kvm_uread is invoked is met. As long as the size of "command" + "argumentlist" remains below (or equals) this 242 byte threshold .. everything works as expected. The reason the gnustep-gui port triggers this error is because it tries to build documentation on default (it gets REINPLACEd from no to yes) ... and since the commandline required to perform this action Obviously exceeds this 242 character threshold .. experiences the problem described above. I guess to sum it all up it all boils down to the following question. Is it intended that kvm_getargv() apparently has a conditional under which it depends on the existince of a working /proc .. even though the manpage states this condition is only present for kvm_getenvv ? And if kvm_getargv should not depend on /proc ... how can we go about to fixing this as this is apprently only the case for "short commandlines" in our current implementation. With Kind Regards, Pascal Hofstee P.S.: This is as experienced on a recent 6.0-CURRENT system .. though the problem is Known to exist on 5.x as well.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d8a0b76205010618212e484cf4>