Re: [patch 2/2+rfc+doc] Install gcore by default (+new man page)

[Pedro Alves <palves at redhat dot com>]

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