Ensure softfloat and singlefloat take precedence in consistency checks

gas/

* tc-mips.c (check_fpabi): Move softfloat and singlefloat
checks higher.

gas/testsuite/

* gas/mips/attr-gnu-4-5-msingle-float.l: New file.
* gas/mips/attr-gnu-4-5-msingle-float.s: Likewise.
* gas/mips/attr-gnu-4-5-msoft-float.l: Likewise.
* gas/mips/attr-gnu-4-5-msoft-float.s: Likewise.
* gas/mips/attr-gnu-4-6-msingle-float.l: Update expected output.
* gas/mips/attr-gnu-4-6-msoft-float.l: Likewise.
* gas/mips/attr-gnu-4-7-msingle-float.l: Likewise.
* gas/mips/attr-gnu-4-7-msoft-float.l: Likewise.
* gas/mips/mips.exp: Update expected output for FP ABI 5,6,7.

daily update

Fix set up of queue-signal.exp test.

The test does a backtrace to see which thread (#2 or #3) is assigned
to which SIGUSR (1 or 2).  If the main thread gets to all_threads_running
before the sigusr threads get to their entry point, then the function
name isn't in the backtrace and the test fails.

Alas this version of the code is within epsilon of what I started with,
and then over-simplified things.

New command queue-signal.

If I want to change the signalled state of multiple threads
it's a bit cumbersome to do with the "signal" command.
What you really want is a way to set the signal state of the
desired threads and then just do "continue".

This patch adds a new command, queue-signal, to accomplish this.
Basically "signal N" == "queue-signal N" + "continue".
That's not precisely true in that "signal" can be used to inject
any signal, including signals set to "nopass"; whereas "queue-signal"
just queues the signal as if the thread stopped because of it.
"nopass" handling is done when the thread is resumed which
"queue-signal" doesn't do.

One could add extra complexity to allow queue-signal to be used to
deliver "nopass" signals like the "signal" command.  I have no current
need for it so in the interests of incremental complexity, I have
left such support out and just have the code flag an error if one
tries to queue a nopass signal.

gdb/ChangeLog:

* NEWS: Mention new "queue-signal" command.
* infcmd.c (queue_signal_command): New function.
(_initialize_infcmd): Add new queue-signal command.

gdb/doc/ChangeLog:

* gdb.texinfo (Signaling): Document new queue-signal command.

gdb/testsuite/ChangeLog:

* gdb.threads/queue-signal.c: New file.
* gdb.threads/queue-signal.exp: New file.

daily update

* linux-nat.c (wait_lwp): Add debugging printf.
(linux_nat_wait_1): Ditto.

Pass plain-text prompt to with_gdb_prompt.

I had occasion to use with_gdb_prompt in a test for the patch for PR 17314
and was passing the plain text prompt as the value, "(top-gdb)",
instead of a regexp, "\(top-gdb\)" (expressed as "\\(top-gdb\\)" in TCL).

I then discovered that in order to restore the prompt gdb passes the
original value of $gdb_prompt to "set prompt", which works because
"set prompt \(gdb\) " is equivalent to "set prompt (gdb) ".
Perhaps I'm being overly cautious but this feels a bit subtle,
but at any rate as an API choice I'd much rather pass the plain text
form to with_gdb_prompt.

I also discovered that the initial value of gdb_prompt is set in
two places to two different values.
At the global level gdb.exp sets it to "\[(\]gdb\[)\]"
and default_gdb_init sets it to "\\(gdb\\)".
The former form is undesirable as an argument to "set prompt",
but it's not clear to me that just deleting this code won't break
anything.  Thus I just changed the value to be consistent and added
a comment.

gdb/testsuite/ChangeLog:

* lib/gdb.exp (gdb_prompt): Add comment and change initial value to
be consistent with what default_gdb_init uses.
(with_gdb_prompt): Change form of PROMPT argument from a regexp to
the plain text of the prompt.  Add some logging printfs.
* gdb.perf/disassemble.exp: Update call to with_gdb_prompt.

Fix some ChangeLog typos

daily update

after gdb_run_cmd, gdb_expect -> gdb_test_multiple/gdb_test

See:
  https://sourceware.org/ml/gdb-patches/2014-09/msg00404.html

We have a number of places that do gdb_run_cmd followed by gdb_expect,
when it would be better to use gdb_test_multiple or gdb_test.

This converts all that "grep gdb_run_cmd -A 2 | grep gdb_expect"
found.

Tested on x86_64 Fedora 20, native and gdbserver.

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

* gdb.arch/gdb1558.exp: Replace uses of gdb_expect after
gdb_run_cmd with gdb_test_multiple or gdb_test throughout.
* gdb.arch/i386-size-overlap.exp: Likewise.
* gdb.arch/i386-size.exp: Likewise.
* gdb.arch/i386-unwind.exp: Likewise.
* gdb.base/a2-run.exp: Likewise.
* gdb.base/break.exp: Likewise.
* gdb.base/charset.exp: Likewise.
* gdb.base/chng-syms.exp: Likewise.
* gdb.base/commands.exp: Likewise.
* gdb.base/dbx.exp: Likewise.
* gdb.base/find.exp: Likewise.
* gdb.base/funcargs.exp: Likewise.
* gdb.base/jit-simple.exp: Likewise.
* gdb.base/reread.exp: Likewise.
* gdb.base/sepdebug.exp: Likewise.
* gdb.base/step-bt.exp: Likewise.
* gdb.cp/mb-inline.exp: Likewise.
* gdb.cp/mb-templates.exp: Likewise.
* gdb.objc/basicclass.exp: Likewise.
* gdb.threads/killed.exp: Likewise.

[IRIX] eliminate deprecated_insert_raw_breakpoint uses

The IRIX support wants to set a breakpoint to be hit when the startup
phase is complete, which is where shared libraries have been mapped
in.  AFAIU, for most IRIX ports, that location is the entry point.

For MIPS IRIX however, GDB needs to set a breakpoint earlier, in
__dbx_link, as explained by:

 #ifdef SYS_syssgi
   /* On mips-irix, we need to stop the inferior early enough during
      the startup phase in order to be able to load the shared library
      symbols and insert the breakpoints that are located in these shared
      libraries.  Stopping at the program entry point is not good enough
      because the -init code is executed before the execution reaches
      that point.

      So what we need to do is to insert a breakpoint in the runtime
      loader (rld), more precisely in __dbx_link().  This procedure is
      called by rld once all shared libraries have been mapped, but before
      the -init code is executed.  Unfortuantely, this is not straightforward,
      as rld is not part of the executable we are running, and thus we need
      the inferior to run until rld itself has been mapped in memory.

      For this, we trace all syssgi() syscall exit events.  Each time
      we detect such an event, we iterate over each text memory maps,
      get its associated fd, and scan the symbol table for __dbx_link().
      When found, we know that rld has been mapped, and that we can insert
      the breakpoint at the symbol address.  Once the dbx_link() breakpoint
      has been inserted, the syssgi() notifications are no longer necessary,
      so they should be canceled.  */
   proc_trace_syscalls_1 (pi, SYS_syssgi, PR_SYSEXIT, FLAG_SET, 0);
 #endif

The loop in irix_solib_create_inferior_hook then runs until whichever
breakpoint is hit first, the one set by solib-irix.c or the one set by
procfs.c.

Note the comment in disable_break talks about __dbx_init, but I think
that's a typo for __dbx_link:

 -  /* Note that it is possible that we have stopped at a location that
 -     is different from the location where we inserted our breakpoint.
 -     On mips-irix, we can actually land in __dbx_init(), so we should
 -     not check the PC against our breakpoint address here.  See procfs.c
 -     for more details.  */

This looks very much like referring to the loop in
irix_solib_create_inferior_hook stopping at __dbx_link instead of at
the entry point.

What this patch does is convert these deprecated raw breakpoints to
standard solib_event breakpoints.  When the first solib-event
breakpoint is hit, we delete all solib-event breakpoints.  We do that
in the so_ops->handle_event hook.

This allows getting rid of the loop in irix_solib_create_inferior_hook
completely, which should allow properly handling signals and other
events in the early startup phase, like in SVR4.

Built on x86_64 Fedora 20 with --enable-targets=all (builds
solib-irix.c).

Joel tested that with an earlier version of this patch "info shared"
after starting a program gave the same list of shared libraries as
before.

gdb/ChangeLog:
2014-09-12  Pedro Alves  <palves@redhat.com>

* breakpoint.c (remove_solib_event_breakpoints_at_next_stop)
(create_and_insert_solib_event_breakpoint): New functions.
* breakpoint.h (create_and_insert_solib_event_breakpoint)
(remove_solib_event_breakpoints_at_next_stop): New declarations.
* procfs.c (dbx_link_bpt_addr, dbx_link_bpt): Delete globals.
(remove_dbx_link_breakpoint): Delete function.
(insert_dbx_link_bpt_in_file): Use
create_and_insert_solib_event_breakpoint instead of
deprecated_insert_raw_breakpoint.
(procfs_wait): Don't check whether we hit __dbx_link here.
(procfs_mourn_inferior): Don't delete the __dbx_link breakpoint
here.
* solib-irix.c (base_breakpoint): Delete global.
(disable_break): Delete function.
(enable_break): Use create_solib_event_breakpoint
instead of deprecated_insert_raw_breakpoint.
(irix_solib_handle_event): New function.
(irix_solib_create_inferior_hook): Don't run the target or disable
the mapping-complete breakpoint here.
(_initialize_irix_solib): Install irix_solib_handle_event as
so_ops->handle_event hook.

gas: fix bumping to architectures >v9 in sparc64-* targets.

This patch fixes two related problems:

- By default gas is supposed to bump the current architecture
  (starting with v6) as it finds "higher" instructions as the
  assembling progresses.  There are four possible cases depending on
  the usage of the -A and -bump options:

  (a) No -A and -bump are specified.  In this case max_architecture
      must be the highest architecture not conflicting with the
      default architecture.  The default opcode architecture is
      indirectly set in configure.tgt and is "v9" in sparc64 systems
      (from "v9-64").  Thus the maximum architecture in sparc64
      systems must be "v9b".  No warnings are echoed when the assembly
      of an instruction bumps the current architecture.

  (b) Only -bump is specified.  This is like (a) but warnings are
      always issued when the assembly of an instruction bumps the
      current architecture.

  (c) Only -A is specified.  In this case bumping to a new
      architecture is an error.

  (d) Both -A and -bump are specified.  In this case max_architecture
      must be the highest architecture not conflicting with the
      default architecture, but warnings are only to be issued when
      bumping to an architecture higher than the architecture selected
      in the -A option.

  `max_architecture' is a global variable defined in tc-sparc.c which
  is initialized to the opcode architecture corresponding to the
  default architecture ("sparclite" for sparc-* targets and "v9" for
  sparc64-* targets).  Then in `md_begin' it is set to the highest
  non-conflicting architecture, but only when both -A and -bump are
  specified.

  Thus (a) does not work:

    $ echo "fzero %f0" | as
    {standard input}: Assembler messages:
    {standard input}:1: Error: Architecture mismatch on "fzero".
    {standard input}:1:  (Requires v9a|v9b; requested architecture is v9.)

  Neither (b):

    $ echo "fzero %f0" | as -bump
    {standard input}: Assembler messages:
    {standard input}:1: Error: Architecture mismatch on "fzero".
    {standard input}:1:  (Requires v9a|v9b; requested architecture is v9.)

  Only (d) does:

    $ echo "fzero %f0" | as -Av9 -bump
    {standard input}: Assembler messages:
    {standard input}:1: Warning: architecture bumped from "v6" to "v9a" on "fzero"

  This patch fixes that function to "upgrade" `max_architecture' also
  in the (a) and (b) cases.

  Note that this problem becomes apparent only in sparc64-* targets
  because in sparc-* targets the default architecture is the "higher"
  among the 32bit architectures ("sparclite").

- Gas maintains a set of hardware capabilities associated with each
  gas architecture, in `sparc_arch_table'.  On the other hand
  libopcodes maintains a set of hardware capabilities needed by each
  individual sparc instruction.

  When an instruction is assembled in `sparc_ip' gas checks for the
  presence of the hardware capabilities required by the instruction,
  emitting an error if some capability is missing.

  However, this mechanism does not work properly if the current
  architecture is bumped due to an instruction requiring new hw
  capabilities not present on either the default architecture or an
  architecture specified with -A:

  $ echo "fzero %f0" | as -bump
  {standard input}: Assembler messages:
  {standard input}:1: Warning: architecture bumped from "v6" to "v9a" on "fzero"
  {standard input}:1: Error: Hardware capability "vis" not enabled for "fzero".

  This patch fixes this by adding the set of required hw caps of an
  instruction if it triggers an architecture bump.

The patch has been tested in sparc64-unknown-linux-gnu.

gas/ChangeLog:

2014-09-12  Jose E. Marchesi  <jose.marchesi@oracle.com>

* config/tc-sparc.c (sparc_ip): Update the set of allowed hwcaps
when bumping the current architecture.
(md_begin): Adjust the highetst architecture level also when a
specific architecture is not requested.

Add mips*-img-elf* target triple.

/
* configure.ac: Add mips*-img-elf* target triple.
* configure: Regenerate.

bfd/
* config.bfd: Add mips*-img-elf* target triple.

gas/
* configure.tgt: Add mips*-img-elf* target triple.

gas/testsuite/
* gas/mips/mips.exp: Add mips*-img-elf* target triple.

binutils/testsuite/
* binutils-all/objcopy.exp: Add mips*-img-elf* target triple.
* binutils-all/readelf.exp: Likewise.

ld/
* configure.tgt: Add mips*-img-elf* target triple.

ld/testsuite/
* ld-mips-elf/mips-elf.exp: Add support for mips*-img-elf* target
triple.

PR tdep/17379: Fix internal-error when stack pointer is invalid.

The problem is that rs6000_frame_cache attempts to read the stack backchain via
read_memory_unsigned_integer, which throws an exception if the stack pointer is
invalid.  With this patch, it calls safe_read_memory_integer instead, which
doesn't throw an exception and allows for safe handling of that situation.

gdb/ChangeLog
2014-09-12  Edjunior Barbosa Machado  <emachado@linux.vnet.ibm.com>
    Ulrich Weigand  <uweigand@de.ibm.com>

PR tdep/17379
* rs6000-tdep.c (rs6000_frame_cache): Use safe_read_memory_integer
instead of read_memory_unsigned_integer.

gdb/testcase/ChangeLog
2014-09-12  Edjunior Barbosa Machado  <emachado@linux.vnet.ibm.com>

PR tdep/17379
* gdb.arch/powerpc-stackless.S: New file.
* gdb.arch/powerpc-stackless.exp: New file.

testsuite: Fix runaway attach processes

I have started seeing occasional runaway 'attach' processes these days.
I cannot be certain it is really caused by this patch, for example
grep 'FAIL.*cmdline attach run' does not show anything in my logs.

But as I remember this 'attach' runaway process always happened in GDB (but
I do not remember it in the past months) I think it would be most safe to just
solve it forever by [attached].

gdb/testsuite/ChangeLog
2014-09-12  Jan Kratochvil  <jan.kratochvil@redhat.com>

* gdb.base/attach.c: Include unistd.h.
(main): Call alarm.  Add label postloop.
* gdb.base/attach.exp (do_attach_tests): Use gdb_get_line_number,
gdb_breakpoint, gdb_continue_to_breakpoint.
(test_command_line_attach_run): Kill ${testpid} in one exit path.

Clarify GDBSERVER use in linux-waitpid.c

This commit makes linux-waitpid.c include common-defs.h.  GDB's
inclusion of defs.h is removed, but gdbserver's inclusion of
server.h remains to support some gdbserver-specific debug code
that cannot presently be merged.  A new FIXME documents this.

gdb/ChangeLog:

* nat/linux-waitpid.c: Include common-defs.h.
[GDBSERVER]: Add FIXME comment.
[!GDBSERVER]: Don't include defs.h or signal.h.
(linux_debug) [!GDBSERVER]: Remove empty block.

Remove GDBSERVER uses from x86-dregs.c

This commit makes nat/x86-dregs.c include common-defs.h rather than
defs.h or server.h.  An extra header required including in order to
support this change.

gdb/ChangeLog:

* nat/x86-dregs.c: Include common-defs.h and break-common.h.
Don't include defs.h or server.h.

Remove GDBSERVER uses from linux-btrace.c

This commit makes nat/linux-btrace.c include common-defs.h rather
than defs.h or server.h.  A couple of minor changes were required
to support this change.

gdb/ChangeLog:

* nat/linux-btrace.c: Include common-defs.h.
Don't include defs.h, server.h or gdbthread.h.
* nat/linux-btrace.h (struct target_ops): New forward declaration.

Include common-defs.h instead of defs.h/server.h in shared code

This commit makes 19 of the 22 shared .c files in common, nat and
target include common-defs.h instead of defs.h/server.h.  The
remaining three files need slight extra work and are dealt with
in separate commits.

gdb/ChangeLog:

* common/agent.c: Include common-defs.h.
Don't include defs.h or server.h.
* common/buffer.c: Likewise.
* common/common-debug.c: Likewise.
* common/common-utils.c: Likewise.
* common/errors.c: Likewise.
* common/filestuff.c: Likewise.
* common/format.c: Likewise.
* common/gdb_vecs.c: Likewise.
* common/print-utils.c: Likewise.
* common/ptid.c: Likewise.
* common/rsp-low.c: Likewise.
* common/signals.c: Likewise.
* common/vec.c: Likewise.
* common/xml-utils.c: Likewise.
* nat/linux-osdata.c: Likewise.
* nat/linux-procfs.c: Likewise.
* nat/linux-ptrace.c: Likewise.
* nat/mips-linux-watch.c: Likewise.
* target/waitstatus.c: Likewise.

Introduce common-regcache.h

This introduces common-regcache.h.  This contains two functions that
allow nat/linux-btrace.c to be simplified.  A better long term
solution would be unify the regcache code, but this is sufficient for
now.

gdb/ChangeLog:

* common/common-regcache.h: New file.
* Makefile.in (HFILES_NO_SRCDIR): Add common/common-regcache.h.
* regcache.h: Include common-regcache.h.
(regcache_read_pc): Don't declare.
* regcache.c (get_thread_regcache_for_ptid): New function.
* nat/linux-btrace.c: Don't include regcache.h.
Include common-regcache.h.
(perf_event_read_bts): Use get_thread_regcache_for_ptid.

gdb/gdbserver/ChangeLog:

* regcache.h: Include common-regcache.h.
(regcache_read_pc): Don't declare.
* regcache.c (get_thread_regcache_for_ptid): New function.

Fix tc-i386.c -Werror=logical-not-parentheses error

* config/tc-i386.c (match_template): Remove redundant "!!" testing
single-bit bitfields.
(build_modrm_byte): Don't compare single-bit bitfields to "1".

Test for overflow in eh_frame_hdr entries and for overlapping FDEs

With larger binaries on 64-bit systems, or indeed just binaries that
have a large gap between text and data, it is possible for the
.eh_frame_hdr lookup table entry values to overflow a signed 32-bit
relative offset.  It is also a requirement for the glibc FDE lookup
code that only one FDE claim to cover any given address.

* elf-bfd.h (struct eh_frame_array_ent): Add "range".
* elf-eh-frame.c (_bfd_elf_write_section_eh_frame): Stash address
range of FDEs to hdr_info->array.
(_bfd_elf_write_section_eh_frame_hdr): Report overflow in
.eh_frame_hdr entries, and overlapping FDEs.

daily update

Make gdb/regcache.h self-contained.

gdb/
* regcache.h (struct regset): Declare.

Commit 0b3092721e5cfa1697f1dafe81efefdbb0236f21 added uses of struct regset to
gdb/regcache.h, but that struct is not declared in this file, and, as it
happens, also nowhere else in the #include chain on x86 GNU/Hurd.  This results
in warnings/errors such as:

    gcc-4.8 [...] ../../W._C._Handy/gdb/gdb.c
    In file included from ./nm.h:25:0,
                     from ../../W._C._Handy/gdb/defs.h:454,
                     from ../../W._C._Handy/gdb/gdb.c:19:
    ../../W._C._Handy/gdb/regcache.h:190:9: warning: 'struct regset' declared inside parameter list [enabled by default]
             size_t size);
             ^
    ../../W._C._Handy/gdb/regcache.h:190:9: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
    ../../W._C._Handy/gdb/regcache.h:193:10: warning: 'struct regset' declared inside parameter list [enabled by default]
              int regnum, void *buf, size_t size);
              ^

gdb/17347 - Regression: GDB stopped on run with attached process

Doing:

  gdb --pid=PID -ex run

Results in GDB getting a SIGTTIN, and thus ending stopped.  That's
usually indicative of a missing target_terminal_ours call.

E.g., from the PR:

 $ sleep 1h & p=$!; sleep 0.1; gdb -batch sleep $p -ex run
 [1] 28263
 [1]   Killed                  sleep 1h

 [2]+  Stopped                 gdb -batch sleep $p -ex run

The workaround is doing:

 gdb -ex "attach $PID" -ex "run"

instead of

 gdb [-p] $PID -ex "run"

With the former, gdb waits for the attach command to complete before
moving on to the "run" command, because the interpreter is in sync
mode at this point, within execute_command.  But for the latter,
attach_command is called directly from captured_main, and thus misses
that waiting.  IOW, "run" is running before the attach continuation
has run, before the program stops and attach completes.  The broken
terminal settings are just one symptom of that.  Any command that
queries or requires input results in the same.

The fix is to wait in catch_command_errors (which is specific to
main.c nowadays), just like we wait in execute_command.

gdb/ChangeLog:
2014-09-11  Pedro Alves  <palves@redhat.com>

PR gdb/17347
* main.c: Include "infrun.h".
(catch_command_errors, catch_command_errors_const): Wait for the
foreground command to complete.
* top.c (maybe_wait_sync_command_done): New function, factored out
from ...
(maybe_wait_sync_command_done): ... here.
* top.h (maybe_wait_sync_command_done): New declaration.

gdb/testsuite/ChangeLog:
2014-09-11  Pedro Alves  <palves@redhat.com>

PR gdb/17347
* lib/gdb.exp (gdb_spawn_with_cmdline_opts): New procedure.
* gdb.base/attach.exp (test_command_line_attach_run): New
procedure.
(top level): Call it.

testsuite: refactor spawn and wait for attach

Several places in the testsuite have a copy of a snippet of code that
spawns a test program, waits a bit, and then does some PID munging for
Cygwin.  This is in order to have GDB attach to the spawned program.

This refactors all that to a common procedure.

(multi-attach.exp wants to spawn multiple processes, so this makes the
new procedure's interface work with lists.)

Tested on x86_64 Fedora 20.

gdb/testsuite/ChangeLog:
2014-09-11  Pedro Alves  <palves@redhat.com>

* lib/gdb.exp (spawn_wait_for_attach): New procedure.
* gdb.base/attach.exp (do_attach_tests, do_call_attach_tests)
(do_command_attach_tests): Use spawn_wait_for_attach.
* gdb.base/solib-overlap.exp: Likewise.
* gdb.multi/multi-attach.exp: Likewise.
* gdb.python/py-prompt.exp: Likewise.
* gdb.python/py-sync-interp.exp: Likewise.
* gdb.server/ext-attach.exp: Likewise.

Introduce common/symbol.h

This introduces common/symbol.h.  This file declares a function that
the shared code can use and that the clients must implement.  It also
changes some shared code to use these functions.

gdb/ChangeLog:

* common/symbol.h: New file.
* Makefile.in (HFILES_NO_SRCDIR): Add common/symbol.h.
* minsyms.c (find_minimal_symbol_address): New function.
* common/agent.c: Include common/symbol.h.
[!GDBSERVER]: Don't include objfiles.h.
(agent_look_up_symbols): Use find_minimal_symbol_address.

gdb/gdbserver/ChangeLog:

* symbol.c: New file.
* Makefile.in (SFILES): Add symbol.c.
(OBS): Add symbol.o.

Introduce target_{stop,continue}_ptid

This commit introduces two new functions to stop and restart target
processes that shared code can use and that clients must implement.
It also changes some shared code to use these functions.

gdb/ChangeLog:

* target/target.h (target_stop_ptid, target_continue_ptid):
Declare.
* target.c (target_stop_ptid, target_continue_ptid): New
functions.
* common/agent.c [!GDBSERVER]: Don't include infrun.h.
(agent_run_command): Always use target_stop_ptid and
target_continue_ptid.

gdb/gdbserver/ChangeLog:

* target.c (target_stop_ptid, target_continue_ptid): New
functions.

Introduce target/target.h

This introduces target/target.h.  This file declares some functions
that the shared code can use and that clients must implement.  It also
changes some shared code to use these functions.

gdb/ChangeLog:

* target/target.h: New file.
* Makefile.in (HFILES_NO_SRCDIR): Add target/target.h.
* target.h: Include target/target.h.
(target_read_memory, target_write_memory): Don't declare.
* target.c (target_read_uint32): New function.
* common/agent.c: Include target/target.h.
[!GDBSERVER]: Don't include target.h.
(helper_thread_id): Type changed to uint32_t.
(agent_get_helper_thread_id): Use target_read_uint32.
(agent_run_command): Always use target_read_memory and
target_write_memory.
(agent_capability): Type changed to uint32_t.
(agent_capability_check): Use target_read_uint32.

gdb/gdbserver/ChangeLog:

* target.h: Include target/target.h.
* target.c (target_read_memory, target_read_uint32)
(target_write_memory): New functions.

Introduce show_debug_regs

This commit adds a new global flag show_debug_regs to common-debug.h
to replace the flag debug_hw_points used by gdbserver and by the
Linux x86 and AArch64 ports, and to replace the flag maint_show_dr
used by the Linux MIPS port.

Note that some debug printing in the AArch64 port was enabled only if
debug_hw_points > 1 but no way to set debug_hw_points to values other
than 0 and 1 was provided; that code was effectively dead.  This
commit enables all debug printing if show_debug_regs is nonzero, so
the AArch64 output will be more verbose than previously.

gdb/ChangeLog:

* common/common-debug.h (show_debug_regs): Declare.
* common/common-debug.c (show_debug_regs): Define.
* aarch64-linux-nat.c (debug_hw_points): Don't define.  Replace
all uses with show_debug_regs.  Replace all uses that considered
debug_hw_points as a multi-value integer with straight boolean
uses.
* x86-nat.c (debug_hw_points): Don't define.  Replace all uses
with show_debug_regs.
* nat/x86-dregs.c (debug_hw_points): Don't declare.  Replace
all uses with show_debug_regs.
* mips-linux-nat.c (maint_show_dr): Don't define.  Replace all
uses with show_debug_regs.

gdb/gdbserver/ChangeLog:

* server.h (debug_hw_points): Don't declare.
* server.c (debug_hw_points): Don't define.  Replace all uses
with show_debug_regs.
* linux-aarch64-low.c (debug_hw_points): Don't define.  Replace
all uses with show_debug_regs.

Fix gdb.fortran/array-element.exp failures.

This fixes two FAIL results on this testcase which were caused by a
misplaced "continue" command.  This testcase used to end inferior's
execution too soon, causing the following tests to fail.  Now we break
right after inferior's loop and perform the rest of the tests there.

gdb/testsuite/ChangeLog:

* gdb.fortran/array-element.exp: Remove unexpected "continue"
command in testcase.  Simplify testcase.

daily update

Support gdbarch_convert_register_p targets in address_from_register

Since the last change to address_from_register, it no longer supports
targets that require a special conversion (gdbarch_convert_register_p)
for plain pointer type; I had assumed no target does so.

This turned out to be incorrect: MIPS64 n32 big-endian needs such a
conversion in order to properly sign-extend pointer values.

This patch fixes this regression by handling targets that need a
special conversion in address_from_register as well.

gdb/ChangeLog:

* findvar.c (address_from_register): Handle targets requiring
a special conversion routine even for plain pointer types.

Properly handle suffix for iret and sysret

gas/testsuite/

* gas/i386/i386.exp: Run suffix-intel, x86-64-suffix and
x86-64-suffix-intel.

* gas/i386/suffix.s: Add tests for iret and sysret.
* gas/i386/suffix.d: Updated.

* gas/i386/suffix-intel.d: New file.
* gas/i386/x86-64-suffix-intel.d: Likewise.
* gas/i386/x86-64-suffix.d: Likewise.
* gas/i386/x86-64-suffix.s: Likewise.

opcodes/

* i386-dis.c (dis386): Replace "P" with "%LP" for iret and sysret.
(putop): Handle "%LP".

Move ELF section headers to end of object file

Currently, section ordering differs a little for non-loaded reloc
sections output by ld -emit-relocs or ld -r and that after passing
such objects through objcopy.  Not that it really matters, but it
would be better for a simple objcopy to produce an unchanged output
object file.  Also, section headers are put somewhere in the middle of
the non-loaded sections, again slightly differently for ld and
objcopy.  This patch fixes these discrepancies and puts section
headers last, which is where gold puts them, and is where
bfd_from_remote_memory wrongly assumed they will be found.

bfd/
* elf.c (assign_file_positions_except_relocs): Move section header
placement to..
(_bfd_elf_assign_file_positions_for_relocs): ..here.  Make static.
* elf-bfd.h (_bfd_elf_assign_file_positions_for_relocs): Delete.
* elflink.c (bfd_elf_final_link): Don't call above function.
gas/testsuite/
* gas/arm/got_prel.d: Adjust for changed section header placement.
* gas/i386/ilp32/x86-64-size-1.d: Likewise.
* gas/i386/ilp32/x86-64-size-3.d: Likewise.
* gas/i386/ilp32/x86-64-size-5.d: Likewise.
* gas/i386/ilp32/x86-64-unwind.d: Likewise.
* gas/i386/size-1.d: Likewise.
* gas/i386/size-3.d: Likewise.
* gas/i386/x86-64-size-1.d: Likewise.
* gas/i386/x86-64-size-3.d: Likewise.
* gas/i386/x86-64-size-5.d: Likewise.
* gas/i386/x86-64-unwind.d: Likewise.
* gas/ia64/alias-ilp32.d: Likewise.
* gas/ia64/alias.d: Likewise.
* gas/ia64/group-1.d: Likewise.
* gas/ia64/group-2.d: Likewise.
* gas/ia64/secname-ilp32.d: Likewise.
* gas/ia64/secname.d: Likewise.
* gas/ia64/unwind-ilp32.d: Likewise.
* gas/ia64/unwind.d: Likewise.
* gas/mmix/bspec-1.d: Likewise.
* gas/mmix/bspec-2.d: Likewise.
* gas/mmix/byte-1.d: Likewise.
* gas/mmix/loc-1.d: Likewise.
* gas/mmix/loc-2.d: Likewise.
* gas/mmix/loc-3.d: Likewise.
* gas/mmix/loc-4.d: Likewise.
* gas/mmix/loc-5.d: Likewise.
* gas/tic6x/scomm-directive-4.d: Likewise.
ld/testsuite/
* ld-aarch64/emit-relocs-local-addend.d: Adjust for changed
section header placement.
* ld-aarch64/local-addend-r.d: Likewise.
* ld-mmix/bspec1.d: Likewise.
* ld-mmix/bspec2.d: Likewise.
* ld-mmix/local1.d: Likewise.
* ld-mmix/local3.d: Likewise.
* ld-mmix/local5.d: Likewise.
* ld-mmix/local7.d: Likewise.
* ld-mmix/undef-3.d: Likewise.
* ld-sh/sh64/crange3-cmpct.rd: Likewise.
* ld-sh/sh64/crange3-media.rd: Likewise.
* ld-sh/sh64/crangerel1.rd: Likewise.
* ld-sh/sh64/crangerel2.rd: Likewise.
* ld-tic6x/common.d: Likewise.
* ld-tic6x/shlib-1.rd: Likewise.
* ld-tic6x/shlib-1b.rd: Likewise.
* ld-tic6x/shlib-1r.rd: Likewise.
* ld-tic6x/shlib-1rb.rd: Likewise.
* ld-tic6x/shlib-app-1.rd: Likewise.
* ld-tic6x/shlib-app-1b.rd: Likewise.
* ld-tic6x/shlib-app-1r.rd: Likewise.
* ld-tic6x/shlib-app-1rb.rd: Likewise.
* ld-tic6x/shlib-noindex.rd: Likewise.
* ld-tic6x/static-app-1.rd: Likewise.
* ld-tic6x/static-app-1b.rd: Likewise.
* ld-tic6x/static-app-1r.rd: Likewise.
* ld-tic6x/static-app-1rb.rd: Likewise.
* ld-x86-64/ilp32-4.d: Likewise.
* ld-x86-64/split-by-file-nacl.rd: Likewise.
* ld-x86-64/split-by-file.rd: Likewise.

AIX: Remove exec_one_dummy_insn hack

Old AIX versions required GDB to update the stack pointer register and
execute at least one instruction before accessing the space newly allocated
on the user stack.  This was done using the exec_one_dummy_insn routine
in rs6000-nat.c

However, in currently supported AIX versions (tested on AIX 6.1), this hack
is no longer necessary.  In fact, removing the hack actually fixed several
test case failures, and removes a call to deprecated_insert_raw_breakpoint.

gdb/ChangeLog:

* rs6000-nat.c (exec_one_dummy_insn): Remove.
(store_register): Do not call exec_one_dummy_insn.

dynarr-ptr.exp: Add ptype tests.

This patch adds a number of "ptype" tests to gdb.dwarf2/dynarr-ptr.exp.

gdb/testsuite/ChangeLog:

        * gdb.dwarf2/dynarr-ptr.exp: Add a few ptype tests.

Ada: Print bounds/length of pointer to array with dynamic bounds

Trying to print the bounds or the length of a pointer to an array
whose bounds are dynamic results in the following error:

    (gdb) p foo.three_ptr.all'first
    Location address is not set.
    (gdb) p foo.three_ptr.all'length
    Location address is not set.

This is because, after having dereferenced our array pointer, we
use the type of the resulting array value, instead of the enclosing
type.  The former is the original type where the bounds are unresolved,
whereas we need to get the actual array bounds.

Similarly, trying to apply those attributes to the array pointer
directly (without explicitly dereferencing it with the '.all'
operator) yields the same kind of error:

    (gdb) p foo.three_ptr'first
    Location address is not set.
    (gdb) p foo.three_ptr'length
    Location address is not set.

This is caused by the fact that the dereference was done implicitly
in this case, and perform at the type level only, which is not
sufficient in order to resolve the array type.

This patch fixes both issues, thus allowing us to get the expected output:

    (gdb) p foo.three_ptr.all'first
    $1 = 1
    (gdb) p foo.three_ptr.all'length
    $2 = 3
    (gdb) p foo.three_ptr'first
    $3 = 1
    (gdb) p foo.three_ptr'length
    $4 = 3

gdb/ChangeLog:

        * ada-lang.c (ada_array_bound): If ARR is a TYPE_CODE_PTR,
        dereference it first.  Use value_enclosing_type instead of
        value_type.
        (ada_array_length): Likewise.

gdb/testsuite/ChangeLog:

        * gdb.dwarf2/dynarr-ptr.exp: Add 'first, 'last and 'length tests.

Ada subscripting of pointer to array with dynamic bounds

Consider a pointer to an array which dynamic bounds, described in
DWARF as follow:

        <1><25>: Abbrev Number: 4 (DW_TAG_array_type)
           <26>   DW_AT_name        : foo__array_type
        [...]
        <2><3b>: Abbrev Number: 5 (DW_TAG_subrange_type)
           [...]
           <40>   DW_AT_lower_bound : 5 byte block: 97 38 1c 94 4
                  (DW_OP_push_object_address; DW_OP_lit8; DW_OP_minus;
                   DW_OP_deref_size: 4)
           <46>   DW_AT_upper_bound : 5 byte block: 97 34 1c 94 4
                  (DW_OP_push_object_address; DW_OP_lit4; DW_OP_minus;
                   DW_OP_deref_size: 4)

GDB is now able to correctly print the entire array, but not one
element of the array. Eg:

    (gdb) p foo.three_ptr.all
    $1 = (1, 2, 3)
    (gdb) p foo.three_ptr.all(1)
    Cannot access memory at address 0xfffffffff4123a0c

The problem occurs because we are missing a dynamic resolution of
the variable's array type when subscripting the array. What the current
code does is "fix"-ing the array type using the GNAT encodings, but
that operation ignores any of the array's dynamic properties.

This patch fixes the issue by using ada_value_ind to dereference
the array pointer, which takes care of the array type resolution.
It also continues to "fix" arrays described using GNAT encodings,
so backwards compatibility is preserved.

gdb/ChangeLog:

        * ada-lang.c (ada_value_ptr_subscript): Remove parameter "type".
        Adjust function implementation and documentation accordingly.
        (ada_evaluate_subexp) <OP_FUNCALL>: Only assign "type" if
        NOSIDE is EVAL_AVOID_SIDE_EFFECTS.
        Update call to ada_value_ptr_subscript.

gdb/testsuite/ChangeLog:

        * gdb.dwarf2/dynarr-ptr.exp: Add subscripting tests.

print PTR.all where PTR is an Ada thin pointer

Consider the following declaration:

   type Array_Type is array (Natural range <>) of Integer;
   type Array_Ptr is access all Array_Type;
   for Array_Ptr'Size use 64;
   Three_Ptr : Array_Ptr := new Array_Type'(1 => 1, 2 => 2, 3 => 3);

This creates a pointer to an array where the bounds are stored
in a memory region just before the array itself (aka a "thin pointer").
In DWARF, this is described as a the usual pointer type to an array
whose subrange has dynamic values for its bounds:

    <1><25>: Abbrev Number: 4 (DW_TAG_array_type)
       <26>   DW_AT_name        : foo__array_type
    [...]
    <2><3b>: Abbrev Number: 5 (DW_TAG_subrange_type)
       [...]
       <40>   DW_AT_lower_bound : 5 byte block: 97 38 1c 94 4
              (DW_OP_push_object_address; DW_OP_lit8; DW_OP_minus;
               DW_OP_deref_size: 4)
       <46>   DW_AT_upper_bound : 5 byte block: 97 34 1c 94 4
              (DW_OP_push_object_address; DW_OP_lit4; DW_OP_minus;
               DW_OP_deref_size: 4)

GDB is currently printing the value of the array incorrectly:

    (gdb) p foo.three_ptr.all
    $1 = (26629472 => 1, 2,
    value.c:819: internal-error: value_contents_bits_eq: [...]

The dereferencing (".all" operator) is done by calling ada_value_ind,
which itself calls value_ind. It first produces a new value where
the bounds of the array were correctly resolved to their actual value,
but then calls readjust_indirect_value_type which replaces the resolved
type by the original type.

The problem starts when ada_value_print does not take this situation
into account, and starts using the type of the resulting value, which
has unresolved array bounds, instead of using the value's enclosing
type.

After fixing this issue, the debugger now correctly prints:

    (gdb) p foo.three_ptr.all
    $1 = (1, 2, 3)

gdb/ChangeLog:

        * ada-valprint.c (ada_value_print): Use VAL's enclosing type
        instead of VAL's type.

gdb/testsuite/ChangeLog:

        * gdb.dwarf2/dynarr-ptr.c: New file.
        * gdb.dwarf2/dynarr-ptr.exp: New file.

Add <sys/uio.h> #include back in amd64-linux-nat.c.

This include is needed to access the definition of "struct iovec".

gdb/ChangeLog:

        * amd64-linux-nat.c: Add <sys/uio.h> #include.

PR guile/17367

gdb/ChangeLog:

* acinclude.m4 (GDB_GUILE_PROGRAM_NAMES): Pass guile version as
last parameter to pkg-config, not first.
* configure.ac: Pass --with-guile provided pkg-config path to
GDB_GUILE_PROGRAM_NAMES.
* configure: Regenerate.

Add myself as write-after-approval GDB maintainer.

gdb/ChangeLog:

* MAINTAINERS (Write After Approval): Add "Gabriel Krisman
Bertazi".

Disable gdb for nds32*-*-* until it is supported.

daily update

MIPS: Don't infer IRIX OS ABI from generic section names

There are `.MIPS.abiflags', `.MIPS.options' and `.MIPS.stubs' sections
also present in Linux executables, so we can't infer IRIX OS ABI solely
from the existence of these sections.  This is not going to be a problem
as there are bound to be other sections whose names start with `.MIPS.'
in IRIX executables and this selection only matters for a non-default OS
ABI in a multiple-target GDB executable.  As a last resort the automatic
selection can be overridden with `set osabi'.

* mips-irix-tdep.c (mips_irix_elf_osabi_sniff_abi_tag_sections):
Exclude `.MIPS.abiflags', `.MIPS.options' and `.MIPS.stubs' from
the list of sections determining GDB_OSABI_IRIX.

Add myself as write-after-approval GDB maintainer

gdb/ChangeLog:

* MAINTAINERS (Write After Approval): Add "James Hogan".

GDB/testsuite: Correct gdb.base/watchpoint-solib.exp timeout tweak

Similarly to the previous changes to gdb.reverse/sigall-reverse.exp and
gdb.reverse/until-precsave.exp this corrects the timeout tweak in
gdb.base/watchpoint-solib.exp.

This test case executes a large amount of code with a software watchpoint
enabled.  This means single-stepping all the way through and takes a lot
of time, e.g. for an ARMv7 Panda board and a `-march=armv5te' multilib:

PASS: gdb.base/watchpoint-solib.exp: continue to foo again
elapsed: 714

for the same board and a `-mthumb -march=armv5te' multilib:

PASS: gdb.base/watchpoint-solib.exp: continue to foo again
elapsed: 1275

and for QEMU in the system emulation mode and a `-march=armv4t'
multilib:

PASS: gdb.base/watchpoint-solib.exp: continue to foo again
elapsed: 115

(values in seconds) -- all of which having the default timeout of 60s,
set based on the requirement of the remaining test cases (other than
gdb.reverse ones).

Here again the timeout extension to have a meaning should be calculated
by scaling rather than using an arbitrary constant, and a larger factor
of 30 will do, leaving some margin.  Hopefully for everyone or otherwise
we'll probably have to come up with a smarter solution.

OTOH the other test cases in this script do not require the extension so
they can be moved outside its umbrella so as to avoid unnecessary delays
if something goes wrong and a genuine timeout triggers.

* gdb.base/watchpoint-solib.exp: Increase the timeout by a factor
of 30 rather than hardcoding 120 for a slow test case.  Take the
`gdb,timeout' target setting into account for this calculation.
Don't extend the timeout for the test cases that don't need it.

GDB/testsuite: Add/correct gdb.reverse timeout tweaks

There are three cases in two scripts in the gdb.reverse subset that
take a particularly long time.  Two of them are already attempted to
take care of by extending the timeout from the default.  The remaining
one has no precautions taken.  The timeout extension is ineffective
though, it is done by adding a constant rather than by scaling and as
a result while it may work for target boards that get satisfied with
the detault test timeout of 10s, it does not serve its purpose for
slower ones.

Here are indicative samples of execution times (in seconds) observed
for these cases respectively, for an ARMv7 Panda board running Linux
and a `-march=armv5te' multilib:

PASS: gdb.reverse/sigall-reverse.exp: continue to signal exit
elapsed: 385
PASS: gdb.reverse/until-precsave.exp: run to end of main
elapsed: 4440
PASS: gdb.reverse/until-precsave.exp: save process recfile
elapsed: 965

for the same board and a `-mthumb -march=armv5te' multilib:

PASS: gdb.reverse/sigall-reverse.exp: continue to signal exit
elapsed: 465
PASS: gdb.reverse/until-precsave.exp: run to end of main
elapsed: 4191
PASS: gdb.reverse/until-precsave.exp: save process recfile
elapsed: 669

and for QEMU in the system emulation mode and a `-march=armv4t'
multilib:

PASS: gdb.reverse/sigall-reverse.exp: continue to signal exit
elapsed: 45
PASS: gdb.reverse/until-precsave.exp: run to end of main
elapsed: 433
PASS: gdb.reverse/until-precsave.exp: save process recfile
elapsed: 104

Based on the performance of other tests these two test configurations
have their default timeout set to 450s and 60s respectively.

The remaining two multilibs (`-mthumb -march=armv4t' and `-mthumb
-march=armv7-a') do not produce test results usable enough to have data
available for these cases.

 Based on these results I have tweaked timeouts for these cases as
follows.  This, together with a suitable board timeout setting, removes
timeouts for these cases.  Note that for the default timeout of 10s the
new setting for the first case in gdb.reverse/until-precsave.exp is
compatible with the old one, just a bit higher to keep the convention
of longer timeouts to remain multiples of 30s.  The second case there
does not need such a high setting so I have lowered it a bit to avoid
an unnecessary delay where this test case genuinely times out.

* gdb.reverse/sigall-reverse.exp: Increase the timeout by
a factor of 2 for a slow test case.  Take the `gdb,timeout'
target setting into account for this calculation.
* gdb.reverse/until-precsave.exp: Increase the timeout by
a factor of 15 and 3 respectively rather than adding 120
for a pair of slow test cases.  Take the `gdb,timeout'
target setting into account for this calculation.

GDB/testsuite: Avoid timeout lowering

The recent change to introduce `gdb_reverse_timeout' turned out
ineffective for board setups that set the `gdb,timeout' target variable.
A lower `gdb,timeout' setting takes precedence and defeats the effect of
`gdb_reverse_timeout'.  This is because the global timeout is overridden
in gdb_test_multiple and then again in gdb_expect.

Three timeout variables are taken into account in these two places, in
this precedence:

1. The `gdb,timeout' target variable.

2. The caller's local `timeout' variable (upvar timeout)

3. The global `timeout' variable.

This precedence is obeyed by gdb_test_multiple strictly.  OTOH
gdb_expect will select the higher of the two formers and will only take
the latter into account if none of the formers is present.  However the
two timeout selections are conceptually the same and gdb_test_multiple
does its only for the purpose of passing it down to gdb_expect.

Therefore I decided there is no point to keep carrying on this
duplication and removed the sequence from gdb_test_multiple, however
retaining the `upvar timeout' variable definition.  This way gdb_expect
will still access gdb_test_multiple's caller `timeout' variable (if any)
via its own `upvar timeout' reference.

Now as to the sequence in gdb_expect.  In addition to the three
variables described above it also takes a timeout argument into account,
as the fourth value to choose from.  It is currently used if it is
higher than the timeout selected from the variables as described above.

With the timeout selection code from gdb_test_multiple gone, gone is
also the most prominent use of this timeout argument, it's now used in
a couple of places only, mostly within this test framework library code
itself for preparatory commands or suchlike.  With this being the case
this timeout selection code can be simplified as follows:

1. Among the three timeout variables, the highest is always chosen.
   This is so that a test case doesn't inadvertently lower a high value
   timeout needed by slow target boards.  This is what all test cases
   use.

2. Any timeout argument takes precedence.  This is for special cases
   such as within the framework library code, e.g. it doesn't make sense
   to send `set height 0' with a timeout of 7200 seconds.  This is a
   local command that does not interact with the target and setting a
   high timeout here only risks a test suite run taking ages if it goes
   astray for some reason.

3. The fallback timeout of 60s remains.

* lib/gdb.exp (gdb_test_multiple): Remove code to select the
timeout, don't pass one down to gdb_expect.
(gdb_expect): Rework timeout selection.

Remove trad_frame_set_reg_unknown declaration

The trad_frame_set_reg_unknown declaration was added in commit
0db9b4b70969 (March 2004), but apparently never defined or referenced.

gdb/ChangeLog:

* trad-frame.h (trad_frame_set_reg_unknown): Remove declaration.

gdbserver-support: Handle gdbserver start failures

As it happens we have a board that fails a gdb.base/gcore-relro.exp
test case reproducibly and moreover the case appears to trigger a
kernel bug making the it less than usable.  Specifically the board
remains responsive to some extent, however processes do not appear
to be able to successfully complete termination anymore and perhaps
more importantly further gdbserver processes can be started, but they
never reach the stage of listening on the RSP socket.

This change handles timeouts in gdbserver start properly, by throwing
a TCL error exception when gdbserver does not report listening on the
RSP socket in time.  This is then caught at the outer level and
reported, and 2 rather than 1 is returned so that the caller may tell
the failure to start gdbserver and other issues apart and act
accordingly (or do nothing).

I thought letting the exception unwind further on might be a good idea
for any test harnesses out there to break outright where a gdbserver
start error is silently ignored right now, however I figured out the
calls to gdbserver-support.exp are buried down too deep in the GDB test
suite for such a change to be made easily.  I think returning a distinct
return value is good enough (the API says "non-zero", so 2 is as good as
1) and we can always make the error harder in a later step if required.

With config/gdbserver.exp being used this change remains transparent
to the target board, the return value is passed up by gdb_reload and
the error exception unwinds through gdbserver_gdb_load and is caught
and handled by mi_gdb_target_load.  A call to perror is still made,
reporting the timeout, and in the case of mi_gdb_target_load the
procedure returns a value denoting unsuccessful completion.  An
unsuccessful completion of gdb_reload is already handled elsewhere.

An alternative gdbserver board configuration can interpret the return
value in its gdb_reload implementation and catch the error in
gdbserver_gdb_load in an attempt to recover a target board that has
gone astray, for example by rebooting the board somehow.  This has
proved effective with our failing board, that now completes the
remaining test cases with no further hiccups.

* lib/gdbserver-support.exp (gdbserver_start): Throw an error
exception on timeout.
(gdbserver_run): Catch any `gdbserver_spawn' error exceptions.
(gdbserver_start_extended): Catch any `gdbserver_start' error
exceptions.
(gdbserver_start_multi, mi_gdbserver_start_multi): Likewise.
* lib/mi-support.exp (mi_gdb_target_load): Catch any
`gdbserver_gdb_load' error exceptions.

GDB/testsuite: Extend the time gdbserver is waited for

Gdbserver support code uses the global timeout value to determine when
to stop waiting for a gdbserver process being started to respond before
continuing anyway.  This timeout is usually as low as 10s and may not
be enough in this context, for example on the first run where the
filesystem cache is cold, even if it is elsewhere.

E.g. I observe this reliably with gdbserver started the first time in
QEMU running in the system emulation mode:

(gdb) file .../gdb.base/advance
Reading symbols from .../gdb.base/advance...done.
(gdb) delete breakpoints
(gdb) info breakpoints
No breakpoints or watchpoints.
(gdb) break main
Breakpoint 1 at 0x87f8: file .../gdb.base/advance.c,
line 41.
(gdb) set remotetimeout 15
(gdb) kill
The program is not being run.
(gdb)
[...]
.../bin/gdbserver --once :6014 advance
target remote localhost:6014
Remote debugging using localhost:6014
Remote communication error.  Target disconnected.: Connection reset by peer.
(gdb) continue
The program is not being run.
(gdb) Process advance created; pid = 999
Listening on port 6014
FAIL: gdb.base/advance.exp: Can't run to main

-- notice how the test harness proceeded with the `target remote ...'
command even though gdbserver hasn't completed its startup yet.  A
while later when it's finally ready it's too late already.  I checked
the timing here and it takes gdbserver roughly 25 seconds to start in
this scenario.  Subsequent gdbserver starts in the same test run take
less time and usually complete within 10 seconds although occasionally
`target remote ...' precedes the corresponding `Listening on port...'
message again.

Therefore I have fixed this problem by setting an explicit timeout to
120s on the expect call in question.  If this turns out too arbitrary
sometime, then perhaps a separate `gdbserver_timeout' setting might be
due.

* lib/gdbserver-support.exp (gdbserver_start): Set timeout to
120 on waiting for the TCP socket to open.

Fix missing "struct iovec" definition on some x86-linux.

The following patch...

    commit 3116063bd617de56fbc3bad046a692b1fb363a9d
    Date:   Fri Jun 27 09:52:29 2014 +0100
    Subject: Tidy #include lists

... introduced a build failure on certain x86 GNU/Linux distributions
(reproduced on SuSE 10 and RHES4) due to "struct iovec" not being
defined. This struct is defined in <sys/uio.h>, which used to be
explicitly included, but no longer is after the commit above was
applied.

    [...]/i386-linux-nat.c: In function 'fetch_xstateregs':
    [...]/i386-linux-nat.c:325:16: error: storage size of 'iov' isn't known
    [...]/i386-linux-nat.c: In function 'store_xstateregs':
    [...]/i386-linux-nat.c:348:16: error: storage size of 'iov' isn't known
    make[2]: *** [i386-linux-nat.o] Error 1

It seems to be working on newer GNU/Linux distros thanks to indirect
inclusion of <sys/uio.h>, but it does not work on some other versions
of the same distros. This is why indirect includes of public APIs
should be avoided if at all possible.

This patch fixes the issue by adding the explicit include back.

gdb/ChangeLog:

        * i386-linux-nat.c, x86-linux-nat.c: Add <sys/uio.h> #include.

[PATCH][ARM] Add Cortex-A17 support to gas

     * config/tc-arm.c (arm_cpus): Add cortex-a17.

Fix regression in default.exp caused by _caller_is, etc.

gdb/testsuite/ChangeLog:

* gdb.base/default.exp (show_conv_list): Add _caller_is,
_caller_matches, _any_caller_is, _any_caller_matches.

Fix for PR 17247: Block SIGCHLD while initializing Guile.

The problem here is that if a thread other than gdb's main thread
gets a SIGCHLD (it's an asynchronous signal so the kernel will
essentially pick a random thread) then gdb will hang if it is
in sigsuspend when the SIGCHLD is delivered.  The other thread
will see the signal and the sigsuspend won't "wake up".

Guile and libgc should be blocking SIGCHLD in their threads,
but we need to work with Guile 2.0 and libgc 7.4.
The problem first shows up in libgc 7.4 because it is the first
release that enables multiple marker threads by default.

gdb/ChangeLog:

PR 17247
* guile.c: #include <signal.h>.
(_initialize_guile): Block SIGCHLD while initializing Guile.

Replaces the following, which is reverted.

2014-07-26  Doug Evans  <xdje42@gmail.com>

PR 17185
* configure.ac: Add check for header gc/gc.h.
Add check for function setenv.
* configure: Regenerate.
* config.in: Regenerate.
* guile/guile.c (_initialize_guile): Add workaround for libgc 7.4.0.

gdb.guile/scm-error.exp: Handle guile 2.2 backtrace output.

gdb/testsuite/ChangeLog:

* gdb.guile/scm-error.exp: Handle guile 2.2 backtrace output.

Replace use of magic number with named constant.

gdb/ChangeLog:

* guile/scm-cmd.c (gdbscm_parse_command_name): Replace magic number
with named constant.  Fix style of pointer comparison.
* python/py-cmd.c (gdbpy_parse_command_name): Ditto.

Set print symbol off in mi-var-display.exp

Hi,
I see the following fail on arm-none-eabi target,

-var-evaluate-expression -f nat foo^M
^done,value="0x3 <_ftext+2>"^M
(gdb) ^M
FAIL: gdb.mi/mi-var-display.exp: eval variable -f nat foo

the "<_ftext+2>" isn't expected in the test, so "set print symbol off"
can prevent printing it.  It is obvious and I'll commit it in three
days if no comments.

gdb/testsuite:

2014-09-09  Yao Qi  <yao@codesourcery.com>

* gdb.mi/mi-var-display.exp: Set print symbol off.

daily update

Change pe/coff build-id section name to '.buildid'

The section name used to store the build-id on pe/coff is arbitrary, as it's
contents should be located using the pe/coff header's DataDirectory debug data
entry, not by using the section name.

But '.build-id' is not a good choice for that section name, as it is 9
characters long, and hence truncated to 8 characters when
--disable-long-section-names is used (which is the default, when producing an
executable with no dwarf debug sections, e.g. using ld --strip-all --build-id)

This truncation then breaks 'objcopy --only-keep-debug', which does use the
section name, due to concerns that keeping an arbitrary section which contains
the debug directory is not sensible.

binutils/ChangeLog

2014-09-01  Jon TURNEY  <jon.turney@dronecode.org.uk>

* objcopy.c (is_nondebug_keep_contents_section): Change pe/coff
build-id section name from '.build-id' to '.buildid'.

ld/ChangeLog

2014-09-01  Jon TURNEY  <jon.turney@dronecode.org.uk>

* emultempl/pe.em (write_build_id, setup_build_id): Change pe/coff
build-id section name from '.build-id' to '.buildid'.
* emultempl/pep.em (write_build_id, setup_build_id): Ditto.

Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>

Fix ppc_collect/supply_ptrace_register() routines

This patch fixes the routines to collect and supply ptrace registers on ppc64le
gdbserver. Originally written for big endian arch, they were causing several
issues on little endian. With this fix, the number of unexpected failures in
the testsuite dropped from 263 to 72 on ppc64le.

gdb/gdbserver/ChangeLog

* linux-ppc-low.c (ppc_collect_ptrace_register): Adjust routine to take
endianness into account.
(ppc_supply_ptrace_register): Likewise.

daily update

Fix PR gdb/17035: "show user" doesn't list user-defined commands that
have empty bodies.

User-defined commands that have empty bodies weren't being shown because
the print function returned too soon.  Now, it prints the command's name
before checking if it has any body at all.  This also fixes the same
problem on "show user <myemptycommand>", which wasn't being printed due
to a similar reason.

gdb/Changelog:

* cli/cli-cmds.c (show_user): Use cli_user_command_p to
decide whether we display the command on "show user".
* cli/cli-script.c (show_user_1): Only verify cmdlines after
printing command name.
* cli/cli-decode.h (cli_user_command_p): Declare new function.
* cli/cli-decode.c (cli_user_command_p): Create helper function
to verify whether cmd_list_element is a user-defined command.

gdb/testsuite/Changelog:

* gdb.base/commands.exp: Add tests to verify user-defined
commands with empty bodies.
* gdb.python/py-cmd.exp: Test that we don't show user-defined
python commands in `show user command`.
* gdb.python/scm-cmd.exp: Test that we don't show user-defined
scheme commands in `show user command`.

Fix crash on Python frame filters with unreadable arg

https://bugzilla.redhat.com/show_bug.cgi?id=1126177

ERROR: AddressSanitizer: SEGV on unknown address 0x000000000050 (pc 0x000000992bef sp 0x7ffff9039530 bp 0x7ffff9039540
T0)
    #0 0x992bee in value_type .../gdb/value.c:925
    #1 0x87c951 in py_print_single_arg python/py-framefilter.c:445
    #2 0x87cfae in enumerate_args python/py-framefilter.c:596
    #3 0x87e0b0 in py_print_args python/py-framefilter.c:968

It crashes because frame_arg::val is documented it may contain NULL
(frame_arg::error is then non-NULL) but the code does not handle it.

Another bug is that py_print_single_arg() calls goto out of its TRY_CATCH
which messes up GDB cleanup chain crashing GDB later.

It is probably 7.7 regression (I have not verified it) due to the introduction
of Python frame filters.

gdb/ChangeLog

PR python/17355
* python/py-framefilter.c (py_print_single_arg): Handle NULL FA->VAL.
Fix goto out of TRY_CATCH.

gdb/testsuite/ChangeLog

PR python/17355
* gdb.python/amd64-py-framefilter-invalidarg.S: New file.
* gdb.python/py-framefilter-invalidarg-gdb.py.in: New file.
* gdb.python/py-framefilter-invalidarg.exp: New file.
* gdb.python/py-framefilter-invalidarg.py: New file.

daily update

MIPS testsuite cleanup - part 4

ld/testsuite/

* ld-mips-elf/abiflags-strip1-ph.d: Ignore big/little endian
differences. Ignore program headers other than PT_MIPS_ABIFLAGS.
Do not force -32, -EB and ld emulation but instead rely on the
test driver to build for some form of O32.
* ld-mips-elf/abiflags-strip2-ph.d: Likewise.
* ld-mips-elf/abiflags-strip3-ph.d: Likewise.
* ld-mips-elf/abiflags-strip4-ph.d: Likewise.
* ld-mips-elf/abiflags-strip5-ph.d: Likewise.
* ld-mips-elf/abiflags-strip6-ph.d: Likewise.
* ld-mips-elf/abiflags-strip7-ph.d: Likewise.
* ld-mips-elf/abiflags-strip8-ph.d: Likewise.
* ld-mips-elf/abiflags-strip9-ph.d: Likewise.
* ld-mips-elf/attr-gnu-4-0-ph.d: Likewise.
* ld-mips-elf/attr-gnu-4-05.d: Likewise.
* ld-mips-elf/attr-gnu-4-06.d: Likewise.
* ld-mips-elf/attr-gnu-4-07.d: Likewise.
* ld-mips-elf/attr-gnu-4-1-ph.d: Likewise.
* ld-mips-elf/attr-gnu-4-10.d: Likewise.
* ld-mips-elf/attr-gnu-4-15.d: Likewise.
* ld-mips-elf/attr-gnu-4-16.d: Likewise.
* ld-mips-elf/attr-gnu-4-17.d: Likewise.
* ld-mips-elf/attr-gnu-4-2-ph.d: Likewise.
* ld-mips-elf/attr-gnu-4-25.d: Likewise.
* ld-mips-elf/attr-gnu-4-26.d: Likewise.
* ld-mips-elf/attr-gnu-4-27.d: Likewise.
* ld-mips-elf/attr-gnu-4-3-ph.d: Likewise.
* ld-mips-elf/attr-gnu-4-35.d: Likewise.
* ld-mips-elf/attr-gnu-4-36.d: Likewise.
* ld-mips-elf/attr-gnu-4-37.d: Likewise.
* ld-mips-elf/attr-gnu-4-4-ph.d: Likewise.
* ld-mips-elf/attr-gnu-4-45.d: Likewise.
* ld-mips-elf/attr-gnu-4-46.d: Likewise.
* ld-mips-elf/attr-gnu-4-47.d: Likewise.
* ld-mips-elf/attr-gnu-4-5-ph.d: Likewise.
* ld-mips-elf/attr-gnu-4-50.d: Likewise.
* ld-mips-elf/attr-gnu-4-51.d: Likewise.
* ld-mips-elf/attr-gnu-4-52.d: Likewise.
* ld-mips-elf/attr-gnu-4-53.d: Likewise.
* ld-mips-elf/attr-gnu-4-54.d: Likewise.
* ld-mips-elf/attr-gnu-4-55.d: Likewise.
* ld-mips-elf/attr-gnu-4-56.d: Likewise.
* ld-mips-elf/attr-gnu-4-57.d: Likewise.
* ld-mips-elf/attr-gnu-4-58.d: Likewise.
* ld-mips-elf/attr-gnu-4-6-ph.d: Likewise.
* ld-mips-elf/attr-gnu-4-60.d: Likewise.
* ld-mips-elf/attr-gnu-4-61.d: Likewise.
* ld-mips-elf/attr-gnu-4-62.d: Likewise.
* ld-mips-elf/attr-gnu-4-63.d: Likewise.
* ld-mips-elf/attr-gnu-4-64.d: Likewise.
* ld-mips-elf/attr-gnu-4-65.d: Likewise.
* ld-mips-elf/attr-gnu-4-66.d: Likewise.
* ld-mips-elf/attr-gnu-4-67.d: Likewise.
* ld-mips-elf/attr-gnu-4-68.d: Likewise.
* ld-mips-elf/attr-gnu-4-7-ph.d: Likewise.
* ld-mips-elf/attr-gnu-4-70.d: Likewise.
* ld-mips-elf/attr-gnu-4-71.d: Likewise.
* ld-mips-elf/attr-gnu-4-72.d: Likewise.
* ld-mips-elf/attr-gnu-4-73.d: Likewise.
* ld-mips-elf/attr-gnu-4-74.d: Likewise.
* ld-mips-elf/attr-gnu-4-75.d: Likewise.
* ld-mips-elf/attr-gnu-4-76.d: Likewise.
* ld-mips-elf/attr-gnu-4-77.d: Likewise.
* ld-mips-elf/attr-gnu-4-78.d: Likewise.
* ld-mips-elf/mips-elf.exp: Update default abi_asflags(o32) to explicitly
pass -32 for the 'no abi' configurations.  Modify the way attr-gnu* tests
are run to use O32 flags appropriate for the current target.

MIPS testsuite cleanup - part 3

gas/testsuite/

* gas/mips/attr-gnu-abi-fp-1.d: Relax expected output.
* gas/mips/elf_ase_micromips-2.d: Likewise.
* gas/mips/elf_ase_micromips.d: Likewise.
* gas/mips/elf_ase_mips16-2.d: Likewise.
* gas/mips/elf_ase_mips16.d: Likewise.
* gas/mips/module-mfp32.d: Likewise.
* gas/mips/module-msingle-float.d: Likewise.
* gas/mips/module-msoft-float.d: Likewise.

MIPS testsuite cleanup - part 2

gas/testsuite/

* gas/mips/module-defer-warn2.l: Ignore differences in output from
64-bit vs 32-bit targets using O32.

MIPS testsuite cleanup - part 1

binutils/testsuite/

* binutils-all/readelf.ss-mips: Account for new sections.

gas/testsuite/

* gas/elf/type.e: Account for new sections.
* gas/mips/mips16-e.d: Likewise.
* gas/mips/mips16-f.d: Likewise.
* gas/mips/mipsel16-e.d: Likewise.
* gas/mips/mipsel16-f.d: Likewise.
* gas/mips/tmips16-e.d: Appropriately escape dots.
* gas/mips/tmips16-f.d: Likewise.
* gas/mips/tmipsel16-e.d: Likewise.
* gas/mips/tmipsel16-f.d: Likewise.

Add missing author to previous entry (PR 15276).

PR 15276: Add $_caller_is, $_caller_matches, $_any_caller_is, $_any_caller_matches

gdb/ChangeLog:

PR 15276
* NEWS: Mention $_caller_is, $_caller_matches, $_any_caller_is,
$_any_caller_matches.
* data-directory/Makefile.in (PYTHON_FILE_LIST): Add caller_is.py.
* python/lib/gdb/function/caller_is.py: New file.

gdb/testsuite/ChangeLog:

PR 15276
* gdb.python/py-caller-is.c: New file.
* gdb.python/py-caller-is.exp: New file.

gdb/doc/ChangeLog:

PR 15276
* gdb.texinfo (Convenience Funs): Document $_caller_is,
$_caller_matches, $_any_caller_is, $_any_caller_matches.

infcmd.c (program_info): Fix typo.

gdb/ChangeLog:

* infcmd.c (program_info): Fix typo.

daily update

Regenerate top-level configure.

Our top-level configure somehow got out of sync the current
configure.ac, so this patch regenerates it.

ChangeLog:

* configure: Regenerate.

Fix for PR gdb/17235: possible bug extracting systemtap probe operand

This patch is a fix to PR gdb/17235.  The bug is about an unused
variable that got declared and set during one of the parsing phases of
an SDT probe's argument.  I took the opportunity to rewrite some of the
code to improve the parsing.  The bug was actually a thinko, because
what I wanted to do in the code was to discard the number on the string
being parsed.

During this portion, the code identifies that it is dealing with an
expression that begins with a sign ('+', '-' or '~').  This means that
the expression could be:

- a numeric literal (e.g., '+5')
- a register displacement (e.g., '-4(%rsp)')
- a subexpression (e.g., '-(2*3)')

So, after saving the sign and moving forward 1 char, now the code needs
to know if there is a digit followed by a register displacement prefix
operand (e.g., '(' on x86_64).  If yes, then it is a register
operation.  If not, then it will be handled recursively, and the code
will later apply the requested operation on the result (either a '+', a
'-' or a '~').

With the bug, the code was correctly discarding the digit (though using
strtol unnecessarily), but it wasn't properly dealing with
subexpressions when the register indirection prefix was '(', like on
x86_64.  This patch also fixes this bug, and includes a testcase.  It
passes on x86_64 Fedora 20.

daily update

parse_number("0") reads uninitialized memory

valgrind caught that parse_number reads uninitialized memory when we
parse literal "0":

 $ valgrind ./gdb -q -nx -ex "set height 0"
 (...)
 ==10378== Conditional jump or move depends on uninitialised value(s)
 ==10378==    at 0x548A10: parse_number (c-exp.y:1828)
 ==10378==    by 0x54A340: lex_one_token (c-exp.y:2638)
 ==10378==    by 0x54B4BB: c_lex (c-exp.y:3089)
 ==10378==    by 0x544951: c_parse_internal (c-exp.c:2208)
 ==10378==    by 0x54BF8C: c_parse (c-exp.y:3260)
 ==10378==    by 0x6502E7: parse_exp_in_context_1 (parse.c:1221)
 ==10378==    by 0x650064: parse_exp_in_context (parse.c:1122)
 ==10378==    by 0x65001F: parse_exp_1 (parse.c:1114)
 ==10378==    by 0x650421: parse_expression (parse.c:1266)
 ==10378==    by 0x5A74B7: parse_and_eval_long (eval.c:92)
 ==10378==    by 0x501ABD: do_set_command (cli-setshow.c:302)
 ==10378==    by 0x721059: execute_command (top.c:452)
 ==10378==
 (gdb)

I've pushed the obvious fix.

Tested on x86_64 Fedora 20.

gdb/ChangeLog:
* c-exp.y (parse_number): Skip handling base-switching prefixes if
the input is only one character long.

Fix PR fortran/17237: bug in f-valprint.c

This commit fixes the PR mentioned in $subject.  It is about a set but
unused variable that refers to the output format of integer values
printed in Fortran.

This was probably a thinko (like most set-but-unused-vars), but it
could cause an internal error depending on the scenario.  I am sending
a testcase which triggers this error as well.

gdb/ChangeLog:
2014-09-04  Sergio Durigan Junior  <sergiodj@redhat.com>

PR fortran/17237
* f-valprint.c (f_val_print): Specify the correct print option to
use when printing integer values.

gdb/testsuite/ChangeLog:
2014-09-04  Sergio Durigan Junior  <sergiodj@redhat.com>

PR fortran/17237
* gdb.fortran/print-formatted.exp: New file.
* gdb.fortran/print-formatted.f90: Likewise.

Remove code to cope with LWPs wrapped as PIDs

Historically the Linux x86 watchpoint code did not cope with multi-
threaded processes and LWP IDs were passed to it wrapped as PIDs.
Not all entry points were converted when the Linux x86 watchpoint
code was made multi-thread-aware, so a handler was left in place to
cope with wrapped LWPs.  Since then all such entry points have been
converted to pass regular LWPs and the handler is now redundant.
This commit removes the handler and adds assertions to ensure no
wrapped LWPs are passed in future.

gdb/ChangeLog:

* x86-linux-nat.c (x86_linux_dr_get, x86_linux_dr_set):
Remove code to cope with LWPs wrapped as PIDs.
Add assertions to ensure no wrapped LWPs are passed.

Regression for i686 gdb.dwarf2/pieces-optimized-out.exp

Git 9a0dc9e3 regressed gdb.dwarf2/pieces-optimized-out.exp, visible on
i686 (the test doesn't run on x86_64):

 (gdb) p s
 -$1 = {a = 5, b = <optimized out>, c = <optimized out>, d = <optimized out>}
 +$1 = {a = 5, b = <optimized out>, c = 0, d = 0}
 -(gdb) PASS: gdb.dwarf2/pieces-optimized-out.exp: print s
 +(gdb) FAIL: gdb.dwarf2/pieces-optimized-out.exp: print s

The regression was caused by this removal in cp-valprint.c:

  @@ -293,12 +293,6 @@ cp_print_value_fields (struct type *type, struct type *real_type,
  {
    fputs_filtered (_("<synthetic pointer>"), stream);
  }
  -             else if (!value_bits_valid (val,
  -                                         TYPE_FIELD_BITPOS (type, i),
  -                                         TYPE_FIELD_BITSIZE (type, i)))
  -               {
  -                 val_print_optimized_out (val, stream);
  -               }
else
  {
    struct value_print_options opts = *options;

The idea was that we'd just fallback to calling value_field_bitfield,
which handles unavailable values (in unpack_value_bits_as_long_1) so
should be able to handle optimized out values too.  Alas, it doesn't.
This is currently a bit too messy.  Instead of teaching
unpack_value_bits_as_long_1 about optimized out bits, let's bite the
bullet and teach the value code to handle partially optimized out
bitfield, by having it unpack a bitfield and then propagate the range
metadata.  Turns out the resulting code looks simpler and clearer.

Tested on x86_64 Fedora 20, -m64/-m32.

gdb/ChangeLog:

* value.c (value_ranges_copy_adjusted): New function, factored out
from ...
(value_contents_copy_raw): ... here.
(unpack_value_bits_as_long_1): Rename back to ...
(unpack_bits_as_long): ... this.  Remove 'original_value' and
'result' parameters.  Change return type to LONGEST.
(unpack_value_bits_as_long): Delete.
(unpack_value_field_as_long_1): Delete.
(unpack_value_field_as_long, unpack_field_as_long): Reimplement.
(unpack_value_bitfield): New function.
(value_field_bitfield): Reimplement using unpack_value_bitfield.
(value_fetch_lazy): Use unpack_value_bitfield.
* value.h (unpack_value_bits_as_long): Delete declaration.

MIPS: Update the list of addr32 targets

gas/testsuite/

* gas/mips/mips.exp: Add mipsisa32 and mipsisa32el to
the list of addr32 targets.

daily update

Improve Type.template_argument docs in Python API.

gdb/doc/ChangeLog:

* python.texi (Types In Python): Type.template_argument(n) returns a
gdb.Value or a gdb.Type and throws an exception if n is out of
range.

Add support for reading frame registers to Python API.

The ability to read registers is needed to use Frame Filter API to
display the frames created by JIT compilers.

gdb/ChangeLog:

2014-08-29  Sasha Smundak  <asmundak@google.com>

* python/py-frame.c (frapy_read_register): New function.

gdb/doc/ChangeLog:

2014-08-26  Sasha Smundak  <asmundak@google.com>

* python.texi (Frames in Python): Add read_register description.

gdb/testsuite/ChangeLog:

2014-08-26  Sasha Smundak  <asmundak@google.com>

* gdb.python/py-frame.exp: Test Frame.read_register.

Reset errno before PTRACE_PEEKUSER for MIPS DSP_CONTROL

PTRACE_PEEKUSER can return -1, which is usually used to determine whether
a system call has reported an error, so errno must be used alone to
determine whether an error occurred. However errno isn't modified by a
successful system call so it must be reset to a known value (0) before the
syscall call.

Add the missing errno reset when reading the DSP_CONTROL register in the
native MIPS Linux backend and the MIPS gdbserver backend.

gdb/:
* mips-linux-nat.c (mips_linux_read_description): Reset errno to 0
prior to reading DSP_CONTROL with PTRACE_PEEKUSER ptrace call.

gdb/gdbserver/:
* linux-mips-low.c (mips_read_description): Reset errno to 0 prior
to reading DSP_CONTROL with PTRACE_PEEKUSER ptrace call.

PR python/16699: GDB Python command completion with overriden complete vs. completer class

This PR came from a Red Hat bug that was filed recently.  I checked and
it still exists on HEAD, so here's a proposed fix.  Although this is
marked as a Python backend bug, this is really about the completion
mechanism used by GDB.  Since this code reminds me of my first attempt
to make a good noodle, it took me quite some time to fix it in a
non-intrusive way.

The problem is triggered when one registers a completion method inside a
class in a Python script, rather than registering the command using a
completer class directly.  For example, consider the following script:

    class MyFirstCommand(gdb.Command):
          def __init__(self):
              gdb.Command.__init__(self,'myfirstcommand',gdb.COMMAND_USER,gdb.COMPLETE_FILENAME)

              def invoke(self,argument,from_tty):
                  raise gdb.GdbError('not implemented')

    class MySecondCommand(gdb.Command):
          def __init__(self):
              gdb.Command.__init__(self,'mysecondcommand',gdb.COMMAND_USER)

              def invoke(self,argument,from_tty):
                  raise gdb.GdbError('not implemented')

                  def complete(self,text,word):
                      return gdb.COMPLETE_FILENAME

    MyFirstCommand ()
    MySecondCommand ()

When one loads this into GDB and tries to complete filenames for both
myfirstcommand and mysecondcommand, she gets:

    (gdb) myfirstcommand /hom<TAB>
    (gdb) myfirstcommand /home/
                               ^
    ...
    (gdb) mysecondcommand /hom<TAB>
    (gdb) mysecondcommand /home
                                ^

(The "^" marks the final position of the cursor after the TAB).

So we see that myfirstcommand honors the COMPLETE_FILENAME class (as
specified in the command creation), but mysecondcommand does not.  After
some investigation, I found that the problem lies with the set of word
break characters that is used for each case.  The set should be the same
for both commands, but it is not.

During the process of deciding which type of completion should be used,
the code in gdb/completer.c:complete_line_internal analyses the command
that requested the completion and tries to determine the type of
completion wanted by checking which completion function will be called
(e.g., filename_completer for filenames, location_completer for
locations, etc.).

This all works fine for myfirstcommand, because immediately after the
command registration the Python backend already sets its completion
function to filename_completer (which then causes the
complete_line_internal function to choose the right set of word break
chars).  However, for mysecondcommand, this decision is postponed to
when the completer function is evaluated, and the Python backend uses an
internal completer (called cmdpy_completer).  complete_line_internal
doesn't know about this internal completer, and can't choose the right
set of word break chars in time, which then leads to a bad decision when
completing the "/hom" word.

So, after a few attempts, I decided to create another callback in
"struct cmd_list_element" that will be responsible for handling the case
when there is an unknown completer function for complete_line_internal
to work with.  So far, only the Python backend uses this callback, and
only when the user provides a completer method instead of registering
the command directly with a completer class.  I think this is the best
option because it not very intrusive (all the other commands will still
work normally), but especially because the whole completion code is so
messy that it would be hard to fix this without having to redesign
things.

I have regtested this on Fedora 18 x86_64, without regressions.  I also
included a testcase.

gdb/ChangeLog:
2014-09-03  Sergio Durigan Junior  <sergiodj@redhat.com>

PR python/16699
* cli/cli-decode.c (set_cmd_completer_handle_brkchars): New
function.
(add_cmd): Set "completer_handle_brkchars" to NULL.
* cli/cli-decode.h (struct cmd_list_element)
<completer_handle_brkchars>: New field.
* command.h (completer_ftype_void): New typedef.
(set_cmd_completer_handle_brkchars): New prototype.
* completer.c (set_gdb_completion_word_break_characters): New
function.
(complete_line_internal): Call "completer_handle_brkchars"
callback from command.
* completer.h: Include "command.h".
(set_gdb_completion_word_break_characters): New prototype.
* python/py-cmd.c (cmdpy_completer_helper): New function.
(cmdpy_completer_handle_brkchars): New function.
(cmdpy_completer): Adjust to use cmdpy_completer_helper.
(cmdpy_init): Set completer_handle_brkchars to
cmdpy_completer_handle_brkchars.

gdb/testsuite/ChangeLog:
2014-09-03  Sergio Durigan Junior  <sergiodj@redhat.com>

PR python/16699
* gdb.python/py-completion.exp: New file.
* gdb.python/py-completion.py: Likewise.

Add NaCl (NativeClient) specific classes Target_mips_nacl and
Target_selector_mips_nacl.

gold/
* mips.cc (Target_mips_nacl): New class.
(Target_selector_mips_nacl): New class.
(target_selector_mips32): Rename from target_selector_mips32be and use
Target_selector_mips_nacl instead of Target_selector_mips.
(target_selector_mips32el): Rename from target_selector_mips32 and use
Target_selector_mips_nacl instead of Target_selector_mips.
(target_selector_mips64): Rename from target_selector_mips64be and use
Target_selector_mips_nacl instead of Target_selector_mips.
(target_selector_mips64el): Rename from target_selector_mips64 and use
Target_selector_mips_nacl instead of Target_selector_mips.
(Target_mips::mips_info): Add const attribute.

[PATCH/AArch64] Generic support for all system registers using mrs and msr

  2014-09-03  Jiong Wang  <jiong.wang@arm.com>

  opcode/
    * aarch64-tbl.h (aarch64_opcode_table): Update encoding for mrs/msr.
    * aarch64-dis-2.c: Update auto-generated file.

  gas/
    * config/tc-aarch64.c (parse_sys_reg): Remove the restriction on op0 field.

  gas/testsuite/
    * gas/aarch64/illegal.s: Update testcase.
    * gas/aarch64/illegal.d: Likewise.
    * gas/aarch64/sysreg-1.s: Likewise.
    * gas/aarch64/sysreg-1.d: Likewise.

[PATCH/AArch64] Implement LSE feature

2014-09-03  Jiong Wang  <jiong.wang@arm.com>

  gas/
* config/tc-aarch64.c (parse_operands): Recognize PAIRREG.
(aarch64_features): Add entry for lse extension.

  include/opcode/
* aarch64.h (AARCH64_FEATURE_LSE): New feature added.
(aarch64_opnd): Add AARCH64_OPND_PAIRREG.
(aarch64_insn_class): Add lse_atomic.
(F_LSE_SZ): New field added.
(opcode_has_special_coder): Recognize F_LSE_SZ.

  opcode/
* aarch64-tbl.h (QL_R4NIL): New qualifiers.
(aarch64_feature_lse): New feature added.
(LSE): New Added.
(aarch64_opcode_table): New LSE instructions added.  Improve
descriptions for ldarb/ldarh/ldar.
(aarch64_opcode_table): Describe PAIRREG.
* aarch64-opc.h (aarch64_field_kind): Add FLD_lse_sz.
* aarch64-opc.c (fields): Add entry for F_LSE_SZ.
(aarch64_print_operand): Recognize PAIRREG.
(operand_general_constraint_met_p): Check reg pair constraints for CASP
instructions.
* aarch64-dis.c (aarch64_ext_regno_pair): New extractor for paired reg.
(do_special_decoding): Recognize F_LSE_SZ.
* aarch64-asm.c (do_special_encoding): Recognize F_LSE_SZ.

  gas/testsuite/
* gas/aarch64/lse-atomic.d: New.
* gas/aarch64/lse-atomic.s: Likewise.
* gas/aarch64/illegal-lse.d: Likewise.
* gas/aarch64/illegal-lse.l: Likewise.
* gas/aarch64/illegal-lse.s: Likewise.
* gas/aarch64/diagnostic.s: Check processor feature detect for lse
instruction.
* gas/aarch64/diagnostic.l: Likewise.

x86 debug address register clarifications

The loop macro ALL_DEBUG_REGISTERS does not iterate over the status or
control registers, so its name is misleading.  This commit renames it
as ALL_DEBUG_ADDRESS_REGISTERS and updates all uses.  This commit also
updates its loop conditions to an equivalent but better form, and
makes two functions use it that had previously hardwired the loop.
A comment on a related field in the x86_debug_reg_state structure is
also updated to reflect that the field refers specifically to address
registers only.

gdb/ChangeLog:

* nat/x86-dregs.h (ALL_DEBUG_REGISTERS): Renamed as...
(ALL_DEBUG_ADDRESS_REGISTERS): New macro.  All uses updated.
Loop conditions changed to equivalent form.
(struct x86_debug_reg_state): Updated dr_ref_count comment.
* x86-linux-nat.c (x86_linux_prepare_to_resume): Use
ALL_DEBUG_ADDRESS_REGISTERS.

gdb/gdbserver/ChangeLog:

* linux-x86-low.c (x86_linux_prepare_to_resume): Use
ALL_DEBUG_ADDRESS_REGISTERS.

Fix dwarf2loc.h::dwarf2_evaluate_property function description.

gdb/ChangeLog:

        * dwarf2loc.h (dwarf2_evaluate_property): Minor function
        description fix.

daily update

typeprint.c (find_global_typedef): Fix comment.

gdb/ChangeLog:

* typeprint.c (find_global_typedef): Fix comment.

Make Elf_file::section_name() a const function, so that it can be used in
places where we have only a const Elf_file*.

elfcpp/
* elfcpp_file.h (Elf_file::shnum): New const function.
(Elf_file::shstrndx): New const function.
(Elf_file::large_shndx_offset): New const function.
(Elf_file::section_name): Add const attribute.
(Elf_file::section_header_offset): Likewise.

gold/
* dwp.cc (Sized_relobj_dwo::do_section_name): Add const attribute.
* dynobj.h (Sized_dynobj::do_section_name): Likewise.
* incremental.cc (Sized_relobj_incr::do_section_name): Likewise.
(Sized_incr_dynobj::do_section_name): Likewise.
* incremental.h (Sized_relobj_incr::do_section_name): Likewise.
(Sized_incr_dynobj::do_section_name): Likewise.
* object.h (Object::section_name): Likewise.
(Object::do_section_name): Likewise.
(Sized_relobj_file::do_section_name): Likewise.
* plugin.cc (Sized_pluginobj::do_section_name): Likewise.
* plugin.h (Sized_pluginobj::do_section_name): Likewise.

Fix problem with optimization of .eh_frame section and --sort-section option.

When --sort-section=name is used, gold will sort the linker-generated contents
of .eh_frame (after optimization) after the endcap provided by crtendS.o.
This causes two problems: the .eh_frame_hdr section is generated assuming that
the optimized .eh_frame contents will be placed at the very beginning of the
section, and the endcap no longer appears at the end of the section.

This patch fixes the first problem by adjusting FDE offsets to take into account
the actual starting offset within the output section, and fixes the second
problem by sorting linker-generated (Output_section_data) sections based on the
name of the output section.

gold/
PR gold/17005
* ehframe.cc (Fde::write): Add output_offset parameter.
(Cie::write): Likewise.
(Eh_frame::set_final_data_size): Account for offset within output
section.
(Eh_frame::do_sized_write): Likewise.
* ehframe.h (Fde::write): Add output_offset parameter.
(Cie::write): Likewise.
* output.cc (Output_section::Input_section_sort_entry): Remove
section_has_name_; add output_section_name parameter. Use
output section name for non-input sections.
(Output_section::Input_section_sort_entry::section_has_name): Remove.
(Output_section::Input_section_sort_entry::section_has_name_): Remove.
(Output_section::Input_section_sort_compare): Remove logic for
sections without names.
(Output_section::Input_section_sort_init_fini_compare): Likewise.
(Output_section::Input_section_sort_section_prefix_special_ordering_compare):
Likewise.
(Output_section::Input_section_sort_section_name_compare): Likewise.

Rename 32- and 64-bit Intel files from "i386" to "x86"

This commit renames nine files that contain code used by both 32- and
64-bit Intel ports such that their names are prefixed with "x86"
rather than "i386".  All types, functions and variables within these
files are likewise renamed such that their names are prefixed with
"x86" rather than "i386".  This makes GDB follow the convention used
by gdbserver such that 32-bit Intel code lives in files called
"i386-*", 64-bit Intel code lives in files called "amd64-*", and code
for both 32- and 64-bit Intel lives in files called "x86-*".

This commit only renames OS-independent files.  The Linux ports of
both GDB and gdbserver now follow the i386/amd64/x86 convention fully.
Some ports still use the old convention where "i386" in file/function/
type/variable names can mean "32-bit only" or "32- and 64-bit" but I
don't want to touch ports I can't fully test except where absolutely
necessary.

gdb/ChangeLog:

* i386-nat.h: Renamed as...
* x86-nat.h: New file.  All type, function and variable name
prefixes changed from "i386_" to "x86_".  All references updated.
* i386-nat.c: Renamed as...
* x86-nat.c: New file.  All type, function and variable name
prefixes changed from "i386_" to "x86_".  All references updated.
* common/i386-xstate.h: Renamed as...
* common/x86-xstate.h: New file.  All type, function and variable
name prefixes changed from "i386_" to "x86_".  All references
updated.
* nat/i386-cpuid.h: Renamed as...
* nat/x86-cpuid.h: New file.  All type, function and variable name
prefixes changed from "i386_" to "x86_".  All references updated.
* nat/i386-gcc-cpuid.h: Renamed as...
* nat/x86-gcc-cpuid.h: New file.  All type, function and variable
name prefixes changed from "i386_" to "x86_".  All references
updated.
* nat/i386-dregs.h: Renamed as...
* nat/x86-dregs.h: New file.  All type, function and variable name
prefixes changed from "i386_" to "x86_".  All references updated.
* nat/i386-dregs.c: Renamed as...
* nat/x86-dregs.c: New file.  All type, function and variable name
prefixes changed from "i386_" to "x86_".  All references updated.

gdb/gdbserver/ChangeLog:

* i386-low.h: Renamed as...
* x86-low.h: New file.  All type, function and variable name
prefixes changed from "i386_" to "x86_".  All references updated.
* i386-low.c: Renamed as...
* x86-low.c: New file.  All type, function and variable name
prefixes changed from "i386_" to "x86_".  All references updated.

Use XCNEW rather than xcalloc (1, ...) in linux-x86-low.c

This commit replaces two uses of xcalloc (1, ...) with XCNEW.

gdb/gdbserver/ChangeLog:

* linux-x86-low.c (x86_linux_new_process): Use XCNEW.
(x86_linux_new_thread): Likewise.

daily update