From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 128459 invoked by alias); 16 Feb 2017 22:06:22 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 128448 invoked by uid 89); 16 Feb 2017 22:06:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:3402, H*f:sk:a8867ae, H*i:sk:a8867ae X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 16 Feb 2017 22:06:11 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 88611552CE; Thu, 16 Feb 2017 22:06:11 +0000 (UTC) Received: from localhost (unused-10-15-17-193.yyz.redhat.com [10.15.17.193]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v1GM6A8D005551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 16 Feb 2017 17:06:11 -0500 From: Sergio Durigan Junior To: Pedro Alves Cc: GDB Patches , Luis Machado Subject: Re: [PATCH v3 3/6] Share parts of gdb/inflow.c with gdbserver References: <1482464361-4068-1-git-send-email-sergiodj@redhat.com> <20170208032257.15443-1-sergiodj@redhat.com> <20170208032257.15443-4-sergiodj@redhat.com> X-URL: http://blog.sergiodj.net Date: Thu, 16 Feb 2017 22:06:00 -0000 In-Reply-To: (Pedro Alves's message of "Wed, 15 Feb 2017 16:01:45 +0000") Message-ID: <874lztokoe.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2017-02/txt/msg00454.txt.bz2 Thanks for the review. Comments below. On Wednesday, February 15 2017, Pedro Alves wrote: > On 02/08/2017 03:22 AM, Sergio Durigan Junior wrote: > >> gdb/ChangeLog: >> yyyy-mm-dd Sergio Durigan Junior >> >> * Makefile.in (SFILES): Add "common/common-inflow.c". >> (COMMON_OBS): Add "common/common-inflow.o". >> * common/common-inflow.c: New file, with contents from >> "gdb/inflow.c". >> * inflow.c (gdb_setpgid): Move to "common/common-inflow.c". >> (_initialize_inflow): Move setting of "job_control" to >> "handle_job_control". >> * utils.c (job_control): Delete. >> >> gdb/gdbserver/ChangeLog: >> yyyy-mm-dd Sergio Durigan Junior >> >> * Makefile.in: Add rule for "common-inflow.o". >> (SFILE): Add "common/common-inflow.c". >> (OBS): Add "common-inflow.o". > > > We should take the opportunity to rename the file to something that > makes a more sense wrt to its contents. "inflow.c" in gdb is > horribly named, I think simply due to code evolution. It used to > contain, many many years ago the (from the top of the file): > > /* Low level interface to ptrace, for GDB when running under Unix. > > but everything related to low level ptrace stuff moved away, and > all it was left with was the terminal/job control stuff. > > Maybe call it common/job-control.c or maybe something even more > to the point or something like that. Good point, I hadn't thought about that. I renamed the file to common/job-control.c, because even though it also contains terminal related stuff, the main purpose of the functions there is to help with job control. >> diff --git a/gdb/common/common-inflow.c b/gdb/common/common-inflow.c >> new file mode 100644 >> index 0000000..9871b5e >> --- /dev/null >> +++ b/gdb/common/common-inflow.c >> @@ -0,0 +1,91 @@ >> +/* Low level interface to ptrace, for GDB and gdbserver when running under Unix. > > Please update this. The file really has nothing to do with ptrace. Done. >> + >> +#include "common-defs.h" >> +#include "common-terminal.h" >> + >> +/* Nonzero if we have job control. */ >> +int job_control; >> + >> +/* This is here because this is where we figure out whether we (probably) >> + have job control. Just using job_control only does part of it because >> + setpgid or setpgrp might not exist on a system without job control. >> + It might be considered misplaced (on the other hand, process groups and >> + job control are closely related to ttys). > > > This "misplaced" comment could use some updating. This is no longer > next to the tty stuff. Done. >> + >> + For a more clean implementation, in libiberty, put a setpgid which merely >> + calls setpgrp and a setpgrp which does nothing (any system with job control >> + will have one or the other). */ >> + >> +int >> +gdb_setpgid (void) >> +{ >> + int retval = 0; >> + >> + if (job_control) >> + { >> +#if defined (HAVE_TERMIOS) || defined (TIOCGPGRP) >> +#ifdef HAVE_SETPGID >> + /* The call setpgid (0, 0) is supposed to work and mean the same >> + thing as this, but on Ultrix 4.2A it fails with EPERM (and >> + setpgid (getpid (), getpid ()) succeeds). */ >> + retval = setpgid (getpid (), getpid ()); >> +#else >> +#ifdef HAVE_SETPGRP Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/