info proc cmd

There seems to be a bug in "info proc".  The
command line of the
process is produced like this (in linux-nat.c):

  if (cmdline_f || all)
    {
      sprintf (fname1, "/proc/%lld/cmdline",
pid);
      if ((procfile = fopen (fname1, "r")) !=
NULL)
        {
          fgets (buffer, sizeof (buffer), procfile);
          printf_filtered ("cmdline = '%s'n",
buffer);

This seems to assume that the command line is stored in
/proc/PID/cmdline as a single newline-terminated character
string.
But in fact the command-line arguments are stored there as a
set of
null-terminated strings.  (Or at least that's what I see on
two
GNU/Linux systems I have access to from where I'm writing
this, and
the proc(5) man page says that as well.)  So what we wind up
doing is
display only the first command-line argument.

This bug is easy enough to fix, but I wonder whether some
older
versions of Linux did use the one-string format, in which
case fixing
this to assume a set of null-terminated arguments would
break those
old systems.

Does anyone has further insight into the history of this? 
Should I
just go ahead and fix the code?

On Sat, Mar 08, 2008 at 06:55:22PM +0200, Eli Zaretskii
wrote:
> There seems to be a bug in "info proc".  The
command line of the
> process is produced like this (in linux-nat.c):

Another bug in it; it accepts things which are neither pids
nor
keywords.  I thought at first you meant "info proc
cmd" literally,
so I tried it, and it behaved just like info proc 

> This bug is easy enough to fix, but I wonder whether
some older
> versions of Linux did use the one-string format, in
which case fixing
> this to assume a set of null-terminated arguments would
break those
> old systems.
> 
> Does anyone has further insight into the history of
this?  Should I
> just go ahead and fix the code?

I think you can go ahead and fix it; it's been NUL separated
for as
long as I can remember.  The kernel actually reads memory
from the
child to display this, and the memory is where the initial
argv
strings were placed; there won't be any spaces unless the
app put them
there with setproctitle.

-- 
Daniel Jacobowitz
CodeSourcery

> Date: Sun, 9 Mar 2008 17:13:29 -0400
> From: Daniel Jacobowitz <drowfalse.org>
> Cc: gdbsources.redhat.com
> 
> I thought at first you meant "info proc cmd"
literally,

Actually, I did.  (I looked in the sources, and it mentions
"cmd"
explicitly.)

> so I tried it, and it behaved just like info proc 

That's because cmdline_f, cwd_f, and exe_f are ON by
default, so
mentioning them as part of "info proc" has no
effect.

> > This bug is easy enough to fix, but I wonder
whether some older
> > versions of Linux did use the one-string format,
in which case fixing
> > this to assume a set of null-terminated arguments
would break those
> > old systems.
> > 
> > Does anyone has further insight into the history
of this?  Should I
> > just go ahead and fix the code?
> 
> I think you can go ahead and fix it; it's been NUL
separated for as
> long as I can remember.

Will do.

Thanks for the feedback.

On Mon, Mar 10, 2008 at 12:36:36AM +0200, Eli Zaretskii
wrote:
> > Date: Sun, 9 Mar 2008 17:13:29 -0400
> > From: Daniel Jacobowitz <drowfalse.org>
> > Cc: gdbsources.redhat.com
> > 
> > I thought at first you meant "info proc
cmd" literally,
> 
> Actually, I did.  (I looked in the sources, and it
mentions "cmd"
> explicitly.)

Interesting, so it does.  And there's no way to turn it off,
so I
guess it doesn't make any difference that it's not listed in
the help.

-- 
Daniel Jacobowitz
CodeSourcery