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

Aarch64: Make CPSR a 32-bit register again in the target description

This reverts commit a4d9ba85 - 'AARCH64: Change cpsr type to be
64bit.'.

Even though Linux's ptrace exposes CPSR as 64-bit, CPSR is really
32-bit, and basing GDB's fundamentals on a particular OS's ptrace(2)
implementation is a bad idea.

In addition, while that commit intended to fix big endian Aarch64, it
ended up breaking floating point debugging against GDBserver, for both
big and little endian, because it changed the CPSR to be 64-bit in the
features/aarch64-core.xml file, but missed regenerating the
regformats/aarch64.dat file.  If we generate it now, we see this:

  diff --git c/gdb/regformats/aarch64.dat w/gdb/regformats/aarch64.dat
  index afe1028..0d32183 100644
  --- c/gdb/regformats/aarch64.dat
  +++ w/gdb/regformats/aarch64.dat
  @@ -35,7 +35,7 @@ expedite:x29,sp,pc
   64:x30
   64:sp
   64:pc
  -32:cpsr
  +64:cpsr
   128:v0
   128:v1
   128:v2

IOW, that commit left regformats/aarch64.dat still considering CPSR as
32-bits.  regformats/aarch64.dat is used by GDBserver for its internal
regcache layout, and for the g/G packet register block.  See the
generated aarch64.c file in GDBserver's build dir.

So the target description xml file that GDBserver reports to GDB is
now claiming that CPSR is 64-bit, but what GDBserver actually puts in
the g/G register packets is 32-bits.  Because GDB thinks CPSR is
64-bit (because that's what the XML description says), GDB will be
reading the remaining 32-bit bits of CPSR out of v0 (the register
immediately afterwards), and then all the registers that follow CPSR
in the register packet end up wrong in GDB, because they're being read
from the wrong offsets...

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

* features/aarch64-core.xml (cpsr): Change back to 32-bit.
* features/aarch64.c: Regenerate.

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

Fix regression for Linux vDSO in GDB (PR gdb/17407).

since
5979d6b69b20a8355ea94b75fad97415fce4788c
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=5979d6b69b20a8355ea94b75fad97415fce4788c
vdso handling
https://sourceware.org/ml/binutils/2014-03/msg00082.html
https://sourceware.org/ml/binutils/2014-04/msg00003.html
Message-ID: <A78C989F6D9628469189715575E55B230AA884EB@IRSMSX104.ger.corp.intel.com>
I get on
kernel-3.16.2-200.fc20.x86_64
https://koji.fedoraproject.org/koji/buildinfo?buildID=575860
attaching its vdso.bin.gz
GDB (FSF HEAD 5e43d46791c4c66fd83947a12d4f716b561a9103) regression:
reproducer:
./gdb -ex start ./gdb
actual result / FAIL:
Got object file from memory but can't read symbols: File truncated.
expected result / PASS:
<nothing>
or / PASS:
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?

That "warning: Could not load shared library..." is mostly harmless (it is
a bug in GDB), in the FAIL case it is not printed just because
bfd_check_format() fails there.

It seems logical to me this way when the 'size' parameter has been already
added.
Alan Modra:
I was wrongly thinking that the section headers were
always last when I wrote that code.  (They are now!  If you relink
that vdso with current binutils master you won't hit this problem, but
that of course doesn't help existing kernels.)

I do not see a regression for add-symbol-file-from-memory for libncurses.so.5
from the original thread above.

  Start of section headers:          1080 (bytes into file)
  Size of section headers:           64 (bytes)
  Number of section headers:         13
  Section header string table index: 8
Section Headers:
  [Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al
  [ 8] .fake_shstrtab    STRTAB          0000000000000780 000780 000076 00   A  0   0 32
Program Headers:
  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
  LOAD           0x000000 0x0000000000000000 0x0000000000000000 0x0012fe 0x0012fe R E 0x1000

size == 0x2000
shdr_end == 0x778 == 1080 + 13 * 64
high_offset == 0x12fe

       else if (size >= shdr_end)
- high_offset = shdr_end;
+ high_offset = size;

But then 0x778 < 0x780 for "Section header string table index" so whole
bfd_check_format() fails because section headers were not cleared here:
  /* If the segments visible in memory didn't include the section headers,
     then clear them from the file header.  */
  if (high_offset < shdr_end)

bfd/ChangeLog
2014-09-18  Jan Kratochvil  <jan.kratochvil@redhat.com>

PR gdb/17407
* elfcode.h (bfd_from_remote_memory): Use SIZE for HIGH_OFFSET.

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

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

Doing:

  gdb --pid=PID -ex run

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

E.g., from the PR:

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

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

The workaround is doing:

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

instead of

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

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

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

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

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

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

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

testsuite: refactor spawn and wait for attach

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

This refactors all that to a common procedure.

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

Tested on x86_64 Fedora 20.

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

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

Automatic date update in version.in

PR guile/17367

gdb/ChangeLog:

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

Fix for PR 17247: Block SIGCHLD while initializing Guile.

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

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

gdb/ChangeLog:

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

     Replaces the following, which is reverted.

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

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

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Fix crash on Python frame filters with unreadable arg

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

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

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

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

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

gdb/ChangeLog

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

gdb/testsuite/ChangeLog

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

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

Fix xmethod Python so that it works with Python3.

gdb/

* python/lib/gdb/command/xmethods.py (set_xm_status1): Use the
'items' methods instead of 'iteritems' method on dictionaries.

gdb/testsuite/

* gdb.python/py-xmethods.py (A_getarrayind)
(E_method_char_worker.__call__, E_method_int_worker.__call__):
Use 'print' with function call syntax.
(E_method_matcher.match): Fix tab vs space indentation mixup.

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

Remove workaround to libbabeltrace 1.1.0 issue

When GDB uses recent version of babeltrace, such as 1.2.x, we'll see
such error emitted from babeltrace library,

 (gdb) target ctf .../gdb/testsuite/gdb.trace/actions.ctf
 [error] Invalid CTF stream: content size is smaller than packet headers.
 [error] Stream index creation error.
 [error] Open file stream error.

The problem can be reproduce out of GDB too, using babeltrace,

 $ babeltrace ./fake-packet.ctf/
 [error] Invalid CTF stream: content size is smaller than packet headers.
 [error] Stream index creation error.
 [error] Open file stream error.

Recent babeltrace library becomes more strict on CTF, and complains
about one "faked packet" GDB adds, when saving trace data in ctf
format from GDB.  babeltrace 1.1.0 has a bug that it can't read trace
data smaller than a certain size (see https://bugs.lttng.org/issues/450).
We workaround it in GDB to append some meaningless data in a faked
packet to make sure trace file is large enough (see ctf.c:ctf_end).
The babeltrace issue was fixed in 1.1.1 release.  However, babeltrace
recent release (since 1.1.2) starts to complain about such faked
packet.  Here is a table shows that whether faked packet or no faked
packet is "supported" by various babeltrace releases,

        faked packet      no faked packet
1.1.0      Yes                 No
1.1.1      Yes                 Yes
1.1.2      No                  Yes
1.2.0      No                  Yes

We decide to get rid of this workaround in GDB, and people can build GDB
with libbabeltrace >= 1.1.1.  In this way, both configure and ctf.c is
simpler.

Run gdb.trace/* tests in the following combinations:

 wo/ this pattch  1.1.0
 w/  this patch   1.1.1
 w/  this patch   1.1.2
 w/  this patch   1.2.0

No test results change.

gdb:

2014-08-27  Yao Qi  <yao@codesourcery.com>

* ctf.c (CTF_FILE_MIN_SIZE): Remove.
(ctf_end): Remove code.

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

Fix 'gcore' with exited threads

Program received signal SIGABRT, Aborted.
[...]
(gdb) gcore foobar
Couldn't get registers: No such process.
(gdb) info threads
[...]
(gdb) gcore foobar
Saved corefile foobar
(gdb)

gcore tries to access the exited thread:
[Thread 0x7ffff7fce700 (LWP 6895) exited]
ptrace(PTRACE_GETREGS, 6895, 0, 0x7fff18167dd0) = -1 ESRCH (No such process)

Without the TRY_CATCH protection testsuite FAILs for:
gcore .../gdb/testsuite/gdb.threads/gcore-thread0.test
Cannot find new threads: debugger service failed
(gdb) FAIL: gdb.threads/gcore-thread.exp: save a zeroed-threads corefile
+
core .../gdb/testsuite/gdb.threads/gcore-thread0.test
".../gdb/testsuite/gdb.threads/gcore-thread0.test" is not a core dump: File format not recognized
(gdb) FAIL: gdb.threads/gcore-thread.exp: core0file: re-load generated corefile (bad file format)
Maybe the TRY_CATCH could be more inside update_thread_list().

Similar update_thread_list() call is IMO missing in procfs_make_note_section()
but I do not have where to verify that change.

gdb/ChangeLog
2014-08-21  Jan Kratochvil  <jan.kratochvil@redhat.com>

* linux-tdep.c (linux_corefile_thread_callback): Ignore THREAD_EXITED.
(linux_make_corefile_notes): call update_thread_list, protected against
exceptions.

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

* gdb.threads/gcore-stale-thread.c: New file.
* gdb.threads/gcore-stale-thread.exp: New file.

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

Avoid compiler warnings about incomplete parameter types.

gdb/ChangeLog:

* dcache.h: Include target.h, to avoid compile time warnings.

(cherry picked from commit cb039ba4535a3e9ba59517dc973c842c513b4f05)

Add "frame.h" #include in gdbarch.h.

This include is needed because gdbarch_dummy_id needs the full
definition of struct frame_id.

gdb/ChangeLog:

        * gdbarch.sh: #include "frame.h" in gdbarch.h.  Delete "struct
        frame_info" partial declaration.
        * gdbarch.h: Regenerate.

Tested on x86_64-linux by rebuilding GDB.

(cherry picked from commit eb7a547ad40c97ca306e29c94678e4eab1822089)

Automatic date update in version.in

Automatic date update in version.in

Fix build/17104

This patch is to fix the build error when GDB is configured as:

  CFLAGS=-Wall ./configure --with-babeltrace; make

This patch adds one line of code in configure test to use local
variable 'pos'.

Note that we append -Werror to CFLAGS to catch the warning related to
assignment to scope.  See more in this thread
https://sourceware.org/ml/gdb-patches/2014-08/msg00045.html

2014-08-13  Yao Qi  <yao@codesourcery.com>

PR build/17104
* configure.ac: Use local variable 'pos'.
* configure: Regenerated.

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

Fix incorrect placement of two Intel gdb/NEWS items

there were two commits which placed new gdb/NEWS items to the bottom of the
NEWS file (such as for gdb-4.0) instead at their right place under:
*** Changes in GDB 7.8

https://sourceware.org/git/?p=binutils-gdb.git;a=blobdiff;f=gdb/NEWS;h=ae84e009b8008f9da2707829c0cbab358abc17fb;hp=a8ae8c7b7a5ddce9b5779914dd1e6a87463d7d60;hb=ca8941bbd088002cb8ff87abe16d02ecc8d58d1e;hpb=489e41ddf4bb5616a7471fb4072df5efbb9a706e
commit ca8941bbd088002cb8ff87abe16d02ecc8d58d1e
Author: Walfred Tedeschi <walfred.tedeschi@intel.com>
Date:   Tue Dec 3 13:31:03 2013 +0000
    Documentation for MPX.
Message-Id: <1386074172-14177-1-git-send-email-walfred.tedeschi@intel.com>
https://sourceware.org/ml/gdb-patches/2013-12/msg00082.html

and

https://sourceware.org/git/?p=binutils-gdb.git;a=blobdiff;f=gdb/NEWS;h=a7067fdf9a7af422572a29d1fdd6ef011c87cd9f;hp=b72d64db313d0785edec19a9c4b441b854698e6a;hb=01f9f808e2e86187c95e7cff4aeb014a421a53ce;hpb=93ee1e3683a12f4774b8beb4f821910982e21ce2
commit 01f9f808e2e86187c95e7cff4aeb014a421a53ce
Author: Michael Sturm <michael.sturm@intel.com>
Date:   Mon Dec 16 16:43:05 2013 +0100
    Add AVX512 registers support to GDB and GDBserver.
Message-Id: <1398258160-9070-4-git-send-email-michael.sturm@intel.com>
https://sourceware.org/ml/gdb-patches/2013-12/msg00818.html

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

* NEWS (Changes in GDB-4.0): Move Intel MPX and Intel AVX-512 items ...
(Changes in GDB 7.8): ... here.

Message-ID: <20140804165708.GA12824@host2.jankratochvil.net>

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.8.0.DATE-cvs.

gdb/ChangeLog:

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

Document the GDB 7.8 release in gdb/ChangeLog

gdb/ChangeLog:

GDB 7.8 released.

Set GDB version number to 7.8.

gdb/ChangeLog:

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

Update gdb/NEWS in preparation for GDB 7.8 release.

gdb/ChangeLog:

* NEWS: Change "Changes since GDB 7.7" into "Changes in GDB 7.8".

Fix PR 17206

As reported in PR 17206, an internal error is triggered when command
until is executed.  In infcmd.c:until_next_command, step_range_end is
set to 'pc',

  if (!func)
    {
      struct bound_minimal_symbol msymbol = lookup_minimal_symbol_by_pc (pc);

      if (msymbol.minsym == NULL)
error (_("Execution is not within a known function."));

      tp->control.step_range_start = BMSYMBOL_VALUE_ADDRESS (msymbol);
      tp->control.step_range_end = pc;
    }

and later in infrun.c:resume, the assert below is triggered in PR
17206.

  if (tp->control.may_range_step)
    {
      /* If we're resuming a thread with the PC out of the step
 range, then we're doing some nested/finer run control
 operation, like stepping the thread out of the dynamic
 linker or the displaced stepping scratch pad.  We
 shouldn't have allowed a range step then.  */
      gdb_assert (pc_in_thread_step_range (pc, tp));
    }

In until_next_command, we set step range to [XXX, pc), so pc isn't
within the range.  pc_in_thread_step_range returns false and the
assert is triggered.  AFAICS, the range we want in until_next_command
is [XXX, pc] instead of [XXX, pc), because we want to program step
until greater than pc.  This patch is to set step_range_end to
'pc + 1'.  Running until-nodebug.exp with unpatched GDB will get the
following fail,

FAIL: gdb.base/until-nodebug.exp: until 2 (GDB internal error)

and the fail goes away when the fix is applied.

gdb:

2014-07-29  Yao Qi  <yao@codesourcery.com>

PR gdb/17206
* infcmd.c (until_next_command): Set step_range_end to PC + 1.

gdb/testsuite:

2014-07-29  Yao Qi  <yao@codesourcery.com>

PR gdb/17206
* gdb.base/until-nodebug.exp: New.

PR guile/17203

* guile/scm-param.c (pascm_parameter_defined_p): New function.
(gdbscm_register_parameter_x): Call it.  Raise error for pre-existing
parameters.

testsuite/
* gdb.guile/scm-parameter.exp: Add tests for trying to create
previously existing parameter, and previously ambiguously spelled
parameter.

Automatic date update in version.in

2014-07-28  Edjunior Barbosa Machado  <emachado@linux.vnet.ibm.com>

    * ppc-linux-nat.c (ppc_linux_can_use_hw_breakpoint): Report no hardware
    breakpoint support correctly.

watchpoint-reuse-slot.exp: Correctly skip unsupported commands.

The test case "watchpoint-reuse-slot.exp" yields a lot of failures on
s390/s390x: all instances of awatch, rwatch, and hbreak are performed
even though they aren't supported on these targets.  This is because
the test case ignores non-support error messages when probing for
support of these commands, like:

    (gdb) rwatch buf.byte[0]
    Target does not support this type of hardware watchpoint.

The patch adds handling for this case in the appropriate
gdb_test_multiple invocations.

gdb/testsuite/
    * gdb.base/watchpoint-reuse-slot.exp: Handle the case that the
    target lacks support for awatch, rwatch, or hbreak.

Match PLT entry only for ELFOSABI_GNU input

* elf32-i386.c (elf_i386_plt_sym_val): Match PLT entry only for
ELFOSABI_GNU input.
* elf64-x86-64.c (elf_x86_64_plt_sym_val): Likewise.
(elf_x86_64_plt_sym_val_offset_plt_bnd): Likewise.

Properly match PLT entry against .got.plt relocation

Relocations against .got.plt section may not be in the same order as
entries in PLT section.  It is incorrect to assume that the Ith reloction
index against .got.plt section always maps to the (I + 1)th entry in PLT
section.  This patch matches the .got.plt relocation offset/index in PLT
entry against the index in .got.plt relocation table.  It only checks
R_*_JUMP_SLOT and R_*_IRELATIVE relocations.  It ignores R_*_TLS_DESC
and R_*_TLSDESC relocations since they have different PLT entries.

bfd/

PR binutils/17154
* elf32-i386.c (elf_i386_plt_sym_val): Only match R_*_JUMP_SLOT
and R_*_IRELATIVE relocation offset with PLT entry.
* elf64-x86-64.c (elf_x86_64_plt_sym_val): Likewise.
(elf_x86_64_plt_sym_val_offset_plt_bnd): New.
(elf_x86_64_get_synthetic_symtab): Use it.

ld/testsuite/

PR binutils/17154
* ld-ifunc/pr17154-i386.d: New file.
* ld-ifunc/pr17154-x86-64.d: Likewise.
* ld-ifunc/pr17154-x86.s: Likewise.
* ld-x86-64/bnd-ifunc-2.d: Likewise.
* ld-x86-64/bnd-ifunc-2.s: Likewise.
* ld-x86-64/mpx.exp: Run bnd-ifunc-2.
* ld-x86-64/tlsdesc-nacl.pd: Updated.
* ld-x86-64/tlsdesc.pd: Likewise.

Automatic date update in version.in

PR guile/17146

* acinclude.m4 (GDB_GUILE_PROGRAM_NAMES): New macro.
(GDB_GUILD_TARGET_FLAG, GDB_TRY_GUILD): New macros.
* configure.ac: Try to use guild to compile an scm file, if it fails
then disable guile support.
* configure: Regenerate.
* data-directory/Makefile.in (GUILE_SOURCE_FILES): Renamed from
GUILE_FILE_LIST.
(GUILE_COMPILED_FILES): New variable.
(GUILE_FILES) Update.
(GUILD, GUILD_TARGET_FLAG, GUILD_COMPILE_FLAGS): New variables.
(stamp-guile): Compile scm files.
* guile/guile.c (boot_guile_support): New function.
(standard_throw_args_p): New function.
(print_standard_throw_error, print_throw_error): New functions.
(handle_boot_error): New function.
(initialize_scheme_side): Rewrite to call boot_guile_support.
* guile/lib/gdb/boot.scm: Update %load-compiled-path.  Load gdb.go.
* guile/lib/gdb/init.scm (%silence-compiler-warnings%): New function.