public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] Fix /proc pathname sizes on Solaris
Date: Mon, 17 Sep 2018 18:35:00 -0000	[thread overview]
Message-ID: <20180917183459.GE19172@adacore.com> (raw)
In-Reply-To: <yddlg80nrhk.fsf@CeBiTec.Uni-Bielefeld.DE>

Hi Rainer,

On Mon, Sep 17, 2018 at 04:11:35PM +0200, Rainer Orth wrote:
> I'm slowly working my way through the gdb patches from the
> solaris-userland repo
> 
> 	https://github.com/oracle/solaris-userland/tree/master/components/gdb/patches
> 
> Some of them are pretty obvious and should be able to go in (such as
> this one and the next), while others are either incomplete
> (e.g. 008-syscalls.patch, which adds XML descriptions of the Solaris
> syscalls, but lacks their registration) or inappropriate in their
> current form (unnecessarily intrusive).
> 
> This one (001-fix-proc-name-size.patch) should be obvious given the
> patches' comment:
> 
> # In Solaris, PID_MAX is 999999 (6 digit pid).
> # In Solaris, lwpid_t is an unsigned int, so theoretically the lwp id
> # could be 10 digits.
> 
> Two questions about procedure here:
> 
> * AFAIK Oracle has a corporate copyright assignment on file, so the
>   patches should be covered.  Even if that were not the case, this one
>   and the next are certainly below the 15-line limit for non-trivial
>   patches.

I checked, and indeed, Oracle has a copyright assignment.

> * Given the code isn't mine, how should we handle attribution?  I
>   suspect the engineer who committed the patch to github is the author,
>   but don't know for certain.  Should I attribute it to her in the
>   ChangeLog?

Can you ask the user in question if they are the author? If not,
can they help figuring out who it is? Ideally, we would want the
name and email of the author of  the patch -- not sure what we should
be doing if we don't have that info.

> Tested on i386-pc-solaris2.11.  Ok for master?
> 
> 	Rainer
> 
> -- 
> -----------------------------------------------------------------------------
> Rainer Orth, Center for Biotechnology, Bielefeld University
> 
> 
> 2018-06-27  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>
> 
> 	* procfs.c (MAX_PROC_NAME_SIZE): Allow for 6-digit PID_MAX and
> 	uint_t lwpid_t.
> 	(create_procinfo): Print pids in /proc without leading zeros.

OK for me.

> # HG changeset patch
> # Parent  e6140f0a7128422be8a7e2a148da8de516d676d8
> Fix /proc pathname sizes on Solaris
> 
> diff --git a/gdb/procfs.c b/gdb/procfs.c
> --- a/gdb/procfs.c
> +++ b/gdb/procfs.c
> @@ -233,7 +233,7 @@ enum { READ_WATCHFLAG  = WA_READ,
>  #define AS_PROC_NAME_FMT     "/proc/%d/as"
>  #define MAP_PROC_NAME_FMT    "/proc/%d/map"
>  #define STATUS_PROC_NAME_FMT "/proc/%d/status"
> -#define MAX_PROC_NAME_SIZE sizeof("/proc/99999/lwp/8096/lstatus")
> +#define MAX_PROC_NAME_SIZE sizeof("/proc/999999/lwp/0123456789/lwpstatus")
>  
>  typedef struct procinfo {
>    struct procinfo *next;
> @@ -483,7 +483,7 @@ create_procinfo (int pid, int tid)
>      }
>    else
>      {
> -      sprintf (pi->pathname, "/proc/%05d/lwp/%d", pid, tid);
> +      sprintf (pi->pathname, "/proc/%d/lwp/%d", pid, tid);

I am wondering how this ever worked for processes whose pid had
fewer than 5 digits. I was initially concerned that this patch
introduced a change of behavior that would create an incompatibility.
But looking at Solaris 2.8 and 2.11 systems, I see processes with
3 or 4 digits PIDs, and the path in /proc doesn't have leading zeroes.

I also checked whether the file might be used on platforms other than
Solaris (see configure.nat), and this does not appear to be the case.

>        pi->next = parent->thread_list;
>        parent->thread_list = pi;
>      }


-- 
Joel

  reply	other threads:[~2018-09-17 18:35 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-17 14:11 Rainer Orth
2018-09-17 18:35 ` Joel Brobecker [this message]
2018-09-17 19:27   ` Rainer Orth
2018-09-19  9:04   ` Rainer Orth
2018-09-19 13:21     ` Joel Brobecker
2018-09-19 12:58 ` Tom Tromey
2018-09-19 13:28   ` Rainer Orth
2018-09-19 15:16 ` Pedro Alves
2018-09-19 17:42   ` Rainer Orth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180917183459.GE19172@adacore.com \
    --to=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=ro@CeBiTec.Uni-Bielefeld.DE \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).