This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch 2/2+rfc+doc] Install gcore by default (+new man page)
- From: Pedro Alves <palves at redhat dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: Tom Tromey <tromey at redhat dot com>, gdb-patches at sourceware dot org
- Date: Thu, 11 Apr 2013 11:33:10 +0100
- Subject: Re: [patch 2/2+rfc+doc] Install gcore by default (+new man page)
- References: <20130407185443 dot GB15389 at host2 dot jankratochvil dot net> <83r4ilawlx dot fsf at gnu dot org> <20130408172841 dot GA28868 at host2 dot jankratochvil dot net> <87hajgua2o dot fsf at fleche dot redhat dot com> <516424FE dot 4050307 at redhat dot com> <20130409165525 dot GA29570 at host2 dot jankratochvil dot net> <51654DF0 dot 3090101 at redhat dot com> <20130410194910 dot GA3941 at host2 dot jankratochvil dot net>
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