From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 7 02:21:56 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E5FF016A4CF for ; Fri, 7 Jan 2005 02:21:55 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5162843D1D for ; Fri, 7 Jan 2005 02:21:55 +0000 (GMT) (envelope-from caelian@gmail.com) Received: by rproxy.gmail.com with SMTP id a36so139917rnf for ; Thu, 06 Jan 2005 18:21:54 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:mime-version:content-type:content-transfer-encoding; b=fPGAcyxcUeAFILywHxigOrE6gAgXAVbYvoF8TXqyYts2kMmXYnLK/44MenBAlbNZQRZZ1B+5mEer9tRMFPeO8Ri8NBkrliGUgTtzmKpsun8mnzaoJMD+PlvF+zg8195l5nLTki5Z29auUBgl7kFpUoelWtpEAew0ye6z6YlBTCU= Received: by 10.39.3.34 with SMTP id f34mr381635rni; Thu, 06 Jan 2005 18:21:54 -0800 (PST) Received: by 10.38.89.69 with HTTP; Thu, 6 Jan 2005 18:21:54 -0800 (PST) Message-ID: Date: Thu, 6 Jan 2005 18:21:54 -0800 From: Pascal Hofstee To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: Dirk Meyer Subject: GNUstep and libkvm X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Pascal Hofstee List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2005 02:21:56 -0000 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.