infrun.c:normal_stop: Fix typo in comment

gdb/
2014-10-10  Pedro Alves  <palves@redhat.com>

	* infrun.c (normal_stop): Fix typo in comment.
Split vDSO range lookup to a gdbarch hook

We have a case in solib-svr4.c where we could reuse symfile-mem.c's
vDSO range lookup.  Since symfile-mem.c is not present in all
configurations solib-svr4.c is, move that lookup to a gdbarch hook.

This has the minor (good) side effect that we stop even trying the
target_auxv_search lookup against targets that don't have a concept of
a vDSO, in case symfile-mem.c happens to be linked in the build
(--enable-targets=all).

Tested on x86_64 Fedora 20.

gdb/
2014-10-10  Pedro Alves  <palves@redhat.com>

	* arch-utils.c (default_vsyscall_range): New function.
	* arch-utils.h (default_vsyscall_range): New declaration.
	* gdbarch.sh (vsyscall_range): New hook.
	* gdbarch.h, gdbarch.c: Regenerate.
	* linux-tdep.c (linux_vsyscall_range): New function.
	(linux_init_abi): Install linux_vsyscall_range as
	vsyscall_range gdbarch hook.
	* memrange.c (address_in_mem_range): New function.
	* memrange.h (address_in_mem_range): New declaration.
	* symfile-mem.c (find_vdso_size): Delete function.
	(add_vsyscall_page): Use gdbarch_vsyscall_range.
PR symtab/14466: Work around PR libc/13097 "linux-vdso.so.1"

With upstream glibc, GDB prints:

  warning: Could not load shared library symbols for linux-vdso.so.1.
  Do you need "set solib-search-path" or "set sysroot"?

A bug's been filed for glibc a few years back:

  http://sourceware.org/bugzilla/show_bug.cgi?id=13097

but it's still not resolved.  It's not clear whether there's even
consensus that this is indeed a glibc bug.  It would actually be nice
if GDB also listed the vDSO in the shared library list, but there are
some design considerations with that:

 - the vDSO is mapped by the kernel, not userspace, therefore we
   should load its symbols right from the process's start of life,
   even before glibc / the userspace loader sets up the initial DSO
   list.  The program might even be using a custom loader or no
   loader.

 - that kind of hints at that solib.c should handle retrieving shared
   library lists from more than one source, and that symfile-mem.c's
   loading of the vDSO would be converted to load and relocate the
   vDSO's bfd behind the target_so_ops interface.

 - and then, once glibc links in the vDSO to its DSO list, we'd need
   to either:

    a) somehow hand over the vDSO from one target_so_ops to the other

    b) simply keep hiding glibc's entry.

And then b) seems the simplest.

With that in mind, this patch simply discards the vDSO from glibc's
reported shared library list.

We can match the vDSO address range with the addresses found iterating
the dynamic linker list, to tell which dynamic linker entry is the
vDSO.

Tested on x86_64 Fedora 20.

gdb/
2014-10-10  Jan Kratochvil  <jan.kratochvil@redhat.com>
	    Pedro Alves  <palves@redhat.com>

	PR symtab/14466
	* solib-svr4.c (svr4_read_so_list): Rename to ...
	(svr4_current_sos_1): ... this and change the function comment.
	(svr4_current_sos): New function.

gdb/testsuite/
2014-10-10  Jan Kratochvil  <jan.kratochvil@redhat.com>
	    Pedro Alves  <palves@redhat.com>

	PR symtab/14466
	* gdb.base/vdso-warning.c: New file.
	* gdb.base/vdso-warning.exp: New file.
Cache the vsyscall/vDSO range per-inferior

We're now doing a vsyscall/vDSO address range lookup whenever we fetch
shared libraries, either through an explicit "info shared", or when
the target reports new libraries have been loaded, in order to filter
out the vDSO from glibc's DSO list.  Before we started doing that, GDB
would only ever lookup the vsyscall's address range once in the
process's lifetime.

Looking up the vDSO address range requires an auxv lookup (which is
already cached, so no problem), but also reading the process's
mappings from /proc to find out the vDSO's mapping's size.  That
generates extra RSP traffic when remote debugging.  Particularly
annoying when the process's mappings grow linearly as more libraries
are mapped in, and we went through the trouble of making incremental
DSO list updates work against gdbserver (when the probes-based dynamic
linker interface is available).

The vsyscall/vDSO is mapped by the kernel when the process is
initially mapped in, and doesn't change throughout the process's
lifetime, so we can cache its address range.

Caching at this level brings GDB back to one and only one vsyscall
address range lookup per process.

Tested on x86_64 Fedora 20.

gdb/
2014-10-10  Pedro Alves  <palves@redhat.com>

	* linux-tdep.c: Include observer.h.
	(linux_inferior_data): New global.
	(struct linux_info): New structure.
	(invalidate_linux_cache_inf, linux_inferior_data_cleanup)
	(get_linux_inferior_data): New functions.
	(linux_vsyscall_range): Rename to ...
	(linux_vsyscall_range_raw): ... this.
	(linux_vsyscall_range): New function; handles caching.
	(_initialize_linux_tdep): Register linux_inferior_data.  Install
	inferior_exit and inferior_appeared observers.
Microblaze: Reject invalid target descriptions

We currently validate the target description, but then forget to
reject it if found invalid.

Tested that incorrect descriptions are rejected and GDB warns about
them.

Tested the Microblaze Design with and without stack-protect registers.
The gdb command "info registers" displayed the register correctly.  If
a stack protect design is not selected, only core registers are
displayed.  When the stack-protect registers are selected in the
design, the core registers along with stack-protect registers are
displayed.

gdb/
2014-10-10  Ajit Agarwal  <ajitkum@xilinx.com>

	* microblaze-tdep.c (microblaze_gdbarch_init): If the description
	isn't valid, release the tdesc arch data and return NULL.
Delete IRIX support

This does most of the mechanical removal.  IOW, the easy part.

This doesn't touch procfs.c as that'd be a harder excision,
potentially affecting Solaris.

mips-tdep.c is left alone.  E.g., I didn't delete the GDB_OSABI_IRIX
enum value, nor references to it in mips-tdep.c.  Some comments
mentioning IRIX ABIs may still be relevant and I wouldn't know what to
do with them. in That can always be done on a separate pass,
preferably by someone who can test on MIPS.

I didn't remove a reference to IRIX in testsuite/lib/future.exp, as I
believe that code is imported from DejaGNU.

Built and tested on x86_64 Fedora 20, with --enable-targets=all.

Tested that building for --target=mips-sgi-irix6 on x86_64 Fedora 20
fails with:

 checking for default auto-load directory... $debugdir:$datadir/auto-load
 checking for default auto-load safe-path... $debugdir:$datadir/auto-load
 *** Configuration mips-sgi-irix6 is obsolete.
 *** Support has been REMOVED.
 make[1]: *** [configure-gdb] Error 1
 make[1]: Leaving directory `/home/pedro/gdb/mygit/build-irix'
 make: *** [all] Error 2

gdb/
2014-10-10  Pedro Alves  <palves@redhat.com>

	* Makefile.in (ALL_TARGET_OBS): Remove mips-irix-tdep.o and solib-irix.o.
	(ALLDEPFILES): Remove mips-irix-tdep.c and solib-irix.c.
	(HFILES_NO_SRCDIR): Remove solib-irix.h.
	* NEWS: Mention that support for mips-sgi-irix5* mips-sgi-irix6*
	and been removed.
	* config/mips/irix5.mh, config/mips/irix6.mh: Delete files.
	* configure.ac: Remove references to IRIX.
	* configure.host: Add *-*-irix* to the obsolete hosts section.
	Remove all other references to irix.
	* irix5-nat.c, mips-irix-tdep.c, solib-irix.c, solib-irix.h:
	Delete files.

gdb/testsuite/
2014-10-10  Pedro Alves  <palves@redhat.com>

	* gdb.base/bigcore.exp: Remove references to IRIX.
	* gdb.base/funcargs.exp: Likewise.
	* gdb.base/interrupt.exp: Likewise.
	* gdb.base/mips_pro.exp: Likewise.
	* gdb.base/nodebug.exp: Likewise.
	* gdb.base/setvar.exp: Likewise.
	* lib/gdb.exp (gdb_compile_shlib): Remove mips-sgi-irix* case.
daily update
No longer pull thread list explicitly

As the result of the patch below, GDB updates thread list when a stop is
presented to user.  The tests don't have to fetch thread list explicitly.

  [PATCH 3/3] Fix non-stop regressions caused by "breakpoints always-inserted off" changes
  https://sourceware.org/ml/gdb-patches/2014-09/msg00734.html

This patch is to remove the test code updating thread list.

Run these three tests many times on arm-linux-gnueabi and x86-linux.
No regressions.

gdb/testsuite:

2014-10-11  Yao Qi  <yao@codesourcery.com>

	* gdb.threads/thread-find.exp: Don't execute command
	"info threads".
	* gdb.threads/attach-into-signal.exp (corefunc): Likewise.
	* gdb.threads/linux-dp.exp: Don't check the condition
	$threads_created equals to zero.
Clean up server-kill.exp

This patch is to remove some lines which looks unnecessary.  These
lines were added when server-kill.exp was added.  In the version 1,
https://sourceware.org/ml/gdb-patches/2013-03/msg00691.html the test
calls runto_main and delete breakpoint on main,

+if ![runto_main] {
+    return -1
+}
+
+# Otherwise the breakpoint at 'main' would not cause insert
breakpoints during
+# first step.
+delete_breakpoints

However, in the version 2
https://sourceware.org/ml/gdb-patches/2013-03/msg00854.html runto_main
is removed but delete_breakpoints is still there.  AFAICS, the line of
delete_breakpoints can be removed too.

gdb/testsuite:

2014-10-11  Yao Qi  <yao@codesourcery.com>

	* gdb.server/server-kill.exp: Remove "delete_breakpoints".
Get GDBserver pid on remote target

Hi,
We see the following fail in the real remote testing...

(gdb) Executing on target: kill -9 29808    (timeout = 300)
spawn [open ...]^M
sh: 1: kill: No such process

The test tries to kill gdbserver in this way:

set server_pid [exp_pid -i [board_info target fileid]]
remote_exec target "kill -9 $server_pid"

in native testing, we'll get the pid of spawned gdbserver, however, in
remote testing, we'll get the pid of ssh session, since we start
gdbserver on the remote target through ssh.  The pid on build doesn't
exist on target.

In this patch, we tweak server-kill.c to get the parent pid, which is
the pid of GDBserver.  GDB gets it and kill GDBserver on target.

gdb/testsuite:

2014-10-11  Yao Qi  <yao@codesourcery.com>

	* gdb.server/server-kill.c: Include sys/types.h and unistd.h.
	(main): Call getppid.
	* gdb.server/server-kill.exp: Set breakpoint on line "i = 0;"
	and continue to it.  Read variable "server_pid".
Enable qTStatus packet in case it is disabled

Nowadays, we are using command "tstatus" to send a packet to GDBserver
in order to check the connection.  However, on the target doesn't
support tracepoint, the following error is emitted before sending any
packet to GDBserver.

tstatus^M
Trace can not be run on this target.^M
(gdb) FAIL: gdb.server/server-kill.exp: tstatus

qTStatus is disabled after receiving the empty reply during connecting
to the remote target.  When the test executes command "tstatus" again,
remote_get_trace_status returns -1 at the very beginning, and no RSP
packet is sent out.

This patch is to enable qTStatus packet again.

gdb/testsuite:

2014-10-11  Yao Qi  <yao@codesourcery.com>

	* gdb.server/server-kill.exp: Execute command
	"set remote trace-status-packet on" before "tstatus".