From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 51431 invoked by alias); 18 Oct 2017 09:41:38 -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 51033 invoked by uid 89); 18 Oct 2017 09:41:37 -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= X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0a-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.156.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 18 Oct 2017 09:41:35 +0000 Received: from pps.filterd (m0098410.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v9I9e3hS012556 for ; Wed, 18 Oct 2017 05:41:34 -0400 Received: from smtp.notes.na.collabserv.com (smtp.notes.na.collabserv.com [192.155.248.72]) by mx0a-001b2d01.pphosted.com with ESMTP id 2dp2nkwsdb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 18 Oct 2017 05:41:34 -0400 Received: from localhost by smtp.notes.na.collabserv.com with smtp.notes.na.collabserv.com ESMTP for from ; Wed, 18 Oct 2017 09:41:33 -0000 Received: from us1a3-smtp04.a3.dal06.isc4sb.com (10.106.154.237) by smtp.notes.na.collabserv.com (10.106.227.158) with smtp.notes.na.collabserv.com ESMTP; Wed, 18 Oct 2017 09:41:31 -0000 Received: from us1a3-mail142.a3.dal06.isc4sb.com ([10.146.38.78]) by us1a3-smtp04.a3.dal06.isc4sb.com with ESMTP id 2017101809413056-280397 ; Wed, 18 Oct 2017 09:41:30 +0000 In-Reply-To: <20171017101111.9C680D807C2@oc3748833570.ibm.com> To: "Ulrich Weigand" Cc: edelsohn@us.ibm.com (David Edelsohn), gdb-patches@sourceware.org Subject: Re: gcore support for AIX From: "Sangamesh Mallayya" Date: Wed, 18 Oct 2017 09:41:00 -0000 References: from "Sangamesh Mallayya" at Oct 13, 2017 10:58:34 AM <20171017101111.9C680D807C2@oc3748833570.ibm.com> MIME-Version: 1.0 X-KeepSent: 0FB27DEE:C04E1BD5-652581BD:003116A6; type=4; name=$KeepSent X-LLNOutbound: False X-Disclaimed: 2039 X-TNEFEvaluated: 1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="US-ASCII" x-cbid: 17101809-6059-0000-0000-000005CC070A X-IBM-SpamModules-Scores: BY=0; FL=0; FP=0; FZ=0; HX=0; KW=0; PH=0; SC=0.40962; ST=0; TS=0; UL=0; ISC=; MB=0.262408 X-IBM-SpamModules-Versions: BY=3.00007911; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000237; SDB=6.00932836; UDB=6.00469797; IPR=6.00713126; BA=6.00005645; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00017588; XFM=3.00000015; UTC=2017-10-18 09:41:33 X-IBM-AV-DETECTION: SAVI=unsuspicious REMOTE=unsuspicious XFE=unused X-IBM-AV-VERSION: SAVI=2017-10-18 07:22:30 - 6.00007478 x-cbparentid: 17101809-6060-0000-0000-0000866D0569 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-10-18_03:,, signatures=0 X-Proofpoint-Spam-Reason: safe X-SW-Source: 2017-10/txt/msg00556.txt.bz2 >=20 > > I have came across a way to add gencore support for the AIX. > > Need to your input and suggestions on current implementation or is=20 their > > any other way this can be done ? > >=20 > > Some background on the gencore command/API on AIX. > >=20 > > 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. > >=20 > > 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. > >=20 > > In order to keep it from hanging, gdb would need to continue one=20 thread > > in the process for as little as one instruction. > > If a thread is continued, then when it runs it will be resumed such=20 that > > the core signal will be handled by that thread of the process and the > > core file will be written. >=20 > 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. >=20 Thanks for the review and providing your valuable inputs. Since AIX provides gencore command and api, thought it would be easy to=20 make this feature work. If the current implementation make semantics of gencore different, then i=20 will see if this can be done as the way it was done for other platforms. > > In this implementation gencore api will be called through a separate=20 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. >=20 > I really don't like this either :-) GDB currently is not=20 multi-threaded, > and making it so just on one platform for this one special case seems=20 odd. > I'd rather just fork and exec the gencore command instead, if we do have > to use it ... >=20 I did try with fork/exec method, but thought multi-threaded would be=20 leaner. Agree that GDB on AIX would be multi-threaded just for gcore support. >=20 > Some comments on the patch itself: >=20 > > +#if (GDB_OSABI_DEFAULT =3D=3D GDB_OSABI_AIX) >=20 > 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 >=20 Thanks for pointing this out. Best possible solution here to add gcore support for AIX is to implement=20 it the way it was done for other platforms instead of using gencore=20 command/API. And platform changes should go into the rs600-nat.c files. > > +#include > > +#include > > +#include > > +#include > > +struct aix_gencore_args { > > + char *name; > > + pid_t pid;=20 > > +}; >=20 > This shouldn't be in the header file. >=20 > > +extern void step_1_ext (int, int, char *); >=20 > This should be in an appropriate header if we need it, not here. >=20 > > + /* Their can be a slight delay in scheduling gencore=20 > call after gdb's > > + single step for an multi-threaded programs, and=20 > above checks might > > + fail. But eventually we will be having a core file=20 > generated from > > + the gencore. So display informative message that=20 > core will be=20 > > + created. */ > > + fprintf_filtered (gdb_stdout, > > + "corefile might be saved as '%s' \n",=20 aix_core);=20 >=20 > This isn't nice :-) Shouldn't it be possible to wait on completion of=20 the > gencore process, simply by waiting on termination of the thread (or=20 process) > running it? >=20 Idea here is just to make gdb continue it's execution after executing=20 single instruction. I think waiting on gencore process completion can be also possible and can= =20 be done that way too.=20 =20 > > +void step_1_ext (int skip, int inst, char *string) > > +{ > > + step_1 (skip, inst, string); > > +} >=20 > What is the point of creating a new routine here? step_1 is a static function in infcmd.c. So, this is a wrapper to call=20 static function in infcmd.c from gcore.c. =20 >=20 > > --- ./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=20 > (__NetBSD__) \ > > || defined (__CYGWIN__) || defined (__CYGWIN32__) || defined=20 > (__MINGW32__) \ > > @@ -117,6 +118,7 @@ > > #define basename basename_cannot_be_used_without_a_prototype > > #endif > > #endif > > +#endif >=20 > libiberty patches need to be handled separately since libiberty is > shared between multiple projects, in particular including GCC. >=20 > What does this have to do with the gencore patch anyway? It doesn't > appear to be using basename in the first place? >=20 I have included libgen.h header for dirname function. However, libgen.h=20 also declares the basename and we would get the error as below. /usr/include/libgen.h:60:14: error: conflicting declaration of C function=20 'char* basename(char*)' extern char *basename(char *); ^~~~~~~~ In file included from ./common/common-defs.h:72:0, from defs.h:28, from exec.c:20: ./../include/libiberty.h:112:14: note: previous declaration 'char*=20 basename(const char*)'