From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16755 invoked by alias); 11 Apr 2013 10:33:15 -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 16744 invoked by uid 89); 11 Apr 2013 10:33:14 -0000 X-Spam-SWARE-Status: No, score=-8.9 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_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; Thu, 11 Apr 2013 10:33:13 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r3BAXC06020169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 11 Apr 2013 06:33:12 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r3BAXA4a008321; Thu, 11 Apr 2013 06:33:11 -0400 Message-ID: <51669166.5060007@redhat.com> Date: Thu, 11 Apr 2013 17:49:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: Jan Kratochvil CC: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [patch 2/2+rfc+doc] Install gcore by default (+new man page) References: <20130407185443.GB15389@host2.jankratochvil.net> <83r4ilawlx.fsf@gnu.org> <20130408172841.GA28868@host2.jankratochvil.net> <87hajgua2o.fsf@fleche.redhat.com> <516424FE.4050307@redhat.com> <20130409165525.GA29570@host2.jankratochvil.net> <51654DF0.3090101@redhat.com> <20130410194910.GA3941@host2.jankratochvil.net> In-Reply-To: <20130410194910.GA3941@host2.jankratochvil.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-04/txt/msg00325.txt.bz2 On 04/10/2013 08:49 PM, Jan Kratochvil wrote: > Do you insist on the *.mh flag for the hosts covered by linux-tdep.o ? I agree with your reasoning, and I do not insist. >> With --enable-targets=all, I got: >> >> $ make DESTDIR=/tmp/foo/ install >> ... >> /usr/bin/install: cannot stat `gcore': No such file or directory >> >> But I'm not sure that's related to the issue pointed out >> above, or whether I hasn't applied the patch properly. > > I believe you did not run autoconf. I did run autoconf. If I hadn't I wouldn't have been able to do the other "--host=x86_64-unknown-linux-gnu --target=arm-linux-gnu" or "--host=x86_64-unknown-linux-gnu --target=arm-linux-gnu \ --enable-targest=x86_64-unknown-linux-gnu" tests I mentioned. ;-) > The problem is not reproducible for me > and also I guess it would happen without the configure update. I see what happened. While doing my several tests, and switching configurations, I deleted the generated "gcore" from the build dir. "make" alone is not triggering a regeneration of gcore. Only the configure step is generating it. This fixes it: diff --git a/gdb/Makefile.in b/gdb/Makefile.in index 427c122..ebe6eb7 100644 --- a/gdb/Makefile.in +++ b/gdb/Makefile.in @@ -969,7 +969,7 @@ DISTSTUFF = $(YYFILES) # All generated files which can be included by another file. generated_files = config.h observer.h observer.inc ada-lex.c jit-reader.h \ - $(GNULIB_H) $(NAT_GENERATED_FILES) + $(GNULIB_H) $(NAT_GENERATED_FILES) gcore .c.o: $(COMPILE) $< @@ -1328,6 +1328,9 @@ data-directory/Makefile: data-directory/Makefile.in config.status @frags@ jit-reader.h: $(srcdir)/jit-reader.in $(SHELL) config.status $@ +gcore: $(srcdir)/gcore.in + $(SHELL) config.status $@ + config.h: stamp-h ; @true stamp-h: $(srcdir)/config.in config.status CONFIG_HEADERS=config.h:config.in \ With that, "make" generates gcore. > FYI there is also archer.git branch: jankratochvil/man Thanks. (I find it much better for review when test branches are rebased versions on top of upstream, just containing the proposed patches though.) > case x$CONFIG_HEADERS in > diff --git a/gdb/configure.tgt b/gdb/configure.tgt > index c6357d2..abbd8cd 100644 > --- a/gdb/configure.tgt > +++ b/gdb/configure.tgt > @@ -703,3 +703,14 @@ m68*-*-openbsd* | m88*-*-openbsd* | vax-*-openbsd*) ;; > *-*-symbianelf*) > gdb_osabi=GDB_OSABI_SYMBIAN ;; > esac > + > +# Check whether this target supports gcore if used as a native one. s/if used as a native one// . The "native" aspect is a concern of a particular caller. > +# Such target has to call set_gdbarch_find_memory_regions. > +case " ${gdb_target_obs} " in > + *" linux-tdep.o "*) > + gdb_have_gcore=true > + ;; > + *) > + gdb_have_gcore=false > + ;; Please document $gdb_have_gcore at the top of the configure.tgt file though, in the "This file sets the following shell variables:" section. > +<<<<<<< HEAD > +gcore.1: $(GDB_DOC_FILES) > + touch $@ > + -$(TEXI2POD) $(MANCONF) -Dgcore < $(srcdir)/gdb.texinfo > gcore.pod > + -($(POD2MAN1) gcore.pod | sed -e '/^.if n .na/d' > $@.T$$$$ && \ > + mv -f $@.T$$$$ $@) || (rm -f $@.T$$$$ && exit 1) > + rm -f gcore.pod > + > +||||||| merged common ancestors > +======= > +gdb-add-index.1: $(GDB_DOC_FILES) > + touch $@ > + -$(TEXI2POD) $(MANCONF) -Dgdb-add-index < $(srcdir)/gdb.texinfo > gdb-add-index.pod > + -($(POD2MAN1) gdb-add-index.pod | sed -e '/^.if n .na/d' > $@.T$$$$ && \ > + mv -f $@.T$$$$ $@) || (rm -f $@.T$$$$ && exit 1) > + rm -f gdb-add-index.pod > + > +>>>>>>> addindex I see this on the branch as well. > > +@node gdb-add-index man > + This whole node looks unrelated ? > +@c man title gdb-add-index Add index files to speed up GDB > + > +@c man begin SYNOPSIS gdb-add-index > +gdb-add-index @var{filename} > +@c man end > + > +@c man begin DESCRIPTION gdb-add-index > +When GDB finds a symbol file, it scans the symbols in the file in order > +to construct an internal symbol table. This lets most GDB operations > +work quickly--at the cost of a delay early on. For large programs, > +this delay can be quite lengthy, so GDB provides a way to build an > +index, which speeds up startup. > + > +To determine whether a file contains such an index, use the command > +@command{readelf -S filename}: the index is stored in a section named > +@code{.gdb_index}. Note that the index is never generated for files that do > +not contain DWARF debug information (sections named @code{.debug_*}). > + > +See more in > +@ifset man > +the @value{GDBN} manual in node @code{Index Files} > +-- shell command @code{info -f gdb -n 'Index Files'}. > +@end ifset > +@ifclear man > +@ref{Index Files}. > +@end ifclear > +@c man end > + Otherwise looks good to me. -- Pedro Alves