Use keep_going in proceed and start_step_over too

The main motivation of this patch is sharing more code between the
proceed (starting the inferior for the first time) and keep_going
(restarting the inferior after handling an event) paths and using the
step_over_chain queue now embedded in the thread_info object for
pending in-line step-overs too (instead of just for displaced
stepping).

So this commit:

 - splits out a new keep_going_pass_signal function out of keep_going
   that is just like keep_going except for the bits that clear the
   signal to pass if the signal is set to "handle nopass".

 - makes proceed use keep_going too.

 - Makes start_step_over use keep_going_pass_signal instead of lower
   level displaced stepping things.

One user visible change: if inserting breakpoints while trying to
proceed fails, we now get:

  (gdb) si
  Warning:
  Could not insert hardware watchpoint 7.
  Could not insert hardware breakpoints:
  You may have requested too many hardware breakpoints/watchpoints.

  Command aborted.
  (gdb)

while before we only saw warnings with no indication that the command
was cancelled:

  (gdb) si
  Warning:
  Could not insert hardware watchpoint 7.
  Could not insert hardware breakpoints:
  You may have requested too many hardware breakpoints/watchpoints.

  (gdb)

Tested on x86_64-linux-gnu, ppc64-linux-gnu and s390-linux-gnu.

gdb/ChangeLog:
2015-08-07  Pedro Alves  <palves@redhat.com>

* gdbthread.h (struct thread_info) <prev_pc>: Extend comment.
* infrun.c (struct execution_control_state): Move higher up in the
file.
(reset_ecs): New function.
(start_step_over): Now returns int.  Rewrite to use
keep_going_pass_signal instead of manually starting a displaced step.
(resume): Don't call set_running here.  If displaced stepping
can't start now, clear trap_expected.
(find_thread_needs_step_over): Delete function.
(proceed): Set up finish_thread_state_cleanup.  Call set_running.
If the current thread needs a step over, push it in the step-over
chain.  Don't set insert breakpoints nor call resume directly
here.  Instead rewrite to use start_step_over and
keep_going_pass_signal.
(finish_step_over): New function.
(handle_signal_stop): Call finish_step_over instead of
start_step_over.
(switch_back_to_stepped_thread): If the event thread needs another
step-over do that first.  Use start_step_over.
(keep_going_pass_signal): New function, factored out from ...
(keep_going): ... here.
(_initialize_infrun): Comment moved here.
* thread.c (set_running_thread): New function.
(set_running, finish_thread_state): Use set_running_thread.

Embed the pending step-over chain in thread_info objects

In order to teach non-stop mode to do in-line step-overs (pause all
threads, remove breakpoint, single-step, reinsert breakpoint, restart
threads), we'll need to be able to queue in-line step over requests,
much like we queue displaced stepping (out-of-line) requests.
Actually, the queue should be the same -- threads wait for their turn
to step past something (breakpoint, watchpoint), doesn't matter what
technique we end up using when the step over actually starts.

I found that the queue management ends up simpler and more efficient
if embedded in the thread objects themselves.  This commit converts
the existing displaced stepping queue to that.  Later patches will
make the in-line step-overs code paths use it too.

gdb/ChangeLog:
2015-08-07  Pedro Alves  <palves@redhat.com>

* gdbthread.h (struct thread_info) <step_over_prev,
step_over_next>: New fields.
(thread_step_over_chain_enqueue, thread_step_over_chain_remove)
(thread_step_over_chain_next, thread_is_in_step_over_chain): New
declarations.
* infrun.c (struct displaced_step_request): Delete.
(struct displaced_step_inferior_state) <step_request_queue>:
Delete field.
(displaced_step_prepare): Assert that trap_expected is set.  Use
thread_step_over_chain_enqueue.  Split starting a new displaced
step to ...
(start_step_over): ... this new function.
(resume): Assert the thread isn't waiting for a step over already.
(proceed): Assert the thread isn't waiting for a step over
already.
(infrun_thread_stop_requested): Adjust to remove threads from the
embedded step-over chain.
(handle_inferior_event) <fork/vfork>: Call start_step_over after
displaced_step_fixup.
(handle_signal_stop): Call start_step_over after
displaced_step_fixup.
* infrun.h (step_over_queue_head): New declaration.
* thread.c (step_over_chain_enqueue, step_over_chain_remove)
(thread_step_over_chain_next, thread_is_in_step_over_chain)
(thread_step_over_chain_enqueue)
(thread_step_over_chain_remove): New functions.
(delete_thread_1): Remove thread from the step-over chain.

Make thread_still_needs_step_over consider stepping_over_watchpoint too

I noticed that even though keep_going knows to start a step over for a
watchpoint, thread_still_needs_step_over forgets it.

gdb/ChangeLog:
2015-08-07  Pedro Alves  <palves@redhat.com>

* infrun.c (thread_still_needs_step_over): Rename to ...
(thread_still_needs_step_over_bp): ... this.
(enum step_over_what): New.
(thread_still_needs_step_over): Reimplement.

remote.c/all-stop: Implement TARGET_WAITKIND_NO_RESUMED and TARGET_WNOHANG

Even though "target remote" supports target-async, the all-stop
target_wait implementation ignores TARGET_WNOHANG.  If the core
happens to poll for events and we've already read the stop reply out
of the serial/socket, remote_wait_as hangs forever instead of
returning an indication that there are no events to process.  This
can't happen currently, but later changes will trigger this.

gdb/ChangeLog:
2015-08-07  Pedro Alves  <palves@redhat.com>

* remote.c (remote_wait_as): If not waiting for a stop reply,
return TARGET_WAITKIND_NO_RESUMED.  If TARGET_WNOHANG is
requested, don't block waiting forever.

Change adjust_pc_after_break's prototype

Prepare to use it in contexts without an ecs handy.  Follow up patches
will make use of this.

gdb/ChangeLog:
2015-08-07  Pedro Alves  <pedro@codesourcery.com>

* infrun.c (adjust_pc_after_break): Now takes thread_info and
waitstatus pointers instead of an ecs.  Adjust.
(handle_inferior_event): Adjust caller.

Fix and test "checkpoint" in non-stop mode

Letting a "checkpoint" run to exit with "set non-stop on" behaves
differently compared to the default all-stop mode ("set non-stop
off").

Currently, in non-stop mode:

  (gdb) start
  Temporary breakpoint 1 at 0x40086b: file src/gdb/testsuite/gdb.base/checkpoint.c, line 28.
  Starting program: build/gdb/testsuite/gdb.base/checkpoint

  Temporary breakpoint 1, main () at src/gdb/testsuite/gdb.base/checkpoint.c:28
  28        char *tmp = &linebuf[0];
  (gdb) checkpoint
  checkpoint 1: fork returned pid 24948.
  (gdb) c
  Continuing.
  Copy complete.
  Deleting copy.
  [Inferior 1 (process 24944) exited normally]
  [Switching to process 24948]
  (gdb) info threads
    Id   Target Id         Frame
    1    process 24948 "checkpoint" (running)

  No selected thread.  See `help thread'.
  (gdb) c
  The program is not being run.
  (gdb)

Two issues above:

 1. Thread 1 got stuck in "(running)" state (it isn't really running)

 2. While checkpoints try to preserve the illusion that the thread is
    still the same when the process exits, GDB switched to "No thread
    selected." instead of staying with thread 1 selected.

Problem #1 is caused by handle_inferior_event and normal_stop not
considering that when a
TARGET_WAITKIND_SIGNALLED/TARGET_WAITKIND_EXITED event is reported,
and the inferior is mourned, the target may still have execution.

Problem #2 is caused by the make_cleanup_restore_current_thread
cleanup installed by fetch_inferior_event not being able to find the
original thread 1's ptid in the thread list, thus not being able to
restore thread 1 as selected thread.  The fix is to make the cleanup
installed by make_cleanup_restore_current_thread aware of thread ptid
changes, by installing a thread_ptid_changed observer that adjusts the
cleanup's data.

After the patch, we get the same in all-stop and non-stop modes:

  (gdb) c
  Continuing.
  Copy complete.
  Deleting copy.
  [Inferior 1 (process 25109) exited normally]
  [Switching to process 25113]
  (gdb) info threads
    Id   Target Id         Frame
  * 1    process 25113 "checkpoint" main () at src/gdb/testsuite/gdb.base/checkpoint.c:28
  (gdb)

Turns out the whole checkpoints.exp file can run in non-stop mode
unmodified.  I thought of moving most of the test file's contents to a
procedure that can be called twice, once in non-stop mode and another
in all-stop mode.  But then, the test already takes close to 30
seconds to run on my machine, so I thought it'd be nicer to run
all-stop and non-stop mode in parallel.  Thus I added a new
checkpoint-ns.exp file that just appends "set non-stop on" to GDBFLAGS
and sources checkpoint.exp.

gdb/ChangeLog:
2015-08-07  Pedro Alves  <palves@redhat.com>

* infrun.c (handle_inferior_event): If we get
TARGET_WAITKIND_SIGNALLED or TARGET_WAITKIND_EXITED in non-stop
mode, mark all threads of the exiting process as not-executing.
(normal_stop): If we get TARGET_WAITKIND_SIGNALLED or
TARGET_WAITKIND_EXITED in non-stop mode, finish all threads of the
exiting process, if inferior_ptid still points at a process.
* thread.c (struct current_thread_cleanup) <next>: New field.
(current_thread_cleanup_chain): New global.
(restore_current_thread_ptid_changed): New function.
(restore_current_thread_cleanup_dtor): Remove the cleanup from the
current_thread_cleanup_chain list.
(make_cleanup_restore_current_thread): Add the cleanup data to the
current_thread_cleanup_chain list.
(_initialize_thread): Install restore_current_thread_ptid_changed
as thread_ptid_changed observer.

gdb/testsuite/ChangeLog:
2015-08-07  Pedro Alves  <palves@redhat.com>

* gdb.base/checkpoint-ns.exp: New file.
* gdb.base/checkpoint.exp: Pass explicit "checkpoint.c" to
standard_testfile.

ignore invalid DOF provider sections

On x86-solaris 10, we noticed that starting a program would sometimes
cause the debugger to crash. For instance:

    % gdb a
    (gdb) break adainit
    Breakpoint 1 at 0x8051f03
    (gdb) run
    Starting program: /[...]/a
    [Thread debugging using libthread_db enabled]
    zsh: 24398 segmentation fault (core dumped)  /[...]/gdb a

The exception occurs in dtrace_process_dof_probe, while trying
to process each probe referenced by a DTRACE_DOF_SECT_TYPE_PROVIDER
DOF section from /lib/libc.so.1. For reference, the ELF section
in that shared library providing the DOF data has the following
characteristics:

    Idx Name          Size      VMA       LMA       File off  Algn
     14 .SUNW_dof     0000109d  000b4398  000b4398  000b4398  2**3
                      CONTENTS, ALLOC, LOAD, READONLY, DATA

The function dtrace_process_dof gets passed the contents of that
ELF section, which allows it to determine the location of the table
where all DOF sections are described. I dumped the contents of
each DOF section as seen by GDB, and it seemed to be plausible,
because the offset of each DOF section was pretty much equal to
the sum of the offset and size of the previous DOF section. Also,
the offset + sum of the last section corresponds to the size of
the .SUNW_dof section.

Things start to break down when processing one of the DOF sections
that has a type of DTRACE_DOF_SECT_TYPE_PROVIDER. It gets the contents
of this DOF section via:

        struct dtrace_dof_provider *provider = (struct dtrace_dof_provider *)
          DTRACE_DOF_PTR (dof, DOF_UINT (dof, section->dofs_offset));

Said more simply, the struct dtrace_dof_provider data is at
section->dofs_offset of the entire DOF contents. Given that
the contents of SECTION seemed to make sense, so far so good.

However, what SECTION tells us is that our DOF provider section
is 40 bytes long:

    (gdb) print *section
    $36 = {dofs_type = 15, dofs_align = 4, dofs_flags = 1,
           dofs_entsize = 0, dofs_offset = 3264, dofs_size = 40}
                                                 ^^^^^^^^^^^^^^

But on the other hand:

    (gdb) p sizeof (struct dtrace_dof_provider)
    $54 = 44

In other words GDB expected a bigger DOF section and when we try to
fetch the value of the last field of that DOF section (dofpv_prenoffs)...

    eoffsets_s = DTRACE_DOF_SECT (dof,
                                  DOF_UINT (dof, provider->dofpv_prenoffs));

... we end up reading data that actually belongs to another DOF
section, and therefore irrelevant. This in turn means that the value
of eofftab gets incorrectly set, since it depends on eoffsets_s:

    eofftab = DTRACE_DOF_PTR (dof, DOF_UINT (dof, eoffsets_s->dofs_offset));

This invalid address quickly catches up to us when we pass it to
dtrace_process_dof_probe shortly after, where we crash because
we try to subscript it:

    Program received signal SIGSEGV, Segmentation fault.
    0x08155bba in dtrace_process_dof_probe ([...]) at [...]/dtrace-probe.c:378
    378             = ((uint32_t *) eofftab)[...];

This patch fixes the issue by detecting provider DOF sections
that are smaller than expected, and discarding the DOF data.

gdb/ChangeLog:

        * dtrace-probe.c (dtrace_process_dof): Ignore the objfile's DOF
        data if a DTRACE_DOF_SECT_TYPE_PROVIDER section is found to be
        smaller than expected.

Sync config.sub and config.guess with GCC

Sync with GCC
2015-07-28  Ben Elliston  <bje@gnu.org>

* config.sub, config.guess: Import from upstream.

Remove CpuFMA4 support from CPU_ZNVER1_FLAGS.

opcodes/

* i386-gen.c: Remove CpuFMA4 from CPU_ZNVER1_FLAGS.
* i386-init.h: Regenerated.

Properly merge hidden versioned symbol

The hidden versioned symbol can only be merged with the versioned
symbol with the same symbol version.  _bfd_elf_merge_symbol should
check the symbol version before merging the new hidden versioned
symbol with the existing symbol.  _bfd_elf_link_hash_copy_indirect can't
copy any references to the hidden versioned symbol.   We need to
bind a symbol locally when linking executable if it is locally defined,
hidden versioned, not referenced by shared library and not exported.

bfd/

PR ld/18720
* elflink.c (_bfd_elf_merge_symbol): Add a parameter to indicate
if the new symbol matches the existing one.  The new hidden
versioned symbol matches the existing symbol if they have the
same symbol version. Update the existing symbol only if they
match.
(_bfd_elf_add_default_symbol): Update call to
_bfd_elf_merge_symbol.
(_bfd_elf_link_assign_sym_version): Don't set the hidden field
here.
(elf_link_add_object_symbols): Override a definition only if the
new symbol matches the existing one.
(_bfd_elf_link_hash_copy_indirect): Don't copy any references to
the hidden versioned symbol.
(elf_link_output_extsym): Bind a symbol locally when linking
executable if it is locally defined, hidden versioned, not
referenced by shared library and not exported.  Turn on
VERSYM_HIDDEN only if the hidden vesioned symbol is defined
locally.

ld/testsuite/

PR ld/18720
* ld-elf/indirect.exp: Run tests for PR ld/18720.
* ld-elf/pr18720.out: New file.
* ld-elf/pr18720a.c: Likewise.
* ld-elf/pr18720b.c: Likewise.
* ld-elf/pr18720c.c: Likewise.

gdb: Move get_frame_language from stack.c to frame.c.

The get_frame_language feels like it would be more at home in frame.c
rather than in stack.c, while the declaration, that is currently in
language.h can be moved into frame.h to match.

A couple of new includes are added, but otherwise no substantial change
here.

gdb/ChangeLog:

* stack.c (get_frame_language): Moved ...
* frame.c (get_frame_language): ... to here.
* language.h (get_frame_language): Declaration moved to frame.h.
* frame.h: Add language.h include, for language enum.
(get_frame_language): Declaration moved from language.h.
* language.c: Add frame.h include.
* top.c: Add frame.h include.
* symtab.h (struct obj_section): Declare.
(struct cmd_list_element): Declare.

gdb: get_frame_language now takes a frame parameter.

As part of a drive to remove deprecated_safe_get_selected_frame, make
the get_frame_language function take a frame parameter.  Given the name
of the function this actually seems to make a lot of sense.

The task of fetching a suitable frame is then passed to the calling
functions.  For get_frame_language there are not many callers, these are
updated to get the selected frame in a suitable way.

gdb/ChangeLog:

* language.c (show_language_command): Find selected frame before
asking for the language of that frame.
(set_language_command): Likewise.
* language.h (get_frame_language): Add frame parameter.
* stack.c (get_frame_language): Add frame parameter, assert
parameter is not NULL, update comment and reindent.
* top.c (check_frame_language_change): Pass the selected frame
into get_frame_language.

objcopy: Improve wildcard matching for symbols with '!' prefix.

When using options such as --localize-symbol, --globalize-symbol, etc,
along with the --wildcard option, prefixing a symbol name with '!'
should provide non-matching behaviour, as example the following example
is given in the manual:

    --wildcard --weaken-symbol !foo --weaken-symbol fo*

which should weaken all symbols matching the pattern 'fo*', but not the
symbol 'foo'.

However, this currently does not work, the current logic will waken all
symbols matching the pattern 'fo*' AND all symbols that are not 'foo'.
The symbol 'foo' is covered by the first condition, and so is weakened,
while, other symbols, for example 'bar' will match the second condition,
and so be weakened.

This patch adjusts the logic so that a pattern prefixed with '!'
specifically DOES NOT apply the relevant change to any matching symbols,
instead of applying the change to all non-matching symbols.  So this:

    --weaken-symbol !foo

will ensure that the symbol 'foo' is not weakened, but says nothing
about symbols that are not 'foo'.  As a result, a pattern prefixed with
'!' now only makes sense when used alongside a more wide ranging
wildcard pattern.

This change should make the wildcard matching feature more useful, with
no overall loss of functionality.  The example given in the manual,
weaken all symbols matching 'fo*' except 'foo' can now be achieved, but
so too can more complex examples, such as weaken all symbols matching
'fo*' except 'foo', 'foa', and 'fob', like this:

    --wildcard --weaken-symbol !foo \
               --weaken-symbol !foa \
               --weaken-symbol !fob \
               --weaken-symbol fo*

Under the previous scheme, something as symbols as, weaken all symbols
except 'foo' could have been achieved with this:

    --weaken-symbol !foo

however, this will no longer work.  To achieve the same result under the
new scheme this is now required:

    --weaken-symbol !foo --weaken-symbol *

binutils/ChangeLog:

* objcopy.c (is_specified_symbol_predicate): Don't stop at first
match.  Non-match rules set found to FALSE.

binutils/testsuite/ChangeLog:

* binutils-all/objcopy.exp: Run new symbol tests.
(objcopy_test_symbol_manipulation): New function.
* binutils-all/symbols-1.d: New file.
* binutils-all/symbols-2.d: New file.
* binutils-all/symbols-3.d: New file.
* binutils-all/symbols-4.d: New file.
* binutils-all/symbols.s: New file.

btrace: indicate speculative execution

Indicate speculatively executed instructions with a leading '?'.  We use the
space that is normally used for the PC prefix.  In the case where the
instruction at the current PC had been executed speculatively before, the PC
prefix will be partially overwritten resulting in "?> ".

As a side-effect, the /p modifier to omit the PC prefix in the "record
instruction-history" command now uses a 3-space PC prefix "   " in order to
have enough space for the speculative execution indication.

gdb/
* btrace.c (btrace_compute_ftrace_bts): Clear insn flags.
(pt_btrace_insn_flags): New.
(ftrace_add_pt): Call pt_btrace_insn_flags.
* btrace.h (btrace_insn_flag): New.
(btrace_insn) <flags>: New.
* record-btrace.c (btrace_insn_history): Print insn prefix.
* NEWS: Announce it.

doc/
* gdb.texinfo (Process Record and Replay): Document prefixing of
speculatively executed instructions in the "record instruction-history"
command.

testsuite/
* gdb.btrace/instruction_history.exp: Update.
* gdb.btrace/tsx.exp: New.
* gdb.btrace/tsx.c: New.
* lib/gdb.exp (skip_tsx_tests, skip_btrace_pt_tests): New.

configure: check for perf_event.h version

Intel(R) Processor Trace support requires a recent linux/perf_event.h header.

When GDB is built on an older system, Intel(R) Processor Trace will not be
available and there is no indication in the configure and build log as to
what went wrong.

Check for a compatible linux/perf_event.h at configure-time.

gdb/
* configure.ac: Check for PERF_ATTR_SIZE_VER5 in linux/perf_event.h
* configure: Regenerate.

Yaakov Selkowitz: fixes for in-tree libiconv

        * Makefile.def (libiconv): Define bootstrap=true.
        Mark pdf/html/info as missing.
        (configure-gcc): Depend on all-libiconv.
        (all-gcc): Ditto.
        (configure-libcpp): Ditto.
        (all-libcpp): Ditto.
        (configure-intl): Ditto.
        (all-intl): Ditto.
        * Makefile.in: Regenerate.

binutils/
        * configure: Regenerate.

gdb/
        * Makefile.in (LIBICONV): Define.
        (CLIBS): Add LIBICONV.
        * acinclude.m4: Use config/iconv.m4 instead of custom AM_ICONV.
        * configure: Regenerate.

Automatic date update in version.in

Bump timeouts for a couple gdb.reverse/*-precsave.exp tests

The buildbot shows that PPC64 and x86_64 builders, both native and
extended-remote gdbserver frequently timeout these tests.
until-precsave.exp times out on my x86_64 occasionally as well.
Inspecting the logs, we see that if we waited some more, the tests
would pass.

Simply bump until-precsave.exp timeouts further, and apply the same
treatment to step-precsave.exp.

gdb/testsuite/ChangeLog:
2015-08-06  Pedro Alves <palves@redhat.com>

* gdb.reverse/step-precsave.exp: Use with_timeout_factor to
increase timeout.
* gdb.reverse/until-precsave.exp: Bump timeouts.

Fix gdb.base/valgrind-infcall.exp with the native-extended-gdbserver board

This test fails with --target_board=native-extended-gdbserver because
it misses the usual "disconnect":

 (gdb)  target remote | /usr/lib64/valgrind/../../bin/vgdb --pid=30454
 Already connected to a remote target.  Disconnect? (y or n) n
 Still connected.
 (gdb) FAIL: gdb.base/valgrind-infcall.exp: target remote for vgdb (got interactive prompt)

gdb/testsuite/ChangeLog:
2015-08-06  Pedro Alves  <palves@redhat.com>

* gdb.base/valgrind-infcall.exp: Issue a "disconnect".

Add casts for legitimate integer to enum conversions

This patch is mostly extracted from Pedro's C++ branch.  It adds explicit
casts from integer to enum types, where it is really the intention to do
so.  This could be because we are ...

 * iterating on enum values (we need to iterate on an equivalent integer)
 * converting from a value read from bytes (dwarf attribute, agent
 expression opcode) to the equivalent enum
 * reading the equivalent integer value from another language (Python/Guile)

An exception to that is the casts in regcache.c.  It seems to me like
struct regcache's register_status field could be a pointer to an array of
enum register_status.  Doing so would waste a bit of memory (4 bytes
used by the enum vs 1 byte used by the current signed char, for each
register).  If we switch to C++11 one day, we can define the underlying
type of an enum type, so we could have the best of both worlds.

gdb/ChangeLog:

* arm-tdep.c (set_fp_model_sfunc): Add cast from integer to enum.
(arm_set_abi): Likewise.
* ax-general.c (ax_print): Likewise.
* c-exp.y (exp : string_exp): Likewise.
* compile/compile-loc2c.c (compute_stack_depth_worker): Likewise.
(do_compile_dwarf_expr_to_c): Likewise.
* cp-name-parser.y (demangler_special : DEMANGLER_SPECIAL start):
Likewise.
* dwarf2expr.c (execute_stack_op): Likewise.
* dwarf2loc.c (dwarf2_compile_expr_to_ax): Likewise.
(disassemble_dwarf_expression): Likewise.
* dwarf2read.c (dwarf2_add_member_fn): Likewise.
(read_array_order): Likewise.
(abbrev_table_read_table): Likewise.
(read_attribute_value): Likewise.
(skip_unknown_opcode): Likewise.
(dwarf_decode_macro_bytes): Likewise.
(dwarf_decode_macros): Likewise.
* eval.c (value_f90_subarray): Likewise.
* guile/scm-param.c (gdbscm_make_parameter): Likewise.
* i386-linux-tdep.c (i386_canonicalize_syscall): Likewise.
* infrun.c (handle_command): Likewise.
* memory-map.c (memory_map_start_memory): Likewise.
* osabi.c (set_osabi): Likewise.
* parse.c (operator_length_standard): Likewise.
* ppc-linux-tdep.c (ppc_canonicalize_syscall): Likewise, and use
single return point.
* python/py-frame.c (gdbpy_frame_stop_reason_string): Likewise.
* python/py-symbol.c (gdbpy_lookup_symbol): Likewise.
(gdbpy_lookup_global_symbol): Likewise.
* record-full.c (record_full_restore): Likewise.
* regcache.c (regcache_register_status): Likewise.
(regcache_raw_read): Likewise.
(regcache_cooked_read): Likewise.
* rs6000-tdep.c (powerpc_set_vector_abi): Likewise.
* symtab.c (initialize_ordinary_address_classes): Likewise.
* target-debug.h (target_debug_print_signals): Likewise.
* utils.c (do_restore_current_language): Likewise.

Add missing ChangeLog entry header

Fix ChangeLog formatting

Spaces -> Tab.

gdbserver/tracepoint.c: make exported IPA global int instead of enum

Fixes another C++ -fpermissive error:

  src/gdb/gdbserver/tracepoint.c:4535:21: error: invalid conversion from ‘int’ to ‘eval_result_type’ [-fpermissive]
    expr_eval_result = ipa_expr_eval_result;

gdb/gdbserver/ChangeLog:
2015-08-06  Pedro Alves  <palves@redhat.com>

* tracepoint.c (expr_eval_result): Now an int.

gdbserver: no point in hiding the regcache type nowadays

The regcache used to be hidden inside inferiors.c, but since the
tracepoints support that it's a first class object.  This also fixes a
few implicit pointer conversion errors in C++ mode, caused by a few
places missing the explicit cast.

gdb/gdbserver/ChangeLog:
2015-08-06  Pedro Alves  <palves@redhat.com>

* gdbthread.h (struct regcache): Forward declare.
(struct thread_info) <regcache_data>: Now a struct regcache
pointer.
* inferiors.c (inferior_regcache_data)
(set_inferior_regcache_data): Now work with struct regcache
pointers.
* inferiors.h (struct regcache): Forward declare.
(inferior_regcache_data, set_inferior_regcache_data): Now work
with struct regcache pointers.
* regcache.c (get_thread_regcache, regcache_invalidate_thread)
(free_register_cache_thread): Remove struct regcache pointer
casts.

PR python/17136

gdb/ChangeLog:

* python/lib/gdb/command/type_printers.py (InfoTypePrinter): Fix typo.

gdbserver: fix silent error exit

Running gdb.threads/process-dies-while-handling-bp.exp against
gdbserver sometimes FAILs because GDBserver drops the connection, but
the logs leave no clue on what the reason could be.  Running manually
a few times, I saw the same:

 $  ./gdbserver/gdbserver --multi :9999 testsuite/gdb.threads/process-dies-while-handling-bp
 Process testsuite/gdb.threads/process-dies-while-handling-bp created; pid = 12766
 Listening on port 9999
 Remote debugging from host 127.0.0.1
 Listening on port 9999

 Child exited with status 0

 Child exited with status 0

What happened is that an exception escaped and gdbserver reopened the
connection, which led to that second "Listening on port 9999" output.

The error was a failure to access registers from a now-dead thread.
The exception probably shouldn't have escaped here, but meanwhile,
this at least makes the issue less mysterious.

Tested on x86_64 Fedora 20.

gdb/gdbserver/ChangeLog:
2015-08-06  Pedro Alves  <palves@redhat.com>

* server.c (captured_main): On error, print the exception message
to stderr, and if run_once is set, throw a quit.

Change type of struct complaints::series

Found while processing the C++ enum changes.  It seems like series
should be of type enum complaint_series, instead of adding a cast.

Redundant and out of date comments are also removed.

gdb/ChangeLog:

* complaints.c (enum complaint_series): Add newlines and remove
out of date comment.
(struct complaints) <series>: Change type to enum
complaint_series and remove out of date comment.
(symfile_complaint_hook): Use equivalent enum value
ISOLATED_MESSAGE instead of 0.

gdbserver: move_out_of_jump_pad_callback misses switching current thread

While hacking on the fix for PR threads/18600 (Threads left stopped
after fork+thread spawn), I once saw its test (fork-plus-threads.exp)
FAIL against gdbserver because move_out_of_jump_pad_callback has a
gdb_breakpoint_here call, and the caller isn't making sure the current
thread points to the right thread.  In the case I saw, the current
thread pointed to the wrong process, so gdb_breakpoint_here returned
the wrong answer.  Unfortunately I didn't save logs.  Still, seems
obvious enough and it should fix a potential occasional racy FAIL.

Tested on x86_64 Fedora 20.

gdb/gdbserver/ChangeLog:
2015-08-06  Pedro Alves  <palves@redhat.com>

* linux-low.c (move_out_of_jump_pad_callback): Temporarily switch
the current thread.

Fix gdbserver --debug issues caught by Valgrind

Running gdbserver --debug under Valgrind shows:

 ==4803== Invalid read of size 4
 ==4803==    at 0x432B62: linux_write_memory (linux-low.c:5320)
 ==4803==    by 0x4143F7: write_inferior_memory (target.c:83)
 ==4803==    by 0x415895: remove_memory_breakpoint (mem-break.c:362)
 ==4803==    by 0x432EF5: linux_remove_point (linux-low.c:5460)
 ==4803==    by 0x416319: delete_raw_breakpoint (mem-break.c:802)
 ==4803==    by 0x4163F3: release_breakpoint (mem-break.c:842)
 ==4803==    by 0x416477: delete_breakpoint_1 (mem-break.c:869)
 ==4803==    by 0x4164EF: delete_breakpoint (mem-break.c:891)
 ==4803==    by 0x416843: delete_gdb_breakpoint_1 (mem-break.c:1069)
 ==4803==    by 0x4168D8: delete_gdb_breakpoint (mem-break.c:1098)
 ==4803==    by 0x4134E3: process_serial_event (server.c:4051)
 ==4803==    by 0x4138E4: handle_serial_event (server.c:4196)
 ==4803==  Address 0x4c6b930 is 0 bytes inside a block of size 1 alloc'd
 ==4803==    at 0x4A0645D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
 ==4803==    by 0x4240C6: xmalloc (common-utils.c:43)
 ==4803==    by 0x41439C: write_inferior_memory (target.c:80)
 ==4803==    by 0x415895: remove_memory_breakpoint (mem-break.c:362)
 ==4803==    by 0x432EF5: linux_remove_point (linux-low.c:5460)
 ==4803==    by 0x416319: delete_raw_breakpoint (mem-break.c:802)
 ==4803==    by 0x4163F3: release_breakpoint (mem-break.c:842)
 ==4803==    by 0x416477: delete_breakpoint_1 (mem-break.c:869)
 ==4803==    by 0x4164EF: delete_breakpoint (mem-break.c:891)
 ==4803==    by 0x416843: delete_gdb_breakpoint_1 (mem-break.c:1069)
 ==4803==    by 0x4168D8: delete_gdb_breakpoint (mem-break.c:1098)
 ==4803==    by 0x4134E3: process_serial_event (server.c:4051)
 ==4803==

And:

 ==7272== Conditional jump or move depends on uninitialised value(s)
 ==7272==    at 0x3615E48361: vfprintf (vfprintf.c:1634)
 ==7272==    by 0x414E89: debug_vprintf (debug.c:60)
 ==7272==    by 0x42800A: debug_printf (common-debug.c:35)
 ==7272==    by 0x43937B: my_waitpid (linux-waitpid.c:149)
 ==7272==    by 0x42D740: linux_wait_for_event_filtered (linux-low.c:2441)
 ==7272==    by 0x42DADA: linux_wait_for_event (linux-low.c:2552)
 ==7272==    by 0x42E165: linux_wait_1 (linux-low.c:2860)
 ==7272==    by 0x42F5D8: linux_wait (linux-low.c:3453)
 ==7272==    by 0x4144A4: mywait (target.c:107)
 ==7272==    by 0x413969: handle_target_event (server.c:4214)
 ==7272==    by 0x41A1A6: handle_file_event (event-loop.c:429)
 ==7272==    by 0x41996D: process_event (event-loop.c:184)

gdb/ChangeLog:
2015-08-06  Pedro Alves  <palves@redhat.com>

* nat/linux-waitpid.c (my_waitpid): Only print *status if waitpid
returned > 0.

gdb/gdbserver/ChangeLog:
2015-08-06  Pedro Alves  <palves@redhat.com>

* linux-low.c (linux_write_memory): Rewrite debug output to avoid
reading beyond the passed in buffer length.

Revert "test slowdown"

That was pushed by mistake.

Test for PR18749: problems if whole process dies while (ptrace-) stopped

This adds a kfailed test that has the whole process exit just while
several threads continuously step over a breakpoint.  Usually, the
process exits just while GDB or GDBserver is handling the breakpoint
hit.  In other words, the process disappears while the event thread is
(ptrace-) stopped.  This exposes several issues in GDB and GDBserver.
Errors, crashes, etc.

I fixed some of these issues recently, but there's a lot more to do.
It's a bit like playing whack-a-mole at the moment.  You fix an issue,
which then exposes several others.

E.g., with the native target, you get (among other errors):

  (...)
  [New Thread 0x7ffff47b9700 (LWP 18077)]
  [New Thread 0x7ffff3fb8700 (LWP 18078)]
  [New Thread 0x7ffff37b7700 (LWP 18079)]
  Cannot find user-level thread for LWP 18076: generic error
  (gdb) KFAIL: gdb.threads/process-dies-while-handling-bp.exp: non_stop=on: cond_bp_target=1: inferior 1 exited (prompt) (PRMS: gdb/18749)

gdb/testsuite/ChangeLog:
2015-08-06  Pedro Alves  <palves@redhat.com>

PR gdb/18749
* gdb.threads/process-dies-while-handling-bp.c: New file.
* gdb.threads/process-dies-while-handling-bp.exp: New file.

test slowdown

Remove required field in agent's symbols

This field was never set nor used.  This patch removes it.

gdb/ChangeLog:

* common/agent.c (symbol_list) <required>: Remove.

gdb/gdbserver/ChangeLog:

* tracepoint.c (symbol_list) <required>: Remove.

gdbserver: Fix non-stop / fork / step-over issues

Ref: https://sourceware.org/ml/gdb-patches/2015-07/msg00868.html

This adds a test that has a multithreaded program have several threads
continuously fork, while another thread continuously steps over a
breakpoint.

This exposes several intertwined issues, which this patch addresses:

 - When we're stopping and suspending threads, some thread may fork,
   and we missed setting its suspend count to 1, like we do when a new
   clone/thread is detected.  When we next unsuspend threads, the fork
   child's suspend count goes below 0, which is bogus and fails an
   assertion.

 - If a step-over is cancelled because a signal arrives, but then gdb
   is not interested in the signal, we pass the signal straight back
   to the inferior.  However, we miss that we need to re-increment the
   suspend counts of all other threads that had been paused for the
   step-over.  As a result, other threads indefinitely end up stuck
   stopped.

 - If a detach request comes in just while gdbserver is handling a
   step-over (in the test at hand, this is GDB detaching the fork
   child), gdbserver internal errors in stabilize_thread's helpers,
   which assert that all thread's suspend counts are 0 (otherwise we
   wouldn't be able to move threads out of the jump pads).  The
   suspend counts aren't 0 while a step-over is in progress, because
   all threads but the one stepping past the breakpoint must remain
   paused until the step-over finishes and the breakpoint can be
   reinserted.

 - Occasionally, we see "BAD - reinserting but not stepping." being
   output (from within linux_resume_one_lwp_throw).  That was because
   GDB pokes memory while gdbserver is busy with a step-over, and that
   suspends threads, and then re-resumes them with proceed_one_lwp,
   which missed another reason to tell linux_resume_one_lwp that the
   thread should be set back to stepping.

 - In a couple places, we were resuming threads that are meant to be
   suspended.  E.g., when a vCont;c/s request for thread B comes in
   just while gdbserver is stepping thread A past a breakpoint.  The
   resume for thread B must be deferred until the step-over finishes.

 - The test runs with both "set detach-on-fork" on and off.  When off,
   it exercises the case of GDB detaching the fork child explicitly.
   When on, it exercises the case of gdb resuming the child
   explicitly.  In the "off" case, gdb seems to exponentially become
   slower as new inferiors are created.  This is _very_ noticeable as
   with only 100 inferiors gdb is crawling already, which makes the
   test take quite a bit to run.  For that reason, I've disabled the
   "off" variant for now.

gdb/ChangeLog:
2015-08-06  Pedro Alves  <palves@redhat.com>

* target/waitstatus.h (enum target_stop_reason)
<TARGET_STOPPED_BY_SINGLE_STEP>: New value.

gdb/gdbserver/ChangeLog:
2015-08-06  Pedro Alves  <palves@redhat.com>

* linux-low.c (handle_extended_wait): Set the fork child's suspend
count if stopping and suspending threads.
(check_stopped_by_breakpoint): If stopped by trace, set the LWP's
stop reason to TARGET_STOPPED_BY_SINGLE_STEP.
(linux_detach): Complete an ongoing step-over.
(lwp_suspended_inc, lwp_suspended_decr): New functions.  Use
throughout.
(resume_stopped_resumed_lwps): Don't resume a suspended thread.
(linux_wait_1): If passing a signal to the inferior after
finishing a step-over, unsuspend and re-resume all lwps.  If we
see a single-step event but the thread should be continuing, don't
pass the trap to gdb.
(stuck_in_jump_pad_callback, move_out_of_jump_pad_callback): Use
internal_error instead of gdb_assert.
(enqueue_pending_signal): New function.
(check_ptrace_stopped_lwp_gone): Add debug output.
(start_step_over): Use internal_error instead of gdb_assert.
(complete_ongoing_step_over): New function.
(linux_resume_one_thread): Don't resume a suspended thread.
(proceed_one_lwp): If the LWP is stepping over a breakpoint, reset
it stepping.

gdb/testsuite/ChangeLog:
2015-08-06  Pedro Alves  <palves@redhat.com>

* gdb.threads/forking-threads-plus-breakpoint.exp: New file.
* gdb.threads/forking-threads-plus-breakpoint.c: New file.

Linux gdbserver confused when event randomization picks process exit event

The tail end of linux_wait_1 isn't expecting that the select_event_lwp
machinery can pick a whole-process exit event to report to GDB.  When
that happens, both gdb and gdbserver end up quite confused:

 ...
 (gdb)
 [Thread 24971.24971] #1 stopped.
 0x0000003615a011f0 in ?? ()
 c&
 Continuing.
 (gdb) [New Thread 24971.24981]
 [New Thread 24983.24983]
 [New Thread 24971.24982]

 [Thread 24983.24983] #3 stopped.
 0x0000003615ebc7cc in __libc_fork () at ../nptl/sysdeps/unix/sysv/linux/fork.c:130
 130       pid = ARCH_FORK ();
 [New Thread 24984.24984]
 Error in re-setting breakpoint -16: PC register is not available
 Error in re-setting breakpoint -17: PC register is not available
 Error in re-setting breakpoint -18: PC register is not available
 Error in re-setting breakpoint -19: PC register is not available
 Error in re-setting breakpoint -24: PC register is not available
 Error in re-setting breakpoint -25: PC register is not available
 Error in re-setting breakpoint -26: PC register is not available
 Error in re-setting breakpoint -27: PC register is not available
 Error in re-setting breakpoint -28: PC register is not available
 Error in re-setting breakpoint -29: PC register is not available
 Error in re-setting breakpoint -30: PC register is not available
 PC register is not available
 (gdb)

gdb/gdbserver/ChangeLog:
2015-08-06  Pedro Alves  <palves@redhat.com>

* linux-low.c (add_lwp): Set waitstatus to TARGET_WAITKIND_IGNORE.
(linux_thread_alive): Use lwp_is_marked_dead.
(extended_event_reported): Delete.
(linux_wait_1): Check if waitstatus is TARGET_WAITKIND_IGNORE
instead of extended_event_reported.
(mark_lwp_dead): Don't set the 'dead' flag.  Store the waitstatus
as well.
(lwp_is_marked_dead): New function.
(lwp_running): Use lwp_is_marked_dead.
* linux-low.h: Delete 'dead' field, and update 'waitstatus's
comment.

Linux gdbserver fork event debug output

The "extended event with waitstatus" debug output is unreachable, as
it is guarded by "if (!report_to_gdb)".  If extended_event_reported is
true, then so is report_to_gdb.  Move it to where we print why we're
reporting an event to GDB.

Also, the debug output currently tries to print the wrong struct
target_waitstatus.

gdb/gdbserver/ChangeLog:
2015-08-06  Pedro Alves  <palves@redhat.com>

* linux-low.c (linux_wait_1): Move fork event output out of the
!report_to_gdb check.  Pass event_child->waitstatus to
target_waitstatus_to_string instead of ourstatus.

Revert ALIGN changes

Reverts a2c59f28 and e474ab13.  Since the unary form of ALIGN only
references "dot" implicitly, there isn't really a strong argument for
making ALIGN use a relative value when inside an output section.

* ldexp.c (align_dot_val): Delete.
(fold_unary <ALIGN_K, NEXT>): Revert 2015-07-10 change.
(is_align_conditional): Revert 2015-07-20 change.
(exp_fold_tree_1): Likewise, but keep expanded comment.
* scripttempl/elf.sc (.ldata, .bss): Revert 2015-07-20 change.
* ld.texinfo (<ALIGN>): Correct description.

Automatic date update in version.in

stepping is disturbed by setjmp/longjmp | try/catch in other threads

At https://sourceware.org/ml/gdb-patches/2015-08/msg00097.html, Joel
observed that trying to next/step a program on GNU/Linux sometimes
results in the following failed assertion:

% gdb -q .obj/gprof/main
    (gdb) start
    (gdb) n
    (gdb) step
    [...]/infrun.c:2391: internal-error:
    resume: Assertion `sig != GDB_SIGNAL_0' failed.

What happened is that, during the "next" operation, GDB hit a
longjmp/exception/step-resume breakpoint but failed to see that this
breakpoint was set for a different thread than the one being stepped.

Joel's detailed analysis follows:

More precisely, at the end of the "start" command, we are stopped at
the start of function Main in main.adb; there are 4 threads in total,
and we are in the main thread (which is thread 1):

    (gdb) info thread
      Id   Target Id         Frame
      4    Thread 0xb7a56ba0 (LWP 28379) 0xffffe410 in __kernel_vsyscall ()
      3    Thread 0xb7c5aba0 (LWP 28378) 0xffffe410 in __kernel_vsyscall ()
      2    Thread 0xb7e5eba0 (LWP 28377) 0xffffe410 in __kernel_vsyscall ()
    * 1    Thread 0xb7ea18c0 (LWP 28370) main () at /[...]/main.adb:57

All the logs below reference Thread ID/LWP, but it'll be easier to
talk about the threads by GDB thread number.  For instance, thread 1
is LWP 28370 while thread 3 is LWP 28378.  So, the explanations below
translate the LWPs into thread numbers.

Back to what happens while we are trying to "next' our program:
    (gdb) n
    infrun: clear_proceed_status_thread (Thread 0xb7a56ba0 (LWP 28379))
    infrun: clear_proceed_status_thread (Thread 0xb7c5aba0 (LWP 28378))
    infrun: clear_proceed_status_thread (Thread 0xb7e5eba0 (LWP 28377))
    infrun: clear_proceed_status_thread (Thread 0xb7ea18c0 (LWP 28370))
    infrun: proceed (addr=0xffffffff, signal=GDB_SIGNAL_DEFAULT)
    infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 0xb7ea18c0 (LWP 28370)] at 0x805451e
    infrun: target_wait (-1.0.0, status) =
    infrun:   28370.28370.0 [Thread 0xb7ea18c0 (LWP 28370)],
    infrun:   status->kind = stopped, signal = GDB_SIGNAL_TRAP
    infrun: TARGET_WAITKIND_STOPPED
    infrun: stop_pc = 0x8054523

We've resumed thread 1 (LWP 28370), and received in return a signal
that the same thread stopped slightly further.  It's still in the
range of instructions for the line of source we started the "next"
from, as evidenced by the following trace...

    infrun: stepping inside range [0x805451e-0x8054531]

... and thus, we decide to continue stepping the same thread:

    infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 0xb7ea18c0 (LWP 28370)] at 0x8054523
    infrun: prepare_to_wait

That's when we get an event from a different thread (thread 3)...

    infrun: target_wait (-1.0.0, status) =
    infrun:   28370.28378.0 [Thread 0xb7c5aba0 (LWP 28378)],
    infrun:   status->kind = stopped, signal = GDB_SIGNAL_TRAP
    infrun: TARGET_WAITKIND_STOPPED
    infrun: stop_pc = 0x80782d0
    infrun: context switch
    infrun: Switching context from Thread 0xb7ea18c0 (LWP 28370) to Thread 0xb7c5aba0 (LWP 28378)

... which we find to be at the address where we set a breakpoint on
"the unwinder debug hook" (namely "_Unwind_DebugHook").  But GDB fails
to notice that the breakpoint was inserted for thread 1 only, and so
decides to handle it as...

    infrun: BPSTAT_WHAT_SET_LONGJMP_RESUME

... and inserts a breakpoint at the corresponding resume address, as
evidenced by this the next log:

    infrun: exception resume at 80542a2

That breakpoint seems innocent right now, but will play a role fairly
quickly.  But for now, GDB has inserted the exception-resume
breakpoint, and needs to single-step thread 3 past the breakpoint it
just hit.  Thus, it temporarily disables the exception breakpoint, and
requests a step of that thread:

    infrun: skipping breakpoint: stepping past insn at: 0x80782d0
    infrun: skipping breakpoint: stepping past insn at: 0x80782d0
    infrun: skipping breakpoint: stepping past insn at: 0x80782d0
    infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current thread [Thread 0xb7c5aba0 (LWP 28378)] at 0x80782d0
    infrun: prepare_to_wait

We then get a notification, still from thread 3, that it's now past
that breakpoint...

    infrun: prepare_to_wait
    infrun: target_wait (-1.0.0, status) =
    infrun:   28370.28378.0 [Thread 0xb7c5aba0 (LWP 28378)],
    infrun:   status->kind = stopped, signal = GDB_SIGNAL_TRAP
    infrun: TARGET_WAITKIND_STOPPED
    infrun: stop_pc = 0x8078424

... so we can resume what we were doing before, which is single-stepping
thread 1 until we get to a new line of code:

    infrun: switching back to stepped thread
    infrun: Switching context from Thread 0xb7c5aba0 (LWP 28378) to Thread 0xb7ea18c0 (LWP 28370)
    infrun: expected thread still hasn't advanced
    infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 0xb7ea18c0 (LWP 28370)] at 0x8054523

The "resume" log above shows that we're resuming thread 1 from where
we left off (0x8054523).  We get one more stop at 0x8054529, which is
still inside our stepping range so we go again.  That's when we get
the following event, from thread 3:

    infrun: prepare_to_wait
    infrun: target_wait (-1.0.0, status) =
    infrun:   28370.28378.0 [Thread 0xb7c5aba0 (LWP 28378)],
    infrun:   status->kind = stopped, signal = GDB_SIGNAL_TRAP
    infrun: TARGET_WAITKIND_STOPPED
    infrun: stop_pc = 0x80542a2

Now the stop_pc address is interesting, because it's the address of
"exception resume" breakpoint...

    infrun: context switch
    infrun: Switching context from Thread 0xb7ea18c0 (LWP 28370) to Thread 0xb7c5aba0 (LWP 28378)
    infrun: BPSTAT_WHAT_CLEAR_LONGJMP_RESUME

... and since that location is at a different line of code, this is
where it decides the "next" operation should stop:

    infrun: stop_waiting
    [Switching to Thread 0xb7c5aba0 (LWP 28378)]
    0x080542a2 in inte_tache_rt.ttache_rt (
        <_task>=0x80968ec <inte_tache_rt_inst.tache2>)
        at /[...]/inte_tache_rt.adb:54
    54            end loop;

However, what GDB should have noticed earlier that the exception
breakpoint we hit was for a different thread, thus should have
single-stepped that thread out of the breakpoint _without_ inserting
the exception-return breakpoint, and then resumed the single-stepping
of the initial thread (thread 1) until that thread stepped out of its
stepping range.

This is what this patch does, and after applying it, GDB now correctly
stops on the next line of code.

The patch adds a C++ test that exercises this, both for setjmp/longjmp
and exception breakpoints.  With an unpatched GDB it shows:

 (gdb) next
 [Switching to Thread 22445.22455]
 thread_try_catch (arg=0x0) at /home/pedro/gdb/mygit/build/../src/gdb/testsuite/gdb.threads/next-other-thr-longjmp.c:59
 59            catch (...)
 (gdb) FAIL: gdb.threads/next-other-thr-longjmp.exp: next to line 1
 next
 /home/pedro/gdb/mygit/build/../src/gdb/infrun.c:4865: internal-error: process_event_stop_test: Assertion `ecs->event_thread->control.exception_resume_breakpoint != NULL' fa
 iled.
 A problem internal to GDB has been detected,
 further debugging may prove unreliable.
 Quit this debugging session? (y or n) FAIL: gdb.threads/next-other-thr-longjmp.exp: next to line 2 (GDB internal error)
 Resyncing due to internal error.
 n

Tested on x86_64-linux, no regressions.

gdb/ChangeLog:
2015-08-05  Pedro Alves  <palves@redhat.com>
    Joel Brobecker  <brobecker@adacore.com>

        * breakpoint.c (bpstat_what) <bp_longjmp, bp_longjmp_call_dummy>
<bp_exception, bp_longjmp_resume, bp_exception_resume>: Handle the
case where BS->STOP is not set.

gdb/testsuite/ChangeLog:
2015-08-05  Pedro Alves  <palves@redhat.com>

* gdb.threads/next-while-other-thread-longjmps.c: New file.
* gdb.threads/next-while-other-thread-longjmps.exp: New file.

Change the behaviour of the --only-keep-debug option to objcopy and strip so that the sh_link and sh_info fields in stripped section headers are preserved.

bfd * elf.c (_bfd_elf_copy_private_bfd_data): Copy the sh_link and
sh_info fields of sections whose type has been changed to
SHT_NOBITS.

bin * doc/binutils.texi: Document that the --only-keep-debug option
to strip and objcopy preserves the section headers of stripped
sections.

tests * binutils-all/objcopy.exp (keep_debug_symbols_and_check_links):
New proc.  Checks that debug-info-only binaries retain the
sh_link field in stripped sections.

Protect nat/gdb_thread_db.h against multiple inclusion.

Fixes a build error due to typedef redefinition with some compilers.

Also added missing copyright header.

gdb/
* nat/gdb_thread_db.h: Add copyright header.
Protect against multiple inclusion.

Fix building GDB for the M32C by providing a stub sim_info function.

* gdb-if.c (sim_info): Stub function to allow GDB to be built
with this simulator.

Remove get_thread_id

This patch removes get_thread_id from aarch64-linux-nat.c,
arm-linux-nat.c and xtensa-linux-nat.c.

get_thread_id was added in this commit below in 2000,

  41c49b06c471443d3baf2eaa2463a315f9b5edca
  https://sourceware.org/ml/gdb-patches/2000-04/msg00398.html

which predates the ptid_t stuff added into GDB.  Nowadays, lwpid of
inferior_ptid is only zero when the inferior is created (in
fork-child.c:fork_inferior) and its lwpid will be set after
linux_nat_wait_1 gets the first event.  After that, lwpid of
inferior_ptid is not zero for linux-nat target, then we can use
ptid_get_lwp, so this function isn't needed anymore.

Even when GDB attaches to a process, the lwp of inferior_ptid
isn't zero,  see linux-nat.c:linux_nat_attach,

  /* The ptrace base target adds the main thread with (pid,0,0)
     format.  Decorate it with lwp info.  */
  ptid = ptid_build (ptid_get_pid (inferior_ptid),
     ptid_get_pid (inferior_ptid),
     0);

Note that linux_nat_xfer_partial shifts lwpid to pid for inferior_ptid
temperately for calling linux_ops->to_xfer_partial, but all the
affected functions in this patch are not called in
linux_ops->to_xfer_partial.

I think we can safely remove get_thread_id for all linux native targets.

Regression tested on arm-linux and aarch64-linux.  Unable to build
native GDB and test it on xtensa-linux.

gdb:

2015-08-05  Yao Qi  <yao.qi@linaro.org>

* aarch64-linux-nat.c (get_thread_id): Remove.
(debug_reg_change_callback): Call ptid_get_lwp instead of
get_thread_id.
(fetch_gregs_from_thread): Likewise.
(store_gregs_to_thread): Likewise.
(fetch_fpregs_from_thread): Likewise.
(store_fpregs_to_thread): Likewise.
(aarch64_linux_get_debug_reg_capacity): Likewise.
* arm-linux-nat.c (get_thread_id): Remove.
(GET_THREAD_ID): Update macro to use ptid_get_lwp.
* xtensa-linux-nat.c (get_thread_id): Remove.
(GET_THREAD_ID): Update macro to use ptid_get_lwp.
* arm-linux-nat.c (get_thread_id): Remove.
(GET_THREAD_ID): Remove.
(fetch_fpregs): Call ptid_get_lwp instead of GET_THREAD_ID.
(store_fpregs, fetch_regs, store_regs): Likewise.
(fetch_wmmx_regs, store_wmmx_regs): Likewise.
(fetch_vfp_regs, store_vfp_regs): Likewise.
(arm_linux_read_description): Likewise.
(arm_linux_get_hwbp_cap): Likewise.
* xtensa-linux-nat.c (get_thread_id): Remove.
(GET_THREAD_ID): Remove.
(fetch_gregs, store_gregs): Call ptid_get_lwp instead of
GET_THREAD_ID.

Automatic date update in version.in

python: fix Linetable case to LineTable in docstrings and comments

The class is called LineTable, not Linetable, as specified by
py-linetable.c/gdbpy_initialize_linetable:

    if (gdb_pymodule_addobject (gdb_module, "LineTable",

gdb/ChangeLog:

        * python/py-linetable.c: Fix case of Linetable to LineTable
        in docstrings and code comments.
        * python/py-symtab.c: Same.

Fix stack buffer overflows when parsing corrupt ihex files.

PR binutils/18750
* ihex.c (ihex_scan): Fixes incorrect escape sequence in error message
and stack overflow when char is signed and \200-\376 was in place of hex
digit; also fixes \377 was handled as EOF instead of "incorrect character".
(ihex_read_section): Changed for consistency.
(ihex_bad_byte): Prevent (now impossible to trigger) stack
overflow and incorrect escape sequence handling.
* srec.c (srec_bad_byte): Likewise.

* readelf.c (process_mips_specific): Fix incorrect escape
sequence handling.

Fix memory leak in ar if it encounters an invalid path whilst extracting files.

* ar.c (extract_file): Free cbuf if the path is invalid.

Disable tracepoint support for aarch32

We only support tracepoint for aarch64.  Although arm program can run
on aarch64, GDBserver doesn't support tracepoint for it.

gdb/gdbserver:

2015-08-04  Yao Qi  <yao.qi@linaro.org>

* linux-aarch64-low.c (aarch64_supports_tracepoints): Return 0
if current_thread is 32 bit.

Disable Z0 packet on aarch64 on multi-arch debugging

In multi-arch debugging, if GDB sends Z0 packet, GDBserver should be
able to do several things below:

 - choose the right breakpoint instruction to insert according to the
   information available, such as 'kind' in Z0 packet and address,

 - choose the right breakpoint instruction to check memory writes and
   validate inserted memory breakpoint

 - be aware of different breakpoint instructions in $ARCH_breakpoint_at.

unfortunately GDBserver can't do them now.  Although x86 GDBserver
supports multi-arch, it doesn't need to support them above because
breakpoint instruction on i686 and x86_64 is the same.  However,
breakpoint instructions on aarch64 and arm (arm mode, thumb1, and thumb2)
are different.

I tried to teach aarch64 GDBserver backend to be really
multi-arch-capable in the following ways,

 - linux_low_target return the right breakpoint instruction according to
   the 'kind' in Z0 packet, and insert_memory_breakpoint can do the right
   thing.
 - once breakpoint is inserted, the breakpoint data and length is recorded
   in each breakpoint object, so that validate_breakpoint and
   check_mem_write can get the right breakpoint instruction from each
   breakpoint object, rather than from global variable breakpoint_data.
 - linux_low_target needs another hook function for pc increment after
   hitting a breakpoint.
 - let set_breakpoint_at, which is widely used for tracepoint, use the
   'default' breakpoint instruction.  We can always use aarch64 breakpoint
   instruction since arm doesn't support tracepoint yet.

looks it is not a small piece of work, so I decide to disable Z0 packet
on multi-arch, which means aarch64 GDBserver only supports Z0 packet
if it is started to debug only one process (extended protocol is not
used) and process target description is 64-bit.

gdb/gdbserver:

2015-08-04  Yao Qi  <yao.qi@linaro.org>

* linux-aarch64-low.c (aarch64_supports_z_point_type): Return
0 for Z_PACKET_SW_BP if it may be used in multi-arch debugging.
* server.c (extended_protocol): Remove "static".
* server.h (extended_protocol): Declare it.

Get and set PC correctly on aarch64 in multi-arch

gdb/gdbserver:

2015-08-04  Yao Qi  <yao.qi@linaro.org>

* linux-aarch64-low.c (aarch64_get_pc): Get PC register on
both aarch64 and aarch32.
(aarch64_set_pc): Likewise.

Use arm target description and regs_info for 32-bit file on aarch64 GDBserver

This patch teaches aarch64-linux GDBserver use 32-bit arm target
description and regs_info if the elf file is 32-bit.

gdb/gdbserver:

2015-08-04  Yao Qi  <yao.qi@linaro.org>

* configure.srv (case aarch64*-*-linux*): Append arm-with-neon.o
to srv_regobj and append arm-core.xml arm-vfpv3.xml and
arm-with-neon.xml to srv_xmlfiles.
* linux-aarch64-low.c: Include linux-aarch32-low.h.
(is_64bit_tdesc): New function.
(aarch64_linux_read_description): New function.
(aarch64_arch_setup): Call aarch64_linux_read_description.
(regs_info): Rename to regs_info_aarch64.
(aarch64_regs_info): Return right regs_info.
(initialize_low_arch): Call initialize_low_arch_aarch32.

New regs_info for aarch32

This patch adds a new regs_info regs_info_aarch32 for aarch32, which
can be used by both aarch64 and arm backend.

gdb/gdbserver:

2015-08-04  Yao Qi  <yao.qi@linaro.org>

* configure.srv (srv_tgtobj): Add linux-aarch32-low.o.
* linux-aarch32-low.c: New file.
* linux-aarch32-low.h: New file.
* linux-arm-low.c (arm_fill_gregset): Move it to
linux-aarch32-low.c.
(arm_store_gregset): Likewise.
(arm_fill_vfpregset): Call arm_fill_vfpregset_num
(arm_store_vfpregset): Caa arm_store_vfpregset_num.
(arm_arch_setup): Check if PTRACE_GETREGSET works.
(regs_info): Rename to regs_info_arm.
(arm_regs_info): Return regs_info_aarch32 if
have_ptrace_getregset is 1 and target description is
arm_with_neon or arm_with_vfpv3.
(initialize_low_arch): Don't call init_registers_arm_with_neon.
Call initialize_low_arch_aarch32 instead.

Move have_ptrace_getregset to linux-low.c

This patch moves variable have_ptrace_getregset from linux-x86-low.c
to linux-low.c, so that arm can use it too.

gdb/gdbserver:

2015-08-04  Yao Qi  <yao.qi@linaro.org>

* linux-x86-low.c (have_ptrace_getregset): Move it to ...
* linux-low.c: ... here.
* linux-low.h (have_ptrace_getregset): Declare it.

signal_command: Leftover cleanup chain regression

gdb/ChangeLog
2015-08-04  Jan Kratochvil  <jan.kratochvil@redhat.com>

* infcmd.c (signal_command): Call do_cleanups for args_chain.

ASAN attach crash - 7.9 regression

-fsanitize=address
gdb.base/attach-pie-noexec.exp

==32586==ERROR: AddressSanitizer: heap-use-after-free on address 0x60200004ed90 at pc 0x48ad50 bp 0x7ffceb3aef50 sp 0x7ffceb3aef20
READ of size 2 at 0x60200004ed90 thread T0
    #0 0x48ad4f in __interceptor_strlen (/home/jkratoch/redhat/gdb-test-asan/gdb/gdb+0x48ad4f)
    #1 0xeafe5c in xstrdup xstrdup.c:33
    #2 0x85e024 in attach_command /home/jkratoch/redhat/gdb-test-asan/gdb/infcmd.c:2680

regressed by:

commit 6c4486e63f7583ed85a0c72841f6ccceebbf858e
Author: Pedro Alves <palves@redhat.com>
Date:   Fri Oct 17 13:31:26 2014 +0100
    PR gdb/17471: Repeating a background command makes it foreground

gdb/ChangeLog
2015-08-04  Jan Kratochvil  <jan.kratochvil@redhat.com>

PR gdb/18767
* infcmd.c (attach_command): Move ARGS_CHAIN cleanup after last ARGS
use.

ld: map option for run_dump_test requires no program.

When using run_dump_test with the map option to compare the linker map
file produced, no additional dump program should be required.  A dump
program can still be given if needed, but leaving it off will no longer
produce an error.

ld/testsuite/ChangeLog:

* ld/ld-lib.exp (run_dump_test): When using the map option, no
program is required.

ld: Add file based error/warning regexp for run_dump_test.

The run_dump_test mechanism supports options error and warning, which
allow regexp to be specified within the test file, these regexp are
matched against the stderr output from the linker.

Similar dump test style functions for gas and gdb also support file
based matching versions of these options; the patterns are placed into a
file which the test driver then references.  It is sometimes clearer,
when the pattern to be matched spans multiple lines if the patterns can
be placed into a separate file.

This patch adds new options error_output and warning_output for the
linker run_dump_test function.  These new options take a filename
parameter, this file is then used (with regexp_diff) to compare against
the linker output.

ld/testsuite/ChangeLog:

* ld/ld-lib.exp (run_dump_test): Add error_output and
warning_output options.

ld: Add '--require-defined' command line option.

Add a new command line option '--require-defined' to the linker.  This
option operates identically to the '--undefined' option, except that if
the symbol is not defined in the final output file then the linker will
exit with an error.

When making use of --gc-section, or just when trying to pull in parts of
a library, it is not uncommon for a user to use the '--undefined'
command line option to specify a symbol that the user then expects to be
defined by one of the object files supplied to the link.

However, if for any reason the symbol is not satisfied by an object
provided to the link the user will be left with an undefined symbol in
the output file, instead of a defined symbol.

In some cases the above behaviour is what the user wants, in other cases
though we can do better.  The '--require-defined' option tries to fill
this gap.  The symbol passed to the '--require-defined' option is
treated exactly as if the symbol was passed to '--undefined', however,
before the linker exits a check is made that all symbols passed to
'--require-defined' are actually defined, if any are not then the link
will fail with an error.

ld/ChangeLog:

* ld.texinfo (Options): Document --require-defined option.
* ldlang.c (struct require_defined_symbol): New structure.
(require_defined_symbol_list): New variable.
(ldlang_add_require_defined): New function.
(ldlang_check_require_defined_symbols): New function.
(lang_process): Check required symbols are defined.
* ldlang.h (ldlang_add_require_defined): Declare.
* ldlex.h (enum option_values): Add OPTION_REQUIRE_DEFINED_SYMBOL.
* lexsup.c (ld_options): Add '--require-defined' entry.
(parse_args): Handle '--require-defined' entry.
* NEWS: Mention new '--require-defined' option.

ld/testsuite/ChangeLog:

* ld-undefined/require-defined-1.d: New file.
* ld-undefined/require-defined-2.d: New file.
* ld-undefined/require-defined-3.d: New file.
* ld-undefined/require-defined-4.d: New file.
* ld-undefined/require-defined-5.d: New file.
* ld-undefined/require-defined.exp: New file.
* ld-undefined/require-defined.s: New file.

C++: dlsym casts in gdb/linux-thread-db.c and gdb/gdbserver/thread-db.c

Implicit void * -> function pointer conversion doesn't work in C++, so
in C++, we need to cast the result of dlsym.  This adds a few typedefs
and macros that make this easy.  GDBserver's version already had the
CHK macro, so I added it to GDB too.

Tested on x86_64 Fedora 20, native and gdbserver.

gdb/gdbserver/ChangeLog:
2015-08-04  Pedro Alves  <palves@redhat.com>

* thread-db.c (struct thread_db): Use new typedefs.
(try_thread_db_load_1): Define local TDB_DLSYM macro and use it in
CHK calls.
(disable_thread_event_reporting): Cast result of dlsym to
destination function pointer type.
(thread_db_mourn): Use td_ta_delete_ftype.

gdb/ChangeLog:
2015-08-04  Pedro Alves  <palves@redhat.com>

* nat/gdb_thread_db.h (td_init_ftype, td_ta_new_ftype)
(td_ta_map_lwp2thr_ftype, td_ta_thr_iter_ftype)
(td_ta_event_addr_ftype, td_ta_set_event_ftype)
(td_ta_clear_event_ftype, td_ta_event_getmsg_ftype)
(td_thr_validate_ftype, td_thr_get_info_ftype)
(td_thr_event_enable_ftype, td_thr_tls_get_addr_ftype)
(td_thr_tlsbase_ftype, td_symbol_list_ftype, td_ta_delete_ftype):
New typedefs.
* linux-thread-db.c (struct thread_db_info): Use new typedefs.
(try_thread_db_load_1): Define TDB_VERBOSE_DLSYM, TDB_DLSYM , CHK
local macros and use them instead of verbose_dlsym and dlsym
calls.

Update description of proc run_dump_test

* lib/utils-lib.exp (run_dump_test): Document DUMPPROG, readelf
and size parameters.  Alpha-sort switch tables.  Include
addr2line, and size in list of possible auto-detected dump
programs.

2015-08-04  Thomas Preud'homme  <thomas.preudhomme@arm.com>

        * doc/c-aarch64.texi (.xword): Document directive.

Automatic date update in version.in

ld/doc: Document that multiple MEMORY commands are allowed.

The linker documentation explicitly states that there can be only one
MEMORY command.  This is not true.  Multiple MEMORY commands are
allowed, the contents of all will be treated as if a single MEMORY
command was given.

Update the documentation to make this clear to the users.

ld/ChangeLog:

* ld.texinfo (MEMORY): Explain that multiple MEMORY commands are
acceptable.

Fix ChangeLog for "FAIL: -Bsymbolic-functions" for cris-linux in ld

It's bfd_link_info, not elf_link_hash_entry, for the old reference:

* elf32-cris.c (cris_elf_relocate_section)
(elf_cris_finish_dynamic_symbol, cris_elf_check_relocs)
(elf_cris_discard_excess_dso_dynamics): Use SYMBOLIC_BIND, not
just bfd_link_info->symbolic, to check if a symbol should be bound
symbolically.

Nios II R2 support for GDB.

2015-08-03  Sandra Loosemore  <sandra@codesourcery.com>

gdb/
* nios2-tdep.h: Include opcode/nios2.h here.
(NIOS2_CDX_OPCODE_SIZE): New.
(struct gdbarch_tdep): Add OP parameter to syscall_next_pc.
* nios2-tdep.c: Don't include opcode/nios2.h here.
(nios2_fetch_insn): For R2, try reading 2-byte instruction if
4-byte read fails.
(nios2_match_add, nios2_match_sub): Add cases for R2 encodings.
(nios2_match_addi, nios2_match_orhi): Likewise.
(nios2_match_stw, nios2_match_ldw): Likewise.
(nios2_match_rdctl): Likewise.
(nios2_match_stwm, nios2_match_ldwm): New.
(nios2_match_branch): Add cases for R2 encodings.
(nios2_match_jmpi, nios2_match_calli): Likewise.
(nios2_match_jmpr, nios2_match_callr): Likewise.
(nios2_match_break, nios2_match_trap): Likewise.
(nios2_in_epilogue_p): Add R2 support.
(nios2_analyze_prologue): Update comments.  Recognize R2 CDX
prologues.
(nios2_breakpoint_from_pc): Handle R2 instructions.
(nios2_get_next_pc): Likewise.  Adjust call to
tdep->syscall_next_pc.
* nios2-linux-tdep.c (nios2_r1_linux_rt_sigreturn_tramp_frame):
Renamed from nios2_linux_rt_sigreturn_tramp_frame.  Use
instruction field macros instead of literal hex values.
(nios2_r2_linux_rt_sigreturn_tramp_frame): New.
(nios2_linux_syscall_next_pc): Adjust signature to pass OP.
Use size field from OP instead of assuming all instructions
are the same size.
(nios2_linux_init_abi): Register appropriate unwinder for mach.

gdb/gdbserver/
* linux-nios2-low.c (NIOS2_BREAKPOINT): Conditionalize for
arch variant.
(CDX_BREAKPOINT): Define for R2.
(nios2_breakpoint_at): Check for CDX_BREAKPOINT when R2.
(the_low_target): Add comments.

Fix "FAIL: -Bsymbolic-functions" for cris-linux in ld

* elf32-cris.c (cris_elf_relocate_section)
(elf_cris_finish_dynamic_symbol, cris_elf_check_relocs)
(elf_cris_discard_excess_dso_dynamics): Use SYMBOLIC_BIND, not
just h->symbolic, to check if a symbol should be bound
symbolically.

Further robustify gdb.base/bp-permanent.exp.

2015-08-03  Sandra Loosemore  <sandra@codesourcery.com>

gdb/testsuite/
* gdb.base/bp-permanent.exp: Report test as unsupported if
the target cannot stop at the permanent breakpoint.

dwarf2read.c: fix latent buglet

cust->includes is:

struct compunit_symtab
{
...
  struct compunit_symtab **includes;

gdb/ChangeLog:
2015-08-03  Pedro Alves  <palves@redhat.com>

* dwarf2read.c (compute_compunit_symtab_includes): Use size of struct
compunit_symtab pointer.

Missing changelog entry for previous commit: Add gmonster-{1,2} perf testcases.

These testcases are mocks of real programs.
GDB doesn't care what the programs do, they just have to look
and/or behave like the real program.
These testcases exercise gdb when debugging really large programs.
E.g., gmonster-1 has 10,000 CUs, and gmonster-2 has 1000 shared libs
(which is actually a little small, 5000 would be more accurate).

gdb/testsuite/ChangeLog:

* gdb.perf/lib/perftest/utils.py: New file.
* gdb.perf/gm-hello.cc: New file.
* gdb.perf/gm-pervasive-typedef.cc: New file.
* gdb.perf/gm-pervasive-typedef.h: New file.
* gdb.perf/gm-std.cc: New file.
* gdb.perf/gm-std.h: New file.
* gdb.perf/gm-use-cerr.cc: New file.
* gdb.perf/gm-utils.h: New file.
* gdb.perf/gmonster-null-lookup.py: New file.
* gdb.perf/gmonster-pervasive-typedef.py: New file.
* gdb.perf/gmonster-print-cerr.py: New file.
* gdb.perf/gmonster-ptype-string.py: New file.
* gdb.perf/gmonster-runto-main.py: New file.
* gdb.perf/gmonster-select-file.py: New file.
* gdb.perf/gmonster1-null-lookup.exp: New file.
* gdb.perf/gmonster1-pervasive-typedef.exp: New file.
* gdb.perf/gmonster1-print-cerr.exp: New file.
* gdb.perf/gmonster1-ptype-string.exp: New file.
* gdb.perf/gmonster1-runto-main.exp: New file.
* gdb.perf/gmonster1-select-file.exp: New file.
* gdb.perf/gmonster1.cc: New file.
* gdb.perf/gmonster1.exp: New file.
* gdb.perf/gmonster2-null-lookup.exp: New file.
* gdb.perf/gmonster2-pervasive-typedef.exp: New file.
* gdb.perf/gmonster2-print-cerr.exp: New file.
* gdb.perf/gmonster2-ptype-string.exp: New file.
* gdb.perf/gmonster2-runto-main.exp: New file.
* gdb.perf/gmonster2-select-file.exp: New file.
* gdb.perf/gmonster2.cc: New file.
* gdb.perf/gmonster2.exp: New file.

Fix file paths in earlier entry.

gdb.perf/single-step.exp (SINGLE_STEP_COUNT): Change to 1000 from 10000.

single-step.exp takes a while to run, and while that's not necessarily
bad, here it's because the default value of SINGLE_STEP_COUNT is 10,000.
We're not going to gain any more insight into perf issues
single-stepping (stepi) 10,000 times over 1,000 times,
so this patch changes the default to 1,000.

gdb/testsuite/ChangeLog:

* gdb.perf/single-step.exp (SINGLE_STEP_COUNT): Change to 1000 from
10000.

Add parallel build support for perf tests.

gdb/testsuite/ChangeLog:

* Makefile.in (workers/%.worker, build-perf): New rule.
(GDB_PERFTEST_MODE): New variable.
(check-perf): Use it.
(clean): Clean up gdb.perf parallel build subdirs.
* lib/build-piece.exp: New file.
* lib/gdb.exp (make_gdb_parallel_path): New function
(standard_output_file, standard_temp_file): Call it.
(GDB_PARALLEL handling): Make outputs,temp,cache directories as subdirs
of $GDB_PARALLEL.
* lib/cache.exp (gdb_do_cache): Call make_gdb_parallel_path.

Move basic perf-test output from perftest.log to perftest.sum.

This patch does two things.
1) Add support for multiple data points.
2) Move the "report" output from perftest.log to perftest.sum.

I want to record the raw data somewhere, and a bit of statistical analysis
(standard deviation left for another day), but I also don't want
it to clutter up the basic report.
This patch takes a cue from gdb.{sum,log} and does the same thing
with perftest.{sum,log}.
Ultimately, we'll probably want to emit raw data to csv files or some
such and then do post-processing passes on that.

gdb/testsuite/ChangeLog:

* lib/perftest/reporter.py (SUM_FILE_NAME): New global.
(LOG_FILE_NAME): New global.
(TextReporter.__init__): Initialize self.txt_sum.
(TextReporter.report): Add support for multiple data-points.
Move report to perftest.sum, put raw data in perftest.log.
(TextReporter.start): Open sum and log files.
(TextReporter.end): Close sum and log files.
* lib/perftest/testresult.py (SingleStatisticTestResult.record): Handle
multiple data-points.

Fix build error due to uninitialized variable warning

As of commit a5fdf78a4402341a0ae23a5ca8a63825e2b5286c, building GDB with
a GCC 4.1 host compiler fails with:

gdb/cp-namespace.c: In function 'cp_lookup_symbol_via_imports':
gdb/cp-namespace.c:482: warning: 'sym.block' may be used uninitialized in this function

Apparently, more recent compilers are able to deduce that no actual
uninitialized use of sym.block takes place, but GCC 4.1 isn't yet
able to do that.

Fixed by adding an explicit initalization.

gdb/
* cp-namespace.c (cp_lookup_symbol_via_imports): Fix uninitialized
variable warning with some compilers.

Enum fix for arm-linux-nat.c

This patch fixes GDB build breakage on arm-linux.

gdb:

2015-08-03  Yao Qi  <yao.qi@linaro.org>

* arm-linux-nat.c (arm_linux_get_hwbp_type): Capitalize "type"
in comment.  Replace "rw" with "type".
(arm_linux_remove_watchpoint): Change type of "rw" to
"enum target_hw_bp_type".

Fix thinkos in the description of the --hash-size command line option for GAS.

* doc/as.texinfo (Overview): Add --hash-size to the synopsis and
fix typo in its entry: @kindex -> @item.

Fix the block_found refactoring ChangeLog entry

Replace the old "struct symbol_in_block" with the actual "struct
block_symbol", fix a typo and remove mention to an unmodified function.

Automatic date update in version.in

Unbreak PPC gdb builds

Commit f486487f5586 (Mostly trivial enum fixes) missed updating
ppc-linux-nat.c, resulting in:

 ../../src/gdb/ppc-linux-nat.c: In function ‘_initialize_ppc_linux_nat’:
 ../../src/gdb/ppc-linux-nat.c:2503:27: error: assignment from incompatible pointer type [-Werror]
 ../../src/gdb/ppc-linux-nat.c:2504:27: error: assignment from incompatible pointer type [-Werror]

gdb/ChangeLog
2015-08-02  Pedro Alves  <palves@redhat.com>

* ppc-linux-nat.c (get_trigger_type, create_watchpoint_request)
(ppc_linux_insert_watchpoint, ppc_linux_remove_watchpoint): Change
parameter 'rw's type to enum target_hw_bp_type and rename to
'type'.

Complete the previous commit (block_found refactoring)

The previous commit (Replace the block_found global with explicit
data-flow) lacks updates in a couple of files because it was not
tested building GDB with --enable-targets=all... but buildbots did.
This adds the appropriate simple updates to fix the build.

gdb/ChangeLog:

* alpha-mdebug-tdep.c (find_proc_desc): Update call to
lookup_symbol.
* ft32-tdep.c (ft32_skip_prologue): Likewise.
* moxie-tdep.c (moxie_skip_prologue): Likewise.
* mt-tdep.c (mt_skip_prologue): Likewise.
* xstormy16-tdep.c (xstormy16_skip_prologue): Likewise.

Automatic date update in version.in

Replace the block_found global with explicit data-flow

As Pedro suggested on gdb-patches@ (see
https://sourceware.org/ml/gdb-patches/2015-05/msg00714.html), this
change makes symbol lookup functions return a structure that includes
both the symbol found and the block in which it was found.  This makes
it possible to get rid of the block_found global variable and thus makes
block hunting explicit.

gdb/

* ada-exp.y (write_object_renaming): Replace struct
ada_symbol_info with struct block_symbol.  Update field
references accordingly.
(block_lookup, select_possible_type_sym): Likewise.
(find_primitive_type): Likewise.  Also update call to
ada_lookup_symbol to extract the symbol itself.
(write_var_or_type, write_name_assoc): Likewise.
* ada-lang.h (struct ada_symbol_info): Remove.
(ada_lookup_symbol_list): Replace struct ada_symbol_info with
struct block_symbol.
(ada_lookup_encoded_symbol, user_select_syms): Likewise.
(ada_lookup_symbol): Return struct block_symbol instead of a
mere symbol.
* ada-lang.c (defns_collected): Replace struct ada_symbol_info
with struct block_symbol.
(resolve_subexp, ada_resolve_function, sort_choices,
user_select_syms, is_nonfunction, add_defn_to_vec,
num_defns_collected, defns_collected,
symbols_are_identical_enums, remove_extra_symbols,
remove_irrelevant_renamings, add_lookup_symbol_list_worker,
ada_lookup_symbol_list, ada_iterate_over_symbols,
ada_lookup_encoded_symbol, get_var_value): Likewise.
(ada_lookup_symbol): Return a block_symbol instead of a mere
symbol.  Replace struct ada_symbol_info with struct
block_symbol.
(ada_lookup_symbol_nonlocal): Likewise.
(standard_lookup): Make block passing explicit through
lookup_symbol_in_language.
* ada-tasks.c (get_tcb_types_info): Update the calls to
lookup_symbol_in_language to extract the mere symbol out of the
returned value.
(ada_tasks_inferior_data_sniffer): Likewise.
* ax-gdb.c (gen_static_field): Likewise for the call to
lookup_symbol.
(gen_maybe_namespace_elt): Deal with struct symbol_in_block from
lookup functions.
(gen_expr): Likewise.
* c-exp.y: Likewise.  Remove uses of block_found.
(lex_one_token, classify_inner_name, c_print_token): Likewise.
(classify_name): Likewise.  Rename the "sym" local variable to
"bsym".
* c-valprint.c (print_unpacked_pointer): Likewise.
* compile/compile-c-symbols.c (convert_symbol_sym): Promote the
"sym" parameter from struct symbol * to struct block_symbol.
Use it to remove uses of block_found.  Deal with struct
symbol_in_block from lookup functions.
(gcc_convert_symbol): Likewise.  Update the call to
convert_symbol_sym.
* compile/compile-object-load.c (compile_object_load): Deal with
struct symbol_in_block from lookup functions.
* cp-namespace.c (cp_lookup_nested_symbol_1,
cp_lookup_nested_symbol, cp_lookup_bare_symbol,
cp_search_static_and_baseclasses,
cp_lookup_symbol_in_namespace, cp_lookup_symbol_via_imports,
cp_lookup_symbol_imports_or_template,
cp_lookup_symbol_via_all_imports, cp_lookup_symbol_namespace,
lookup_namespace_scope, cp_lookup_nonlocal,
find_symbol_in_baseclass): Return struct symbol_in_block instead
of mere symbols and deal with struct symbol_in_block from lookup
functions.
* cp-support.c (inspect_type, replace_typedefs,
cp_lookup_rtti_type): Deal with struct symbol_in_block from
lookup functions.
* cp-support.h (cp_lookup_symbol_nonlocal,
cp_lookup_symbol_from_namespace,
cp_lookup_symbol_imports_or_template, cp_lookup_nested_symbol):
Return struct symbol_in_block instead of mere symbols.
* d-exp.y (d_type_from_name, d_module_from_name, push_variable,
push_module_name):
Deal with struct symbol_in_block from lookup functions.  Remove
uses of block_found.
* eval.c (evaluate_subexp_standard): Update call to
cp_lookup_symbol_namespace.
* f-exp.y: Deal with struct symbol_in_block from lookup
functions.  Remove uses of block_found.
(yylex): Likewise.
* gdbtypes.c (lookup_typename, lookup_struct, lookup_union,
lookup_enum, lookup_template_type, check_typedef): Deal with
struct symbol_in_block from lookup functions.
* guile/scm-frame.c (gdbscm_frame_read_var): Likewise.
* guile/scm-symbol.c (gdbscm_lookup_symbol): Likewise.
(gdbscm_lookup_global_symbol): Likewise.
* gnu-v3-abi.c (gnuv3_get_typeid_type): Likewise.
* go-exp.y: Likewise.  Remove uses of block_found.
(package_name_p, classify_packaged_name, classify_name):
Likewise.
* infrun.c (insert_exception_resume_breakpoint): Likewise.
* jv-exp.y (push_variable): Likewise.
* jv-lang.c (java_lookup_class, get_java_object_type): Likewise.
* language.c (language_bool_type): Likewise.
* language.h (struct language_defn): Update
la_lookup_symbol_nonlocal to return a struct symbol_in_block
rather than a mere symbol.
* linespec.c (find_label_symbols): Deal with struct
symbol_in_block from lookup functions.
* m2-exp.y: Likewise.  Remove uses of block_found.
(yylex): Likewise.
* mi/mi-cmd-stack.c (list_args_or_locals): Likewise.
* objc-lang.c (lookup_struct_typedef, find_imps): Likewise.
* p-exp.y: Likewise.  Remove uses of block_found.
(yylex): Likewise.
* p-valprint.c (pascal_val_print): Likewise.
* parse.c (write_dollar_variable): Likewise.  Remove uses of
block_found.
* parser-defs.h (struct symtoken): Turn the SYM field into a
struct symbol_in_block.
* printcmd.c (address_info): Deal with struct symbol_in_block
from lookup functions.
* python/py-frame.c (frapy_read_var): Likewise.
* python/py-symbol.c (gdbpy_lookup_symbol,
gdbpy_lookup_global_symbol): Likewise.
* skip.c (skip_function_command): Likewise.
* solib-darwin.c (darwin_lookup_lib_symbol): Return a struct
symbol_in_block instead of a mere symbol.
* solib-spu.c (spu_lookup_lib_symbol): Likewise.
* solib-svr4.c (elf_lookup_lib_symbol): Likewise.
* solib.c (solib_global_lookup): Likewise.
* solist.h (solib_global_lookup): Likewise.
(struct target_so_ops): Update lookup_lib_global_symbol to
return a struct symbol_in_block rather than a mere symbol.
* source.c (select_source_symtab): Deal with struct
symbol_in_block from lookup functions.
* stack.c (print_frame_args, iterate_over_block_arg_vars):
Likewise.
* symfile.c (set_initial_language): Likewise.
* symtab.c (SYMBOL_LOOKUP_FAILED): Turn into a struct
symbol_in_block.
(SYMBOL_LOOKUP_FAILED_P): New predicate as a macro.
(struct symbol_cache_slot): Turn the FOUND field into a struct
symbol_in_block.
(block_found): Remove.
(eq_symbol_entry): Update to deal with struct symbol_in_block in
cache slots.
(symbol_cache_lookup): Return a struct symbol_in_block rather
than a mere symbol.
(symbol_cache_mark_found): Add a BLOCK parameter to fill
appropriately the cache slots.  Update callers.
(symbol_cache_dump): Update cache slots handling to the type
change.
(lookup_symbol_in_language, lookup_symbol, lookup_language_this,
lookup_symbol_aux, lookup_local_symbol,
lookup_symbol_in_objfile, lookup_global_symbol_from_objfile,
lookup_symbol_in_objfile_symtabs,
lookup_symbol_in_objfile_from_linkage_name,
lookup_symbol_via_quick_fns, basic_lookup_symbol_nonlocal,
lookup_symbol_in_static_block, lookup_static_symbol,
lookup_global_symbol):
Return a struct symbol_in_block rather than a mere symbol.  Deal
with struct symbol_in_block from other lookup functions.  Remove
uses of block_found.
(lookup_symbol_in_block): Remove uses of block_found.
(struct global_sym_lookup_data): Turn the RESULT field into a
struct symbol_in_block.
(lookup_symbol_global_iterator_cb): Update references to the
RESULT field.
(search_symbols): Deal with struct symbol_in_block from lookup
functions.
* symtab.h (struct symbol_in_block): New structure.
(block_found): Remove.
(lookup_symbol_in_language, lookup_symbol,
basic_lookup_symbol_nonlocal, lookup_symbol_in_static_block,
looku_static_symbol, lookup_global_symbol,
lookup_symbol_in_block, lookup_language_this,
lookup_global_symbol_from_objfile): Return a struct
symbol_in_block rather than just a mere symbol.  Update comments
to remove mentions of block_found.
* valops.c (find_function_in_inferior,
value_struct_elt_for_reference, value_maybe_namespace_elt,
value_of_this):  Deal with struct symbol_in_block from lookup
functions.
* value.c (value_static_field, value_fn_field): Likewise.

Automatic date update in version.in

testsuite: tcl exec& -> 'kill -9 $pid' is racy (attach-many-short-lived-thread.exp races and others)

The buildbots show that attach-many-short-lived-thread.exp is racy.
But after staring at debug logs and playing with SystemTap scripts for
a (long) while, I figured out that neither GDB, nor the kernel nor the
test's program itself are at fault.

The problem is simply that the testsuite machinery is currently
subject to PID-reuse races.  The attach-many-short-lived-threads.c
test program just happens to be much more susceptible to trigger this
race because threads and processes share the same number space on
Linux, and the test spawns many many short lived threads in
succession, thus enlarging the race window a lot.

Part of the problem is that several tests spawn processes with "exec&"
(in order to test the "attach" command) , and then at the end of the
test, to make sure things are cleaned up, issue a 'remote_spawn "kill
-p $testpid"'.  Since with tcl's "exec&", tcl itself is responsible
for reaping the process's exit status, when we go kill the process,
testpid may have already exited _and_ its status may have (and often
has) been reaped already.  Thus it can happen that another process
meanwhile reuses $testpid, and that "kill" command kills the wrong
process...  Frequently, that happens to be
attach-many-short-lived-thread, but this explains other test's races
as well.

In the attach-many-short-lived-threads test, it sometimes manifests
like this:

 (gdb) file /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.threads/attach-many-short-lived-threads
 Reading symbols from /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.threads/attach-many-short-lived-threads...done.
 (gdb)           Loaded /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.threads/attach-many-short-lived-threads into /home/pedro/gdb/mygit/build/gdb/testsuite/../../gdb/gdb
 attach 5940
 Attaching to program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.threads/attach-many-short-lived-threads, process 5940
 warning: process 5940 is a zombie - the process has already terminated
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 ptrace: Operation not permitted.
 (gdb) PASS: gdb.threads/attach-many-short-lived-threads.exp: iter 1: attach
 info threads
 No threads.
 (gdb) PASS: gdb.threads/attach-many-short-lived-threads.exp: iter 1: no new threads
 set breakpoint always-inserted on
 (gdb) PASS: gdb.threads/attach-many-short-lived-threads.exp: iter 1: set breakpoint always-inserted on

Other times the process dies while the test is ongoing (the process is
ptrace-stopped):

 (gdb) print again = 1
 Cannot access memory at address 0x6020cc
 (gdb) FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 2: reset timer in the inferior

(Recall that on Linux, SIGKILL is not interceptable)

And other times it dies just while we're detaching:

 $4 = 319
 (gdb) PASS: gdb.threads/attach-many-short-lived-threads.exp: iter 2: print seconds_left
 detach
 Can't detach Thread 0x7fb13b7de700 (LWP 1842): No such process
 (gdb) FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 2: detach

GDB mishandles the latter (it should ignore ESRCH while detaching just
like when continuing), but that's another story.

The fix here is to change spawn_wait_for_attach to use Expect's
'spawn' command instead of Tcl's 'exec&' to spawn programs, because
with spawn we control when to wait for/reap the process.  That allows
killing the process by PID without being subject to pid-reuse races,
because even if the process is already dead, the kernel won't reuse
the process's PID until the zombie is reaped.

The other part of the problem lies in DejaGnu itself, unfortunately.
I have occasionally seen tests (attach-many-short-lived-threads
included, but not only that one) die with a random inexplicable
SIGTERM too, and that too is caused by the same reason, except that in
that case, the rogue SIGTERM is sent from this bit in DejaGnu's remote.exp:

    exec sh -c "exec > /dev/null 2>&1 && (kill -2 $pgid || kill -2 $pid) && sleep 5 && (kill $pgid || kill $pid) && sleep 5 && (kill -9 $pgid || kill -9 $pid) &"
    ...
    catch "wait -i $shell_id"

Even if the program exits promptly, that whole cascade of kills
carries on in the background, thus potentially killing the poor
process that manages to reuse $pid...

I sent a fix for that to the DejaGnu list:
 http://lists.gnu.org/archive/html/dejagnu/2015-07/msg00000.html

With both patches in place, I haven't seen
attach-many-short-lived-threads.exp fail again.

Tested on x86_64 Fedora 20, native, gdbserver and extended-gdbserver.

gdb/testsuite/ChangeLog:
2015-07-31  Pedro Alves  <palves@redhat.com>

* gdb.base/attach-pie-misread.exp: Rename $res to $test_spawn_id.
Use spawn_id_get_pid.  Wait for spawn id after eof.  Use
kill_wait_spawned_process instead of explicit "kill -9".
* gdb.base/attach-pie-noexec.exp: Adjust to spawn_wait_for_attach
returning a spawn id instead of a pid.  Use spawn_id_get_pid and
kill_wait_spawned_process.
* gdb.base/attach-twice.exp: Likewise.
* gdb.base/attach.exp: Likewise.
(do_command_attach_tests): Use gdb_spawn_with_cmdline_opts and
gdb_test_multiple.
* gdb.base/solib-overlap.exp: Adjust to spawn_wait_for_attach
returning a spawn id instead of a pid.  Use spawn_id_get_pid and
kill_wait_spawned_process.
* gdb.base/valgrind-infcall.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.
* gdb.threads/attach-into-signal.exp (corefunc): Use
spawn_wait_for_attach, spawn_id_get_pid and
kill_wait_spawned_process.
* gdb.threads/attach-many-short-lived-threads.exp: Adjust to
spawn_wait_for_attach returning a spawn id instead of a pid.  Use
spawn_id_get_pid and kill_wait_spawned_process.
* gdb.threads/attach-stopped.exp (corefunc): Use
spawn_wait_for_attach, spawn_id_get_pid and
kill_wait_spawned_process.
* gdb.base/break-interp.exp: Rename $res to $test_spawn_id.
Use spawn_id_get_pid.  Wait for spawn id after eof.  Use
kill_wait_spawned_process instead of explicit "kill -9".
* lib/gdb.exp (can_spawn_for_attach): Adjust comment.
(kill_wait_spawned_process, spawn_id_get_pid): New procedures.
(spawn_wait_for_attach): Use spawn instead of exec to spawn
processes.  Don't map cygwin/windows pids here.  Now returns a
spawn id list.

Fix m32r_remove_watchpoint parameter type

This change should have been in the previous patch (Mostly trivial enum
fixes).

gdb/ChangeLog:

* remote-m32r-sdi.c (m32r_remove_watchpoint): Use enum type
instead of integer.

Mostly trivial enum fixes

This is a patch I extracted from Pedro's C++ branch.  It contains the
most trivial enum fixes, where an integer type/value was used instead
of the appropriate enum type/value.  It fixes many C++ errors, since
in C++ you can't mix integers and enums implicitely.

Regardless of the C++ conversion, I think this is a good cleanup to make
use of the appropriate enum types.

Regression-tested on native x86_64.

gdb/ChangeLog:

* aarch64-linux-nat.c (aarch64_linux_can_use_hw_breakpoint): Use enum
type or value instead of integer.
(aarch64_linux_insert_watchpoint): Likewise.
(aarch64_linux_remove_watchpoint): Likewise.
* ada-lang.c (ada_op_print_tab): Likewise.
* amd64-linux-tdep.c (amd64_canonicalize_syscall): Likewise.
(amd64_linux_syscall_record_common): Likewise.
* arch-utils.c (target_byte_order_user): Likewise.
(default_byte_order): Likewise.
* arm-linux-nat.c (arm_linux_can_use_hw_breakpoint): Likewise.
(arm_linux_get_hwbp_type): Likewise.
(arm_linux_hw_watchpoint_initialize): Likewise.
(arm_linux_insert_watchpoint): Likewise.
* arm-linux-tdep.c (arm_canonicalize_syscall): Likewise.
(arm_linux_syscall_record): Likewise.
* breakpoint.c (update_watchpoint): Likewise.
(breakpoint_here_p): Likewise.
(bpstat_print): Likewise.
(enable_breakpoint_disp): Likewise.
* c-lang.c (c_op_print_tab): Likewise.
* cli/cli-decode.c (add_info_alias): Likewise.
* d-lang.c (d_op_print_tab): Likewise.
* eval.c (evaluate_subexp_standard): Likewise.
* f-exp.y (dot_ops): Likewise.
(f77_keywords): Likewise.
* f-lang.c (f_op_print_tab): Likewise.
* go-lang.c (go_op_print_tab): Likewise.
* guile/scm-breakpoint.c (gdbscm_make_breakpoint): Likewise.
* guile/scm-cmd.c (gdbscm_make_command): Likewise.
* guile/scm-param.c (gdbscm_make_parameter): Likewise.
* guile/scm-pretty-print.c (gdbscm_apply_val_pretty_printer): Likewise.
* guile/scm-string.c (struct scm_to_stringn_data): Likewise.
(struct scm_from_stringn_data): Likewise.
* i386-linux-tdep.c (i386_canonicalize_syscall): Likewise.
* ia64-linux-nat.c (ia64_linux_insert_watchpoint): Likewise.
(ia64_linux_remove_watchpoint): Likewise.
(ia64_linux_can_use_hw_breakpoint): Likewise.
* infrun.c (print_stop_event): Likewise.
* jv-lang.c (java_op_print_tab): Likewise.
* linux-nat.c (linux_proc_xfer_partial): Likewise.
* linux-nat.h (struct lwp_info): Likewise.
* linux-thread-db.c (enable_thread_event): Likewise.
* m2-lang.c (m2_op_print_tab): Likewise.
* mi/mi-cmd-stack.c (mi_cmd_stack_list_locals): Likewise.
(mi_cmd_stack_list_variables): Likewise.
* mi/mi-main.c (mi_cmd_trace_frame_collected): Likewise.
* mi/mi-out.c (mi_table_begin): Likewise.
(mi_table_header): Likewise.
* mips-linux-nat.c (mips_linux_can_use_hw_breakpoint): Likewise.
(mips_linux_insert_watchpoint): Likewise.
(mips_linux_remove_watchpoint): Likewise.
* nat/mips-linux-watch.c (mips_linux_watch_type_to_irw): Likewise.
* nat/mips-linux-watch.h (struct mips_watchpoint): Likewise.
(mips_linux_watch_type_to_irw): Likewise.
* nto-procfs.c (procfs_can_use_hw_breakpoint): Likewise.
(procfs_insert_hw_watchpoint): Likewise.
(procfs_remove_hw_watchpoint): Likewise.
(procfs_hw_watchpoint): Likewise.
(procfs_can_use_hw_breakpoint): Likewise.
(procfs_remove_hw_watchpoint): Likewise.
(procfs_insert_hw_watchpoint): Likewise.
* p-lang.c (pascal_op_print_tab): Likewise.
* ppc-linux-nat.c (ppc_linux_can_use_hw_breakpoint): Likewise.
* ppc-linux-tdep.c (ppu2spu_unwind_register): Likewise.
* ppc-sysv-tdep.c (get_decimal_float_return_value): Likewise.
* procfs.c (procfs_can_use_hw_breakpoint): Likewise.
(procfs_insert_watchpoint): Likewise.
(procfs_remove_watchpoint): Likewise.
* psymtab.c (recursively_search_psymtabs): Likewise.
* remote-m32r-sdi.c (m32r_can_use_hw_watchpoint): Likewise.
(m32r_insert_watchpoint): Likewise.
* remote-mips.c (mips_can_use_watchpoint): Likewise.
(mips_insert_watchpoint): Likewise.
(mips_remove_watchpoint): Likewise.
* remote.c (watchpoint_to_Z_packet): Likewise.
(remote_insert_watchpoint): Likewise.
(remote_remove_watchpoint): Likewise.
(remote_check_watch_resources): Likewise.
* s390-linux-nat.c (s390_insert_watchpoint): Likewise.
(s390_remove_watchpoint): Likewise.
(s390_can_use_hw_breakpoint): Likewise.
* s390-linux-tdep.c (s390_gdbarch_init): Likewise.
* spu-linux-nat.c (spu_can_use_hw_breakpoint): Likewise.
* target.h (struct target_ops): Likewise.
* tilegx-tdep.c (tilegx_analyze_prologue): Likewise.
* ui-out.c (struct ui_out_hdr): Likewise.
(append_header_to_list): Likewise.
(get_next_header): Likewise.
(verify_field): Likewise.
(ui_out_begin): Likewise.
(ui_out_field_int): Likewise.
(ui_out_field_fmt_int): Likewise.
(ui_out_field_skip): Likewise.
(ui_out_field_string): Likewise.
(ui_out_field_fmt): Likewise.
* varobj.c (new_variable): Likewise.
* x86-nat.c (x86_insert_watchpoint): Likewise.
(x86_remove_watchpoint): Likewise.
(x86_can_use_hw_breakpoint): Likewise.
* xtensa-tdep.h (struct gdbarch_tdep): Likewise.
* inflow.c (enum gdb_has_a_terminal_flag_enum): Add name to
previously anonymous enumeration type..
* linux-record.h (enum gdb_syscall): Add gdb_sys_no_syscall
value.
* target-debug.h (target_debug_print_enum_target_hw_bp_type): New.
(target_debug_print_enum_bptype): New.
* target-delegates.c: Regenerate.

Automatic date update in version.in

Replace incorrect patch to gdb.cp/var-tag.exp.

2015-07-30  Sandra Loosemore  <sandra@codesourcery.com>

gdb/testsuite/
* gdb.cp/var-tag.exp (do_global_tests): Revert broken commit
4bc4d42859e3b42c79c89295ef39944bdb3e6753 and apply the
correct patch.

Don't allow non-stack memory writes in the prologue for nios2.

2015-07-30  Sandra Loosemore  <sandra@codesourcery.com>

gdb/
* nios2-tdep.c (nios2_analyze_prologue): Do what the comment
already says and disallow non-stack memory writes in the prologue.

Update trap/break handling in nios2 prologue analyzer.

2015-07-30  Sandra Loosemore  <sandra@codesourcery.com>

gdb/
* nios2-tdep.c (nios2_analyze_prologue): Update comments to
reflect how current GCC emits stack overflow checks.  Match
both trap and break instructions for backward compatibility.
Disallow other trap and break instructions in the prologue.

Restrict gdb.arch/ppc64-symtab-cordic.exp to ppc64 targets.

2015-07-30  Sandra Loosemore  <sandra@codesourcery.com>

gdb/testsuite/
* gdb.arch/ppc64-symtab-cordic.exp: Restrict to ppc64 targets.

Reapply fix for gdb.cp/var-tag.exp C++ failures.

2015-07-30  Sandra Loosemore  <sandra@codesourcery.com>

gdb/testsuite/

Reapply:
2014-05-21  Mark Wielaard  <mjw@redhat.com>

* gdb.cp/var-tag.exp (do_global_tests): Handle underlying type.

remote follow fork and spurious child stops in non-stop mode

Running gdb.threads/fork-plus-threads.exp against gdbserver in
extended-remote mode, even though the test passes, we still see broken
behavior:

 (gdb) PASS: gdb.threads/fork-plus-threads.exp: set detach-on-fork off
 continue &
 Continuing.
 (gdb) PASS: gdb.threads/fork-plus-threads.exp: continue &
 [New Thread 28092.28092]

 [Thread 28092.28092] #2 stopped.
 [New Thread 28094.28094]
 [Inferior 2 (process 28092) exited normally]
 [New Thread 28094.28105]
 [New Thread 28094.28109]

...

[Thread 28174.28174] #18 stopped.
 [New Thread 28185.28185]
 [Inferior 10 (process 28174) exited normally]
 [New Thread 28185.28196]

 [Thread 28185.28185] #20 stopped.
 Cannot remove breakpoints because program is no longer writable.
 Further execution is probably impossible.
 [Inferior 11 (process 28185) exited normally]
 [Inferior 1 (process 28091) exited normally]
 PASS: gdb.threads/fork-plus-threads.exp: reached breakpoint
 info threads
 No threads.
 (gdb) PASS: gdb.threads/fork-plus-threads.exp: no threads left
 info inferiors
   Num  Description       Executable
 * 1    <null>            /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.threads/fork-plus-threads
 (gdb) PASS: gdb.threads/fork-plus-threads.exp: only inferior 1 left

All the "[Thread FOO] #NN stopped." above are bogus, as well as the
"Cannot remove breakpoints because program is no longer writable.",
which is a consequence.

The problem is that when we intercept a fork event, we should report
the event for the parent, only, and leave the child stopped, but not
report its stop event.  GDB later decides whether to follow the parent
or the child.  But because handle_extended_wait does not set the
child's last_status.kind to TARGET_WAITKIND_STOPPED, a
stop_all_threads/unstop_all_lwps sequence (e.g., from trying to access
memory) by mistake ends up queueing a SIGSTOP on the child, resuming
it, and then when that SIGSTOP is intercepted, because the LWP has
last_resume_kind set to resume_stop, gdbserver reports the stop to
GDB, as GDB_SIGNAL_0:

...
 >>>> entering unstop_all_lwps
 unstopping all lwps
 proceed_one_lwp: lwp 1600
    client wants LWP to remain 1600 stopped
 proceed_one_lwp: lwp 1828
 Client wants LWP 1828 to stop. Making sure it has a SIGSTOP pending
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Sending sigstop to lwp 1828
 pc is 0x3615ebc7cc
 Resuming lwp 1828 (continue, signal 0, stop expected)
   continue from pc 0x3615ebc7cc
 unstop_all_lwps done
 sigchld_handler
 <<<< exiting unstop_all_lwps
 handling possible target event
 >>>> entering linux_wait_1
 linux_wait_1: [<all threads>]
 my_waitpid (-1, 0x40000001)
 my_waitpid (-1, 0x1): status(137f), 1828
 LWFE: waitpid(-1, ...) returned 1828, ERRNO-OK
 LLW: waitpid 1828 received Stopped (signal) (stopped)
 pc is 0x3615ebc7cc
 Expected stop.
 LLW: resume_stop SIGSTOP caught for LWP 1828.1828.
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...
 linux_wait_1 ret = LWP 1828.1828, 1, 0
 <<<< exiting linux_wait_1
 Writing resume reply for LWP 1828.1828:1
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Tested on x86_64 Fedora 20, extended-remote.

gdb/gdbserver/ChangeLog:
2015-07-30  Pedro Alves  <palves@redhat.com>

* linux-low.c (handle_extended_wait): Set the child's last
reported status to TARGET_WAITKIND_STOPPED.

PR threads/18600: Inferiors left around after fork+thread spawn

The new gdb.threads/fork-plus-threads.exp test exposes one more
problem.  When one types "info inferiors" after running the program,
one see's a couple inferior left still, while there should only be
inferior #1 left.  E.g.:

 (gdb) info inferiors
   Num  Description       Executable
   4    process 8393      /home/pedro/bugs/src/test
   2    process 8388      /home/pedro/bugs/src/test
 * 1    <null>            /home/pedro/bugs/src/test
 (gdb) info threads

Calling prune_inferiors() manually at this point (from a top gdb) does
not remove them, because they still have inf->pid != 0 (while they
shouldn't).  This suggests that we never mourned those inferiors.

Enabling logs (master + previous patch) we see:

 ...
 WL: waitpid Thread 0x7ffff7fc2740 (LWP 9513) received Trace/breakpoint trap (stopped)
 WL: Handling extended status 0x03057f
 LHEW: Got clone event from LWP 9513, new child is LWP 9579
 [New Thread 0x7ffff37b8700 (LWP 9579)]
 WL: waitpid Thread 0x7ffff7fc2740 (LWP 9508) received 0 (exited)
 WL: Thread 0x7ffff7fc2740 (LWP 9508) exited.
    ^^^^^^^^
 [Thread 0x7ffff7fc2740 (LWP 9508) exited]
 WL: waitpid Thread 0x7ffff7fc2740 (LWP 9499) received 0 (exited)
 WL: Thread 0x7ffff7fc2740 (LWP 9499) exited.
 [Thread 0x7ffff7fc2740 (LWP 9499) exited]
 RSRL: resuming stopped-resumed LWP Thread 0x7ffff37b8700 (LWP 9579) at 0x3615ef4ce1: step=0
 ...
 (gdb) info inferiors
   Num  Description       Executable
   5    process 9508      /home/pedro/bugs/src/test
^^^^
   4    process 9503      /home/pedro/bugs/src/test
   3    process 9500      /home/pedro/bugs/src/test
   2    process 9499      /home/pedro/bugs/src/test
 * 1    <null>            /home/pedro/bugs/src/test
 (gdb)
 ...

Note the "Thread 0x7ffff7fc2740 (LWP 9508) exited." line.
That's this in wait_lwp:

      /* Check if the thread has exited.  */
      if (WIFEXITED (status) || WIFSIGNALED (status))
{
  thread_dead = 1;
  if (debug_linux_nat)
    fprintf_unfiltered (gdb_stdlog, "WL: %s exited.\n",
target_pid_to_str (lp->ptid));
}
    }

That was the leader thread reporting an exit, meaning the whole
process is gone.  So the problem is that this code doesn't understand
that an WIFEXITED status of the leader LWP should be reported to
infrun as process exit.

gdb/ChangeLog:
2015-07-30  Pedro Alves  <palves@redhat.com>

PR threads/18600
* linux-nat.c (wait_lwp): Report to the core when thread group
leader exits.

gdb/testsuite/ChangeLog:
2015-07-30  Pedro Alves  <palves@redhat.com>

PR threads/18600
* gdb.threads/fork-plus-threads.exp: Test that "info inferiors"
only shows inferior 1.

PR threads/18600: Threads left stopped after fork+thread spawn

When a program forks and another process start threads while gdb is
handling the fork event, newly created threads are left stuck stopped
by gdb, even though gdb presents them as "running", to the user.

This can be seen with the test added by this patch.  The test has the
inferior fork a certain number of times and waits for all children to
exit.  Each fork child spawns a number of threads that do nothing and
joins them immediately.  Normally, the program should run unimpeded
(from the point of view of the user) and exit very quickly.  Without
this fix, it doesn't because of some threads left stopped by gdb, so
inferior 1 never exits.

The program triggers when a new clone thread is found while inside the
linux_stop_and_wait_all_lwps call in linux-thread-db.c:

      linux_stop_and_wait_all_lwps ();

      ALL_LWPS (lp)
if (ptid_get_pid (lp->ptid) == pid)
  thread_from_lwp (lp->ptid);

      linux_unstop_all_lwps ();

Within linux_stop_and_wait_all_lwps, we reach
linux_handle_extended_wait with the "stopping" parameter set to 1, and
because of that we don't mark the new lwp as resumed.  As consequence,
the subsequent resume_stopped_resumed_lwps, called from
linux_unstop_all_lwps, never resumes the new LWP.

There's lots of cruft in linux_handle_extended_wait that no longer
makes sense.  On systems with CLONE events support, we don't rely on
libthread_db for thread listing anymore, so the code that preserves
stop_requested and the handling of last_resume_kind is all dead.

So the fix is to remove all that, and simply always mark the new LWP
as resumed, so that resume_stopped_resumed_lwps re-resumes it.

gdb/ChangeLog:
2015-07-30  Pedro Alves  <palves@redhat.com>
    Simon Marchi  <simon.marchi@ericsson.com>

PR threads/18600
* linux-nat.c (linux_handle_extended_wait): On CLONE event, always
mark the new thread as resumed.  Remove STOPPING parameter.
(wait_lwp): Adjust call to linux_handle_extended_wait.
(linux_nat_filter_event): Adjust call to
linux_handle_extended_wait.
(resume_stopped_resumed_lwps): Add debug output.

gdb/testsuite/ChangeLog:
2015-07-30  Simon Marchi  <simon.marchi@ericsson.com>
    Pedro Alves  <palves@redhat.com>

PR threads/18600
* gdb.threads/fork-plus-threads.c: New file.
* gdb.threads/fork-plus-threads.exp: New file.

Remove isize output argument from fast_tracepoint_valid_at

This patch removes the isize output argument from the
fast_tracepoint_valid_at gdbarch hook.  It was used to return the size
of the instruction that needs to be replaced when installing a fast
tracepoint.  Instead of getting this value from the
fast_tracepoint_valid_at hook, we can call the gdb_insn_length function.

If we do not do this, then architectures which do not have a restriction
on where to install the fast tracepoint will send uninitialized memory
off to GDBserver.  See remote_download_tracepoint:

~~~
int isize;

if (gdbarch_fast_tracepoint_valid_at (target_gdbarch (),
      tpaddr, &isize, NULL))
  xsnprintf (buf + strlen (buf), BUF_SIZE - strlen (buf), ":F%x",
     isize);
~~~

The default implementation of fast_tracepoint_valid_at will not set
isize resulting in uninitialized memory being sent.  Later on, GDBserver
could use this information to compute a jump offset.

gdb/ChangeLog:

* arch-utils.c (default_fast_tracepoint_valid_at): Remove unused
isize argument.
* arch-utils.h (default_fast_tracepoint_valid_at): Likewise.
* breakpoint.c (check_fast_tracepoint_sals): Adjust call to
gdbarch_fast_tracepoint_valid_at.
* gdbarch.sh (fast_tracepoint_valid_at): Remove isize argument.
* gdbarch.h: Regenerate.
* gdbarch.c: Regenerate.
* i386-tdep.c (i386_fast_tracepoint_valid_at): Remove isize
argument.  Do not set it.
* remote.c (remote_download_tracepoint): Adjust call to
gdbarch_fast_tracepoint_valid_at.  Call gdb_insn_length to get
the instruction length.

Remove global variable arm_hwcap

After previous patch, we don't need global variable arm_hwcap.  This
patch is to remove it.

gdb/gdbserver:

2015-07-30  Yao Qi  <yao.qi@linaro.org>

* linux-arm-low.c (arm_hwcap): Remove it.
(arm_read_description): New local variable arm_hwcap.  Don't
set arm_hwcap to zero.

Use regcache->tdesc instead of arm_hwcap

arm_hwcap is a global variable, and we should avoid using it as much
as we can.  Instead of checking arm_hwcap, we can check whether
regcache->tdesc is a certain kind of target description.  This is
what this patch does.

gdb/gdbserver:

2015-07-30  Yao Qi  <yao.qi@linaro.org>

* linux-arm-low.c (arm_fill_wmmxregset): Don't use arm_hwcap.
Use regcache->tdesc instead.
(arm_store_wmmxregset): Likewise.
(arm_fill_vfpregset): Likewise.
(arm_store_vfpregset): Likewise.

Don't use arm_regmap and arm_num_regs in arm_fill_gregset and arm_store_gregset

In order to align with arm-linux-nat.c counterparts, we don't use
arm_num_regs and arm_regmap in functions arm_fill_gregset and
arm_store_gregset.  Instead, we use register numbers.  With this
patch applied, arm_fill_gregset and arm_store_gregset don't need
arm_num_regs and arm_regmap, and they will be moved to a separate
file shared for both arm and aarch64 in the following patch.

gdb/gdbserver:

2015-07-30  Yao Qi  <yao.qi@linaro.org>

* linux-arm-low.c: Include arch/arm.h.
(arm_fill_gregset): Don't use arm_num_regs and arm_regmap.
(arm_store_gregset): Likewise.

Move ARM register numbers enum to arch/arm.h

This patch moves ARM register numbers enum to arch/arm.h, so that it
can used by GDBserver too.

This patch also creates a new directory gdb/arch in which arch-specific
or target-specific files are placed.

gdb:

2015-07-30  Yao Qi  <yao.qi@linaro.org>

* arm-tdep.h (enum gdb_regnum): Move it to ...
* arch/arm.h: ... here.  New file.
* Makefile.in (HFILES_NO_SRCDIR): Add arch/arm.h.