From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29990 invoked by alias); 17 Jun 2013 17:52:07 -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 29964 invoked by uid 89); 17 Jun 2013 17:52:02 -0000 X-Spam-SWARE-Status: No, score=-6.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Mon, 17 Jun 2013 17:52:01 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r5HHpvjM009632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Jun 2013 13:51:57 -0400 Received: from psique (ovpn-113-144.phx2.redhat.com [10.3.113.144]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r5HHprTi026793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 17 Jun 2013 13:51:55 -0400 From: Sergio Durigan Junior To: "Pierre Muller" Cc: "'GDB Patches'" Subject: Re: [RFC/PATCH] New convenience variable $_exitsignal References: <00db01ce6b24$0b716aa0$22543fe0$@muller@ics-cnrs.unistra.fr> X-URL: http://www.redhat.com Date: Mon, 17 Jun 2013 17:55:00 -0000 In-Reply-To: <00db01ce6b24$0b716aa0$22543fe0$@muller@ics-cnrs.unistra.fr> (Pierre Muller's message of "Mon, 17 Jun 2013 08:29:37 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2013-06/txt/msg00391.txt.bz2 On Monday, June 17 2013, Pierre Muller wrote: > Hi Sergio, > > Is there a reason why you don't handle > corelow.c anymore in your new patch? Hi Pierre, Yes, corelow.c is not important to this patch because (as Pedro explained on ) $_exitsignal should not be set for corefiles, because the inferior has not exited. corelow.c will be touched in my next patch, which will add $_signo (but with the modifications proposed by Pedro). > Also, I seem to vaguely remember that on > linux, the signal that generated the program exit is > finally embedded in the status... > See WIFEXITED and WIFSIGNALED macros in linux-nat.c > > For instance if I interrupt as (launched without argumrents) > with Ctrl-C, > The exit code (at least in bash shell) is 130. > > Is this a shell feature? If not, I am not sure setting $_exitcode > variable to zero is the right thing to do. To the extent of my knowledge, this is a shell feature. It sets $? (the variable which contains the exit code of the program) to 128 + signal number. However, if you use this simple C program (borrowed from waitpid's manpage, and modified to print the exit code when the child is killed by a signal): #include #include #include #include int main(int argc, char *argv[]) { pid_t cpid, w; int status; cpid = fork(); if (cpid == -1) { perror("fork"); exit(EXIT_FAILURE); } if (cpid == 0) { /* Code executed by child */ printf("Child PID is %ld\n", (long) getpid()); if (argc == 1) pause(); /* Wait for signals */ _exit(atoi(argv[1])); } else { /* Code executed by parent */ do { w = waitpid(cpid, &status, WUNTRACED | WCONTINUED); if (w == -1) { perror("waitpid"); exit(EXIT_FAILURE); } if (WIFEXITED(status)) { printf("exited, status=%d\n", WEXITSTATUS(status)); } else if (WIFSIGNALED(status)) { printf("killed by signal %d, exit=%d\n", WTERMSIG(status), WEXITSTATUS(status)); } else if (WIFSTOPPED(status)) { printf("stopped by signal %d\n", WSTOPSIG(status)); } else if (WIFCONTINUED(status)) { printf("continued\n"); } } while (!WIFEXITED(status) && !WIFSIGNALED(status)); exit(EXIT_SUCCESS); } } And run it: $ ./a.out Child PID is 2448 Then, on another terminal: $ kill -USR1 2448 You'll see: killed by signal 10, exit=0 Thus, it makes sense to unset $_exitcode (note that I am not setting it to zero, as you said). > Sorry to bother you again... Hey, no problem, your question was actually very pertinent. Thanks, -- Sergio