Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Add regression test for PR gdb/19858 (JIT code registration on attach)

This test would fail without the previous gdb/jit.c fix:

  (gdb) attach 23031
  Attaching to program: .../build/gdb/testsuite/outputs/gdb.base/jit/jit-main, process 23031
  [...]
  207           WAIT_FOR_GDB; i = 0;  /* gdb break here 1 */
  (gdb) PASS: gdb.base/jit.exp: attach: one_jit_test-2: attach
  set var wait_for_gdb = 0
  (gdb) PASS: gdb.base/jit.exp: attach: one_jit_test-2: set var wait_for_gdb = 0
  info function ^jit_function
  All functions matching regular expression "^jit_function":
  (gdb) FAIL: gdb.base/jit.exp: attach: one_jit_test-2: info function ^jit_function

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

PR gdb/19858
* gdb.base/jit-main.c: Include unistd.h.
(ATTACH): Define to 0 if not already defined.
(wait_for_gdb, mypid): New globals.
(WAIT_FOR_GDB): New macro.
(MAIN): Set an alarm.  Store the process's pid.  Wait for GDB at
some breakpoint locations.
* gdb.base/jit.exp (clean_reattach, continue_to_test_location):
New procedures.
(one_jit_test): Add REATTACH parameter, and handle it.  Use
continue_to_test_location.
(top level): Test attach, and adjusts calls to one_jit_test.

Make gdb.base/jit.exp binaries unique

This testcase compiles the same program and library differently
multiple times using the same file names.  Make them unique, to make
it easier to debug test problems.

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

PR gdb/19858
* gdb.base/jit.exp (compile_jit_test): Add intro comment.  Add
BINSUFFIX parameter, and handle it.
(top level): Adjust calls compile_jit_test.

Fix PR gdb/19858: GDB doesn't register the JIT libraries on attach

Ref: https://sourceware.org/ml/gdb/2016-03/msg00023.html

GDB currently fails to fetch the list of already-registered JIT
modules on attach.

Nothing is calling jit_inferior_init, which is what is responsible for
walking the JIT object list at init time.

Despite the misleading naming, jit_inferior_created_hook ->
jit_inferior_init is only called when the inferior execs.

This regressed with the fix for PR gdb/13431 (03bef283c2d3):
 https://sourceware.org/ml/gdb-patches/2012-02/msg00023.html which
removed the inferior_created (jit_inferior_created_observer)
observer.

Adding an inferior_created observer back fixes the issue.

In turn, this exposes a bug in jit_breakpoint_re_set_internal as well,
which is returning the wrong result when we already have the
breakpoint at the right address.

gdb/ChangeLog:
2016-03-31  Yichao Yu  <yyc1992@gmail.com>

PR gdb/19858
* jit.c (jit_breakpoint_re_set_internal): Return 0 if we already
got the breakpoint at the right address.
(jit_inferior_created): New function.
(_initialize_jit): Install jit_inferior_created as
inferior_created observer.

Signed-off-by: Pedro Alves <palves@redhat.com>

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

btrace: fix PR gdb/19829

This is a backport of

33b4777ca1b7 btrace, frame: fix crash in get_frame_type
a038fa3e14a4 stack: check frame_unwind_caller_id
2f3ef606b912 frame: add skip_tailcall_frames

In skip_artificial_frames we repeatedly call get_prev_frame_always until we get
a non-inline and non-tailcall frame assuming that there must be such a frame
eventually.

For record targets, however, we may have a frame chain that consists only of
artificial frames.  This leads to a crash in get_frame_type when dereferencing a
NULL frame pointer.

Change skip_artificial_frames and skip_tailcall_frames to return NULL in such a
case and modify each caller to cope with a NULL return.

In frame_unwind_caller_pc and frame_unwind_caller_arch, we simply assert that
the returned value is not NULL.  Their caller was supposed to check
frame_unwind_caller_id before calling those functions.

In other cases, we thrown an error.

In infcmd further move the skip_tailcall_frames call to the forward-stepping
case since we don't need a frame for reverse execution and we don't want to fail
because of that.  Reverse-finish does make sense for a tailcall frame.

gdb/
* frame.h (skip_tailcall_frames): New.
* infcmd.c (finish_command): Call skip_tailcall_frames.
* frame.c (skip_artificial_frames): Return NULL if only artificial frames
are found.  Update comment.
(frame_pop): Call skip_tailcall_frames.
(frame_unwind_caller_id): Handle NULL return.
(frame_unwind_caller_pc, frame_unwind_caller_arch): Assert that
skip_artificial_frames does not return NULL.
(frame_pop): Add an error if only tailcall frames are found.
* infcmd.c (finish_command): Move skip_tailcall_frames call into forward-
execution case.  Add an error if only tailcall frames are found.
* stack.c (frame_info): Check frame_unwind_caller_id.

testsuite/
* gdb.btrace/tailcall-only.exp: New.
* gdb.btrace/tailcall-only.c: New.
* gdb.btrace/x86_64-tailcall-only.S: New.
* gdb.btrace/i686-tailcall-only.S: New.

Automatic date update in version.in

Automatic date update in version.in

Fix PR gdb/19676: Internal error in linux-thread.db.c if /proc not mounted

If /proc is not mounted, GDB fails an assertion in find_new_threads_once:

 Continuing.
 .../src/gdb/linux-thread-db.c:1249: internal-error: find_new_threads_once: Assertion `!target_has_execution' failed.
 A problem internal to GDB has been detected,
 further debugging may prove unreliable.
 Quit this debugging session? (y or n)

That was supposed to catch misuses of td_ta_thr_iter, which is unsafe
for live debugging.  However, if /proc is not mounted, we still
fallback to using it.

I didn't bother with a warning, because GDB already prints several
others related to failing to open /proc files.

gdb/ChangeLog:
2016-03-15  Pedro Alves  <palves@redhat.com>

PR gdb/19676
* linux-thread-db.c (try_thread_db_load_1): Leave
info->td_ta_thr_iter_p NULL iff debugging a live process and we
have /proc access.
(find_new_threads_once): Assert that we have a non-NULL
info->td_ta_thr_iter_p instead of checking whether the target has
execution.

Fix PR gdb/19676: Disable displaced stepping if /proc not mounted

On GNU/Linux archs that support displaced stepping, if /proc is not
mounted, GDB gets stuck not able to step past breakpoints:

 (gdb) c
 Continuing.
 dl_main (phdr=<optimized out>, phnum=<optimized out>, user_entry=<optimized out>, auxv=<optimized out>) at rtld.c:2163
 2163      LIBC_PROBE (init_complete, 2, LM_ID_BASE, r);
 Cannot find AT_ENTRY auxiliary vector entry.
 (gdb) c
 Continuing.
 dl_main (phdr=<optimized out>, phnum=<optimized out>, user_entry=<optimized out>, auxv=<optimized out>) at rtld.c:2163
 2163      LIBC_PROBE (init_complete, 2, LM_ID_BASE, r);
 Cannot find AT_ENTRY auxiliary vector entry.
 (gdb)

That's because GDB can't figure out where the scratch pad is.

This is a regression introduced by the earlier changes to make the
Linux native target always work in non-stop mode.

This commit makes GDB detect the case and fallback to stepping over
breakpoints in-line.

gdb/ChangeLog:
2016-03-15  Pedro Alves  <palves@redhat.com>

PR gdb/19676
* infrun.c (displaced_step_prepare): Also disable displaced
stepping on NOT_SUPPORTED_ERROR.
* linux-tdep.c (linux_displaced_step_location): If reading auxv
fails, throw NOT_SUPPORTED_ERROR instead of generic error.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Bump GDB version number to 7.11.0.DATE-git.

gdb/ChangeLog:

* version.in: Set GDB version number to 7.11.0.DATE-git.

Document the GDB 7.11 release in gdb/ChangeLog

gdb/ChangeLog:

GDB 7.11 released.

Set GDB version number to 7.11.

gdb/ChangeLog:

* version.in: Set GDB version number to 7.11.

Automatic date update in version.in

Automatic date update in version.in

gdb-gdb.py: SyntaxError: Missing parentheses in call to 'print'

After building GDB
--with-python=/usr/bin/python3
and for example stripping ./gdb and running:
./gdb -data-directory data-directory/ -iex "add-auto-load-safe-path $PWD/gdb-gdb.gdb" -iex "add-auto-load-safe-path $PWD/gdb-gdb.
py" ./gdb
I get:
Make breakpoint pending on future shared library load? (y or [n]) [answered N; input not from terminal]
  File "/home/jkratoch/redhat/gdb-test-python3/gdb/gdb-gdb.py", line 91
    print "Warning: Cannot find enum type_flag_value type."
  ^
SyntaxError: Missing parentheses in call to 'print'
(top-gdb) q

gdb/ChangeLog
2016-02-22  Jan Kratochvil  <jan.kratochvil@redhat.com>

* gdb-gdb.py (class TypeFlagsPrinter): Use parentheses for print.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

PR remote/19496, internal err forking-threads-plus-bkpt

This patch fixes an internal error that occurs in
gdb.threads/forking-threads-plus-breakpoint.exp:

/blah/binutils-gdb/gdb/target.c:2723: internal-error: Can't determine the
current address space of thread Thread 3170.3170

In default_thread_address_space, find_inferior_ptid couldn't find 3170.3170
because it had been overwritten in inferior_appeared, called as follows:

inferior_appeared
  remote_add_inferior
    remote_notice_new_inferior
      remote_update_thread_list

The cause of the problem was the following sequence of events:

* GDB knows only about the main thread

* the first fork event is reported to GDB, saved as pending_event

* qXfer:threads:read gets the threads from the remote.
  remove_new_fork_children id's the fork child from the pending event
  and removes it from the list reported to GDB.  All the rest of the
  threads, including the fork parent, are added to the GDB thread list.

* GDB stops all the threads.  All the stop events are pushed onto the
  stop reply queue behind the pending fork event.  The fork waitstatus
  is saved in the fork parent thread's pending status field
  thread_info.suspend.

* remote_wait_ns calls queued_stop_reply and process_stop_reply to
  remove the fork event from the front of the stop reply queue and save
  event information in the thread_info structure for the fork parent
  thread.  Unfortunately, none of the information saved in this way is
  the fork-specific information.

* A subsequent qXfer:threads:read packet gets the thread list including
  the fork parent and fork child.  remove_new_fork_children checks the
  thread list to see if there is a fork parent, doesn't find one, checks
  the stop reply queue for a pending fork event, doesn't find one, and
  allows the fork child thread to be reported to GDB before the fork
  event has been handled.  remote_update_thread_list calls
  remote_notice_new_thread and overwrites the current (main) thread in
  inferior_appeared.

So the fork event has been reported out of target_wait but it was left
pending on the infrun side (infrun.c:save_waitstatus).  IOW, the fork
event hasn't been processed by handle_inferior_event yet, so it hasn't
made it to tp->pending_follow yet.

The fix is to check thread_info.suspend along with the
thread_info.pending_follow in remote.c:remove_new_fork_children, to
prevent premature reporting of the fork child thread creation.

gdb/ChangeLog:

PR remote/19496
* remote.c (remove_new_fork_children): Check for pending
fork status in thread_info.suspend.

gdb/testsuite/ChangeLog:

PR remote/19496
* gdb.threads/forking-threads-plus-breakpoint.exp (do_test):
Remove kfail for PR remote/19496.

Fix cleanup in arm_linux_software_single_step

I see the following error in testing aarch64 GDB debugging arm
program.

(gdb) PASS: gdb.reverse/readv-reverse.exp: set breakpoint at marker2
continue
Continuing.
=================================================================
==32273==ERROR: AddressSanitizer: attempting free on address which was not malloc()-ed: 0x000000ce4c00 in thread T0
    #0 0x2ba5615645c7 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x545c7)^M
    #1 0x4be8b5 in VEC_CORE_ADDR_cleanup /home/yao/SourceCode/gnu/gdb/git/gdb/common/gdb_vecs.h:34^M
    #2 0x5e6d95 in do_my_cleanups /home/yao/SourceCode/gnu/gdb/git/gdb/common/cleanups.c:154^M
    #3 0x64c99a in fetch_inferior_event /home/yao/SourceCode/gnu/gdb/git/gdb/infrun.c:3975^M
    #4 0x678437 in inferior_event_handler /home/yao/SourceCode/gnu/gdb/git/gdb/inf-loop.c:44^M
    #5 0x5078f6 in remote_async_serial_handler /home/yao/SourceCode/gnu/gdb/git/gdb/remote.c:13223^M
    #6 0x4cecfd in run_async_handler_and_reschedule /home/yao/SourceCode/gnu/gdb/git/gdb/ser-base.c:137^M
    #7 0x676864 in gdb_wait_for_event /home/yao/SourceCode/gnu/gdb/git/gdb/event-loop.c:834^M
    #8 0x676a27 in gdb_do_one_event /home/yao/SourceCode/gnu/gdb/git/gdb/event-loop.c:323^M
    #9 0x676aed in start_event_loop /home/yao/SourceCode/gnu/gdb/git/gdb/event-loop.c:347^M
    #10 0x6706d2 in captured_command_loop /home/yao/SourceCode/gnu/gdb/git/gdb/main.c:318^M
    #11 0x66db8c in catch_errors /home/yao/SourceCode/gnu/gdb/git/gdb/exceptions.c:240^M
    #12 0x6716dd in captured_main /home/yao/SourceCode/gnu/gdb/git/gdb/main.c:1157^M
    #13 0x66db8c in catch_errors /home/yao/SourceCode/gnu/gdb/git/gdb/exceptions.c:240^M
    #14 0x671b7a in gdb_main /home/yao/SourceCode/gnu/gdb/git/gdb/main.c:1165^M
    #15 0x467684 in main /home/yao/SourceCode/gnu/gdb/git/gdb/gdb.c:32^M
    #16 0x2ba563ed7ec4 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4)^M
    #17 0x4676b2 (/scratch/yao/gdb/build-git/aarch64-linux-gnu/gdb/gdb+0x4676b2)

looks we should discard cleanup if function
arm_linux_software_single_step returns early, or create cleanup when
it is needed.

gdb:

2016-02-16  Yao Qi  <yao.qi@linaro.org>

* arm-linux-tdep.c (arm_linux_software_single_step): Assign
'old_chain' later.

Automatic date update in version.in

Add missing gdb.arch/i386-prologue.c prototypes

The testfile has not ran because:
gdb.arch/i386-prologue.c:34:3: warning: implicit declaration of function 'standard' [-Wimplicit-function-declaration]
   standard ();
   ^
gdb.arch/i386-prologue.c:35:3: warning: implicit declaration of function 'stack_align_ecx' [-Wimplicit-function-declaration]
   stack_align_ecx ();
   ^
gdb.arch/i386-prologue.c:36:3: warning: implicit declaration of function 'stack_align_edx' [-Wimplicit-function-declaration]
   stack_align_edx ();
   ^
gdb.arch/i386-prologue.c:37:3: warning: implicit declaration of function 'stack_align_eax' [-Wimplicit-function-declaration]
   stack_align_eax ();
   ^

gdb/testsuite/ChangeLog
2016-02-15  Jan Kratochvil  <jan.kratochvil@redhat.com>

* gdb.arch/i386-prologue.c: Add missing prototypes.

Fix more testcases with standard_output_file.

Since
commit 2151ccc56c74b55a8f0debf0724a495368f92591
Author: Simon Marchi <simon.marchi@ericsson.com>
Date:   Mon Feb 8 14:02:36 2016 -0500
    Always organize test artifacts in a directory hierarchy
these testfiles could not build.

gdb/testsuite/ChangeLog
2016-02-15  Jan Kratochvil  <jan.kratochvil@redhat.com>

* gdb.arch/i386-gnu-cfi.exp: Use standard_output_file.
* gdb.arch/i386-prologue.exp: Likewise.
* gdb.arch/i386-size.exp: Likewise.

i386-biarch-core.exp: Use standard_output_file

Fix the core file path to use the standard output directory.

gdb/testsuite/ChangeLog:

* i386-biarch-core.exp: Define corefile using
standard_output_file.

Automatic date update in version.in

testsuite: Fix false Fortran regressions with recent gcc

gcc-4.9.2-6.fc21.x86_64 -> gcc-5.3.1-2.fc23.x86_64

-PASS: gdb.fortran/vla-ptype.exp: ptype pvla not initialized
+FAIL: gdb.fortran/vla-ptype.exp: ptype pvla not initialized
-PASS: gdb.fortran/vla-history.exp: print vla1 allocated
+FAIL: gdb.fortran/vla-history.exp: print vla1 allocated
-PASS: gdb.fortran/vla-history.exp: print $2
+FAIL: gdb.fortran/vla-history.exp: print $2
-PASS: gdb.fortran/vla-value.exp: print undefined pvla
+FAIL: gdb.fortran/vla-value.exp: print undefined pvla
-PASS: gdb.fortran/vla-value.exp: print non-associated &pvla
+FAIL: gdb.fortran/vla-value.exp: print non-associated &pvla
-PASS: gdb.fortran/vla-value.exp: print undefined pvla(1,3,8)
+FAIL: gdb.fortran/vla-value.exp: print undefined pvla(1,3,8)

These issues get fixed (or removed if no longer applicable) by attached patch.

It is based on Googled:
http://www.cs.rpi.edu/~szymansk/OOF90/bugs.html#5
When a pointer is declared its status is undefined, and cannot be
safely queried with the associated intrinsic.
-> nullify(VARNAME)
+
https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/268786
ALLOCATE is not supposed to initialize the array.
-> Remove checks like an initial print is: \\( *0, *0, *0...\\)

These regressions remain:
-PASS: gdb.fortran/library-module.exp: print var_i in lib
+FAIL: gdb.fortran/library-module.exp: print var_i in lib
-PASS: gdb.fortran/library-module.exp: print var_i in main
+FAIL: gdb.fortran/library-module.exp: print var_i in main
I believe it is more a GDB bug (in a code contributed by me), filed:
gdb.fortran/library-module.exp false regression on GCC upgrade
https://sourceware.org/bugzilla/show_bug.cgi?id=19635

gdb/testsuite/ChangeLog
2016-02-14  Jan Kratochvil  <jan.kratochvil@redhat.com>

Fix compatibility with recent gfortran-5.3.1.
* gdb.fortran/vla-history.exp (print vla1 allocated)
(print vla2 allocated, print $2, print $3): Remove
(print $4): Rename to ...
(print $2): ... here.
(print $9): Rename to ...
(print $5): ... here.
(print $10): Rename to ...
(print $6): ... here.
* gdb.fortran/vla.f90: Add pvla initialization.

testsuite regression: gdb.fortran/vla-value-sub.exp gdb.fortran/vla-value-sub-finish.exp

> +static int max_value_size = 65536; /* 64k bytes */

FAIL: gdb.fortran/vla-value-sub.exp: print array2 in foo after it was filled (passed fixed array)
FAIL: gdb.fortran/vla-value-sub.exp: print array2 in foo after it was mofified in debugger (passed fixed array)
FAIL: gdb.fortran/vla-value-sub-finish.exp: print array2 in foo after it was filled
FAIL: gdb.fortran/vla-value-sub-finish.exp: print array2 in foo after it was mofified in debugger

print array2
value requires 296352 bytes, which is more than max-value-size
(gdb) FAIL: gdb.fortran/vla-value-sub.exp: print array2 in foo after it was filled (passed fixed array)

gdb/testsuite/ChangeLog
2016-02-14  Jan Kratochvil  <jan.kratochvil@redhat.com>

* gdb.fortran/vla-value-sub-finish.exp (set max-value-size 1024*1024):
New test.
* gdb.fortran/vla-value-sub.exp: Likewise.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Clear *VAL in regcache_raw_read_unsigned

We have function regcache_raw_read_unsigned defined in both GDB and
GDBserver, so that it is used in common like this,

  ULONGEST value;
  status = regcache_raw_read_unsigned (regcache, regnum, &value);

'value' is correctly set in GDB side, but may not be correctly set
in GDBserver, because &value is passed in regcache_raw_read_unsigned
but collect_register may only set part of the whole variable.  In my
test, I see the top half of 'value' is garbage.  This patch fixes this
problem by clearing *VAL before calling collect_register.

gdb/gdbserver:

2016-02-10  Yao Qi  <yao.qi@linaro.org>

* regcache.c (regcache_raw_read_unsigned): Clear *VAL.

gdb/version.in: Replace -cvs suffix by -git suffix

gdb/ChangeLog:

        * version.in: Replace -cvs suffix by -git suffix.

Bump GDB version number to 7.10.90.DATE-cvs.

gdb/ChangeLog:

* version.in: Set GDB version number to 7.10.90.DATE-cvs.

Document the GDB 7.10.90 release in gdb/ChangeLog

gdb/ChangeLog:

GDB 7.10.90 released.

Set GDB version number to 7.10.90.

gdb/ChangeLog:

* version.in: Set GDB version number to 7.10.90.

gdb/NEWS: Change "since GDB 7.10" -> "in GDB 7.11".

gdb/ChangeLog:

        * NEWS: Change "Changes since GDB version 7.10" into "Changes
        in GDB version 7.11".

Set development mode to "off" by default.

bfd/ChangeLog:

* development.sh (development): Set to false.

Bump version to 7.10.90.DATE-git.

Now that the GDB 7.11 branch has been created, we can
bump the version number.

gdb/ChangeLog:

GDB 7.11 branch created (9ef9e6a6a0dd8f948708cb67c9afcfd0be40cb0a):
* version.in: Bump version to 7.10.90.DATE-git.

breakpoints/19546: Fix crash after updating breakpoints

One of the last checks update_breakpoints_after_exec does while looping
over the list of breakpoints is check that the breakpoint has a valid
location spec. It uses event_location_empty_p to check if the location spec
is "empty", and if it is, the breakpoint is deleted.

momentary_breakpoint types rely on setting the breakpoint structure's
location spec to NULL, thereby causing an update to delete the breakpoint.
However, event_location_empty_p assumed that locations were never NULL.
As a result, GDB would crash dereferencing a NULL pointer whenever
update_breakpoints_after_exec would encounter a momentary_breakpoint.

This patch creates a new wrapper/helper function which tests that the given
breakpoint's location spec is non-NULL and if it is not "empty"
or "unspecified."

gdb/ChangeLog

PR breakpoints/19546
* breakpoint.c (breakpoint_event_location_empty_p): New function.
(update_breakpoints_after_exec, bkpt_re_set): Use this new function
instead of event_location_empty_p.

gdb/testsuite/ChangeLog

PR breakpoints/19546
* gdb.base/infcall-exec.c: New file.
* gdb.base/infcall-exec2.c: New file.
* gdb.base/infcall-exec.exp: New file.

Automatic date update in version.in

Enable/update legacy linespecs in MI.

MI is currently using string_to_event_location to enable the use of legacy
linespecs, but using this function (until this patchset) had the (as yet
unnoticed) side effect of allowing both MI and CLI representation for
explicit locations.

This patch simply changes MI to use the same legacy linespec functions
that the python and guile interpreters use.  This eliminates the CLI syntax
for explicit locations (in MI).

gdb/ChangeLog

* mi/mi-cmd-break.c (mi_cmd_break_insert_1): Use
string_to_event_location_basic instead of string_to_event_location.

Use string_to_event_location_basic in guile.

This patch, analogous to the previous python patch, implements proper
legacy linespec support in guile code using the newly introduced
string_to_event_location_basic.

gdb/ChangeLog

* guile/scm-breakpoint.c (gdbscm_register_breakpoint_x): Skip
leading whitespace and use string_to_event_location_basic instead
of new_linespec_location.

gdb/testsuite/ChangeLog

* gdb.guile/scm-breakpoint.exp (test_bkpt_address): New procedure.
(toplevel): Call test_bkpt_address.

python/19506 -- gdb.Breakpoint address location regression

Now that "legacy" linespecs benefit from consolidated support in
string_to_event_location_basic, python's Breakpoint command should use this
function to turn strings into event locations.

As a result, this patch fixes python/19506. Before:

(gdb) python gdb.Breakpoint("*main")
Traceback (most recent call last):
  File "<string>", line 1, in <module>
RuntimeError: Function "*main" not defined.
Error while executing Python code.

After:

(gdb) python gdb.Breakpoint("*main")
Breakpoint 1 at 0x4005fb: file ../../../src/gdb/testsuite/gdb.python/py-breakpoint.c, line 32.

gdb/ChangeLog

PR python/19506
* python/py-breakpoint.c (bppy_init): Use
string_to_event_location_basic instead of new_linespec_location.

gdb/testsuite/ChangeLog

PR python/19506
* gdb.python/py-breakpoint.exp (test_bkpt_address): New procedure.
(toplevel): Call test_bkpt_address.

Refactor string_to_event_location for legacy linespec support.

This patch refactors string_to_event_location, breaking it into two
separate functions:

1) string_to_event_location_basic
A "basic" string parser that implements support for "legacy" linespecs
(linespec, address, and probe locations).  This function is intended to
be used by any UI wishing/needing to support this legacy behavior.

2) string_to_event_location
This is now intended as a CLI-only function which adds explicit location
parsing in a CLI-appropriate manner (in the form of traditional option/value
pairs).

Together these patches serve to simplify string-to-event location parsing
for all existing non-CLI interfaces (MI, guile, and python).

gdb/ChangeLog

* location.c (string_to_explicit_location): Note that "-p" is
reserved for probe locations and return NULL for any input
that starts with that.
(string_to_event_location): Move "legacy" linespec code to ...
(string_to_event_location_basic): ... here.
* location.h (string_to_event_location): Update comment.
(string_to_event_location_basic): New function.

Fix compile time warnings building the binutils with a gcc6 compiler.

include * opcode/metag.h (metag_scondtab): Mark as possibly unused.
* opcode/nds32.h (nds32_r45map): Likewise.
(nds32_r54map): Likewise.
* opcode/visium.h (gen_reg_table): Likewise.
(fp_reg_table, cc_table, opcode_table): Likewise.

bfd * oasys.c (oasys_archive_p): Fix indentation.
* elf32-nds32.c (nds32_elf_relax_section): Use an unsigned
constant for left shifting.

Modernize configure.ac's

Using AC_OUTPUT with arguments has been deprecated for some time in
autoconf, even in version 2.64, which we are using.  This change should
not affect functionality.

I also removed the "exit 0"'s, they shouldn't be necessary.

gdb/ChangeLog:

* configure.ac: Use AC_CONFIG_FILES instead of passing arguments
to AC_OUTPUT.  Remove "exit 0" at the end.
* configure: Regenerate.

gdb/testsuite/ChangeLog:

* configure.ac: Use AC_CONFIG_FILES instead of passing arguments
to AC_OUTPUT.
* configure: Regenerate.

gdb/gdbserver/ChangeLog:

* configure.ac: Use AC_CONFIG_FILES instead of passing arguments
to AC_OUTPUT.
* configure: Regenerate.

Fix PR19548: Breakpoint re-set inserts breakpoints when it shouldn't

PR19548 shows that we still have problems related to 13fd3ff34329:

 [PR17431: following execs with "breakpoint always-inserted on"]
 https://sourceware.org/ml/gdb-patches/2014-09/msg00733.html

The problem this time is that we currently update the global location
list and try to insert breakpoint locations after re-setting _each_
breakpoint in turn.

Say:

 - We have _more_ than one breakpoint set.  Let's assume 2.

 - There's a breakpoint with a pre-exec address that ends up being an
   unmapped address after the exec.

 - That breakpoint is NOT the first in the breakpoint list.

Then when handling an exec, and we re-set the first breakpoint in the
breakpoint list, we mistakently try to install the old pre-exec /
un-re-set locations of the other breakpoint, which fails:

 (gdb) continue
 Continuing.
 process 28295 is executing new program: (...)/execl-update-breakpoints2
 Error in re-setting breakpoint 1: Warning:
 Cannot insert breakpoint 2.
 Cannot access memory at address 0x1000764

 Breakpoint 1, main (argc=1, argv=0x7fffffffd368) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/execl-update-breakpoints.c:34
 34        len = strlen (argv[0]);
 (gdb)

Fix this by deferring the global location list update till after all
breakpoints are re-set.

Tested on x86_64 Fedora 20, native and gdbserver.

gdb/ChangeLog:
2016-02-09  Pedro Alves  <palves@redhat.com>

PR breakpoints/19548
* breakpoint.c (create_overlay_event_breakpoint): Don't update
global location list here.
(create_longjmp_master_breakpoint)
(create_std_terminate_master_breakpoint)
(create_exception_master_breakpoint, create_jit_event_breakpoint)
(update_breakpoint_locations):
(breakpoint_re_set): Update global location list after all
breakpoints are re-set.

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

PR breakpoints/19548
* gdb.base/execl-update-breakpoints.c (some_function): New
function.
(main): Call it.
* gdb.base/execl-update-breakpoints.exp: Add a second breakpoint.
Tighten expected GDB output.

Fix siginfo C++ build error

Change the signature of gdbserver's siginfo_fixup functions so that it's
in line with gdb's.  This gets rid of the following build error in C++:

  /home/emaisin/src/binutils-gdb/gdb/gdbserver/linux-x86-low.c: In function ‘int x86_siginfo_fixup(siginfo_t*, void*, int)’:
  /home/emaisin/src/binutils-gdb/gdb/gdbserver/linux-x86-low.c:694:21: error: invalid conversion from ‘void*’ to ‘gdb_byte* {aka unsigned char*}’ [-fpermissive]
               FIXUP_32);
                       ^
  In file included from /home/emaisin/src/binutils-gdb/gdb/gdbserver/linux-x86-low.c:31:0:
  /home/emaisin/src/binutils-gdb/gdb/gdbserver/../nat/amd64-linux-siginfo.h:52:5: error:   initializing argument 2 of ‘int amd64_linux_siginfo_fixup_common(siginfo_t*, gdb_byte*, int, amd64_siginfo_fixup_mode)’ [-fpermissive]
   int amd64_linux_siginfo_fixup_common (siginfo_t *native, gdb_byte *inf,
       ^
  /home/emaisin/src/binutils-gdb/gdb/gdbserver/linux-x86-low.c:698:20: error: invalid conversion from ‘void*’ to ‘gdb_byte* {aka unsigned char*}’ [-fpermissive]
             FIXUP_X32);
                      ^
  In file included from /home/emaisin/src/binutils-gdb/gdb/gdbserver/linux-x86-low.c:31:0:
  /home/emaisin/src/binutils-gdb/gdb/gdbserver/../nat/amd64-linux-siginfo.h:52:5: error:   initializing argument 2 of ‘int amd64_linux_siginfo_fixup_common(siginfo_t*, gdb_byte*, int, amd64_siginfo_fixup_mode)’ [-fpermissive]
   int amd64_linux_siginfo_fixup_common (siginfo_t *native, gdb_byte *inf,
       ^

gdb/gdbserver/ChangeLog:

* linux-aarch64-low.c (aarch64_linux_siginfo_fixup): Change
void * to gdb_byte *.
* linux-low.c (siginfo_fixup): Likewise.
(linux_xfer_siginfo): Likewise.
* linux-low.h (struct linux_target_ops) <siginfo_fixup>:
Likewise.
* linux-x86-low.c (x86_siginfo_fixup): Likewise.

Add a more helpful warning message to explain why some AArch64 relocations can overflow.

bfd * elfnn-aarch64.c (elfNN_aarch64_relocate_section): Add a more
helpful warning message to explain why certain AArch64 relocs
might overflow.

ld * testsuite/ld-aarch64/reloc-overflow-bad.d: New test.
* testsuite/ld-aarch64/reloc-overflow-1.s: New source file.
* testsuite/ld-aarch64/reloc-overflow-2.s: New source file.
* testsuite/ld-aarch64/aarch64-elf.exp: Run the new test.

Revert "Fix build breakage"

This reverts commit 222cab58b7ed37df6e01dacb0932f400a2588137.

Revert "Add a more helpful warning message to explain why some AArch64 relocations can overflow."

This reverts commit 2ea53e003163338a403d5afbb2046cafb8f3abe9.

Fix build breakage

Add a cast to reinterpret a void* as a gdb_byte*.

2016-02-09  Walfred Tedeschi  <walfred.tedeschi@intel.com>

gdb/gdbserver/ChangeLog:

        * linux-x86-low.c (x86_siginfo_fixup): Add cast to gdb_byte*.

Add a more helpful warning message to explain why some AArch64 relocations can overflow.

bfd * elfnn-aarch64.c (elfNN_aarch64_relocate_section): Add a more
helpful warning message to explain why certain AArch64 relocs
might overflow.

ld * testsuite/ld-aarch64/reloc-overflow-bad.d: New test.
* testsuite/ld-aarch64/reloc-overflow-1.s: New source file.
* testsuite/ld-aarch64/reloc-overflow-2.s: New source file.
* testsuite/ld-aarch64/aarch64-elf.exp: Run the new test.