From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 89540 invoked by alias); 17 Oct 2017 10:11:23 -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 89503 invoked by uid 89); 17 Oct 2017 10:11:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-12.6 required=5.0 tests=BAYES_00,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=__cygwin__, __CYGWIN__, informative X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0b-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.158.5) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 17 Oct 2017 10:11:20 +0000 Received: from pps.filterd (m0098414.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v9HA9QfP027844 for ; Tue, 17 Oct 2017 06:11:18 -0400 Received: from e06smtp13.uk.ibm.com (e06smtp13.uk.ibm.com [195.75.94.109]) by mx0b-001b2d01.pphosted.com with ESMTP id 2dndx15u91-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Tue, 17 Oct 2017 06:11:18 -0400 Received: from localhost by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 17 Oct 2017 11:11:16 +0100 Received: from b06cxnps4076.portsmouth.uk.ibm.com (9.149.109.198) by e06smtp13.uk.ibm.com (192.168.101.143) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 17 Oct 2017 11:11:13 +0100 Received: from d06av24.portsmouth.uk.ibm.com (mk.ibm.com [9.149.105.60]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id v9HABC0E18677930; Tue, 17 Oct 2017 10:11:12 GMT Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 508F44203F; Tue, 17 Oct 2017 11:06:46 +0100 (BST) Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3378442041; Tue, 17 Oct 2017 11:06:46 +0100 (BST) Received: from oc3748833570.ibm.com (unknown [9.167.243.191]) by d06av24.portsmouth.uk.ibm.com (Postfix) with ESMTP; Tue, 17 Oct 2017 11:06:46 +0100 (BST) Received: by oc3748833570.ibm.com (Postfix, from userid 1000) id 9C680D807C2; Tue, 17 Oct 2017 12:11:11 +0200 (CEST) Subject: Re: gcore support for AIX To: sangamesh.swamy@in.ibm.com (Sangamesh Mallayya) Date: Tue, 17 Oct 2017 10:11:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org, Ulrich.Weigand@de.ibm.com (Ulrich Weigand), edelsohn@us.ibm.com (David Edelsohn) In-Reply-To: from "Sangamesh Mallayya" at Oct 13, 2017 10:58:34 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 17101710-0012-0000-0000-0000058296C2 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17101710-0013-0000-0000-000018FCE7AC Message-Id: <20171017101111.9C680D807C2@oc3748833570.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-10-17_07:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710170144 X-SW-Source: 2017-10/txt/msg00501.txt.bz2 Sangamesh Mallaya wrote: > I have came across a way to add gencore support for the AIX. > Need to your input and suggestions on current implementation or is their > any other way this can be done ? > > Some background on the gencore command/API on AIX. > > AIX provides a gencore command and gencore api for generating a > core of a running program. If debugging a process through gdb, > gdb uses ptrace to control the prcoess execution. > > In this case all threads of process must have stopped by > gdb and gencore will hang if gencore command or API is used on the > process which gdb is debugging. > > In order to keep it from hanging, gdb would need to continue one thread > in the process for as little as one instruction. > If a thread is continued, then when it runs it will be resumed such that > the core signal will be handled by that thread of the process and the > core file will be written. I'd prefer if you could find another way to just do whatever it is that "gencore" is doing directly in GDB. Doing this extra "step" would make the semantics of the generate-core-file command different on AIX than it is on any other platform, which seems confusing to end users. > In this implementation gencore api will be called through a separate gdb > thread > which will be scheduled and gencore will be executed after a call to > "step_1_ext (0, 1, "1")" which will call step_1 to execute single > instruction. I really don't like this either :-) GDB currently is not multi-threaded, and making it so just on one platform for this one special case seems odd. I'd rather just fork and exec the gencore command instead, if we do have to use it ... Some comments on the patch itself: > +#if (GDB_OSABI_DEFAULT == GDB_OSABI_AIX) We really try to avoid this type of #ifdef conditional code. Platform- specific code should be encapsulated into target callback routines. There are already some of those related to gcore. If those do not suffice to implement this feature on AIX, they should be extended or new ones added. The actual implementation can then be provided in rs6000-nat.c > +#include > +#include > +#include > +#include > +struct aix_gencore_args { > + char *name; > + pid_t pid; > +}; This shouldn't be in the header file. > +extern void step_1_ext (int, int, char *); This should be in an appropriate header if we need it, not here. > + /* Their can be a slight delay in scheduling gencore call after gdb's > + single step for an multi-threaded programs, and above checks might > + fail. But eventually we will be having a core file generated from > + the gencore. So display informative message that core will be > + created. */ > + fprintf_filtered (gdb_stdout, > + "corefile might be saved as '%s' \n", aix_core); This isn't nice :-) Shouldn't it be possible to wait on completion of the gencore process, simply by waiting on termination of the thread (or process) running it? > +void step_1_ext (int skip, int inst, char *string) > +{ > + step_1 (skip, inst, string); > +} What is the point of creating a new routine here? > --- ./include/libiberty.h_orig 2017-10-10 06:15:51 -0500 > +++ ./include/libiberty.h 2017-10-10 06:49:24 -0500 > @@ -105,6 +105,7 @@ > to find the declaration so provide a fully prototyped one. If it > is 1, we found it so don't provide any declaration at all. */ > #if !HAVE_DECL_BASENAME > +#ifndef _AIX > #if defined (__GNU_LIBRARY__ ) || defined (__linux__) \ > || defined (__FreeBSD__) || defined (__OpenBSD__) || defined (__NetBSD__) \ > || defined (__CYGWIN__) || defined (__CYGWIN32__) || defined (__MINGW32__) \ > @@ -117,6 +118,7 @@ > #define basename basename_cannot_be_used_without_a_prototype > #endif > #endif > +#endif libiberty patches need to be handled separately since libiberty is shared between multiple projects, in particular including GCC. What does this have to do with the gencore patch anyway? It doesn't appear to be using basename in the first place? Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com