review.tizen.org Git - external/binutils.git/log

Automatic date update in version.in

Fix warning on gdb/compile/compile.c (C++-ify "triplet_rx")

This fixes a GCC warning that happens when compiling
gdb/compile/compile.c on some GCC versions (e.g., "gcc (GCC) 7.2.1
20180104 (Red Hat 7.2.1-6)"):

../../gdb/compile/compile.c: In function 'void eval_compile_command(command_line*, const char*, compile_i_scope_types, void*)':
../../gdb/compile/compile.c:548:19: warning: 'triplet_rx' may be used uninitialized in this function [-Wmaybe-uninitialized]
     error_message = compiler->fe->ops->set_arguments_v0 (compiler->fe, triplet_rx,
     ~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         argc, argv);
         ~~~~~~~~~~~
../../gdb/compile/compile.c:466:9: note: 'triplet_rx' was declared here
   char *triplet_rx;
         ^~~~~~~~~~

It's a simple patch that converts "triplet_rx" from "char *" to
"std::string", thus guaranteeing that it will be always initialized.

I've regtested this patch and did not find any regressions.  OK to
apply on both master and 8.1 (after creating a bug for it)?

gdb/ChangeLog:
2018-01-17  Sergio Durigan Junior  <sergiodj@redhat.com>

* compile/compile.c (compile_to_object): Convert "triplet_rx"
to "std::string".

configure: Fix test for fs_base/gs_base in <sys/user.h>

Make <sys/types.h> be included prior to including <sys/user.h>.

glibc versions older than 2.14 use __uintNN_t types within certain
structures defined in <sys/user.h> probably assuming these types are
defined prior to including the header. This results in the following
`configure` feature test compilation error that makes it think that
`struct user_regs_struct` doesn't have `fs_base`/`gs_base` fields,
althouh it does.

    configure:13617: checking for struct user_regs_struct.fs_base
    configure:13617: gcc -c -g -O2 -I/linux/include conftest.c >&5
    In file included from conftest.c:158:0:
    /usr/include/sys/user.h:32:3: error: unknown type name '__uint16_t'
       __uint16_t  cwd;
       ^
    /usr/include/sys/user.h:33:3: error: unknown type name '__uint16_t'
       __uint16_t  swd;
       ^
    /usr/include/sys/user.h:34:3: error: unknown type name '__uint16_t'
       __uint16_t  ftw;
       ^
    /usr/include/sys/user.h:35:3: error: unknown type name '__uint16_t'
       __uint16_t  fop;
       ^
    /usr/include/sys/user.h:36:3: error: unknown type name '__uint64_t'
       __uint64_t  rip;
       ^
    /usr/include/sys/user.h:37:3: error: unknown type name '__uint64_t'
       __uint64_t  rdp;
       ^
    /usr/include/sys/user.h:38:3: error: unknown type name '__uint32_t'
       __uint32_t  mxcsr;
       ^
    /usr/include/sys/user.h:39:3: error: unknown type name '__uint32_t'
       __uint32_t  mxcr_mask;
       ^
    /usr/include/sys/user.h:40:3: error: unknown type name '__uint32_t'
       __uint32_t  st_space[32];   /* 8*16 bytes for each FP-reg = 128 bytes */
       ^
    /usr/include/sys/user.h:41:3: error: unknown type name '__uint32_t'
       __uint32_t  xmm_space[64];  /* 16*16 bytes for each XMM-reg = 256 bytes */
       ^
    /usr/include/sys/user.h:42:3: error: unknown type name '__uint32_t'
       __uint32_t  padding[24];
       ^
    configure:13617: $? = 1
    configure: failed program was:
    | /* confdefs.h */
    ...
    | /* end confdefs.h.  */
    | #include <sys/user.h>
    |
    | int
    | main ()
    | {
    | static struct user_regs_struct ac_aggr;
    | if (ac_aggr.fs_base)
    | return 0;
    |   ;
    |   return 0;
    | }

Recent glibc versions don't use typedef'ed int types in <sys/user.h>,
thus allowing it to be included as is
(glibc commit d79a9c949c84e7f0ba33e87447c47af833e9f11a).
However there're still some distros alive that use older glibc,
for instance, RHEL/CentOS 6 package glibc 2.12.

Also affects PR gdb/21559:

    ../../gdb/regcache.c:1087: internal-error: void regcache_raw_supply(regcache, int, const void): Assertion `regnum >= 0 && regnum < regcache->descr->nr_raw_registers' failed.

As noted by Andrew Paprocki, who submitted the PR
(https://sourceware.org/bugzilla/show_bug.cgi?id=21559#c3):

    > It should be noted that modifying `configure` to force on
    > `HAVE_STRUCT_USER_REGS_STRUCT_FS_BASE` and
    > `HAVE_STRUCT_USER_REGS_STRUCT_GS_BASE` fixes this issue. For some
    > reason the `configure` tests for `fs_base` and `gs_base` fail
    > even though `sys/user.h` on RHEL5 has the fields defined in
    > `user_regs_struct`.

Note that this patch does NOT fix the root cause of PR gdb/21559,
although now that `configure` properly detects the presence of the
fields and sets HAVE_XXX accordingly, the execution takes another
path, which doesn't lead to the assertion failure in question.

gdb/ChangeLog:
2018-01-17  Eldar Abusalimov  <eldar.abusalimov@jetbrains.com>

PR gdb/21559
* configure.ac: Include <sys/types.h> prior to <sys/user.h> when
checking for fs_base/gs_base fields in struct user_regs_struct.
* configure: Regenerate.

gdb/gdbserver/ChangeLog:
2018-01-17  Eldar Abusalimov  <eldar.abusalimov@jetbrains.com>

PR gdb/21559
* configure.ac: Include <sys/types.h> prior to <sys/user.h> when
checking for fs_base/gs_base fields in struct user_regs_struct.
* configure: Regenerate.

Don't pass -m64 to libcc1 on aarch64-linux.

Nowadays, if we use "compile" on aarch64-linux, we'll get the following
error,

(gdb) compile code -- ;
aarch64-none-linux-gnu-gcc: error: unrecognized command line option '-m64'

because the default gcc_target_options returns "-m64" and
"-mcmodel=large", neither is useful to aarch64-linux.

gdb:

2018-01-17 Yao Qi <yao.qi@linaro.org>

* aarch64-linux-tdep.c (aarch64_linux_gcc_target_options): New
function.
(aarch64_linux_init_abi): Install it to gdbarch hook
gcc_target_options.

Relax gdb.compile/compile.exp to match the address printed for frame

One test in gdb.compile/compile.exp passes on one fedora builder,

bt
#0  0x00007ffff7ff43f6 in _gdb_expr (__regs=0x7ffff7ff2000) at gdb
command line:1^M
#1  <function called from gdb>^M
#2  main () at /home/gdb-buildbot/fedora-x86-64-1/fedora-x86-64/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.compile/compile.c:106^M
(gdb) PASS: gdb.compile/compile.exp: bt

but fails on my machine with gcc trunk,

bt^M
#0  _gdb_expr (__regs=0x7ffff7ff3000) at gdb command line:1^M
#1  <function called from gdb>^M
#2  main () at gdb/testsuite/gdb.compile/compile.c:106^M
(gdb) FAIL: gdb.compile/compile.exp: bt

The test should be tweaked to match both cases (pc in the start of line
vs pc in the middle of line).  Note that I am not clear that why libcc1
emits debug info this way so that the address is in the middle of line.

gdb/testsuite:

2018-01-17  Yao Qi  <yao.qi@linaro.org>

* gdb.compile/compile.exp: Match the address printed for
frame in the output of command "bt".

Automatic date update in version.in

Fix scm-ports.exp regression

In https://sourceware.org/ml/gdb-patches/2017-12/msg00215.html, Jan
pointed out that the scalar printing patches caused a regression in
scm-ports.exp on x86.

What happens is that on x86, this:

set sp_reg [get_integer_valueof "\$sp" 0]

... ends up setting sp_reg to a negative value, because
get_integer_valueof uses "print/d":

    print /d $sp
    $1 = -11496

Then later the test suite does:

    gdb_test "guile (print (seek rw-mem-port (value->integer sp-reg) SEEK_SET))" \
"= $sp_reg" \
"seek to \$sp"

... expecting this value to be identical to the saved $sp_reg value.
However it gets:

    guile (print (seek rw-mem-port (value->integer sp-reg) SEEK_SET))
    = 4294955800

"print" is just a wrapper for guile's format:

    gdb_test_no_output "guile (define (print x) (format #t \"= ~A\" x) (newline))"

The seek function returns a scm_t_off, the printing of which is
handled by guile, not by gdb.

Tested on x86-64 Fedora 26 using an ordinary build and also a -m32
build.

2018-01-15  Tom Tromey  <tom@tromey.com>

* gdb.guile/scm-ports.exp (test_mem_port_rw): Use get_valueof to
compute sp_reg.

Automatic date update in version.in

Add testcase for GDB hang fixed by previous commit

This adds a testcase for the previous commit.  The regression was
related to in-line step overs.  The reason we didn't see it on native
x86-64/s390 GNU/Linux testing is that native debugging uses displaced
stepping by default (because native debugging defaults to "maint set
target-non-stop on"), unlike remote debugging.

So in order to trigger the bug with native debugging as well, the
testcase disables displaced stepping explicitly.

Also, instead of using watchpoints to trigger the regression, the
testcase uses a breakpoint at address 0, which should be more
portable.

gdb/testsuite/ChangeLog:
2018-01-12  Pedro Alves  <palves@redhat.com>

* gdb.base/continue-after-aborted-step-over.c: New.
* gdb.base/continue-after-aborted-step-over.exp: New.

Fix GDB hang with remote after error from resume

Since this commit --

  Fix PR18360 - internal error when using "interrupt -a"
  (https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=c65d6b55)

-- the testsuite shows long delays on s390 with native-gdbserver when
executing certain tests, such as watchpoints.exp.  These hangs have been
discussed before in the context of buildbot problems, see here:

  https://sourceware.org/ml/gdb-patches/2017-12/msg00413.html

The problem can easily be triggered by stopping on a breakpoint, then
setting impossible watchpoints, and finally doing "continue".  Then, after
having set the step-over state (in keep_going_pass_signal in infrun.c),
GDB tries to insert breakpoints and watchpoints into the inferior.  This
fails, and the "continue" command is aborted.  But the step-over state is
not cleared in this case, which causes future step-over attempts to be
skipped since GDB thinks that "we already have an in-line step-over
operation ongoing" (see start_step_over in infrun.c).  Thus the next
"continue" just goes on to wait for events from the remote, which will
never occur.

The problem can also be reproduced on amd64 with native-gdbserver, using
the following change to watchpoints.exp:

-- >8 --
--- a/gdb/testsuite/gdb.base/watchpoints.exp
+++ b/gdb/testsuite/gdb.base/watchpoints.exp
@@ -61,2 +61,3 @@ with_test_prefix "before inferior start" {
      gdb_test "watch ival3" ".*" ""
+    gdb_test "watch *(char \[256\] *) main"

-- >8 --

To fix the hang, this patch clears the step-over info when
insert_breakpoints has failed.  Of course, with native-gdbserver the
watchpoints.exp test case still causes many FAILs on s390, because
gdbserver does not support watchpoints for that target.  This is a
separate issue.

gdb/ChangeLog:
2018-01-12  Andreas Arnez  <arnez@linux.vnet.ibm.com>

* infrun.c (keep_going_pass_signal): Clear step-over info when
insert_breakpoints fails.

Bump GDB version number to 8.0.91.DATE-git.

gdb/ChangeLog:

* version.in: Set GDB version number to 8.0.91.DATE-git.
* PROBLEMS: Likewise.

Document the GDB 8.0.91 release in gdb/ChangeLog

gdb/ChangeLog:

GDB 8.0.91 released.

Set GDB version number to 8.0.91.

gdb/ChangeLog:

* version.in: Set GDB version number to 8.0.91.
* PROBLEMS: Likewise.

gdb/NEWS: Rename "Changes since 8.0" into "Changes in 8.1".

gdb/ChangeLog:

* NEWS: Rename "Changes since 8.0" into "Changes in 8.1".

Automatic date update in version.in

gdb.base/breakpoint-in-ro-region.exp regression on sss targets (PR gdb/22583)

As Maciej reported at
<https://sourceware.org/ml/gdb-patches/2017-12/msg00212.html>, this
commit:

commit d930703d68ae160ddfe8ebe5fdcf416fb6090e1e
Date: Thu Nov 16 18:44:43 2017 +0000
Subject: Don't ever Quit out of resume

caused regressions on software single-set targets, specifically:

FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw off: single-step breakpoint is not left behind
FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw on: single-step breakpoint is not left behind
FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted on: auto-hw off: step in ro region (cannot insert hw break)
FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted on: auto-hw off: single-step breakpoint is not left behind
FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted on: auto-hw on: single-step breakpoint is not left behind

and indeed detailed logs indicate a breakpoint is left lingering, e.g.:

(gdb) PASS: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw off: step in ro region (cannot insert sw break)
maint info breakpoints 0
Num     Type           Disp Enb Address    What
0       sw single-step keep y   0x00400774 in main at [...]/gdb/testsuite/gdb.base/breakpoint-in-ro-region.c:24 inf 1 thread 1
stop only in thread 1
(gdb) FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw off: single-step breakpoint is not left behind

vs:

(gdb) PASS: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw off: step in ro region (cannot insert sw break)
maint info breakpoints 0
No breakpoint or watchpoint matching '0'.
(gdb) PASS: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw off: single-step breakpoint is not left behind

as at commit d930703d68ae^.

Before commit d930703d68ae, we had a cleanup installed in 'resume'
that would delete single-step breakpoints on error:

  /* Resuming.  */

  /* Things to clean up if we QUIT out of resume ().  */
  static void
  resume_cleanups (void *ignore)
  {
    if (!ptid_equal (inferior_ptid, null_ptid))
     delete_single_step_breakpoints (inferior_thread ());

    normal_stop ();
  }

That whole function was removed by d930703d68ae mainly to eliminate
the normal_stop call:

~~~~
    Note that the exception called from within resume ends up calling
    normal_stop via resume_cleanups.  That's very borked though, because
    normal_stop is going to re-handle whatever was the last reported
    event, possibly even re-running a hook stop...
~~~~

But as the regression shows, removing resume_cleanups completely went
a bit too far, as the delete_single_step_breakpoints call is still
necessary.

So fix the regression by reinstating the
delete_single_step_breakpoints call on error.  However, since we're
trying to eliminate cleanups, restore it in a different form (using
TRY/CATCH).

Tested on x86-64 GNU/Linux both top of master and on top of a series
that implements software single-step on x86.

gdb/ChangeLog:
2018-01-11  Pedro Alves  <palves@redhat.com>

PR gdb/22583
* infrun.c (resume): Rename to ...
(resume_1): ... this.
(resume): Reimplement as wrapper around resume_1.

Fix backwards compatibility with old GDBservers (PR remote/22597)

At <https://sourceware.org/ml/gdb-patches/2017-12/msg00285.html>,
Maciej reported that commit:

  commit 5cd63fda035d4ba949e6478406162c4673b3c9ef
  Date: Wed Oct 4 18:21:10 2017 +0100
  Subject: Fix "Remote 'g' packet reply is too long" problems with multiple inferiors

made GDB stop working with older stubs.  Any attempt to continue
execution after the initial connection fails with:

  [...]
  Process .../gdb/testsuite/outputs/gdb.base/advance/advance created; pid = 2670
  Listening on port 2346
  target remote [...]:2346
  Remote debugging using [...]:2346
  Reading symbols from .../lib64/ld.so.1...done.
  [Switching to Thread <main>]
  (gdb) continue
  Cannot execute this command without a live selected thread.
  (gdb)

The problem is:

  (gdb) c
  Cannot execute this command without a live selected thread.
  (gdb) info threads
    Id   Target Id         Frame
    1    Thread 14917      0x00007f341cd98ed0 in _start () from /lib64/ld-linux-x86-64.so.2

  The current thread <Thread ID 2> has terminated.  See `help thread'.
      ^^^^^^^^^^^
  (gdb)

Note, thread _2_.  There's really only one thread in the inferior
(it's still at the entry point), but still GDB added a bogus second
thread.

The reason GDB started adding a second thread after 5cd63fda035d is
this hunk:

+                 if (event->ptid == null_ptid)
+                   {
+                     const char *thr = strstr (p1 + 1, ";thread:");
+                     if (thr != NULL)
+                       event->ptid = read_ptid (thr + strlen (";thread:"),
+                                                NULL);
+                     else
+                       event->ptid = magic_null_ptid;
+                   }

Note the else branch that falls back to magic_null_ptid.  We reach
that when we process the initial stop reply sent back in response to
the the "?" (status) packet early in the connection setup:

Sending packet: $?#3f...Ack
Packet received: T0506:0000000000000000;07:40a510f4fd7f0000;10:d0fe1201577f0000;

And note that that response does not include a ";thread:XXX" part.

This stop reply is processed after listing threads with qfThreadInfo /
qsThreadInfo :

Sending packet: $qfThreadInfo#bb...Ack
Packet received: m3915
Sending packet: $qsThreadInfo#c8...Ack
Packet received: l

meaning, when we process that stop reply, we treat the event as coming
from a thread with ptid == magic_null_ptid, which is not yet in the
thread list, so we add it then:

  (top-gdb) p ptid
  $1 = {m_pid = 42000, m_lwp = -1, m_tid = 1}
  (top-gdb) bt
  #0  0x0000000000840a8c in add_thread_silent(ptid_t) (ptid=...) at src/gdb/thread.c:269
  #1  0x00000000007ad61d in remote_add_thread(ptid_t, int, int) (ptid=..., running=0, executing=0)
      at src/gdb/remote.c:1838
  #2  0x00000000007ad8de in remote_notice_new_inferior(ptid_t, int) (currthread=..., executing=0)
      at src/gdb/remote.c:1921
  #3  0x00000000007b758b in process_stop_reply(stop_reply*, target_waitstatus*) (stop_reply=0x1158860, status=0x7fffffffcc00)
      at src/gdb/remote.c:7217
  #4  0x00000000007b7a38 in remote_wait_as(ptid_t, target_waitstatus*, int) (ptid=..., status=0x7fffffffcc00, options=0)
      at src/gdb/remote.c:7380
  #5  0x00000000007b7cd1 in remote_wait(target_ops*, ptid_t, target_waitstatus*, int) (ops=0x102fac0 <remote_ops>, ptid=..., status=0x7fffffffcc00, options=0) at src/gdb/remote.c:7446
  #6  0x000000000081587b in delegate_wait(target_ops*, ptid_t, target_waitstatus*, int) (self=0x102fac0 <remote_ops>, arg1=..., arg2=0x7fffffffcc00, arg3=0) at src/gdb/target-delegates.c:138
  #7  0x0000000000827d77 in target_wait(ptid_t, target_waitstatus*, int) (ptid=..., status=0x7fffffffcc00, options=0)
      at src/gdb/target.c:2179
  #8  0x0000000000715fda in do_target_wait(ptid_t, target_waitstatus*, int) (ptid=..., status=0x7fffffffcc00, options=0)
      at src/gdb/infrun.c:3589
  #9  0x0000000000716351 in wait_for_inferior() () at src/gdb/infrun.c:3707
  #10 0x0000000000715435 in start_remote(int) (from_tty=1) at src/gdb/infrun.c:3212

things go downhill from this.

We don't see the problem with current master gdbserver, because that
version always sends the ";thread:" part in the initial stop reply:

Sending packet: $?#3f...Packet received: T0506:0000000000000000;07:a0d4ffffff7f0000;10:d05eddf7ff7f0000;thread:p3cea.3cea;core:3;

Years ago I had added a "--disable-packet=" command line option to
gdbserver which comes in handy for testing this, since the existing
"--disable-packet=Tthread" precisely makes gdbserver not send that
";thread:" part in stop replies.  The testcase added by this commit
emulates old gdbserver making use of that.

I've compared a testrun at 5cd63fda035d^ (before regression) with
'current master+patch', against old gdbserver at f8b73d13b7ca^.  I
hacked out --once, and "monitor exit" to be able to test.  The results
are a bit too unstable to tell accurately, but it looked like there
were no regressions.  Maciej confirmed this worked for him as well.

No regressions on master (against master gdbserver).

gdb/ChangeLog:
2018-01-11  Pedro Alves  <palves@redhat.com>

PR remote/22597
* remote.c (remote_parse_stop_reply): Default to the last-set
general thread instead of to 'magic_null_ptid'.

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

PR remote/22597
* gdb.server/stop-reply-no-thread.c: New file.
* gdb.server/stop-reply-no-thread.exp: New file.

Automatic date update in version.in

language_get_symbol_name_matcher -> get_symbol_name_matcher

Rename language_get_symbol_name_matcher -> get_symbol_name_matcher,
since the function is no longer a straight "language method".

gdb/ChangeLog:
2018-01-10 Pedro Alves <palves@redhat.com>

* language.h (language_get_symbol_name_matcher): Rename ...
(get_symbol_name_matcher): ... this.
* language.c (language_get_symbol_name_matcher): Ditto.
* dictionary.c, linespec.c, minsyms.c, psymtab.c, symtab.c: All
callers adjusted.

Ada: make verbatim matcher override other language matchers (PR gdb/22670)

A previous patch fixed verbatim matching in the lookup at the minimal
symbol level, but we should also be finding that same symbol through
the partial/full symtab search.

For example, this is what happens if we use "print" instead of
"break":

    (gdb) p <MixedCaseFunc>
    $1 = {<text variable, no debug info>} 0x4024dc <MixedCaseFunc>

Before the C++ wildmatching series, GDB knows that MixedCaseFunc is a
function without parameters, and the expression above means calling
it.  If you try it before having started the inferior, you'd get the
following (expected) error:

    (gdb) print  <MixedCaseFunc>
    You can't do that without a process to debug.

The main idea behind making the name matcher be determined by the
symbol's language is so that C++ (etc.) wildmatching in linespecs
works even if the current language is not C++, as e.g., when you step
through C or assembly code.

Ada's verbatim matching syntax however ("<...>") isn't quite the same.
It is more a property of the current language than of a particular
symbol's language.  We want to support this syntax when debugging an
Ada program, but it's reason of existence is to find non-Ada symbols.
This suggests going back to enabling it depending on current language
instead of language of the symbol being matched.

I'm not entirely happy with the "current_language" reference (though I
think that it's harmless).  I think we could try storing the current
language in the lookup_name_info object, and then convert a bunch of
functions more to pass around lookup_name_info objects instead of
"const char *" names.  I.e., build the lookup_name_info higher up.
I'm not sure about that, I'll have to think more about it.  Maybe
something different will be better.  Meanwhile, this gets us going.

I've extended the testcase to also exercise a no-debug-info function,
for extra coverage of the minsyms-only paths.

gdb/ChangeLog:
2018-01-10  Pedro Alves  <palves@redhat.com>

PR gdb/22670
* dwarf2read.c
(gdb_index_symbol_name_matcher::gdb_index_symbol_name_matcher):
Adjust to use language_get_symbol_name_matcher instead of
language_defn::la_get_symbol_name_matcher.
* language.c (language_get_symbol_name_matcher): If in Ada mode
and the lookup name is a verbatim match, return Ada's matcher.
* language.h (language_get_symbol_name_matcher): Adjust comment.
(ada_lookup_name_info::verbatim_p):: New method.

gdb/testsuite/ChangeLog:
2018-01-10  Pedro Alves  <palves@redhat.com>

PR gdb/22670
* gdb.ada/bp_c_mixed_case.exp: Add intro comment.  Test printing C
functions too.  Test setting breakpoints and printing C functions
with no debug info too.
* gdb.ada/bp_c_mixed_case/qux.c: New file.

Fix gdb.ada/complete.exp's "complete break ada" test (PR gdb/22670)

This patch fixes the regression covered by the test added by:

    commit 344420da6beac1e0b2f7964e7101f8dcdb509b0d
    Date: Thu Jan 4 03:30:37 2018 -0500
    Subject: Add "complete break ada" test to gdb.ada/complete.exp

The regression had been introduced by:

    commit b5ec771e60c1a0863e51eb491c85c674097e9e13
    Date:   Wed Nov 8 14:22:32 2017 +0000
    Subject: Introduce lookup_name_info and generalize Ada's FULL/WILD name matching

The gist of it is that linespec completion in Ada mode is generating
additional matches that should not appear in the match list
(internally generated symbols, or symbols that should be enclosed
between "<...>").  These extraneous entries have uppercase characters, such as:

    break ada__stringsS
    break ada__strings__R11s
    [etc]

These matches come from minimal symbols.  The problem is that Ada
minsyms end up with no language set (language_auto), and thus we end
up using the generic symbol name matcher for those instead of Ada's.
We already had a special case for in compare_symbol_name to handle
this, but it was limited to expressions, while the case at hand is
completing a linespec.  Fix this by applying the special case to
linespec completion as well.  I.e., remove the EXPRESSION check from
compare_symbol_name.  That alone turns out to not be sufficient still
-- GDB would still show a couple entries that shouldn't be there:

~~
    break ada__exceptions__exception_data__append_info_exception_name__2Xn
    break ada__exceptions__exception_data__exception_name_length__2Xn
~~

The reason is that these minimal symbols end up with their language
set to language_cplus / C++, because those encoded names manage to
demangle successfully as C++ symbols (using an old C++ mangling
scheme):

  $ echo ada__exceptions__exception_data__append_info_exception_name__2Xn | c++filt
  Xn::ada__exceptions__exception_data__append_info_exception_name(void)

It's unfortunate that Ada's encoding scheme doesn't start with some
unique prefix like "_Z" in the C++ Itanium ABI mangling scheme.  For
now, paper over that by treating C++ minsyms as Ada minsyms.

gdb/ChangeLog:
2018-01-10  Pedro Alves  <palves@redhat.com>

        PR gdb/22670
* ada-lang.c (ada_collect_symbol_completion_matches): If the
minsym's language is language_auto or language_cplus, pass down
language_ada instead.
* symtab.c (compare_symbol_name): Don't frob symbol language here.

gdb/testsuite/ChangeLog:
2018-01-10  Pedro Alves  <palves@redhat.com>

        PR gdb/22670
* gdb.ada/complete.exp ("complete break ada"): Replace kfail with
a fail.

Fix gdb.ada/bp_c_mixed_case.exp (PR gdb/22670)

The problem here is that we are using the user-provided lookup name
literally for name comparisons.  I.e., "<MixedCase>" with the "<>"s
included.

This commit fixes the minsym lookup case.  psymbol/symbol lookup will
be fixed in a follow up.

In the minsym case, we're using using the user-provided lookup name
literally for linkage name comparisons.  That obviously can't work
since the "<>" are not really part of the linkage name.

The original idea was that we'd use the symbol's language to select
the right symbol name matching algorithm, but that doesn't work for
Ada because it's not really possible to unambiguously tell from the
linkage name alone whether we're dealing with Ada symbols, so Ada
minsyms end up with no language set, or sometimes C++ set.

So fix this by treating Ada mode specially when determining the
linkage name to match against.

gdb/ChangeLog:
2018-01-10  Pedro Alves  <palves@redhat.com>

PR gdb/22670
* minsyms.c (linkage_name_str): New function.
(iterate_over_minimal_symbols): Use it.

gdb/testsuite/ChangeLog:
2018-01-10  Pedro Alves  <palves@redhat.com>

PR gdb/22670
* gdb.ada/bp_c_mixed_case.exp: Remove setup_kfail calls.

Automatic date update in version.in

hurd: Add enough auxv support for AT_ENTRY for PIE binaries

Add PIE support for hurd, by faking an AT_ENTRY auxv entry. That value
is expected to be read by svr4_exec_displacement, which will propagate
the executable displacement.

gdb/ChangeLog:

* gdb/gnu-nat.c: Include <elf.h> and <link.h>.
(gnu_xfer_auxv): New function.
(gnu_xfer_partial): Call gnu_xfer_auxv when `object' is
TARGET_OBJECT_AUXV.

Fix GDBserver build failure when $development is false

When we set bfd/development.sh:$development to false, GDBserver failed to
build,

selftest.o: In function `selftests::run_tests(char const*)':
binutils-gdb/gdb/gdbserver/../common/selftest.c:97:undefined reference to `selftests::reset()'
collect2: error: ld returned 1 exit status

selftest.o shouldn't be compiled and linked when $development is false.
With this patch, in release mode, GDBserver doesn't nothing with option
--selftest,

$ ./gdbserver --selftest=foo
Selftests are not available in a non-development build.
$ ./gdbserver --selftest
Selftests are not available in a non-development build.

gdb/gdbserver:

2018-01-08  Yao Qi  <yao.qi@linaro.org>
    Simon Marchi  <simon.marchi@ericsson.com>

* Makefile.in (OBS): Remove selftest.o.
* configure.ac: Set srv_selftest_objs if $development is true.
(GDBSERVER_DEPFILES): Append $srv_selftest_objs.
* configure: Re-generated.
* server.c (captured_main): Wrap variable selftest_filter with
GDB_SELF_TEST.

gdb/testsuite:

2018-01-08  Simon Marchi  <simon.marchi@ericsson.com>

* gdb.server/unittest.exp: Match the output in non-development
mode.

Fix GDB build failure when $development is false

We don't build GDB selftests bits when $development is false.  However, if
we turn bfd/development.sh:$development to false, common/selftest.c is
compiled which is not expected.  It causes the build failure,

selftest.o: In function `selftests::run_tests(char const*)':
binutils-gdb/gdb/common/selftest.c:97: undefined reference to `selftests::reset()'
collect2: error: ld returned 1 exit status

I fix this issue by putting selftest.o selftest-arch.o into CONFIG_OBS
only when $development is true.  After this is fixed, there are other
build failures in maint.c, this patch fixes them as well.

In the release mode, the output of these commands are:

(gdb) maintenance selftest
Selftests are not available in a non-development build.
(gdb) maintenance selftest foo
Selftests are not available in a non-development build.
(gdb) maintenance info selftests
Selftests are not available in a non-development build.

gdb:

2018-01-08  Yao Qi  <yao.qi@linaro.org>
    Simon Marchi  <simon.marchi@ericsson.com>

* Makefile.in (COMMON_SFILES): Remove selftest-arch.c and
common/selftest.c.
(COMMON_OBS): Remove selftest.o.
* configure.ac: Append selftest-arch.c and common/selftest.c to
CONFIG_SRCS.  Append selftest-arch.o and selftest.o to COMMON_OBS.
* configure: Re-generated.
* maint.c (maintenance_selftest): Wrap selftests::run_tests with
GDB_SELF_TEST.
(maintenance_info_selftests): Likewise.

gdb/testsuite:

2018-01-08  Simon Marchi  <simon.marchi@ericsson.com>

* gdb.gdb/unittest.exp: Match output in non-development mode.

Automatic date update in version.in

Fix regression: cannot start with LD_PRELOAD=libSegFault.so (PR gdb/18653#c7)

At https://sourceware.org/bugzilla/show_bug.cgi?id=18653#c7, Andrew
reports that the fix for PR gdb/18653 made GDB useless if you preload
libSegFault.so, because GDB internal-errors on startup:

$ LD_PRELOAD=libSegFault.so gdb
src/gdb/common/signals-state-save-restore.c:64: internal-error: unexpected signal handler
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Aborted (core dumped)
$

The internal error comes from the code saving the signal dispositions
inherited from gdb's parent:

(top-gdb) bt
#0  0x000000000056b001 in internal_error(char const*, int, char const*, ...) (file=0xaf5f38 "src/gdb/common/signals-state-save-restore.c", line=64, fmt=0xaf5f18 "unexpected signal handler") at src/gdb/common/errors.c:54
#1  0x00000000005752c9 in save_original_signals_state() () at src/gdb/common/signals-state-save-restore.c:64
#2  0x00000000007425de in captured_main_1(captured_main_args*) (context=0x7fffffffd860)
     at src/gdb/main.c:509
#3  0x0000000000743622 in captured_main(void*) (data=0x7fffffffd860) at src/gdb/main.c:1145
During symbol reading, cannot get low and high bounds for subprogram DIE at 24065.
#4  0x00000000007436f9 in gdb_main(captured_main_args*) (args=0x7fffffffd860) at src/gdb/main.c:1171
#5  0x0000000000413acd in main(int, char**) (argc=1, argv=0x7fffffffd968) at src/gdb/gdb.c:32

This commit downgrades the internal error to a warning.  You'll get
instead:

~~~
$ LD_PRELOAD=libSegFault.so gdb
warning: Found custom handler for signal 11 (Segmentation fault) preinstalled.
Some signal dispositions inherited from the environment (SIG_DFL/SIG_IGN)
won't be propagated to spawned programs.
GNU gdb (GDB) 8.0.50.20171213-git
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
(gdb)
~~~

This also moves the location where save_original_signals_state is
called a bit further below (to after option processing), so that "-q"
disables the warning:

~~~
$ LD_PRELOAD=libSegFault.so gdb -q
(gdb)
~~~

New testcase included.

gdb/ChangeLog:
2018-01-05  Pedro Alves  <palves@redhat.com>

PR gdb/18653
* common/signals-state-save-restore.c
(save_original_signals_state): New parameter 'quiet'.  Warn if we
find a custom handler preinstalled, instead of internal erroring.
But only warn if !quiet.
* common/signals-state-save-restore.h
(save_original_signals_state): New parameter 'quiet'.
* main.c (captured_main_1): Move save_original_signals_state call
after option handling, and pass QUIET.

gdb/gdbserver/ChangeLog:
2018-01-05  Pedro Alves  <palves@redhat.com>

PR gdb/18653
* server.c (captured_main): Pass quiet=false to
save_original_signals_state.

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

PR gdb/18653
* gdb.base/libsegfault.exp: New.

Fix gdb/spu-tdep.c build breakage

Commit de63c46b549d ("Fix regresssion(internal-error) printing
subprogram argument (PR gdb/22670)") missed updating spu-tdep.c for
the block_lookup_symbol interface change, resulting in:

  ../../binutils-gdb/gdb/spu-tdep.c: In function void spu_catch_start(objfile*):
  ../../binutils-gdb/gdb/spu-tdep.c:1969:59: error: cannot convert domain_enum_tag to symbol_name_match_type for argument 3 to symbol* block_lookup_symbol(const block*, const char*, symbol_name_match_type, domain_enum)
sym = block_lookup_symbol (block, "main", VAR_DOMAIN);
     ^

gdb/ChangeLog:
2018-01-05  Pedro Alves  <palves@redhat.com>

* spu-tdep.c (spu_catch_start): Pass
symbol_name_match_type::SEARCH_NAME to block_lookup_symbol.

Fix regresssion(internal-error) printing subprogram argument (PR gdb/22670)

At <https://sourceware.org/ml/gdb-patches/2017-12/msg00298.html>, Joel
wrote:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Consider the following code which first declares a tagged type (the
equivalent of a class in Ada), and then a procedure which takes a
pointer (access) to this type's 'Class.

    package Pck is
       type Top_T is tagged record
          N : Integer := 1;
       end record;
       procedure Inspect (Obj: access Top_T'Class);
    end Pck;

Putting a breakpoint in that procedure and then running to it triggers
an internal error:

    (gdb) break inspect
    (gdb) continue
    Breakpoint 1, pck.inspect (obj=0x63e010
    /[...]/gdb/stack.c:621: internal-error: void print_frame_args(symbol*, frame_info*, int, ui_file*): Assertion `nsym != NULL' failed.

What's special about this subprogram is that it takes an access to
what we call a 'Class type, and for implementation reasons, the
compiler adds an extra argument named "objL". If you are curious why,
it allows the compiler for perform dynamic accessibility checks that
are mandated by the language.

If we look at the location where we get the internal error (in
stack.c), we find that we are looping over the symbol of each
parameter, and for each parameter, we do:

    /* We have to look up the symbol because arguments can have
       two entries (one a parameter, one a local) and the one we
       want is the local, which lookup_symbol will find for us.
    [...]
        nsym = lookup_symbol (SYMBOL_LINKAGE_NAME (sym),
                              b, VAR_DOMAIN, NULL).symbol;
        gdb_assert (nsym != NULL);

The lookup_symbol goes through the lookup structure, which means the
symbol's linkage name ("objL") gets transformed into a
lookup_name_info object (in block_lookup_symbol), before it gets fed
to the block symbol dictionary iterators.  This, in turn, triggers the
symbol matching by comparing the "lookup" name which, for Ada, means
among other things, lowercasing the given name to "objl".  It is this
transformation that causes the lookup find no matches, and therefore
trip this assertion.

Going back to the "offending" call to lookup_symbol in stack.c, what
we are trying to do, here, is do a lookup by linkage name.  So, I
think what we mean to be doing is a completely literal symbol lookup,
so maybe not even strcmp_iw, but actually just plain strcmp???

In the past, in practice, you could get that effect by doing a lookup
using the C language. But that doesn't work, because we still end up
somehow using Ada's lookup_name routine which transforms "objL".

So, ideally, as I hinted before, I think what we need is a way to
perform a literal lookup so that searches by linkage names like the
above can be performed.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This commit fixes the problem by implementing something similar to
Joel's literal idea, but with some important differences.

I considered adding a symbol_name_match_type::LINKAGE and supporting
searching by linkage name for any language, but the problem with that
is that the dictionaries only work with SYMBOL_SEARCH_NAME, because
that's what is used for hashing.  We'd need separate dictionaries for
hashed linkage names.

So with the current symbol tables infrastructure, it's not literal
linkage names that we want to pass down, but instead literal _search_
names (SYMBOL_SEARCH_NAME, etc.).

However, psymbols have no overload/function parameter info in C++, so
a straight strcmp doesn't work properly for C++ name matching.

So what we do is be a little less aggressive then and add a new
symbol_name_match_type::SEARCH_SYMBOL instead that takes as input a
non-user-input search symbol, and then we skip any decoding/demangling
steps and make:

- Ada treat that as a verbatim match,
- other languages treat it as symbol_name_match_type::FULL.

This also fixes the new '"maint check-psymtabs" for Ada' testcase for
me (gdb.ada/maint_with_ada.exp).  I've not removed the kfail yet
because Joel still sees that testcase failing with this patch.
That'll be fixed in follow up patches.

gdb/ChangeLog:
2018-01-05  Pedro Alves  <palves@redhat.com>

PR gdb/22670
* ada-lang.c (literal_symbol_name_matcher): New function.
(ada_get_symbol_name_matcher): Use it for
symbol_name_match_type::SEARCH_NAME.
* block.c (block_lookup_symbol): New parameter 'match_type'.  Pass
it down instead of assuming symbol_name_match_type::FULL.
* block.h (block_lookup_symbol): New parameter 'match_type'.
* c-valprint.c (print_unpacked_pointer): Use
lookup_symbol_search_name instead of lookup_symbol.
* compile/compile-object-load.c (get_out_value_type): Pass down
symbol_name_match_type::SEARCH_NAME.
* cp-namespace.c (cp_basic_lookup_symbol): Pass down
symbol_name_match_type::FULL.
* cp-support.c (cp_get_symbol_name_matcher): Handle
symbol_name_match_type::SEARCH_NAME.
* infrun.c (insert_exception_resume_breakpoint): Use
lookup_symbol_search_name.
* p-valprint.c (pascal_val_print): Use lookup_symbol_search_name.
* psymtab.c (maintenance_check_psymtabs): Use
symbol_name_match_type::SEARCH_NAME and SYMBOL_SEARCH_NAME.
* stack.c (print_frame_args): Use lookup_symbol_search_name and
SYMBOL_SEARCH_NAME.
* symtab.c (lookup_local_symbol): Don't demangle the lookup name
if symbol_name_match_type::SEARCH_NAME.
(lookup_symbol_in_language): Pass down
symbol_name_match_type::FULL.
(lookup_symbol_search_name): New.
(lookup_language_this): Pass down
symbol_name_match_type::SEARCH_NAME.
(lookup_symbol_aux, lookup_local_symbol): New parameter
'match_type'.  Pass it down.
* symtab.h (symbol_name_match_type::SEARCH_NAME): New enumerator.
(lookup_symbol_search_name): New declaration.
(lookup_symbol_in_block): New 'match_type' parameter.

gdb/testsuite/ChangeLog:
2018-01-05  Joel Brobecker  <brobecker@adacore.com>

PR gdb/22670
* gdb.ada/access_tagged_param.exp: New file.
* gdb.ada/access_tagged_param/foo.adb: New file.

Fix gdb.ada/info_addr_mixed_case.exp (PR gdb/22670)

The comments about mixed case in the testcase are actually a red
herring.  The problem here is that we'd get to
ada_lookup_encoded_symbol with "my_table", which wraps the looked up
name in "<>"s to force a verbatim match, and that in turn disables
wild matching.

Fix this by swapping around the internals of ada_lookup_encoded_symbol
and ada_lookup_symbol, thus avoiding the encoding and
verbatim-wrapping in the ada_lookup_symbol case, the case that starts
with a user-provided lookup name.

Ada encoding is still done of course, in the ada_lookup_name_info
ctor.  This could be also seen as avoiding the double-encoding problem
in a different way.

gdb/ChangeLog:
2018-01-05  Pedro Alves  <palves@redhat.com>

PR gdb/22670
* ada-lang.c (ada_lookup_encoded_symbol): Reimplement in terms of
ada_lookup_symbol.
(ada_lookup_symbol): Reimplement in terms of
ada_lookup_symbol_list, bits factored out from
ada_lookup_encoded_symbol.

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

PR gdb/22670
* gdb.ada/info_addr_mixed_case.exp: Remove kfail.  Extend test to
exercise lower case too, and to exercise both full matching and
wild matching.

Set development mode to "off" by default.

bfd/ChangeLog:

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

Bump version to 8.0.90.DATE-git.

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

gdb/ChangeLog:

GDB 8.1 branch created (5219ac6237c272b938c28517bf371429260c71e7):
* version.in: Bump version to 8.0.90.DATE-git.

Automatic date update in version.in

RISC-V: Add 2 missing privileged registers.

gas/
* testsuite/gas/riscv/priv-reg.s: Add missing stval and mtval.
* testsuite/gas/riscv/priv-reg.d: Likewise.

include/
* opcode/riscv-opc.h (CSR_SBADADDR): Rename to CSR_STVAL.  Rename
DECLARE_CSR entry.  Add alias to map sbadaddr to CSR_STVAL.
(CSR_MBADADDR): Rename to CSR_MTVAL.  Rename DECLARE_CSR entry.
Add alias to map mbadaddr to CSR_MTVAL.

gdb.ada/maint_with_ada.exp: New testcase

This commit adds a new testcase testing the "check-psymtabs" and
"check-symtabs" maintenance commands.

The "maintenance check-psymtabs" commands is currently known to
produce some errors. While the situation was admetedly made worse
by the following patch...

    commit b5ec771e60c1a0863e51eb491c85c674097e9e13
    Date:   Wed Nov 8 14:22:32 2017 +0000
    Subject: Introduce lookup_name_info and generalize Ada's FULL/WILD name matching

... hence the reference to PR gdb/22670, the command was already
spotting one inconsistency prior to it:

    (gdb) maintenance check-psymtabs
    Global symbol `interfaces__cS' only found in /[...]/b~var_arr_typedef.adb psymtab

For now, the "check-psymtab" test is KFAIL-ed.

gdb/testsuite/ChangeLog:

        PR gdb/22670
        * gdb.ada/maint_with_ada: New testcase.

Tested on x86_64-linux.

Add new gdb.ada/bp_c_mixed_case testcase for PR gdb/22670

This patch adds a new testcase to demonstrate a regression introduced by:

    commit b5ec771e60c1a0863e51eb491c85c674097e9e13
    Date:   Wed Nov 8 14:22:32 2017 +0000
    Subject: Introduce lookup_name_info and generalize Ada's FULL/WILD name matching

The purpose of the testcase is to verify that a user can insert
a breakpoint on a C function while debugging Ada, even if the name
of the function includes uppercase letters, requiring us to use
Ada's "<...>" notation to tell the GDB that the symbol name should
be looked up verbatim.

As of the commit above, GDB is no longer finding the function:

    (gdb) break <MixedCaseFunc>
    Function "<MixedCaseFunc>" not defined.
    Make breakpoint pending on future shared library load? (y or [n])

Before the patch, the breakpoint was inserted without problem.

gdb/testsuite/ChangeLog:

        PR gdb/22670
        * gdb.ada/bp_c_mixed_case: New testcase.

Tested on x86_64-linux; generates a KPASS before the regression
was introduced, and now generates a KFAIL.

Add "complete break ada" test to gdb.ada/complete.exp

This patch adds a new test to demonstrate a regression introduced by:

    commit b5ec771e60c1a0863e51eb491c85c674097e9e13
    Date:   Wed Nov 8 14:22:32 2017 +0000
    Subject: Introduce lookup_name_info and generalize Ada's FULL/WILD name matching

The original purpose of the new test is to exercise the "complete"
command with an expression for which a large number of matches are
returned and to verify that each match returned is a plausible match.
In this particular case, the commit above causes GDB to generate
additional matches which should in fact not appear in the list
(internally generated symbols, or symbols that should be enclosed
between "<...>"). These extraneous entries are easy to spot, because
they have uppercase characters, such as:

    break ada__stringsS
    break ada__strings__R11s
    [etc]

For now, the new test is KFAIL'ed, to avoid generating a new FAIL
while we work on fixing that regression.

gdb/testsuite/ChangeLog:

        PR gdb/22670
        * gdb.ada/complete.exp: Add "complete break ada" test.

Tested on x86_64-linux with GDB built before and after the patch
that caused the regression (b5ec771e60c1a0863e51eb491c85c674097e9e13).
The test passes before the regression, and generates a KFAIL after.

Add gdb.ada/info_addr_mixed_case new testcase

This patch adds a new testcase to demonstrate a regression introduced by:

    commit b5ec771e60c1a0863e51eb491c85c674097e9e13
    Date:   Wed Nov 8 14:22:32 2017 +0000
    Subject: Introduce lookup_name_info and generalize Ada's FULL/WILD name matching

The purpose of the testcase is to verify that a user can use any
casing for an Ada symbol name passed to the "info address" command.
After the patch above was applied, GDB was no longer able to find
the symbol:

    (gdb) info address My_Table
    No symbol "My_Table" in current context.

gdb/testsuite/ChangeLog:

PR gdb/22670
* gdb.ada/info_addr_mixed_case: New testcase.

Tested on x86_64-linux, both before and after the patch.

Automatic date update in version.in

Create pseudo sections for FreeBSD NT_PROCSTAT_(PROC|FILES|VMMAP) notes.

bfd/ChangeLog:

* elf.c (elfcore_grok_freebsd_note): Handle
NT_FREEBSD_PROCSTAT_PROC, NT_FREEBSD_PROCSTAT_FILES, and
NT_FREEBSD_PROCSTAT_VMMAP.

Fix compile time warning introduced by previous delta.

* objcopy.c (merge_gnu_build_notes): Add cast to maximum address
constants.

Add support for v3 binary annotation notes.

  I am checking in the attached patch which updates the binutils
  support for version 3 binary annotation notes.  (Version 3 adds
  an end address to the ranges covered by the notes, so that it
  is possible to detect gaps in the coverage).

  This patch also stops the note merging feature of objcopy from
  executing if the notes have relocations against them.  This makes the
  code simpler, and prevents the problems with architectures which have
  unusual relocation management issues.

* objcopy.c (objcopy_internal_note): New structure.
(gap_exists): New function.
(is_open_note): New function.
(is_func_note): New function.
(is_64bit): New function.
(merge_gnu_build_notes): Handle v3 notes.  Do not merge
if there are relocations against the notes.
* readelf.c (get_note_type): Use short names for build attribute
notes.
(print_symbol_for_build_attribute): Rename to
get_symbol_for_build_attribute.  Returns the found symbol rather
than printing it.
(print_gnu_build_attribute_description): Maintain address ranges
for function notes as well as global notes.  Handle v3 notes.
(print_gnu_build_attribute_name): Use more space for printing the
name in wide mode.
* testsuite/binutils-all/note-2-32.s: Use .dc.l instead of .word.
Eliminate symbol references in order to remove the need for
relocations.
* testsuite/binutils-all/note-2-64.s: Likewise.
* testsuite/binutils-all/note-3-32.s: Add a size to the note_1
symbol.
* testsuite/binutils-all/note-3-64.s: Likewise.
* testsuite/binutils-all/mips/mips-note-2r-n32.d: Update expected
output.
* testsuite/binutils-all/mips/mips-note-2r-n64.d: Likewise.
* testsuite/binutils-all/mips/mips-note-2r.d: Likewise.
* testsuite/binutils-all/note-2-32.d: Likewise.
* testsuite/binutils-all/note-2-64.d: Likewise.
* testsuite/binutils-all/note-3-32.d: Likewise.
* testsuite/binutils-all/note-3-64.d: Likewise.
* testsuite/binutils-all/note-4-64.s: New test.  Checks v3 notes.
* testsuite/binutils-all/note-4-32.s: New test.
* testsuite/binutils-all/note-4-64.d: New test result file.
* testsuite/binutils-all/note-4-32.d: New test result file.

(Ada) New command to stop at start of exception handler.

When using gdb for debugging Ada source code, there are several catchpoint
types you can define in order to stop upon certain conditions.  Let's
use this small example:

procedure Foo is
begin
   begin
      raise Constraint_Error;
   exception
      when Program_Error =>
         null;
      when Constraint_Error =>
         null;
      when others =>
         null;
   end;
end Foo;

One can stop when the exception is being raised by using the exception
catchpoint like below:

(gdb) catch exception
Catchpoint 1: all Ada exceptions
(gdb)

In that case, when running Foo, gdb will stop at the line where the exception
was raised:

   begin
>>>   raise Constraint_Error;
   exception

This patch introduces new type of catchpoint, when the user wants to stop
at the location of the exception handling.
Imagine we want to stop on any exception handled by the program, we can do:

(gdb) catch handlers
Catchpoint 1: all Ada exceptions handlers
(gdb) r
Starting program: /tmp/foo

By doing so, when running Foo, gdb will stop here:

Catchpoint 1, exception at 0x000000000040255a in foo () at foo.adb:25
25          when Constraint_Error =>
(gdb)

It is also possible to stop when the Constraint_Error exception is being
handled in this program.  With this patch, we can use:

(gdb) catch handlers Constraint_Error
Catchpoint 1: `Constraint_Error' Ada exception handlers
(gdb)

Like for other catchpoint, you can set a condition when adding a catchpoint
on exception handlers.
Here the handlers catchpoint checks Global_Var:

(gdb) catch handlers Constraint_Error if Global_Var /= 0

gdb/ChangeLog:

        * ada-lang.h (ada_exception_catchpoint_kind) <ada_catch_handlers>:
        Add field.
        * ada-lang.c (struct exception_support_info) <catch_handlers_sym>:
        Add field.
        (default_exception_support_info) <catch_handlers_sym>: Add field.
        (exception_support_info_fallback) <catch_handlers_sym>: Add field.
        (ada_exception_name_addr_1): Add "catch handlers" handling.
        (ada_exception_catchpoint_cond_string) <ex>: New parameter.
        Update all callers.
        (create_excep_cond_exprs) <ex>: Add parameter.
        (re_set_exception): Update create_excep_cond_exprs call.
        (print_it_exception, print_one_exception, print_mention_exception)
        (print_recreate_exception): Add "catch handler" handling.
        (allocate_location_catch_handlers, re_set_catch_handlers)
        (check_status_catch_handlers, print_it_catch_handlers)
        (print_one_catch_handlers, print_mention_catch_handlers)
        (print_recreate_catch_handlers): New function.
        (catch_handlers_breakpoint_ops): New variable.
        (catch_ada_exception_command_split) <is_catch_handlers_cmd>:
        Add parameter.  Add "catch handler" handling.
        (ada_exception_sym_name, ada_exception_breakpoint_ops):
        Add "catch handler" handling.
        (ada_exception_catchpoint_cond_string): Add "catch handler"
        handling.
        (create_ada_exception_catchpoint): Update create_excep_cond_exprs
        call.
        (catch_ada_handlers_command): New function.
        (initialize_ada_catchpoint_ops): Initialize "catch handlers"
        operations structure.
        (_initialize_ada_language): Add "catch handlers" command entry.
        * NEWS: Document "catch handlers" feature.

gdb/doc/ChangeLog:

        * gdb.texinfo (Set Catchpoints): Add documentation for new
        "catch handlers" action.

gdb/testsuite/ChangeLog:

        * gdb.ada/excep_handle.exp: New testcase.
        * gdb.ada/excep_handle/foo.adb: New file.
        * gdb.ada/excep_handle/pck.ads: New file.

Tested on x86_64-linux.

Update year range in copyright notice of binutils files

ChangeLog rotation

Unbreak spurious fails in gdb.base/step-line.exp

My copyright year update in the copyright headers of the step-line
testcase caused it to start failing, due to shift in line numbers.

    FAIL: gdb.base/step-line.exp: continue to f1
    FAIL: gdb.base/step-line.exp: next to dummy 2
    FAIL: gdb.base/step-line.exp: next over dummy 2
    FAIL: gdb.base/step-line.exp: step into f2
    FAIL: gdb.base/step-line.exp: next over dummy 4
    FAIL: gdb.base/step-line.exp: next to dummy 5
    FAIL: gdb.base/step-line.exp: next to dummy 6
    FAIL: gdb.base/step-line.exp: next over dummy 6
    FAIL: gdb.base/step-line.exp: next to dummy 7
    FAIL: gdb.base/step-line.exp: next to dummy 8
    FAIL: gdb.base/step-line.exp: next over dummy 8
    FAIL: gdb.base/step-line.exp: next to dummy 9
    FAIL: gdb.base/step-line.exp: next to dummy 10
    FAIL: gdb.base/step-line.exp: next over dummy 10

This was caused by the copyright.py script after I changed it to
also update this testcase, which made the following transformation:

    -   Copyright (C) 2001-2017
    -   Free Software Foundation, Inc.
    +   Copyright (C) 2001-2018 Free Software Foundation, Inc.

We can easily unbreak the testcase without having to go back to
manual edits each year by adding an extra line in the header.

gdb/testsuite/ChangeLog:

* gdb.base/step-line.c: Add extra empty line in copyright header.
        * gdb.base/step-line.inp: Likewise.

Tested on x86_64-linux.

Automatic date update in version.in

Fix compile time warning (in the ARM simulator) about a print statement with insufficient arguments.

PR 22663
* maverick.c (DSPCDP4): Add missing parameter to debug print
statement.

Fix typo in do_mrs function in ARM assembler.

PR 18119
* config/tc-arm.c (do_mrs): Fix test of bits 16-19 in non-banked
version of ARM MRS instruction.

x86: partial revert of 10c17abdd0

Other than the variables in tc-i386.c using them, OPERAND_TYPE_REGYMM
and OPERAND_TYPE_REGZMM they aren't entirely unused. No need to update
i386-init.h though, as it mistakenly wasn't updated by the original
commit.

[gdb/Ada] slices of arrays with dynamic strides

    Consider the following Ada code:

       procedure Nested (L, U : Integer) is
          subtype Small_Type is Integer range L .. U;
          type Record_Type (I : Small_Type := L) is record
             S : String (1 .. I);
          end record;
          type Array_Type is array (Integer range <>) of Record_Type;

          A1 : Array_Type :=
            (1 => (I => 0, S => <>),
             2 => (I => 1, S => "A"),
             3 => (I => 2, S => "AB"));

          procedure Discard (R : Record_Type) is
          begin
             null;
          end Discard;

       begin
          Discard (A1 (1));  -- STOP
       end;

Trying to print a slice of that array currently yields:

    (gdb) p a1(1..3)
    $1 = ((i => 0, s => ""), (i => 0, s => ""), (i => 0, s => ""))

We expected instead:

    (gdb) p a1(1..3)
    $1 = ((i => 0, s => ""), (i => 1, s => "A"), (i => 2, s => "AB"))

This is because the functions we use in ada-lang.c to create the type
of the array slice (ada_value_slice and ada_value_slice_from_ptr) was
not taking into account the stride of the array. This patch fixes this.

gdb/ChangeLog:

        * ada-lang.c (ada_value_slice_from_ptr): Take array stride into
        account when creating the array type of the slice.
        (ada_value_slice): Likewise.

gdb/testsuite/ChangeLog:

        * gdb.ada/dyn_stride.exp: Add slice test.

Note that, with the current use of ada_value_slice, the enhancement
to handle dynamic array strides seems unnecessary, because I do not
see how an array with a dynamic stride can be referenced by either
by reference or pointer. Since references are coerced to array pointers,
in both cases, the slice is performed by ada_value_slice_from_ptr.
But ada_value_slice is enhanced nonetheless, in the spirit of making
the code more robust, in case we missed something, and also as similar
as possible with its from_ptr counterpart.

tested on x86_64-linux.

Add support for dynamic DW_AT_byte_stride.

This patch adds support for DW_AT_byte_stride, using Ada as one
example of where this would be useful. However, the implementation
is language-agnostic.

Consider the following Ada code:

   procedure Nested (L, U : Integer) is
      subtype Small_Type is Integer range L .. U;
      type Record_Type (I : Small_Type := L) is record
         S : String (1 .. I);
      end record;
      type Array_Type is array (Integer range <>) of Record_Type;

      A1 : Array_Type :=
        (1 => (I => 0, S => <>),
         2 => (I => 1, S => "A"),
         3 => (I => 2, S => "AB"));

      procedure Discard (R : Record_Type) is
      begin
         null;
      end Discard;

   begin
      Discard (A1 (1));  -- STOP
   end;

It defines an array A1 of Record_Type, which is a variant record
type whose maximum size actually depends on the value of the
parameters passed when calling Nested. As a result, the stride
of the array A1 cannot be known statically, which leads the compiler
to generate a dynamic DW_AT_byte_stride attribute for our type.
Here is what the debugging info looks like with GNAT:

        .uleb128 0x10   # (DIE (0x14e) DW_TAG_array_type)
        .long   .LASF17 # DW_AT_name: "foo__nested__T18b"
        .long   0x141   # DW_AT_byte_stride
        .long   0xdc    # DW_AT_type
        .uleb128 0x11   # (DIE (0x15f) DW_TAG_subrange_type)
        .long   0x166   # DW_AT_type
        .byte   0x3     # DW_AT_upper_bound
        .byte   0       # end of children of DIE 0x14e

There DW_AT_byte_stride is a reference to a local (internal)
variable:

        .uleb128 0x9    # (DIE (0x141) DW_TAG_variable)
        .long   .LASF6  # DW_AT_name: "foo__nested__T18b___PAD___XVZ"

This patch enhances GDB to handle this dynamic byte stride attribute
by first adding a new dynamic_prop_node_kind (DYN_PROP_BYTE_STRIDE)
to store the array dynamic stride info (when dynamic). It then enhances
the dynamic type resolver to handle this dynamic property.

Before applying this patch, trying to print the value of some of
A1's elements after having stopped at the "STOP" comment does not
work. For instance:

    (gdb) p a1(2)
    Cannot access memory at address 0x80000268dec0

With this patch applied, GDB now prints the value of all 3 elements
correctly:

    (gdb) print A1(1)
    $1 = (i => 0, s => "")
    (gdb) print A1(2)
    $2 = (i => 1, s => "A")
    (gdb) print A1(3)
    $3 = (i => 2, s => "AB")

gdb/ChangeLog:

        * gdbtypes.h (enum dynamic_prop_node_kind) <DYN_PROP_BYTE_STRIDE>:
        New enum value.
        (create_array_type_with_stride): Add byte_stride_prop parameter.
        * gdbtypes.c (create_array_type_with_stride) <byte_stride_prop>:
        New parameter.  Update all callers in this file.
        (array_type_has_dynamic_stride): New function.
        (is_dynamic_type_internal, resolve_dynamic_array): Add handling
        of arrays with dynamic byte strides.
        * dwarf2read.c (read_array_type): Add support for dynamic
        DW_AT_byte_stride attributes.

gdb/testsuite/ChangeLog:

        * gdb.ada/dyn_stride: New testcase.

Tested on x86_64-linux.

treat Ada DW_TAG_unspecified_type DIEs as stub types

Consider the gdb.ada/taft_type.exp testcase, which exercises
the situation where a variable is defined using a type which
is a pointer to an incomplete type, with the actual type
definition being provided by another unit. Up to now, the
strategy used by GNAT when generating the DWARF debugging info
was to produce a incomplete DW_TAG_enumeration_type DIE with
a DW_AT_declaration flag attached to it:

        .uleb128 0x4    # (DIE (0x3e) DW_TAG_enumeration_type)
        .long   .LASF4  # DW_AT_name: "pck__empty"
                        # DW_AT_declaration

However, a more standard way for the compiler to describe
this kind of type is to use the DW_TAG_unspecified_type tag.
When the compiler is enhanced to do so, we'll need to treat
such types as stubs -- we only do so with types from Ada units,
however, as the meaning of this TAG is intentionally left
permissive and language-specific by the DWARF standard.

Without this patch, running the testcase above with an enhanced
compiler now yields:

    (gdb) print w.e.all
    Attempt to dereference a generic pointer.
    FAIL: gdb.ada/taft_type.exp: print w.e.all

gdb/ChangeLog:

* dwarf2read.c (read_unspecified_type): Treat
        DW_TAG_enumeration_type DIEs from Ada units as stubs.

Tested on x86_64-linux, fixes the FAIL in gdb.ada/taft_type.exp above.

Update copyright year range in all GDB files

gdb/ChangeLog:

Update copyright year range in all GDB files

gdb/copyright.py: Remove testsuite/gdb.base/step-line.{c,inp} special handling

In the past, these files needed to be handled by hand, because
the testcase was sensitive to the length of the header, which was
potentially changing when new copyright years were added to
the copyright header. Now that we simply maintain and update
a range, the length of the copyright header should not change
as a consequence of the update performed by this script, so
special handling of those files is no longer necessary.

gdb/ChangeLog:

* copyright.py (BY_HAND): Remove gdb/testsuite/gdb.base/step-line.inp
and gdb/testsuite/gdb.base/step-line.c.

gdb/copyright.py: Do not forget to remind about MULTIPLE_COPYRIGHT_HEADERS

There is a small logical error in the part of the script that
dumps the list of files in BY_HAND + MULTIPLE_COPYRIGHT_HEADERS
but only checkis the contents of BY_HAND. The issue becomes
apparent as soon as BY_HAND is empty. Prevent this from happening
by treating the two lists separately, as this allows us to provide
a more informative message in the case of MULTIPLE_COPYRIGHT_HEADERS.

gdb/ChangeLog:

        * copyright.py (main): Dump the contents of
        MULTIPLE_COPYRIGHT_HEADERS (separately) from BY_HAND,
        even if BY_HAND is empty.

Update copyright year in version message of GDB, GDBserver and GDBreplay

gdb/ChangeLog:

* top.c (print_gdb_version): Update Copyright year in version
message.

gdb/gdbserver/ChangeLog:

* gdbreplay.c (gdbreplay_version): Update copyright year in
version message.
* server.c (gdbserver_version): Likewise.

Yearly rotation of the gdb/ChangeLog file

gdb/ChangeLog

* config/djgpp/fnchange.lst: Add entry for gdb/ChangeLog-2017.

Automatic date update in version.in

Avoid indexing std::vector past the end

The code here wants to find address of an element, and often this
element is one past the end of std::vector. Dereferencing that element
leads to undefined behavior, so it's better to simply use pointer
arithmetic instead of taking address of invalid dereference.

gdb/ChangeLog:

* psymtab.c (recursively_search_psymtabs): Use pointer arithmetic
instead of dereferencing std::vector past the end.

Only ignore -Wenum-compare-switch if it exists

My patch

  dwarf2read: Silence -Wenum-compare-switch warning
  132448f8359a268f34f074b0908b5255b568da06

made some parts of dwarf2read.c ignore warnings about switch using enums
of different kinds.  What I did not realize was that older Clang
versions (prior to 6) did not have that warning, and therefore give this
error:

/home/emaisin/src/binutils-gdb/gdb/dwarf2read.c:24187:7: error: unknown warning group '-Wenum-compare-switch', ignored [-Werror,-Wunknown-pragmas]
      DIAGNOSTIC_IGNORE_SWITCH_DIFFERENT_ENUM_TYPES
      ^
/home/emaisin/src/binutils-gdb/gdb/common/diagnostics.h:42:3: note: expanded from macro 'DIAGNOSTIC_IGNORE_SWITCH_DIFFERENT_ENUM_TYPES'
  DIAGNOSTIC_IGNORE ("-Wenum-compare-switch")
  ^
/home/emaisin/src/binutils-gdb/gdb/common/diagnostics.h:27:3: note: expanded from macro 'DIAGNOSTIC_IGNORE'
  _Pragma (STRINGIFY (GCC diagnostic ignored option))
  ^
<scratch space>:10:25: note: expanded from here
GCC diagnostic ignored "-Wenum-compare-switch"
                        ^

Clang has a way to test if it knows about a particular warning.  This
patch uses that feature to only define
DIAGNOSTIC_IGNORE_SWITCH_DIFFERENT_ENUM_TYPES to something if the
warning is recognized by the Clang version being used.  I tested
building dwarf2read.c with clang 4, 5, 6, as well as gcc.

gdb/ChangeLog:

* common/diagnostics.h
(DIAGNOSTIC_IGNORE_SWITCH_DIFFERENT_ENUM_TYPES): Only
define if the compiler knows about -Wenum-compare-switch.

dwarf2read: Silence -Wenum-compare-switch warning

Compiling with Clang 6 gives:

/home/emaisin/src/binutils-gdb/gdb/dwarf2read.c:24385:14: error: comparison of two values with different enumeration types in switch statement ('enum dwarf_macro_record_type' and 'dwarf_macinfo_record_type') [-Werror,-Wenum-compare-switch]
        case DW_MACINFO_vendor_ext:
             ^~~~~~~~~~~~~~~~~~~~~
/home/emaisin/src/binutils-gdb/gdb/dwarf2read.c:24561:7: error: comparison of two values with different enumeration types in switch statement ('enum dwarf_macro_record_type' and 'dwarf_macinfo_record_type') [-Werror,-Wenum-compare-switch]
        case DW_MACINFO_vendor_ext:
             ^~~~~~~~~~~~~~~~~~~~~

This code uses the two enum types on purpose, because it handles both
.debug_macro and .debug_macinfo sections.  Add some pragmas to disable
the warning in these specific cases.

gdb/ChangeLog:

* dwarf2read.c (dwarf_decode_macro_bytes): Ignore
-Wenum-compare-switch warning.
(dwarf_decode_macros): Likewise.

C++-ify parser_state

This mildly C++-ifies parser_state and stap_parse_info -- just enough
to remove some cleanups.

This version includes the changes implemented by Simon.

Regression tested by the buildbot.

gdb/ChangeLog
2017-12-30 Tom Tromey <tom@tromey.com>
Simon Marchi <simon.marchi@ericsson.com>

* stap-probe.h (struct stap_parse_info): Add constructor,
destructor.
* stap-probe.c (stap_parse_argument): Update.
* rust-exp.y (rust_lex_tests): Update.
* parser-defs.h (struct parser_state): Add constructor,
destructor, release method.
<expout>: Change type to expression_up.
(null_post_parser): Change type.
(initialize_expout, reallocate_expout): Remove.
* parse.c (parser_state::parser_state): Rename from
initialize_expout.
(parser_state::release): Rename from reallocate_expout.
(write_exp_elt, parse_exp_in_context_1, increase_expout_size):
Update.
(null_post_parser): Change type of "exp".
* dtrace-probe.c (dtrace_probe::build_arg_exprs): Update.
* ada-lang.c (resolve, resolve_subexp)
(replace_operator_with_call): Change type of "expp".
* language.h (struct language_defn) <la_post_parser>: Change type
of "expp".

Automatic date update in version.in

Make mapped_debug_names and mapped_index final

When compiling with Clang 6, I see these warnings:

/home/emaisin/src/binutils-gdb/gdb/dwarf2read.c:25421:5: error: destructor called on non-final 'mapped_index' that has virtual functions but non-virtual destructor [-Werror,-Wdelete-non-virtual-dtor]
    data->index_table->~mapped_index ();
    ^
In file included from /home/emaisin/src/binutils-gdb/gdb/dwarf2read.c:31:
In file included from /home/emaisin/src/binutils-gdb/gdb/defs.h:28:
In file included from /home/emaisin/src/binutils-gdb/gdb/common/common-defs.h:92:
In file included from /home/emaisin/src/binutils-gdb/gdb/common/gdb_unique_ptr.h:23:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/memory:81:
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/bits/unique_ptr.h:76:2: error: delete called on non-final 'mapped_debug_names' that has virtual functions but non-virtual destructor [-Werror,-Wdelete-non-virtual-dtor]
        delete __ptr;
        ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/bits/unique_ptr.h:236:4: note: in instantiation of member function 'std::default_delete<mapped_debug_names>::operator()' requested here
          get_deleter()(__ptr);
          ^
/home/emaisin/src/binutils-gdb/gdb/dwarf2read.c:2374:21: note: in instantiation of member function 'std::unique_ptr<mapped_debug_names, std::default_delete<mapped_debug_names> >::~unique_ptr' requested here
dwarf2_per_objfile::dwarf2_per_objfile (struct objfile *objfile_,
                    ^

This patch silences these warnings by making the classes final.

gdb/ChangeLog:

* dwarf2read.c (struct mapped_debug_names): Make final.
(struct mapped_index): Make final.

Ignore warning about using different types of enums in switch

When compiling with clang 6, I see a bunch of warnings like this:

/home/emaisin/src/binutils-gdb/gdb/amd64-linux-tdep.c:1427:8: error: comparison of two values with different enumeration types in switch statement ('enum amd64_syscall' and 'amd
64_x32_syscall') [-Werror,-Wenum-compare-switch]
  case amd64_x32_sys_move_pages:
       ^~~~~~~~~~~~~~~~~~~~~~~~

In this switch, we indeed use enumerators of both types
amd64_x32_syscall and amd64_syscall.  This is done on purpose, and the
enum values are chosen so that they are complementary.

I think it's still a useful warning, so I chose to ignore just that
particular case.

gdb/ChangeLog:

* common/diagnostics.h
(DIAGNOSTIC_IGNORE_SWITCH_DIFFERENT_ENUM_TYPES): New macro.
* amd64-linux-tdep.c (amd64_canonicalize_syscall): Use it.

Remove unnecessary call to get_thread_db_info

In thread_db_detach, we call get_thread_db_info to first check if there
exists a thread_db_info entry for the pid to detach. If there is, then
we call delete_thread_db_info. It's unnecessary to call
get_thread_db_info in the first place, since delete_thread_db_info
handles the case where no thread_db_info entry exist for the given pid.

gdb/ChangeLog:

* linux-thread-db.c (thread_db_detach): Remove call to
delete_thread_db_info.

Automatic date update in version.in

RISC-V: Add missing privileged spec registers.

gas/
* testsuite/gas/riscv/priv-reg.d, testsuite/gas/riscv/priv-reg.s: New.

include/
* opcode/riscv-opc.h (DECLARE_CSR): Add missing privileged registers.
Sort to match privileged spec documentation order.
(DECLARE_CSR_ALIAS): Add ubadaddr, and comments.

Remove unused HP-UX TARGET_OBJECT_ enums

These two enumerators are unused, remove them.

gdb/ChangeLog:

* target.h (enum target_object) <TARGET_OBJECT_HPUX_UREGS,
TARGET_OBJECT_HPUX_SOLIB_GOT>: Remove.

Automatic date update in version.in

tdesc: handle arbitrary strings in tdesc_register_in_reggroup_p

tdesc_register_in_reggroup_p in now able to handle arbitrary
groups. This is useful when groups are created while the
target descriptor file is received from the remote.

This can be the case of a soft core target processor where
registers/groups can change.

gdb/ChangeLog:

yyyy-mm-dd  Franck Jullien  <franck.jullien@gmail.com>
    Stafford Horne  <shorne@gmail.com>

* target-descriptions.c (tdesc_register_in_reggroup_p): Support
arbitrary strings.
(tdesc_use_registers): Add logic to register new reggroups.
(tdesc_reg::group): Update comment to indicate we allow
arbitrary strings.
* NEWS (Changes since GDB 8.0): Announce that GDB supports
arbitrary reggroups.

gdb/testsuite/ChangeLog:

yyyy-mm-dd  Stafford Horne  <shorne@gmail.com>

* gdb.xml/extra-regs.xml: Add example foo reggroup.
* gdb.xml/tdesc-regs.exp: Add test to check for foo reggroup.

gdb/doc/ChangeLog:

yyyy-mm-dd  Stafford Horne  <shorne@gmail.com>

* gdb.texinfo (Target Description Format): Explain that arbitrary
strings are now allowed for register groups.

reggroups: Add reggroup_gdbarch_new, reggroup_find for dynamic reggroups

Traditionally reggroups have been created via reggroup_new() during
initialization code and never freed.  Now, if we want to initialize
reggroups dynamically (i.e. in target description) we should be able to
free them.  Create this function reggroup_gdbarch_new() which will
allocate the reggroup memory onto the passed gdbarch obstack.

Also creating reggroup_find() as a utility to find a gdbarch registered
reggroup object by name.

gdb/ChangeLog:

yyyy-mm-dd  Stafford Horne  <shorne@gmail.com>

* reggroups.c (reggroup_gdbarch_new): New function.
(reggroup_find): New function.
* reggroups.h (reggroup_gdbarch_new): New function.
(reggroup_find): New function.

reggroups: Convert reggroups from post_init to pre_init

Currently the reggroups gdbarch_data cannot be manipulated until after
the gdbarch is completely initialized.  This is usually done when the
object init depends on architecture specific fields.  In the case of
reggroups it only depends on the obstack being available.

Coverting this to pre_init allows using reggroups during gdbarch
initialization.  This is needed to allow registering arbitrary reggroups
during gdbarch initializations.

gdb/ChangeLog:

yyyy-mm-dd  Stafford Horne  <shorne@gmail.com>

* reggroups.c (reggroups_init): Change to depend only on
obstack rather than gdbarch.
(reggroup_add): Remove logic for forcing premature init.
(_initialize_reggroup): Set `reggroups_data` with
gdbarch_data_register_pre_init() rather than
gdbarch_data_register_post_init().

reggroups: Add test and docs for `info reg $reggroup` feature

Until now this feature has existed but was not documented.  Adding docs
and tests.

gdb/ChangeLog:

yyyy-mm-dd  Stafford Horne  <shorne@gmail.com>

* infcmd.c (_initialize_infcmd): Add help for info reg $reggroup
and info all-registers $reggroup feature.

gdb/doc/ChangeLog:

yyyy-mm-dd  Stafford Horne  <shorne@gmail.com>

* gdb.texinfo (Registers): Document info reg $reggroup feature.

gdb/testsuite/ChangeLog:

yyyy-mm-dd  Stafford Horne  <shorne@gmail.com>

* gdb.base/reggroups.c: New file.
* gdb.base/reggroups.exp: New file.

Automatic date update in version.in

Add ATTRIBUTE_PRINTF to printf_field_type_assignment

Get rid of:

/home/simark/src/binutils-gdb/gdb/target-descriptions.c:2026:25: error: format string is not a string literal [-Werror,-Wformat-nonliteral]
vprintf_unfiltered (fmt, args);

when building with clang.

gdb/ChangeLog:

* target-descriptions.c (print_c_tdesc)
<printf_field_type_assignment>: Add ATTRIBUTE_PRINTF.

Automatic date update in version.in

Do not emit "field_type" var if not needed on "maint print c-tdesc"

While fiddling a bit with -Wunused-variable, Sergio noticed that "maint
print c-tdesc" was always generating code for the "tdesc_type
*field_type" variable, even when it wasn't used. This is caught by GCC
when using -Wunused-variable, of course.

This patch changes the print_c_tdesc class to only output the field
declaration when we actually need it.

It shouldn't be necessary to do the same with the other variable
declarations (type_with_fields and element_type), because they are
always if they are declared.

The C files in features/ are regenerated, some declarations of
field_type are removed, as expected, while some others move to where
they are used for the first time.

gdb/ChangeLog:

* target-descriptions.c (print_c_tdesc) <visit>: Don't output
field_type declaration, use printf_field_type_assignment
instead.
<printf_field_type_assignment>: New method.
* features/aarch64-core.c, features/aarch64-fpu.c
features/arc-arcompact.c, features/arc-v2.c,
features/arm/arm-with-iwmmxt.c, features/i386/32bit-core.c,
features/i386/32bit-mpx.c, features/i386/32bit-sse.c,
features/i386/64bit-avx512.c, features/i386/64bit-core.c,
features/i386/64bit-mpx.c, features/i386/64bit-sse.c,
features/i386/x32-core.c, features/or1k.c,
features/rs6000/powerpc-7400.c,
features/rs6000/powerpc-altivec32.c,
features/rs6000/powerpc-altivec32l.c,
features/rs6000/powerpc-altivec64.c,
features/rs6000/powerpc-altivec64l.c,
features/rs6000/powerpc-cell32l.c,
features/rs6000/powerpc-cell64l.c,
features/rs6000/powerpc-isa205-altivec32l.c,
features/rs6000/powerpc-isa205-altivec64l.c,
features/rs6000/powerpc-isa205-vsx32l.c,
features/rs6000/powerpc-isa205-vsx64l.c,
features/rs6000/powerpc-vsx32.c,
features/rs6000/powerpc-vsx32l.c,
features/rs6000/powerpc-vsx64.c,
features/rs6000/powerpc-vsx64l.c, features/s390-gs-linux64.c,
features/s390-tevx-linux64.c, features/s390-vx-linux64.c,
features/s390x-gs-linux64.c, features/s390x-tevx-linux64.c,
features/s390x-vx-linux64.c: Re-generate.

Remove write-only assignment in rs6000-tdep.c

The result of this memory read is never used, so it can be removed.

gdb/ChangeLog:

* rs6000-tdep.c (ppc_deal_with_atomic_sequence): Remove
write-only assignment to "insn" variable.

Automatic date update in version.in

RISC-V: Add compressed instruction hints, and a few misc cleanups.

gas/
* config/tc-riscv.c (risc_ip) <o>: Add comment.
* testsuite/gas/riscv/c-nonzero-imm.d,
* testsuite/gas/riscv/c-nonzero-imm.l,
* testsuite/gas/riscv/c-nonzero-imm.s,
* testsuite/gas/riscv/c-nonzero-reg.d,
* testsuite/gas/riscv/c-nonzero-reg.l,
* testsuite/gas/riscv/c-nonzero-reg.s,
* testsuite/gas/riscv/c-zero-imm-64.d,
* testsuite/gas/riscv/c-zero-imm-64.s,
* testsuite/gas/riscv/c-zero-imm.d, testsuite/gas/riscv/c-zero-imm.s,
* testsuite/gas/riscv/c-zero-reg.d,
* testsuite/gas/riscv/c-zero-reg.s: New.

opcodes/
* riscv-opc.c (match_c_add_with_hint, match_c_lui_with_hint): New.
(riscv_opcodes) <li>: Delete "d,0" line. Change Cj to Co.
<andi, and, add, addiw, addw, c.addi>: Change Cj to Co.
<add>: Add explanatory comment for 4-operand add instruction.
<c.nop>: Add support for immediate operand.
<c.mv, c.add>: Use match_c_add_with_hint instead of match_c_add.
<c.lui>: Use match_c_lui_with_hint instead of match_c_lui.
<c.li, c.slli>: Use match_opcode instead of match_rd_nonzero.

[Cell/B.E.] Fix regression due to gdbarch_significant_addr_bit

On Cell/B.E. multi-architecture debugging we use a "merged" address space
that encodes both the main PowerPC address space and the local store address
spaces of all active SPUs.  This will always occupy 64 bits.

However, gdbarch_addr_bit is set to 32 on SPU, and may be set to 32 as well
on PowerPC.  Since the new gdbarch_significant_addr_bit defaults to the
value of gdbarch_addr_bit, this means addresses may be improperly truncated.

Work around this problem by explicitly setting gdbarch_significant_addr_bit
to 64 both for the SPU target and also for PowerPC target that support
Cell/B.E. execution.

gdb/ChangeLog:
2017-12-20  Ulrich Weigand  <uweigand@de.ibm.com>

* spu-tdep.c (spu_gdbarch_init): Set set_gdbarch_significant_addr_bit
to 64 bits.
(ppc_linux_init_abi): Likewise, if Cell/B.E. is supported.

Fix ChangeLog formatting

Doing some unrelated grepping found that there were some missing
spaces, fix it.