GNUstep and libkvm

[Pascal Hofstee]

On Thu, 6 Jan 2005 22:05:31 -0800, Pascal Hofstee <caelian at gmail.com> wrote:
> Well .. i noticed that kvm_getargv indeed only seems to use /proc in
> case that apparently the commandline argument list grows beyond a
> certain size, as i have been able to establish by trial and error.

OK .. i created a small "kvmtest" program that mimics the behaviour of
what GNUstep is trying to do ...  and managed to trigger the exact
same problem.
So i'm at least certain now that it's not related to the use of the
GCC-extension GNUstep uses to run this code before the actual
"main()".

Further more detailed looking into the libkvm-code revealed that the
"certain limit" that triggers the /proc groveling is in fact "sysctl
kern.ps_arg_cache_limit"

I have tried to run my kvmtest in gdb but i am running into problems there.
a standard non-debugging built libkvm doesn't allow me to step through
the entire kvm_getargv function ... (only the entry point and as soon
as i try to step, i end up at kvm_uread which is at least several
function calls further along).

I also tried building a "g -O0" version of libkvm .. but as soon as i
try to step inside kvm_getargv, gdb seems to just "hang" and has to be
killed to terminate.

I am fairly certain by now that kvm_getargv apparently calls kvm_uread
whenever the size of commandname + argumentlength exceeds the sysctl
kern.ps_arg_cache_limit value, and at that point obviously tries to
read its argument list from /proc.

If this in intended behaviour (and cannot be circumvented in any other
way) .. at the very least the manpage for kvm_getargv should be
updated to reflect this conditional dependency on /proc.

i have attached my "kvmtest" for those that would be interested in
having a look at this .. a potential side-note .. GNUstep doesn't
actually kvm_open /dev/kmem but fakes a kvm_open call using /dev/null
instead ..  i am not sure if this may be relevant though.

Any potential insight or assistence in helping me properly debug
libkvm would be appreciated.

-- 
  With kind regards,
  Pascal Hofstee