Add missing changelog entry

I forgot to commit the change before pushing commit
25ec8924842a215e7f684d3a5076607409ac822f

[gdb/testsuite] Work around tcl bug in libsegfault.exp with check-read1

When running libsegfault.exp with check-read1, I get:
...
Running gdb/testsuite/gdb.base/libsegfault.exp ...
ERROR: tcl error sourcing gdb/testsuite/gdb.base/libsegfault.exp.
ERROR: no such variable
    (read trace on "env(LD_PRELOAD)")
    invoked from within
"set env(LD_PRELOAD)"
    ("uplevel" body line 1)
    invoked from within
"uplevel 1 [list set $var]"
    invoked from within
"if [uplevel 1 [list array exists $var]] {
                set saved_arrays($var) [uplevel 1 [list array get $var]]
            } else {
                set saved_scalars($var) [uplevel ..."
    invoked from within
"if [uplevel 1 [list info exists $var]] {
            if [uplevel 1 [list array exists $var]] {
                set saved_arrays($var) [uplevel 1 [list array get $var]]
          ..."
    (procedure "save_vars" line 11)
    invoked from within
"save_vars { env(LD_PRELOAD) } {
        if { ![info exists env(LD_PRELOAD) ]
             || $env(LD_PRELOAD) == "" } {
            set env(LD_PRELOAD) "$lib"
        } else {
         ..."
    (procedure "gdb_spawn_with_ld_preload" line 4)
    invoked from within
"gdb_spawn_with_ld_preload $libsegfault """
...

There are several things here interacting with environment variable
LD_PRELOAD:
- the expect "binary" build/gdb/testsuite/expect-read1 with does
  export LD_PRELOAD=build/gdb/testsuite/read1.so before calling native expect
- read1.so which does unsetenv ("LD_PRELOAD") upon first call to read
- the test-case, which wants to set or append libSegFault.so to LD_PRELOAD

The error occurs when accessing $env(LD_PRELOAD), in a branch where
"info exists env(LD_PRELOAD)" returns true. AFAIU, this is
https://core.tcl-lang.org/tcl/tktview?name=67fd4f973a "incorrect results of
'info exists' when unset env var in one interp and check for existence from
another interp".

Work around the tcl bug by not unsetting the variable, but setting it to ""
instead:
...
-      unsetenv ("LD_PRELOAD");
+      setenv ("LD_PRELOAD", "", 1);
...

Verified that reverting commit de28a3b72e "[gdb/testsuite, 2/2] Fix
gdb.linespec/explicit.exp with check-read1" reintroduced the check-read1
failure in gdb.linespec/explicit.exp.

This fixes a similar error in attach-slow-waitpid.exp, which also sets
LD_PRELOAD.

Tested on x86_64-linux with check-read1.

gdb/testsuite/ChangeLog:

2019-07-30  Tom de Vries  <tdevries@suse.de>

* lib/read1.c (read): Don't use unsetenv (v), use setenv (v, "", 1)
instead.

[gdb/testsuite] Fail in gdb_compile if nopie results in PIE executable

When running gdb.base/dump.exp with --target_board=unix/-fPIE/-pie, we get:
...
Running gdb/testsuite/gdb.base/dump.exp ...
FAIL: gdb.base/dump.exp: dump array as value, intel hex
...

The FAIL happens because although the test specifies nopie, the exec is
in fact compiled as PIE.  The "-fPIE -pie" options specified using the
target_board are interpreted by dejagnu as multilib_flags, and end up
overriding the nopie flags.

Fix this by checking in gdb_compile if the resulting exec is PIE despite of
a nopie setting, and if so return an error:
...
Running gdb/testsuite/gdb.base/dump.exp ...
gdb compile failed, nopie failed to prevent PIE executable

                === gdb Summary ===

nr of untested testcases         1
...

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2019-07-30  Tom de Vries  <tdevries@suse.de>

PR testsuite/24834
* lib/gdb.exp (gdb_compile): Fail if nopie results in PIE executable.
(exec_is_pie): New proc.

Re: Support .gnu.lto_.lto section in ELF files

PR 24768
* bfd.c (struct bfd): Add lto_slim_object flag.
* bfd-in2.h: Regenerate.

Fix misspelling (nonexistant -> nonexistent)

gdb/testsuite/ChangeLog:

2019-07-29  Christian Biesinger  <cbiesinger@google.com>

* gdb.python/py-objfile.exp: Fix misspelling (nonexistant -> nonexistent)

Add Objfile.lookup_{global,static}_symbol functions

This is essentially the inverse of Symbol.objfile. This allows
handling different symbols with the same name (but from different
objfiles) and can also be faster if the objfile is known.

gdb/ChangeLog:

2019-07-29  Christian Biesinger  <cbiesinger@google.com>

* NEWS: Mention new functions Objfile.lookup_{global,static}_symbol.
* python/py-objfile.c (objfpy_lookup_global_symbol): New function.
(objfpy_lookup_static_symbol): New function.
(objfile_object_methods): Add new functions.

gdb/doc/ChangeLog:

2019-07-29  Christian Biesinger  <cbiesinger@google.com>

* python.texi (Objfiles In Python): Document new functions
  Objfile.lookup_{global,static}_symbol.

gdb/testsuite/ChangeLog:

2019-07-29  Christian Biesinger  <cbiesinger@google.com>

* gdb.python/py-objfile.c: Add global and static vars.
* gdb.python/py-objfile.exp: Test new functions Objfile.
  lookup_global_symbol and lookup_static_symbol.

Automatic date update in version.in

Two fixes for test suite's terminal

Exactly which escape sequences are emitted by gdb in TUI mode are
determined largely by the curses implementation.  Testing my latest
(as yet unsubmitted) series to refactor the TUI showed a couple of
failures that I tracked to the test suite's terminal implementation.

In particular, the CSI "@" sequence was not implemented; and the CSI
"X" sequence was implemented incorrectly.

This patch fixes both of these problems.  Tested on x86-64 Fedora 28.

gdb/testsuite/ChangeLog
2019-07-29  Tom Tromey  <tom@tromey.com>

* lib/tuiterm.exp (Term::_csi_@): New proc.
(Term::_csi_X): Don't move cursor.

Document 'set print frame-info|frame-arguments presence'.

gdb/ChangeLog
2019-06-19  Philippe Waroquiers  <philippe.waroquiers@skynet.be>

* NEWS: Mention 'set|show print frame-info'.  Mention new
'presence' value for 'frame-arguments'.  Mention new '-frame-info'
backtrace argument.  Mention that python frame filtering code
is now consistent with what 'backtrace' command prints.

gdb/doc/ChangeLog
2019-07-29  Philippe Waroquiers  <philippe.waroquiers@skynet.be>

* gdb.texinfo (Backtrace): Document the new '-frame-info'
backtrace option.  Reference 'set print frame-info'.
(Print Settings): Document 'set|show print frame-info'.
Document new 'presence' value for 'set print frame-arguments.

Test 'set print frame-info|frame-arguments presence'.

Updated tests to test the new options and new values.
Test the default for print_what in python frame filtering.
Updated the tests impacted by the default in python frame filtering
which is now consistent with the backtrace command.

gdb/testsuite/ChangeLog
2019-07-29  Philippe Waroquiers  <philippe.waroquiers@skynet.be>

* gdb.base/options.exp: Update backtrace - completion to
new option -frame-info.
* gdb.base/frame-args.exp: Test new 'frame-arguments presence'.
Test new 'set print frame-info'.  Test backtrace -frame-info
overriding 'set print frame-info'.
* gdb.python/py-framefilter.exp: Test new 'frame-arguments presence'.
Test new 'set print frame-info'.
Verify consistency of backtrace with and without filters, with and
without -no-filters.
* gdb.python/py-framefilter-invalidarg.exp: Update to new print_what
default.

Implement 'set print frame-info|frame-arguments presence'.

New settings allow to better control what frame information is printed.

'set print frame-info' allows to override the default frame information
printed when a GDB command prints a frame.
The backtrace command has a new option -frame-info to override
this global setting.

It is now possible to have very short frame information by using the
new 'set print frame-arguments presence' and
'set print frame-info short-location'.

Combined with 'set print address off', a backtrace will only show
the essential information to see the function call chain, e.g.:
  (gdb) set print address off
  (gdb) set print frame-arguments presence
  (gdb) set print frame-info short-location
  (gdb) bt
  #0  break_me ()
  #1  call_me (...)
  #2  main ()
  (gdb)

This is handy in particular for big backtraces with functions having
many arguments.

Python frame filter printing logic has been updated to respect the new
setting in non MI mode.

Also, the default frame information printed was inconsistent when
backtrace was printing the frame information itself, or when the python
frame filtering code was printing the frame information.
This patch changes the default of python frame filtering to have a
consistent behaviour regarding printed frame-information, whatever
the presence/activity/matches of python filters.

2019-07-29  Philippe Waroquiers  <philippe.waroquiers@skynet.be>

* frame.h (enum print_what): New value 'SHORT_LOCATION', update
comments.
(print_frame_info_auto, print_frame_info_source_line,
print_frame_info_location, print_frame_info_source_and_location,
print_frame_info_location_and_address, print_frame_info_short_location):
New declarations.
(struct frame_print_options): New member print_frame_info.
* extension.h (enum ext_lang_frame_args): New value CLI_PRESENCE.
* stack.h (get_user_print_what_frame_info): New declaration.
(frame_show_address): New declaration.
* stack.c (print_frame_arguments_choices): New value 'presence'.
(print_frame_info_auto, print_frame_info_source_line,
print_frame_info_location, print_frame_info_source_and_location,
print_frame_info_location_and_address, print_frame_info_short_location,
print_frame_info_choices, print_frame_info_print_what): New definitions.
(print_frame_args): Only print dots for args if print frame-arguments
is 'presence'.
(frame_print_option_defs): New element for "frame-info".
(get_user_print_what_frame_info): New function.
(frame_show_address): Make non static.  Move comment to stack.h.
(print_frame_info_to_print_what): New function.
(print_frame_info): Update comment.  Use fp_opts.print_frame_info
to decide what to print.
(backtrace_command_1): Handle the new print_frame_arguments_presence
value.
(_initialize_stack): Call add_setshow_enum_cmd for frame-info.
* python/py-framefilter.c (py_print_args): Handle CLI_PRESENCE.
(py_print_frame): In non-mi mode, use LOCATION as default for
print_what, similarly to frame information printed directly by
backtrace command. Handle frame-info user option in non MI mode.

[gdb/testsuite, 2/2] Fix gdb.linespec/explicit.exp with check-read1

When running gdb.linespec/explicit.exp with check-read1, we get:
...
(gdb) PASS: gdb.linespec/explicit.exp: set max-completions unlimited
break \a
-function
  ...
top
(gdb) PASS: gdb.linespec/explicit.exp: complete with no arguments
break
-function
 ...
top
(gdb) FAIL: gdb.linespec/explicit.exp: complete with no arguments (clearing input line)
...

The problem is that the send_gdb "\t\t" triggers completion twice:
...
        set tst "complete with no arguments"
        send_gdb "break \t"
        gdb_test_multiple "" $tst {
            "break \\\x07" {
                send_gdb "\t\t"
                gdb_test_multiple "" $tst {
...
}
clear_input_line $tst
...
but the following gdb_test_multiple only parses it once, so the second
completion is left for clear_input_line, which fails.

Fix this by triggering completion only once.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2019-07-29  Tom de Vries  <tdevries@suse.de>

* gdb.linespec/explicit.exp: Fix completion trigger for "complete with
no arguments".

[gdb/testsuite, 1/2] Fix gdb.linespec/explicit.exp with check-read1

When running gdb.linespec/explicit.exp with check-read1, we get:
...
(gdb) PASS: gdb.linespec/explicit.exp: complete unique file name: break -source "3explicit.c"
break -source exp^Glicit^G^M
explicit.c   explicit2.c  ^M
(gdb) FAIL: gdb.linespec/explicit.exp: complete non-unique file name
...

The problem is that we have a gdb_test_multiple where we match two regexps:
...
        set tst "complete non-unique file name"
        send_gdb "break -source exp\t"
        gdb_test_multiple "" $tst {
            -re "break -source exp\\\x07licit" {
                ...
            }

            -re "break -source exp\\\x07l" {
                # This pattern may occur when glibc debuginfo is installed.
...
            }
        }
...
but since second is a substring of the first, we'll usually match the first,
but with check-read1 we'll match the second.

Fix this by using a single regexp and merging the related code.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2019-07-29  Tom de Vries  <tdevries@suse.de>

* gdb.linespec/explicit.exp: Fix gdb_test_multiple regexps where second
is a substring of the first for "complete non-unique file name".

[gdb/testsuite] Fix python.exp with check-read1

when running python/python.exp with check-read1, we get:
...
(gdb) PASS: gdb.python/python.exp: prompt substitution readline - end
python gdb.prompt_hook = error_prompt^M
Python Exception <type 'exceptions.RuntimeError'> Python exception calledPASS: gdb.python/python.exp: set hook
: ^M
(gdb) PASS: gdb.python/python.exp: set the hook to default
python gdb.prompt_hook = None^M
(gdb) PASS: gdb.python/python.exp: set print-stack full for prompt error test
set python print-stack full^M
(gdb) FAIL: gdb.python/python.exp: set the hook
python gdb.prompt_hook = error_prompt^M
Traceback (most recent call last):^M
  File "<string>", line 3, in error_prompt^M
RuntimeError: Python exception called^M
(gdb) FAIL: gdb.python/python.exp: set the hook to default
...

The problem is that gdb_test_multiple here:
...
gdb_test_multiple "python gdb.prompt_hook = error_prompt" "set the hook" {
    -re "Python Exception (exceptions.RuntimeError|<(type 'exceptions.|class ')RuntimeError'>) Python excepti
on called.*" {
       pass "set hook"
    }
}
...
specifies a regexp that ends with ".*" but doesn't specify the expected
$gdb_prompt.

Consequently, due to check-read1, the ".*" is matched to "" and the remaining
$gdb_prompt  is read by the the following gdb_py_test_silent_cmd, which has
its own $gdb_prompt read by the following gdb_py_test_silent_cmd, which has
its own $gdb_prompt causing a mismatch for the following gdb_test_multiple:
...
gdb_test_multiple "python gdb.prompt_hook = error_prompt" "set the hook" {
    -re "Traceback.*File.*line.*RuntimeError.*Python exception called.*" {
        pass "set hook"
    }
}
...
which causes both FAILs.

The second gdb_test_multiple has the same problem as the first, but it happens
not to cause a FAIL because it's followed by a gdb_py_test_silent_cmd and a
clean_restart.

Fix the regexps in both gdb_test_multiple calls.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2019-07-29  Tom de Vries  <tdevries@suse.de>

* gdb.python/python.exp: Don't terminate gdb_test_multiple regexp
with ".*".

[gdb/testsuite] Fix mi-catch-cpp-exceptions.exp and mi-nonstop.exp with check-read1

With check-read1 we get:
...
FAIL: gdb.mi/mi-catch-cpp-exceptions.exp: check for stap probe in libstdc++
FAIL: gdb.mi/mi-nonstop.exp: probe for target remote
...

In both cases this is due to using gdb_test_multiple (which expects $gdb_prompt
by default) in combination with gdb using $gdb_mi_prompt, similar to the
problem fixed by commit d17725d72f "Don't expect gdb_prompt in
mi_skip_python_test".

Fix this by adding the $prompt_regexp argument to the gdb_test_multiple calls.

gdb/testsuite/ChangeLog:

2019-07-29  Tom de Vries  <tdevries@suse.de>

* lib/gdb.exp (skip_libstdcxx_probe_tests_prompt, gdb_is_target_1):
Pass prompt_regexp parameter to gdb_test_multiple calls.

[gdb/testsuite] Fix gdb.base/maint.exp with check-read1

With gdb.base/maint.exp and check-read1, we get:
...
FAIL: gdb.base/maint.exp: maint print registers
...

Using this patch:
...
diff --git a/gdb/testsuite/gdb.base/maint.exp b/gdb/testsuite/gdb.base/maint.exp
index a7675ea215..b81d7ec660 100644
--- a/gdb/testsuite/gdb.base/maint.exp
+++ b/gdb/testsuite/gdb.base/maint.exp
@@ -81,7 +81,9 @@ gdb_test_multiple $test $test {
         exp_continue
     }
     -re "$gdb_prompt $" {
-        gdb_assert { $saw_registers && $saw_headers } $test
+       gdb_assert { $saw_headers } "$test: saw headers"
+       gdb_assert { $saw_registers } "$test: saw registers"
+       pass "$test: got prompt"
     }
 }
...

We get more information:
...
PASS: gdb.base/maint.exp: maint print registers: saw headers
FAIL: gdb.base/maint.exp: maint print registers: saw registers
PASS: gdb.base/maint.exp: maint print registers: got prompt
...

The problem is that when matching:
...
(gdb) maint print registers^M
 Name         Nr  Rel Offset    Size  Type            ^M
 rax           0    0      0       8 int64_t         ^M
...
the regexp for $saw_headers ends in "\[\r\n\]+", which
allows it to match only the "\r".  The remaining "\n" then start the next line
to be matched, which doesn't match for the $saw_registers regexp since it
starts with "^\[^\r\n\]+".

Fix this by ending the regexps with "\r\n".

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2019-07-29  Tom de Vries  <tdevries@suse.de>

* gdb.base/maint.exp: Use "\r\n" instead of "\[\r\n\]+" in "maint
          print registers" regexps.

[gdb/testsuite] Fix gdb.base/define.exp with check-read1

When running gdb.base/define.exp with check-read1, we get:
...
show prompt^M
Gdb's prompt is "(gdb) ".^M
(gdb) PASS: gdb.base/define.exp: save gdb_prompt
set prompt \(blah\) ^M
(blah) PASS: gdb.base/define.exp: set gdb_prompt
set prompt (gdb) PASS: gdb.base/define.exp: reset gdb_prompt
^M
(gdb) FAIL: gdb.base/define.exp: define do-define
...

The problem is that the "$gdb_prompt $" regexp here:
...
gdb_test_multiple "set prompt $prior_prompt " "reset gdb_prompt" {
    -re "$gdb_prompt $" {
        pass "reset gdb_prompt"
    }
}
...
triggers for the echoing of the command "set prompt $prior_prompt " rather
than for the prompt after the command has executed.

Fix this by changing the regexp to "\r\n$gdb_prompt $".

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2019-07-29  Tom de Vries  <tdevries@suse.de>

* gdb.base/define.exp: Add "\r\n" to "reset gdb_prompt" regexp.

[gdb/testsuite] Don't expect gdb_prompt in mi_skip_python_test

When running gdb.python/py-mi-events.exp with make check-read1, we get:
...
(gdb) ^M
python print ('test')^M
&"python print ('test')\n"^M
~"test\n"^M
^done^M
(gdb) FAIL: gdb.python/py-mi-events.exp: verify python support
^M
python print (sys.version_info[0])^M
&"python print (sys.version_info[0])\n"^M
~"2\n"^M
^done^M
(gdb) FAIL: gdb.python/py-mi-events.exp: check if python 3
^M
...

The FAILs happen as follows.

On one hand, skip_python_tests_prompt uses the prompt_regexp parameter for the
user_code argument of gdb_test_multiple:
...
proc skip_python_tests_prompt { prompt_regexp } {
    global gdb_py_is_py3k

    gdb_test_multiple "python print ('test')" "verify python support" {
-re "not supported.*$prompt_regexp" {
    unsupported "Python support is disabled."
    return 1
}
-re "$prompt_regexp" {}
    }

    gdb_test_multiple "python print (sys.version_info\[0\])" "check if python 3" {
-re "3.*$prompt_regexp" {
            set gdb_py_is_py3k 1
        }
-re ".*$prompt_regexp" {
            set gdb_py_is_py3k 0
        }
    }
...

On the other hand, gdb_test_multiple itself uses $gdb_prompt:
...
         -re "\r\n$gdb_prompt $" {
            if ![string match "" $message] then {
                fail "$message"
            }
            set result 1
        }
...

So when mi_skip_python_test calls skip_python_tests_prompt with prompt_regexp
set to $mi_gdb_prompt:
...
proc mi_skip_python_tests {} {
    global mi_gdb_prompt
    return [skip_python_tests_prompt "$mi_gdb_prompt$"]
}
...
and expect reads "(gdb) " and tries to match it (due to the READ1=1 setting),
the user_code regexps using $prompt_regexp (set to $mi_gdb_prompt) don't match,
but the $gdb_prompt regexp in gdb_test_multiple does match.

Fix this by adding a prompt_regexp parameter to gdb_test_multiple, and using the
parameter in skip_python_tests_prompt.

Tested gdb.python/py-mi-events.exp with make check READ1=1 x86_64-linux.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2019-07-29  Tom de Vries  <tdevries@suse.de>

PR gdb/24855
* lib/gdb.exp (gdb_test_multiple): Add prompt_regexp parameter.
(skip_python_tests_prompt): Add prompt_regexp argument to
gdb_test_multiple calls.

Support .gnu.lto_.lto section in ELF files (PR 24768).

bfd/ChangeLog:

2019-07-22  Martin Liska  <mliska@suse.cz>

PR 24768
* archive.c (_bfd_compute_and_write_armap): Come up with
report_plugin_err variable.
* bfd-in2.h (struct bfd): Add lto_slim_object flag.
* elf.c (struct lto_section): New.
(_bfd_elf_make_section_from_shdr): Parse content of
.gnu_lto_.lto section.
* elflink.c: Report error for a missing LTO plugin.
* linker.c (_bfd_generic_link_add_one_symbol): Likewise.

binutils/ChangeLog:

2019-07-22  Martin Liska  <mliska@suse.cz>

PR 24768
* nm.c (filter_symbols): Set report_plugin_err if
error is reported.
(display_rel_file): Report error for a missing LTO plugin.

gold/ChangeLog:

2019-07-22  Martin Liska  <mliska@suse.cz>

PR 24768
* layout.h (class Layout): Add is_lto_slim_object and
set_lto_slim_object.
* object.cc (struct lto_section): Add lto_slim_object_.
(big_endian>::do_layout): Parse content of
.gnu_lto_.lto section.
(big_endian>::do_add_symbols): Report error for a missing
LTO plugin.

Automatic date update in version.in

PR24857, ld: error adding symbols: bad value

This fixes two cases where elf_link_add_object_symbols returns an
error, setting the catch-all bfd_error_bad_value without explaining
the error.  The second one is an internal error that can only be
caused by a target elf_add_symbol_hook, so make that one abort.  The
first one is my PR24339 fix.  PR24339 is another of those fuzzing bugs
and the fix I made catches the problem when loading symbols, rather
than when symbols are used in relocs.  While ld is correct to reject
the object file as not complying with the ELF standard, let's be a
little more forgiving for dynamic objects.

PR 24857
PR 24339
* elflink.c (elf_link_add_object_symbols): Report an informative
error on finding local symbols with index equal or greater than
symbol table sh_info.  Correct comment.  Allow such symbols in
dynamic objects.  Abort on NULL section for symbol.

Add test that "file" shows "main"

This adds a new test that checks that the "file" command will show the
program's "main".

gdb/testsuite/ChangeLog
2019-07-27  Tom Tromey  <tom@tromey.com>

* gdb.tui/main.exp: New file.

Add test case for empty TUI windows

My original intent here was to add a test case to test that empty TUI
windows re-render their contents after a resize.  However, this seems
pretty broken at the moment, so a lot of the test is actually
disabled.

gdb/testsuite/ChangeLog
2019-07-27  Tom Tromey  <tom@tromey.com>

* lib/tuiterm.exp (Term::clean_restart): Make "executable"
optional.
* gdb.tui/empty.exp: New file.

Add TUI resizing test

This adds a test case that resizes the terminal and then checks that
the TUI updates properly.

gdb/testsuite/ChangeLog
2019-07-27  Tom Tromey  <tom@tromey.com>

* lib/tuiterm.exp (spawn): New proc.
(Term::resize): New proc.
* gdb.tui/resize.exp: New file.

Add TUI test for "list"

This adds a test to check that the "list" command will update the TUI
source window.

gdb/testsuite/ChangeLog
2019-07-27  Tom Tromey  <tom@tromey.com>

* gdb.tui/list.exp: New file.

Add TUI register window test

This adds a very simple test of the TUI register window.

gdb/testsuite/ChangeLog
2019-07-27  Tom Tromey  <tom@tromey.com>

* gdb.tui/regs.exp: New file.

Add "layout split" test

This adds a test of "layout split" to the TUI test suite.

gdb/testsuite/ChangeLog
2019-07-27  Tom Tromey  <tom@tromey.com>

* gdb.tui/basic.exp: Add "layout split" test.

Add test for "layout asm"

This adds a very simple test for "layout asm".

gdb/testsuite/ChangeLog
2019-07-27  Tom Tromey  <tom@tromey.com>

* gdb.tui/basic.exp: Add "layout asm" test.

A virtual terminal for the test suite

This patch implements a simple ANSI terminal emulator for the test
suite.  It is still quite basic, but it is good enough to allow some
simple TUI testing to be done.

gdb/testsuite/ChangeLog
2019-07-27  Tom Tromey  <tom@tromey.com>

* lib/tuiterm.exp: New file.
* gdb.tui/basic.exp: New file.

Automatic date update in version.in

Fix gdb.python/py-thrhandle.exp failures for -m32 multilib

This patch fixes the following failures when testing with
"target_board unix/-m32" using a x86_64-pc-linux-gnu native GDB.

FAIL: gdb.python/py-thrhandle.exp: print thread for bogus handle thrs[3]
FAIL: gdb.python/py-thrhandle.exp: print thread for bogus handle thrs[4]
FAIL: gdb.python/py-thrhandle.exp: print thread id for thrs[0]
FAIL: gdb.python/py-thrhandle.exp: print thread id for thrs[1]
FAIL: gdb.python/py-thrhandle.exp: print thread id for thrs[2]
FAIL: gdb.python/py-thrhandle.exp: thread 0: fetch thread handle from thread
FAIL: gdb.python/py-thrhandle.exp: thread 0: verify that handles are the same
FAIL: gdb.python/py-thrhandle.exp: thread 1: fetch thread handle from thread
FAIL: gdb.python/py-thrhandle.exp: thread 1: verify that handles are the same
FAIL: gdb.python/py-thrhandle.exp: thread 2: fetch thread handle from thread
FAIL: gdb.python/py-thrhandle.exp: thread 2: verify that handles are the same

I've written it so that it might work for other 64-bit host / 32-bit target
combos too.

gdb/ChangeLog:

* linux-thread-db.c (thread_db_target::thread_handle_to_thread_info):
Add case for debugging 32-bit target on 64-bit host.  Revise
comment.

Fix stepping bug associated with non-contiguous blocks

I recently noticed the following behavior while debugging
dw2-ranges-func-low-cold.  This is one of the test programs associated
with the test gdb.dwarf2/dw2-ranges-func.exp.

(gdb) b 70
Breakpoint 1 at 0x401129: file dw2-ranges-func-lo-cold.c, line 70.
(gdb) run
Starting program: dw2-ranges-func-lo-cold

Breakpoint 1, foo ()
    at dw2-ranges-func-lo-cold.c:70
70   if (e) foo_cold (); /* foo foo_cold call */
(gdb) set var e=1
(gdb) step
[Inferior 1 (process 12545) exited normally]

This is incorrect.  When stepping, we expect a step to occur.  We do not
expect the program to exit.  Instead, we should see the following behavior:

...
(gdb) set var e=1
(gdb) step
foo ()
    at dw2-ranges-func-lo-cold.c:54
54   baz (); /* foo_cold baz call */

(Note that I've shortened the paths in the above sessions to improve
readability.)

The bug is in fill_in_stop_func() in infrun.c.  While working on
non-contiguous address range improvements in 2018, I replaced the
call to find_pc_partial_function() with a call to
find_function_entry_range_from_pc().  Although this seemed like the
right thing to do at the time, I now think that calling
find_pc_partial_function (along with some other tweaks) is the right
thing to do.

For blocks with a single contiguous range, these functions do pretty
much the same thing: when the function succeeds, the function name,
start address, and end address are all filled in.  Additionally,
find_pc_partial_function contains an additional output parameter
which is set to the block containing that PC.

For blocks with non-contiguous ranges, find_pc_partial_function
sets the start and end addresses to the start and end addresses
of the range containing the pc.  find_function_entry_range_from_pc
does what it says; it sets the start and end addresses to those
of the range containing the entry pc.

The reason that I had thought that using the entry pc range was
correct is due to the fact that fill_in_stop_func() contains some
code for advancing past the function start and entry point.  To do
this, we'd need the range that contains the entry pc.

However, when stepping, we actually want the range that contains the
stop pc.  If that range also contains the entry pc, we should then
attempt to advance stop_func_start past the start offset and entry
point.  (I haven't thought very hard about the reason for advancing
the stop_func_start in this manner.  Since it's been there for quite
a while, I'm assuming that it's still a good idea.)

Back when I wrote the test case, I had included a test for doing the
step shown in the example above.  I had problems with it, however.  At
the time, I thought it was due to differing compiler versions, so I
disabled that portion of the test.  I have now reenabled those tests,
but have left in place the logic which may be used to disable it.

The changes to dw2-ranges-func.exp depend on my other recent changes
to the file which have not been pushed yet.

Finally, I'll note that the only caller of
find_function_entry_range_from_pc() is/was fill_in_stop_func().  Once
this commit goes in, it'll be dead code.  I considered removing it,
but I think that it ought to be used (instead of
find_pc_partial_function) for determining the correct range to scan
for prologue analysis, so I'm going to leave it in place for now.

gdb/ChangeLog:

* infrun.c (fill_in_stop_func): Use find_pc_partial_function
instead of find_function_entry_range_from_pc.

testsuite/ChangeLog:

* gdb.dwarf2/dw2-ranges-func.exp (enable_foo_cold_stepping):
Enable tests associated with this flag.  Adjust regex
referencing "foo_low" to now refer to "foo_cold" instead.

Improve test gdb.dwarf2/dw2-ranges-func.exp

The original dw2-ranges-func.exp test caused a function named foo to be
created with two non-contiguous address ranges.  In the C source file,
a function named foo_low was incorporated into the function foo which
was also defined in that file.  The DWARF assembler is used to do this
manipulation.  The source file had been laid out so that foo_low would
likely be placed (by the compiler and linker) at a lower address than
foo().

The case where a range at a higher set of addresses (than foo) was not
being tested.  In a recent discussion on gdb-patches, it became clear
that performing such tests are desirable because bugs were discovered
which only became evident when the other range was located at high(er)
addresses than the range containing the entry point for the function.

This other (non entry pc) address range is typically used for "cold"
code which executes less frequently.  Thus, I renamed foo_low to
foo_cold and renamed the C source file from dw-ranges-func.c to
dw-ranges-func-lo.c.  I then made a copy of this file, naming it
dw-ranges-func-hi.c.  (That was my intent anyway.  According to git,
I renamed dw-ranges-func.c to dw-ranges-func-hi.c and then modified it.
dw-ranges-func-lo.c shows up as an entirely new file.)

Within dw-ranges-func-hi.c, I changed the placement of foo_cold()
along with some of the other functions so that foo_cold() would be at
a higher address than foo() while also remaining non-contiguous.  The
two files, dw-ranges-func-lo.c and dw-ranges-func-hi.c, are
essentially the same except for the placement of some of the functions
therein.

The tests in dw2-ranges-func.exp where then wrapped in a new proc named
do_test which was then called in a loop from the outermost level.  The
loop causes each of the source files to have the same tests run upon
them.

I also added a few new tests which test functionality fixed by the other
commits to this patch series.  Due to the reorganization of the file,
it's hard to identify these changes in the patch.  So, here are the
tests which were added:

    with_test_prefix "no-cold-names" {

# Due to the calling sequence, this backtrace would normally
# show function foo_cold for frame #1.  However, we don't want
# this to be the case due to placing it in the same block
# (albeit at a different range) as foo.  Thus it is correct to
# see foo for frames #1 and #2.  It is incorrect to see
# foo_cold at frame #1.
gdb_test_sequence "bt" "backtrace from baz" {
    "\[\r\n\]#0 .*? baz \\(\\) "
    "\[\r\n\]#1 .*? foo \\(\\) "
    "\[\r\n\]#2 .*? foo \\(\\) "
    "\[\r\n\]#3 .*? main \\(\\) "
}

# Doing x/2i foo_cold should show foo_cold as the first symbolic
# address and an offset from foo for the second.  We also check to
# make sure that the offset is not too large - we don't GDB to
# display really large offsets that would (try to) wrap around the
# address space.
set foo_cold_offset 0
set test "x/2i foo_cold"
gdb_test_multiple $test $test {
    -re "   (?:$hex) <foo_cold>.*?\n   (?:$hex) <foo\[+-\](\[0-9\]+)>.*${gdb_prompt}" {
        set foo_cold_offset $expect_out(1,string)
pass $test
    }
}
gdb_assert {$foo_cold_offset <= 10000} "offset to foo_cold is not too large"

# Likewise, verify that second address shown by "info line" is at
# and offset from foo instead of foo_cold.
gdb_test "info line *foo_cold" "starts at address $hex <foo_cold> and ends at $hex <foo\[+-\].*?>.*"

    }

When run against a GDB without the requisite bug fixes (from this patch
series), these 6 failures should be seen:

FAIL: gdb.dwarf2/dw2-ranges-func.exp: lo-cold: no-cold-names: backtrace from baz (pattern 4)
FAIL: gdb.dwarf2/dw2-ranges-func.exp: lo-cold: no-cold-names: x/2i foo_cold
FAIL: gdb.dwarf2/dw2-ranges-func.exp: lo-cold: no-cold-names: info line *foo_cold
FAIL: gdb.dwarf2/dw2-ranges-func.exp: hi-cold: no-cold-names: backtrace from baz (pattern 3)
FAIL: gdb.dwarf2/dw2-ranges-func.exp: hi-cold: no-cold-names: x/2i foo_cold
FAIL: gdb.dwarf2/dw2-ranges-func.exp: hi-cold: no-cold-names: info line *foo_cold

gdb/testsuite/ChangeLog:

* gdb.dwarf2/dw2-ranges-func.c: Rename to...
* gdb.dwarf2/dw2-ranges-func-lo-cold.c: ...this.
* gdb.dwarf2/dw2-ranges-func-lo-cold.c (foo_low): Change name to
foo_cold.  Revise comments to match.
* gdb.dwarf2/dw2-ranges-func-hi-cold.c: New file.
* gdb.dwarf2/dw2-ranges-func.exp (do_test): New proc. Existing tests
were wrapped into this proc; Call do_test in loop from outermost
level.
(foo_low): Rename all occurrences to "foo_cold".
(backtrace from baz): New test.
(x2/i foo_cold): New test.
(info line *foo_cold): New test.

dwarf2-frame.c: Fix FDE processing bug involving non-contiguous ranges

In the course of revising the test case for
gdb.dwarf2/dw2-ranges-func.exp, I added a new .c file which would
cause the "cold" range to be at a higher address than the rest of the
function.  In these tests, the range in question isn't really cold in
the sense that a compiler has determined that it'll be executed less
frequently.  Instead, it's simply the range that does not include the
entry pc.  These tests are intended to mimic the output of such a
compiler, so I'll continue to refer to this range as "cold" in the
following discussion.

The original test case had only tested a cold range placed
at lower addresses than the rest of the function.  During testing of the
new code where the cold range was placed at higher addresses, I found
that I could produce the following backtrace:

    (gdb) bt
    #0  0x0000000000401138 in baz ()
at dw2-ranges-func-hi-cold.c:72
    #1  0x0000000000401131 in foo_cold ()
at dw2-ranges-func-hi-cold.c:64
    #2  0x000000000040111e in foo ()
at dw2-ranges-func-hi-cold.c:50
    #3  0x0000000000401144 in main ()
at dw2-ranges-func-hi-cold.c:78

This is correct, except that we'd like to see foo() listed instead
of foo_cold().  (I handle that problem in another patch.)

Now look at what happens for a similar backtrace where the cold range
is at a lower address than the foo's entry pc:

    (gdb) bt
    #0  0x000000000040110a in baz ()
at dw2-ranges-func-lo-cold.c:48
    #1  0x0000000000401116 in foo ()
at dw2-ranges-func-lo-cold.c:54
    #2  0x00007fffffffd4c0 in ?? ()
    #3  0x0000000000401138 in foo ()
at dw2-ranges-func-lo-cold.c:70

Note that the backtrace doesn't go all the way back to main().  Moreover,
frame #2 is messed up.

I had seen this behavior when I had worked on the non-contiguous
address problem last year.  At the time I convinced myself that the
mangled backtrace was "okay" since we're doing strange things with
the DWARF assembler.  We're taking a function called foo_cold (though
it was originally called foo_low - my recent changes to the test case
changed the name) and via the magic of the DWARF assembler, we're
combining it into a separate (non-contiguous) range for foo.  Thus,
it was a surprise to me when I got a good and complete backtrace when
the cold symbol is placed at an address that's greater than entry pc.

The function dwarf2_frame_cache (in dwarf2-frame.c) is making this
call:

    if (get_frame_func_if_available (this_frame, &entry_pc)) ...

If that call succeeds (returns a true value), the FDE is then
processed up to the entry pc.  It doesn't make sense to do this,
however, when the FDE in question does not contain the entry pc.  This
can happen when the function in question is comprised of more than one
(non-contiguous) address range.

My fix is to add some comparisons to the test above to ensure that
ENTRY_PC is within the address range covered by the FDE.

gdb/ChangeLog:

* dwarf2-frame.c (dwarf2_frame_cache): Don't decode FDE instructions
for entry pc when entry pc is out of range for that FDE.

Restrict use of minsym names when printing addresses in disassembled code

build_address_symbolic contains some code which causes it to
prefer the minsym over the the function symbol in certain cases.
The cases where this occurs are the same as the "certain pathological
cases" that used to exist in find_frame_funname().

This commit largely disables that code; it will only prefer the
minsym when the address of minsym is identical to that of the address
under consideration AND the function address for the symbtab sym is
not the same as the address under consideration.

So, without this change, when using the dw2-ranges-func-lo-cold
executable from the gdb.dwarf2/dw2-ranges-func.exp test, GDB exhibits
the following behavior:

(gdb) x/5i foo_cold
   0x40110d <foo+4294967277>: push   %rbp
   0x40110e <foo+4294967278>: mov    %rsp,%rbp
   0x401111 <foo+4294967281>: callq  0x401106 <baz>
   0x401116 <foo+4294967286>: nop
   0x401117 <foo+4294967287>: pop    %rbp

On the other hand, still without this change, using the
dw2-ranges-func-hi-cold executable from the same test, GDB
does this instead:

(gdb) x/5i foo_cold
   0x401128 <foo_cold>: push   %rbp
   0x401129 <foo_cold+1>: mov    %rsp,%rbp
   0x40112c <foo_cold+4>: callq  0x401134 <baz>
   0x401131 <foo_cold+9>: nop
   0x401132 <foo_cold+10>: pop    %rbp

This is inconsistent behavior.  When foo_cold is at a lower
address than the function's entry point, the symtab symbol (foo)
is displayed along with a large positive offset which would wrap
around the address space if the address space were only 32 bits wide.
(A later patch fixes this problem by displaying negative offsets.)

This commit makes the behavior uniform for both the "lo-cold" and
"hi-cold" cases:

lo-cold:

(gdb) x/5i foo_cold
   0x40110d <foo_cold>: push   %rbp
   0x40110e <foo-18>: mov    %rsp,%rbp
   0x401111 <foo-15>: callq  0x401106 <baz>
   0x401116 <foo-10>: nop
   0x401117 <foo-9>: pop    %rbp

hi-cold:

(gdb) x/5i foo_cold
   0x401128 <foo_cold>: push   %rbp
   0x401129 <foo+35>: mov    %rsp,%rbp
   0x40112c <foo+38>: callq  0x401134 <baz>
   0x401131 <foo+43>: nop
   0x401132 <foo+44>: pop    %rbp

In both cases, the symbol shown for the address at which foo_cold
resides is shown as <foo_cold>.  Subsequent offsets are shown as
either negative or positive offsets from the entry pc for foo.

When disassembling a function, care must be taken to NOT display
<+0> as the offset for the second range.  For this reason, I found
it necessary to add the "prefer_sym_over_minsym" parameter to
build_address_symbolic.  The type of this flag is a bool; do_demangle
ought to be a bool also, so I made this change at the same time.

gdb/ChangeLog:

* valprint.h (build_address_symbolic): Add "prefer_sym_over_minsym"
parameter.  Change type of "do_demangle" to bool.
* disasm.c (gdb_pretty_print_disassembler::pretty_print_insn):
Pass suitable "prefer_sym_over_minsym" flag to
build_address_symbolic().  Don't output "+" for negative offsets.
* printcmd.c (print_address_symbolic): Update invocation of
build_address_symbolic to include a "prefer_sym_over_minsym"
flag.
(build_address_symbolic): Add "prefer_sym_over_minsym" parameter.
Restrict cases in which use of minimal symbol is preferred to that
of a found symbol.  Update comments.

Prefer symtab symbol over minsym for function names in non-contiguous blocks

The discussion on gdb-patches which led to this patch may be found
here:

https://www.sourceware.org/ml/gdb-patches/2019-05/msg00018.html

Here's a brief synopsis/analysis:

Eli Zaretskii, while debugging a Windows emacs executable, found
that functions comprised of more than one (non-contiguous)
address range were not being displayed correctly in a backtrace.  This
is the example that Eli provided:

  (gdb) bt
  #0  0x76a63227 in KERNELBASE!DebugBreak ()
     from C:\Windows\syswow64\KernelBase.dll
  #1  0x012e7b89 in emacs_abort () at w32fns.c:10768
  #2  0x012e1f3b in print_vectorlike.cold () at print.c:1824
  #3  0x011d2dec in print_object (obj=<optimized out>, printcharfun=XIL(0),
      escapeflag=true) at print.c:2150

The function print_vectorlike consists of two address ranges, one of
which contains "cold" code which is expected to not execute very often.
There is a minimal symbol, print_vectorlike.cold.65, which is the address
of the "cold" range.

GDB is prefering this minsym over the the name provided by the
DWARF info due to some really old code in GDB which handles
"certain pathological cases".  This comment reads as follows:

      /* In certain pathological cases, the symtabs give the wrong
 function (when we are in the first function in a file which
 is compiled without debugging symbols, the previous function
 is compiled with debugging symbols, and the "foo.o" symbol
 that is supposed to tell us where the file with debugging
 symbols ends has been truncated by ar because it is longer
 than 15 characters).  This also occurs if the user uses asm()
 to create a function but not stabs for it (in a file compiled
 with -g).

 So look in the minimal symbol tables as well, and if it comes
 up with a larger address for the function use that instead.
 I don't think this can ever cause any problems; there
 shouldn't be any minimal symbols in the middle of a function;
 if this is ever changed many parts of GDB will need to be
 changed (and we'll create a find_pc_minimal_function or some
 such).  */

In an earlier version of this patch, I had left the code for the
pathological case intact, but those who reviwed that patch recommended
removing it.  So that's what I've done - I've removed it.

gdb/ChangeLog:

* stack.c (find_frame_funname): Remove code which preferred
minsym over symtab sym in "certain pathological cases".

Automatic date update in version.in

Fix return type typo in obsd-nat.c that breaks build on OpenBSD

To recap the bug report:
Commit a068643 introduced a small typo that breaks the gdb build on OpenBSD.
Line 38 of obsd-nat.c needs to be changed from std::sring to std::string.

gdb/ChangeLog
2019-07-26  Brian Callahan  <bcallah@openbsd.org>

PR gdb/24839:
* gdb/obsd-nat.c (obsd_nat_target::pid_to_str): Fix typo in return
type.

[gdb/testsuite] Fix unterminated string in i386-pkru.exp

I ran into this error:
...
ERROR: tcl error sourcing gdb/testsuite/gdb.arch/i386-pkru.exp.
ERROR: missing "
    while executing
"untested ""
    invoked from within
"if { [prepare_for_testing "failed to prepare" ${testfile} ${srcfile} \
     [list debug additional_flags=${comp_flags}]] } {
    untested "failed to c..."
    (file "gdb/testsuite/gdb.arch/i386-pkru.exp" line 25)
    invoked from within
...
caused by:
...
    untested "failed to compile x86 PKEYS test.
...

Fix the unterminated string.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2019-07-26  Tom de Vries  <tdevries@suse.de>

* gdb.arch/i386-pkru.exp: Fix unterminated string.

PR24798, buffer overflow in process_cu_tu_index

PR 24798
* dwarf.c (process_cu_tu_index): Avoid integer overflow on 64-bit
systems by casting ncols and nslots expressions to size_t.  Display
number of columns and slots before giving up due to buffer overflow.
Use %u to display unsigned ints.  Perform more pointer wrap tests.

Begone elf_linker

This field effectively became usused a long time ago, perhaps as early
as 1994.

* elf-bfd.h (struct output_elf_obj_tdata): Delete "linker" field.
(elf_linker): Don't define.
* elflink.c (bfd_elf_final_link): Don't set elf_linker.

Ajdust lto-3r and lto-5r tests for powerpc64

* testsuite/ld-plugin/lto-3r.d: Accept D for powerpc64 descriptors.
* testsuite/ld-plugin/lto-5r.d: Likewise.

Automatic date update in version.in

Fix comment about the signature of add_separate_debug_file

Also fixes the date in the changelog of my last commit.

gdb/ChangeLog:

2019-07-25  Christian Biesinger  <cbiesinger@google.com>

* python/py-objfile.c (add_separate_debug_file): Fix comment about
  this function's Python signature.

[gdb/testsuite] Test skip_libstdcxx_probe_tests in mi-catch-cpp-exceptions.exp

On a system without SDT probes in libstdc++, we run into:
...
FAIL: gdb.mi/mi-catch-cpp-exceptions.exp: all with invalid regexp: run until \
  breakpoint in main (unknown output after running)
...

The test-case uses a regexp argument for the catch throw/rethrow/catch
command, which is only supported on systems with SDT probes in libstdc++.

Fix this by marking the portions of the test-case that use a regexp argument
as unsupported on a system without SDT probes.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2019-07-25  Tom de Vries  <tdevries@suse.de>

PR testsuite/24830
* gdb.mi/mi-catch-cpp-exceptions.exp: Call
mi_skip_libstdcxx_probe_tests, and skip unsupported tests.
* lib/gdb.exp (skip_libstdcxx_probe_tests_prompt): Factor out of ...
(skip_libstdcxx_probe_tests): ... here.
* lib/mi-support.exp (mi_skip_libstdcxx_probe_tests): New proc.

Fix attributation of DWARF augmentation patch.

Have readelf and objdump display the contents of the DWARF augmentation data as a string, if it is printable.

PR 24809
* dwarf.c (display_debug_names): Display the contents of the
augmentation string, if it is printable.

When linking binary files into MIPS executables, default to MIPS 3 emaulation for 64-bit objects.

PR 24832
* elfxx-mips.c (mips_set_isa_flags): Default to MIPS 3 for 64-bit
mips inputs.

Stop an illegal memory access by readelf when parsing a corrupt MIPS binary file.

PR 24837
* readelf.c (process_mips_specific): Check for buffer overflow
before reading reginfo information.

Allow passing a block to lookup_global_symbol_from_objfile

This has no behavior change in itself, but allows a future patch
to add a function to the Python API to look up symbols in the
static block.

gdb/ChangeLog:

2019-07-24  Christian Biesinger  <cbiesinger@google.com>

* compile/compile-object-load.c (compile_object_load): Pass GLOBAL_SCOPE.
* solib-spu.c (spu_lookup_lib_symbol): Pass GLOBAL_SCOPE.
* solib-svr4.c (elf_lookup_lib_symbol): Pass GLOBAL_SCOPE.
* symtab.c (lookup_global_symbol_from_objfile): Add a scope parameter.
* symtab.h (lookup_global_symbol_from_objfile): Likewise.

Automatic date update in version.in

[gdb/testsuite] Fix implicit declaration of printf in gdb.objc/*.m

When running gdb.objc/objcdecode.exp we get:
...
objcdecode.m: In function '-[Decode multipleDef]':
objcdecode.m:14:3: warning: incompatible implicit declaration of built-in \
  function 'printf'
   printf("method multipleDef\n");
   ^~~~~~
objcdecode.m:14:3: note: include '<stdio.h>' or provide a declaration of \
  'printf'
...

Fix this in the three gdb.objc/*.m test-cases by including stdio.h.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2019-07-24  Tom de Vries  <tdevries@suse.de>

PR testsuite/24807
* gdb.objc/basicclass.m: Include stdio.h.
* gdb.objc/nondebug.m: Same.
* gdb.objc/objcdecode.m: Same.

Revert "Remove tests that test __gnu_lto_v1 symbol."

Revert

commit 8c728a9d93e2342c57039fcdd6e4a502875b9e09
Author: Martin Liska <mliska@suse.cz>
Date:   Mon Jul 22 14:23:32 2019 +0200

    Remove tests that test __gnu_lto_v1 symbol.

since outputs of these tests are used by later tests.  Check the normal
symbol, foo, instead of __gnu_lto_v.*, which GCC stopped emitting after
r273662.

* testsuite/ld-plugin/lto-3r.d: Restored.  Check foo instead
of __gnu_lto_v.*.
* testsuite/ld-plugin/lto-5r.d: Likewise.
* testsuite/ld-plugin/lto.exp: Run lto-3r and lto-5r tests.

[gdb/testsuite] Fix infoline-reloc-main-from-zero.exp compilation

When running gdb.base/infoline-reloc-main-from-zero.exp, I see:
...
Running gdb/testsuite/gdb.base/infoline-reloc-main-from-zero.exp ...
gdb compile failed, ld: infoline-reloc-main-from-zero: \
  not enough room for program headers, try linking with -N
ld: final link failed: bad value
collect2: error: ld returned 1 exit status
UNTESTED: gdb.base/infoline-reloc-main-from-zero.exp: infoline-reloc-main-from-zero.exp
UNTESTED: gdb.base/infoline-reloc-main-from-zero.exp: failed to compile
...

Fix this by following the suggestion:
...
-set opts {debug "additional_flags=-nostdlib -emain -Wl,-Ttext=0x00"}
+set opts {debug "additional_flags=-nostdlib -emain -Wl,-Ttext=0x00 -Wl,-N"}
...

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2019-07-24  Tom de Vries  <tdevries@suse.de>

PR testsuite/24612
* gdb.base/infoline-reloc-main-from-zero.exp: Add -Wl,-N to
additional_flags.

[ARC] [COMMITTED] Fix formatting.

Small formatting fixes.

2019-07-24  Claudiu Zissulescu  <claziss@synopsys.com>

* elf32-arc.c (bfd_get_32_me): Add a small description, fix
formatting.
(reloc_type_to_name): Fix formatting.
(arc_elf_object_p): Likewise.
(debug_arc_reloc): Likewise.
(arc_do_relocation): Likewise.

Update the Swedish translation for the gas sub-directory.

[ARC] Update disassembler opcode selection

New instruction are added, and some of them are overlapping. Update
disassembler to correctly recognize them. Introduce nps400 option.

opcodes/
xxxx-xx-xx  Claudiu Zissulescu  <claziss@synopsys.com>

* arc-dis.c (skip_this_opcode): Check also for 0x07 major opcodes,
and MPY class instructions.
(parse_option): Add nps400 option.
(print_arc_disassembler_options): Add nps400 info.

gas/
xxxx-xx-xx  Claudiu Zissulescu  <claziss@synopsys.com>

* testsuite/gas/arc/nps400-6.d: Update test.

[ARC] Update ARC opcode table

Update ARC opcode table by cleaning up invalid instructions, and fixing wrong encodings.

opcodes/
xxxx-xx-xx  Claudiu Zissulescu  <claziss@synopsys.com>

* arc-ext-tbl.h (bspeek): Remove it, added to main table.
(bspop): Likewise.
(modapp): Likewise.
* arc-opc.c (RAD_CHK): Add.
* arc-tbl.h: Regenerate.

include/
xxxx-xx-xx  Claudiu Zissulescu  <claziss@synopsys.com>

* include/opcode/arc.h (FASTMATH): Add.
(SWITCH): Likewise.

[ARC] Add linker relaxation.

Add linker relaxation. The first relaxation added is converting
GOTPC32 to PCREL relocations. This relaxation doesn't change the size of
the binary.

bfd/
xxxx-xx-xx  Claudiu Zissulescu  <claziss@synopsys.com>

* elf32-arc.c (bfd_get_32_me): New function.
(bfd_put_32_me): Likewise.
(arc_elf_relax_section): Likewise.
(bfd_elf32_bfd_relax_section): Define.

ld/testsuite/
xxxx-xx-xx  Claudiu Zissulescu  <claziss@synopsys.com>

* ld-arc/relax-local-pic.d: New test.
* ld-arc/relax-local-pic.s: New file.

gdb/h8300-tdep.c: Fix register name in h8300h machine.

H8/300H general register name "ER0" - "ER7".
But gdb using "R0" - "R7".
This changes register name "ER0" - "ER7" in h8300h machine mode.

gdb/ChangeLog:

* h8300-tdep.c (h8300_register_name_common): New.
h8300_register_name): Use h8300_register_name_common.
(h8300s_register_name): Likewise.
(h8300sx_register_name): Likewise.
(h8300h_register_nam): New.
(h8300_gdbarch_init): Use h8300h_register_name in h8300h machine.

Fix ar so that it can correctly detect non-dash prefixed options that appear after dash prefixed options.

PR 13256
* ar.c (decode_options): Restart option scanning if no operation
is detected and argument remain to be scanned.

Complain about mbind, ifunc, and unique in final_write

It's not as good as complaining in gas/config/obj-elf.c since you lose
any reference to the source file.

bfd/
* elf-bfd.h (struct elf_backend_data): Return bfd_boolean from
elf_backend_final_write_processing, don't pass linker arg.
(_bfd_elf_final_write_processing): Update prototype.
* elf.c (_bfd_elf_write_object_contents): Adjust call.
(_bfd_elf_final_write_processing): Return error on incompatible
OSABI and has_gnu_osabi.  Remove linker arg.
* elf-nacl.h (nacl_final_write_processing): Update prototype.
* elf-vxworks.h (elf_vxworks_final_write_processing): Likewise.
* elfxx-mips.h (_bfd_mips_final_write_processing): Likewise.
(_bfd_mips_elf_final_write_processing): Likewise.
* elf-hppa.h (elf_hppa_final_write_processing): Return status
and remove linker arg.
* elf-m10300.c (_bfd_mn10300_elf_final_write_processing): Likewise.
* elf-nacl.c (nacl_final_write_processing): Likewise.
* elf-vxworks.c (elf_vxworks_final_write_processing): Likewise.
* elf32-arc.c (arc_elf_final_write_processing): Likewise.
* elf32-arm.c (arm_final_write_processing): Likewise.
(elf32_arm_final_write_processing): Likewise.
(elf32_arm_nacl_final_write_processing): Likewise.
(elf32_arm_vxworks_final_write_processing): Likewise.
* elf32-avr.c (bfd_elf_avr_final_write_processing): Likewise.
* elf32-bfin.c (elf32_bfin_final_write_processing): Likewise.
* elf32-cr16.c (_bfd_cr16_elf_final_write_processing): Likewise.
* elf32-cris.c (cris_elf_final_write_processing): Likewise.
* elf32-h8300.c (elf32_h8_final_write_processing): Likewise.
* elf32-lm32.c (lm32_elf_final_write_processing): Likewise.
* elf32-m32r.c (m32r_elf_final_write_processing): Likewise.
* elf32-m68k.c (elf_m68k_final_write_processing): Likewise.
* elf32-mips.c (mips_vxworks_final_write_processing): Likewise.
* elf32-msp430.c (bfd_elf_msp430_final_write_processing): Likewise.
* elf32-nds32.c (nds32_elf_final_write_processing): Likewise.
* elf32-or1k.c (or1k_elf_final_write_processing): Likewise.
* elf32-pj.c (pj_elf_final_write_processing): Likewise.
* elf32-ppc.c (ppc_final_write_processing): Likewise.
(ppc_elf_final_write_processing): Likewise.
(ppc_elf_vxworks_final_write_processing): Likewise.
* elf32-sparc.c (sparc_final_write_processing): Likewise.
(elf32_sparc_final_write_processing): Likewise.
(elf32_sparc_vxworks_final_write_processing): Likewise.
* elf32-v850.c (v850_elf_final_write_processing): Likewise.
* elf32-xc16x.c (elf32_xc16x_final_write_processing): Likewise.
* elf32-xtensa.c (elf_xtensa_final_write_processing): Likewise.
* elf64-ia64-vms.c (elf64_vms_final_write_processing): Likewise.
* elfnn-ia64.c (elfNN_ia64_final_write_processing): Likewise.
* elfxx-mips.c (_bfd_mips_final_write_processing): Likewise.
(_bfd_mips_elf_final_write_processing): Likewise.
gas/
* config/obj-elf.c (obj_elf_section, obj_elf_type): Set has_gnu_osabi.
* testsuite/gas/elf/section12a.d: Update xfails.
* testsuite/gas/elf/section12b.d: Likewise.

Re: ELF final_write_processing

I missed some early exits from final_write_processing that mean
_bfd_elf_final_write_processing could be missed.

* elf-vxworks.c (elf_vxworks_final_write_processing): Don't return
early.
* elf32-arc.c (arc_elf_final_write_processing): Likewise.
* elf32-xtensa.c (elf_xtensa_final_write_processing): Likewise.

Define ELF_OSABI for visium

and update expected results for gas mbind tests.

bfd/
* elf32-visium.c (visium_elf_post_process_headers): Don't set
EI_OSABI header byte here.
(ELF_OSABI): Define.
gas/
* testsuite/gas/elf/section12a.d: xfail visium and cloudabi.
* testsuite/gas/elf/section12b.d: Likewise.
* testsuite/gas/elf/section13.d: Likewise.

PT_GNU_MBIND section mapping

* elf/internal.h (ELF_SECTION_IN_SEGMENT_1): Exclude non-alloc
sections in GNU_MBIND segments.

Update expected info threads error messages in gdb.multi/tids.exp

We currently have these FAILs:
...
FAIL: gdb.multi/tids.exp: two inferiors: info threads -1
FAIL: gdb.multi/tids.exp: two inferiors: info threads -$one
...
because we're expecting:
...
Invalid thread ID: -1
...
but instead we have:
...
Unrecognized option at: -1
...

This error message for info threads has changed since commit 54d6600669
'Make "info threads" use the gdb::option framework'.

Update the test accordingly.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2019-07-24  Tom de Vries  <tdevries@suse.de>

PR testsuite/24831
* gdb.multi/tids.exp: Update error messages for info threads.

[gdb/testsuite] Fix info-types.exp for debug info from more than one file

On openSUSE Leap 15.0, I get:
...
FAIL: gdb.base/info-types.exp: l=c: info types
FAIL: gdb.base/info-types.exp: l=c++: info types
...
because the info type command prints info for files info-types.c, stddef.h,
elf-init.c and init.c, while the regexp in the test-case expect only info for
info-types.c.

Fix this by extending the regexp.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2019-07-24  Tom de Vries  <tdevries@suse.de>

* gdb.base/info-types.exp: Allow info types to print info for more than
one file.

Automatic date update in version.in

Fix objdump's display of indirect strings in object files, which was broken by the link following code.

PR 24818
* objdump.c (is_relocateable): Delete.
(load_specific_debug_section): Test the abfd for relocations
directly, rather than relying upon is_relocateable.
(dump_dwarf): Delete initlialization of is_relocateable.

Add missing ChangeLog entries for

commit 8c728a9d93e2342c57039fcdd6e4a502875b9e09
Author: Martin Liska <mliska@suse.cz>
Date:   Mon Jul 22 14:23:32 2019 +0200

    Remove tests that test __gnu_lto_v1 symbol.

[AArch64] Add support for GMID_EL1 register for +memtag

We're missing support for the GMID_EL1 system register from the Memory Tagging Extension in binutils.
This is specified at:
https://developer.arm.com/docs/ddi0595/latest/aarch64-system-registers/gmid_el1

This simple patch adds the support for this read-only register.
Tested make check on gas.

[gdb/testsuite] Add missing initial prompt read in multidictionary.exp

When running multidictionary.exp in conjunction with:
...
$ stress -c $(($(cat /proc/cpuinfo | grep -c "^processor") + 1))
...
we get:
...
Running gdb/testsuite/gdb.dwarf2/multidictionary.exp ...
ERROR: Couldn't load multidictionary into gdb.

                === gdb Summary ===

nr of unresolved testcases       1
...

The multidictionary test-case needs -readnow, and achieves this using:
...
gdb_spawn_with_cmdline_opts "-readnow"
gdb_load
...
but the initial gdb prompt is not read.  Usually, the following gdb_load
command accidentally consumes that initial prompt (at the gdb_expect for the
kill command in gdb_file_cmd).  But under high load, that doesn't happen and
we run into the error.

Fix this by consuming the initial gdb prompt after spawning gdb.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2019-07-23  Tom de Vries  <tdevries@suse.de>

PR testsuite/24842
* gdb.dwarf2/multidictionary.exp: Consume initial prompt after
gdb_spawn_with_cmdline_opts.

[gdb][Arm]: gdb cannot step across CMSE secure entry function code.

GDB is not able to execute "step" command on function calls of Armv8-M cmse secure entry functions.
Everytime GNU linker come across definition of any cmse secure entry function in object file(s),
it creates two new instructions secure gateway (sg) and original branch destination (b.w),
place those two instructions in ".gnu.sgstubs" section of executable.
Any function calls to these cmse secure entry functions is re-directed through secure gateway (sg)
present in ".gnu.sgstubs" section.

Example:
Following is a function call to cmse secure entry function "foo":
        ...
        bl xxxx <foo>   --->(a)
        ...
        <foo>
        xxxx: push    {r7, lr}

GNU linker on finding out "foo" is a cmse secure entry function, created sg and b.w instructions and
place them in ".gnu.sgstubs" section (marked by c).

The "bl" instruction (marked by a) which is a call to cmse secure entry function is modified by GNU linker
(as marked by b) and call flow is re-directly through secure gateway (sg) in ".gnu.sgstubs" section.
       ...
       bl yyyy <foo>  ---> (b)
       ...
       section .gnu.sgstubs: ---> (c)
       yyyy <foo>
       yyyy: sg   // secure gateway
     b.w xxxx <__acle_se_foo>  // original_branch_dest
       ...
       0000xxxx <__acle_se_foo>
       xxxx: push    {r7, lr} ---> (d)

On invoking GDB, when the control is at "b" and we pass "step" command, the pc returns "yyyy"
(sg address) which is a trampoline and which does not exist in source code. So GDB jumps
to next line without jumping to "__acle_se_foo" (marked by d).

The above details are published on the Arm website [1], please refer to section 5.4 (Entry functions)
and section 3.4.4 (C level development flow of secure code).

[1] https://developer.arm.com/architectures/cpu-architecture/m-profile/docs/ecm0359818/latest/armv8-m-security-extensions-requirements-on-development-tools-engineering-specification

This patch fixes above problem by returning target pc "xxxx" to GDB on executing "step"
command at "b", so that the control jumps to "__acle_se_foo" (marked by d).

gdb/ChangeLog:

* arm-tdep.c (arm_skip_cmse_entry): New function.
(arm_is_sgstubs_section): New function.
(arm_skip_stub): Add call to arm_skip_cmse_entry function.

gdb/testsuite/ChangeLog:

* gdb.arch/arm-cmse-sgstubs.c: New test.
* gdb.arch/arm-cmse-sgstubs.exp: New file.

Remove tests that test __gnu_lto_v1 symbol.

ld/ChangeLog:

2019-07-22  Martin Liska  <mliska@suse.cz>

* testsuite/ld-plugin/lto-3r.d: Remove.
* testsuite/ld-plugin/lto-5r.d: Remove.
* testsuite/ld-plugin/lto.exp: Do not run lto-3r and lto-5r
tests.

SHF_GNU_MBIND requires ELFOSABI_GNU

When SHF_GNU_MBIND was added in the SHF_LOOS to SHF_HIOS range, it
should have required ELFOSABI_GNU since these flags are already in use
by other OSes.  HPUX SHF_HP_TLS in fact has the same value.  That
means no place in binutils should test SHF_GNU_MBIND without first
checking OSABI, and SHF_GNU_MBIND should not be set without also
setting OSABI.  At least, that's the ideal, but the patch accepts
SHF_GNU_MBIND on ELFOSABI_NONE object files since gas didn't always
set OSABI.  However, to reinforce the fact that SHF_GNU_MBIND isn't
proper without a non-zero OSABI, readelf will display the flag as
LOOS+0 if OSABI isn't set.

The clash with SHF_HP_TLS means that hppa64-linux either has that flag
on .tbss sections or supports GNU_MBIND, not both.  (hppa64-linux
users, if there are any, may have noticed that GNU ld since 2017
mysteriously aligned their .tbss sections to a 4k boundary.  That was
one consequence of SHF_HP_TLS being blindly interpreted as
SHF_GNU_MBIND.)  Since it seems that binutils, gdb, gcc, glibc, and
the linux kernel don't care about SHF_HP_TLS I took that flag out of
.tbss for hppa64-linux.

bfd/
* elf-bfd.h (enum elf_gnu_osabi): Add elf_gnu_osabi_mbind.
* elf.c (_bfd_elf_make_section_from_shdr): Set elf_gnu_osabi_mbind.
(get_program_header_size): Formatting.  Only test SH_GNU_MBIND
when elf_gnu_osabi_mbind is set.
(_bfd_elf_map_sections_to_segments): Likewise.
(_bfd_elf_init_private_section_data): Likewise.
(_bfd_elf_final_write_processing): Update comment.
* elf64-hppa.c (elf64_hppa_special_sections): Move .tbss entry.
(elf_backend_special_sections): Define without .tbss for linux.
binutils/
* readelf.c (get_parisc_segment_type): Split off hpux entries..
(get_ia64_segment_type): ..and these..
(get_hpux_segment_type): ..to here.
(get_segment_type): Condition GNU_MBIND on osabi.  Use
get_hpux_segment_type.
(get_symbol_binding): Do not print UNIQUE for ELFOSABI_NONE.
(get_symbol_type): Do not print IFUNC for ELFOSABI_NONE.
gas/
* config/obj-elf.c (obj_elf_change_section): Don't emit a fatal
error for non-SHF_ALLOC SHF_GNU_MBIND here.
(obj_elf_parse_section_letters): Return SHF_GNU_MBIND in new
gnu_attr param.
(obj_elf_section): Adjust obj_elf_parse_section_letters call.
Formatting.  Set SHF_GNU_MBIND and elf_osabi from gnu_attr.
Emit normal error for non-SHF_ALLOC SHF_GNU_MBIND and wrong osabi.
(obj_elf_type): Set elf_osabi for ifunc.
* testsuite/gas/elf/section12a.d: xfail msp430 and hpux.
* testsuite/gas/elf/section12b.d: Likewise.
* testsuite/gas/elf/section13.d: Likewise.
* testsuite/gas/elf/section13.l: Adjust expected error.
ld/
* emultempl/elf32.em (gld${EMULATION_NAME}_place_orphan): Condition
SHF_GNU_MBIND on osabi.  Set output elf_gnu_osabi_mbind.

ELF final_write_processing

Move setting of OSABI to final_write_processing, after symbols are
written.  This allows OSABI to be set based on symbols actually
written to the output rather than assuming input symbols will be
output.

Corrects object files such as the one generated on powerpc64le-linux
by ld-powerpc/pr23927.s which has a local STT_GNU_IFUNC symbol but
prior to this patch the file was marked ELFOSABI_NONE.

* elf-bfd.h (enum elf_gnu_osabi): Rename from elf_gnu_symbols.
Remove none, any, all enums.
(struct elf_obj_tdata): Rename has_gnu_symbols field to has_gnu_osabi.
(_bfd_elf_final_write_processing): Declare.
* elf.c (_bfd_elf_write_object_contents): Unconditionally call
elf_backend_final_write_processing.
(_bfd_elf_post_process_headers): Move body of function to..
(_bfd_elf_final_write_processing): ..here, but set EI_OSABI byte
only when not already set.  Adjust for rename.
* elfxx-target.h (elf_backend_final_write_processing): Default to
_bfd_elf_final_write_processing.
* elf-hppa.h (elf_hppa_final_write_processing): Call
_bfd_elf_final_write_processing.
* elf-m10300.c (_bfd_mn10300_elf_final_write_processing): Likewise.
* elf-nacl.c (nacl_final_write_processing): Likewise.
* elf-vxworks.c (elf_vxworks_final_write_processing): Likewise.
* elf32-arc.c (arc_elf_final_write_processing): Likewise.
* elf32-avr.c (bfd_elf_avr_final_write_processing): Likewise.
* elf32-bfin.c (elf32_bfin_final_write_processing): Likewise.
* elf32-cr16.c (_bfd_cr16_elf_final_write_processing): Likewise.
* elf32-cris.c (cris_elf_final_write_processing): Likewise.
* elf32-h8300.c (elf32_h8_final_write_processing): Likewise.
* elf32-lm32.c (lm32_elf_final_write_processing): Likewise.
* elf32-m32r.c (m32r_elf_final_write_processing): Likewise.
* elf32-m68k.c (elf_m68k_final_write_processing): Likewise.
* elf32-msp430.c (bfd_elf_msp430_final_write_processing): Likewise.
* elf32-nds32.c (nds32_elf_final_write_processing): Likewise.
* elf32-or1k.c (or1k_elf_final_write_processing): Likewise.
* elf32-pj.c (pj_elf_final_write_processing): Likewise.
* elf32-v850.c (v850_elf_final_write_processing): Likewise.
* elf32-xc16x.c (elf32_xc16x_final_write_processing): Likewise.
* elf32-xtensa.c (elf_xtensa_final_write_processing): Likewise.
* elf64-ia64-vms.c (elf64_vms_final_write_processing): Likewise.
* elfnn-ia64.c (elfNN_ia64_final_write_processing): Likewise.
* elf32-arm.c (arm_final_write_processing): Split out from..
(elf32_arm_final_write_processing): ..here.  Call
_bfd_elf_final_write_processing.
(elf32_arm_nacl_final_write_processing): Adjust.
* elfxx-mips.c (_bfd_mips_final_write_processing): Split out from..
(_bfd_mips_elf_final_write_processing): ..here.  Call
_bfd_elf_final_write_processing.
* elfxx-mips.h (_bfd_mips_final_write_processing): Declare.
* elf32-mips.c (mips_vxworks_final_write_processing): Adjust.
* elf32-ppc.c (ppc_final_write_processing): Split out from..
(ppc_elf_final_write_processing): ..here.  Call
_bfd_elf_final_write_processing.
(ppc_elf_vxworks_final_write_processing): Adjust.
* elf32-sparc.c (sparc_final_write_processing): Split out from..
(elf32_sparc_final_write_processing): ..here.  Call
_bfd_elf_final_write_processing.
(elf32_sparc_vxworks_final_write_processing): Adjust.
* elf32-d10v.c (elf_backend_final_write_processing): Don't define.
* elf32-d30v.c (elf_backend_final_write_processing): Don't define.
* elf32-m68hc11.c (elf_backend_final_write_processing): Don't define.
* elf32-m68hc12.c (elf_backend_final_write_processing): Don't define.
* elf32-s12z.c (elf_backend_final_write_processing): Don't define.
* elf32-i386.c (elf_i386_check_relocs): Don't set has_gnu_symbols.
* elf64-x86-64.c (elf_x86_64_check_relocs): Likewise.
* elflink.c (elf_link_add_object_symbols): Likewise.
(elf_link_output_symstrtab): Set has_gnu_osabi for symbols here
instead.

Move ld-scripts size tests

Also restore them somewhat closer to the original.  They originally
failed on many targets, and a month later I "simplified" them as part
of a larger patch fixing other failing tests.  That unfortunately lost
their main purpose, which was to test TLS layout.

* testsuite/ld-elf/size-1.d,
* testsuite/ld-elf/size-1.s,
* testsuite/ld-elf/size-1.t: New test.
* testsuite/ld-elf/size-2.d,
* testsuite/ld-elf/size-2.s,
* testsuite/ld-elf/size-2.t: New test.
* testsuite/ld-scripts/size-1.d,
* testsuite/ld-scripts/size-1.s,
* testsuite/ld-scripts/size-1.t,
* testsuite/ld-scripts/size-2.s,
* testsuite/ld-scripts/size-2.d,
* testsuite/ld-scripts/size-2.t,
* testsuite/ld-scripts/size.exp: Delete.

binutils testsuite test for ELF32 vs ELF64

* testsuite/binutils-all/objcopy.exp (elf64): Correct object
file used to set this variable.

gas "mbind sections" test

Doesn't fail on rx-elf

* testsuite/gas/elf/section12a.d: Don't skip for rx.

Add Changelog entry missing from previous delta.

2019-07-22  Barnaby Wilks  <barnaby.wilks@arm.com>

* arm-dis.c (is_mve_unpredictable): Stop marking some MVE
instructions as UNPREDICTABLE.

Allow objdump to recognise the System.Runtime.dll files that get shipped with .NET Core 2.1.

include * coff/i386.h (IMAGE_FILE_MACHINE_NATIVE_APPLE_OVERRIDE): Define.
(IMAGE_FILE_MACHINE_NATIVE_FREEBSD_OVERRIDE): Define.
(IMAGE_FILE_MACHINE_NATIVE_LINUX_OVERRIDE): Define.
(IMAGE_FILE_MACHINE_NATIVE_NETBSD_OVERRIDE): Define.
(I386_APPLE_MAGIC): Define.
(I386_FREEBSD_MAGIC): Define.
(I386_LINUX_MAGIC): Define.
(I386_NETBSD_MAGIC): Define.
(I386BADMAG): Extend macro to allow new magic numbers.
* coff/x86_64.h (IMAGE_FILE_MACHINE_NATIVE_APPLE_OVERRIDE): Define.
(IMAGE_FILE_MACHINE_NATIVE_FREEBSD_OVERRIDE): Define.
(IMAGE_FILE_MACHINE_NATIVE_LINUX_OVERRIDE): Define.
(IMAGE_FILE_MACHINE_NATIVE_NETBSD_OVERRIDE): Define.
(AMD64_APPLE_MAGIC): Define.
(AMD64_FREEBSD_MAGIC): Define.
(AMD64_LINUX_MAGIC): Define.
(AMD64_NETBSD_MAGIC): Define.
(AMD64BADMAG): Extend macro to allow new magic numbers.

bfd * coffcode.h (coff_set_arch_mach_hook): Handle I386_APPLE_MAGIC,
I386_FREEBSD_MAGIC, I386_LINUX_MAGIC, I386_NETBSD_MAGIC,
AMD64_APPLE_MAGIC, AMD64_FREEBSD_MAGIC, AMD64_LINUX_MAGIC,
AMD64_NETBSD_MAGIC.
* peXXigen.c: Add comment about source of .NET magic numbers.

binutils* Makefile.am (AUTOMAKE_OPTIONS): Add subdir-objects
(GENTESTDLLSPROG): Define.
(TEST_PROGS): Add GENTESTDLLSPROG.
* Makefile.in: Regenerate.
* testsuite/binutils-all/objdump.exp
(test_objdump_dotnet_assemblies): New proc.
Run the new proc.
* testsuite/gentestdlls.c: New source file.

[gdb/testsuite] Fix command result testing in mi-complete.exp

When running gdb.mi/mi-complete.exp in conjunction with:
...
$ stress -c $(($(cat /proc/cpuinfo | grep -c "^processor") + 1))
...
we get less than 50% full passes:
...
$ for n in  $(seq 1 100); do \
    make V=1 -O check \
      'RUNTESTFLAGS=gdb.mi/mi-complete.exp --target_board=unix'; \
  done 2>&1 \
  | grep "expected passes" | sort | uniq -c
     45 # of expected passes            7
      9 # of expected passes            8
     46 # of expected passes            9
...

A diff between a passing and failing gdb.log shows this difference:
...
-&"set max-completions 1\n"
 2-complete br
+&"set max-completions 1\n"
...

The problem is that the test-case issues the "set max-completion <n>" command,
and without waiting for the output issues a next command, and tries to parse
the results of both commands, expecting a specific interleaving of the various
output streams.

Fix the FAIL by waiting for the result of the "set max-completion <n>" command
before issuing another command.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2019-07-23  Tom de Vries  <tdevries@suse.de>

PR testsuite/24711
* gdb.mi/mi-complete.exp: Wait for "set max-completions" result before
issuing next command.

Automatic date update in version.in

Remove self-assign from make_invisible_and_set_new_height

In https://sourceware.org/ml/gdb-patches/2019-07/msg00509.html, Jan
pointed out that clang points out that
make_invisible_and_set_new_height self-assigns "height".

This patch fixes the bug by renaming the formal parameter.

gdb/ChangeLog
2019-07-22  Tom Tromey  <tom@tromey.com>

* tui/tui-win.c (tui_win_info::make_invisible_and_set_new_height):
Don't self-assign.

Fixes the linker testcase "Secure gateway veneers:cmse functions debug information missing" which was failing due to output regular expression mismatch on arm-none-linux-gnueabihf targets.

* ld/testsuite/ld-arm/cmse_main_sec_debug.d: Modify regexps to
allow for output from a arm-none-linux-gnueabihf target.

This patch addresses the change in the June Armv8.1-M Mainline specification, that marks certain MVE instructions as no longer UNPREDICTABLE when a source operand is the same as a destination operand for a 32-bit element size.

The instructions that this change apply to are:

  VQDMLADH, VQRDMLADH, VQDMLSDH, VQRDMLSDH

The updated documentation is here: https://static.docs.arm.com/ddi0553/bh/DDI0553B_h_armv8m_arm.pdf

Fixed this by removing the check for this warning from GAS as well as opcodes.

Added testcases to test that the warning is not generated for the instructions that have a 32-bit element size
and the same source and destination operand. Also fixed tests that would previously check for this warning.

gas * config/tc-arm.c (do_mve_vqdmladh): Remove check for UNPREDICTABLE.
* testsuite/gas/arm/mve-vqdmladh-bad.l: Remove tests.
* testsuite/gas/arm/mve-vqdmladh-bad.s: Remove tests.
* testsuite/gas/arm/mve-vqdmladh.d: New tests.
* testsuite/gas/arm/mve-vqdmladh.s: New tests.
* testsuite/gas/arm/mve-vqdmlsdh-bad.l: Remove tests.
* testsuite/gas/arm/mve-vqdmlsdh-bad.s: Remove tests.
* testsuite/gas/arm/mve-vqdmlsdh.d: New tests.
* testsuite/gas/arm/mve-vqdmlsdh.s: New tests.

opcodes * arm-dis.c (is_mve_unpredictable): Stop marking some MVE
instructions as UNPREDICTABLE.

gdb: Show type summary for anonymous structures from c_print_typedef

Currently each language has a la_print_typedef method, this is only
used for the "info types" command.

The documentation for "info types" says:

   Print a brief description of all types whose names match the regular
   expression @var{regexp} (or all types in your program, if you supply
   no argument).

However, if we consider this C code:

   typedef struct {
     int a;
   } my_type;

Then currently with "info types" this will be printed like this:

   3:      typedef struct {
       int a;
   } my_type;

I see two problems with this, first the indentation is clearly broken,
second, if the struct contained more fields then it feels like the
actual type names could easily get lost in the noise.

Given that "info types" is about discovering type names, I think there
is an argument to be made that we should focus on giving _only_ the
briefest summary for "info types", and if the user wants to know more
they can take the type name and plug it into "ptype".  As such, I
propose that a better output would be:

   3:      typedef struct {...} my_type;

The user understands that there is a type called `my_type`, and that
it's an alias for an anonymous structure type.

The change to achieve this turns out to be pretty simple, but only
effects languages that make use of c_print_typedef, which are C, C++,
asm, minimal, d, go, objc, and opencl.  Other languages will for now
do whatever they used to do.

The patch to change how anonymous structs are displayed also changes
the display of anonymous enums, consider this code sample:

   typedef enum {
     AA, BB, CC
   } anon_enum_t;

This used to be displayed like this:

   3:      typedef enum {AA, BB, CC} anon_enum_t;

Which will quickly become cluttered for enums with a large number of
values.  The modified output looks like this:

   3:      typedef enum {...} anon_enum_t;

Again, the user can always make use of ptype if they want to see the
details of the anon_enum_t type.

It is worth pointing out that this change (to use {...}) only effects
anonymous structs and enums, named types don't change with this patch,
consider this code:

   struct struct_t {
     int i;
   };
   enum enum_t {
    AA, BB, CC
   };

The output from 'info types' remains unchanged, like this:

   4:      enum enum_t;
   1:      struct struct_t;

An additional area of interest is how C++ handles anonymous types used
within a typedef; enums are handled basically inline with how C
handles them, but structs (and classes) are slightly different.  The
behaviour before the patch is different, and is unchanged by this
patch.  Consider this code compiled for C++:

   typedef struct {
     int i;
   } struct_t;

Both before and after this patch, this is show by 'info types' as:

   3:      typedef struct_t struct_t;

Unions are displayed similarly to structs in both C and C++, the
handling of anonymous unions changes for C in the same way that
it changes for anonymous structs.

I did look at ada, as this is the only language to actually have some
tests for "info types", however, as I understand it ada doesn't really
support typedefs, however, by forcing the language we can see what ada
would print.  So, if we 'set language ada', then originally we printed
this:

   3:      record
       a: int;
   end record

Again the indentation is clearly broken, but we also have no mention
of the type name at all, which is odd, but understandable given the
lack of typedefs.  If I make a similar change as I'm proposing for C,
then we now get this output:

   3:      record ... end record

Which is even less informative I think.  However, the original output
_is_ tested for in gdb.ada/info_auto_lang.exp, and its not clear to me
if the change is a good one or not, so for now I have left this out.

gdb/ChangeLog:

* c-typeprint.c (c_print_typedef): Pass -1 instead of 0 to
type_print.

gdb/testsuite/ChangeLog:

* gdb.ada/info_auto_lang.exp: Update expected results.
* gdb.base/info-types.c: Add additional types to check.
* gdb.base/info-types.exp: Update expected results.

gdb: Improve output from "info types" commad

This commit makes two changes to the "info types" command:

First, only use typedef_print for printing typedefs, and use
type_print for printing non-typedef scalar (non-struct) types.  The
result of this is the output for builtin types goes from this:

    typedef double;
    typedef float;
    typedef int;

to this:

    double;
    float;
    int;

which seems to make more sense.

Next GDB no longer matches msymbols as possible type names.  When
looking for function symbols it makes sense to report matching
msymbols from the text sections, and for variables msymbols from the
data/bss sections, but when reporting types GDB would match msymbols
of type absolute.  But I don't see why these are likely to indicate
type names.  As such I've updated the msymbol matching lists in
symtab.c:search_symbols so that when searching in the TYPES_DOMAIN, we
never match any msymbols.

gdb/ChangeLog:

* symtab.c (search_symbols): Adjust msymbol matching type arrays
so that GDB doesn't match any msymbols when searching in the
TYPES_DOMAIN.
(print_symbol_info): Print using typedef_print or type_print based
on the type of the symbol.  Add updated FIXME comment moved from...
(_initialize_symtab): ... move and update FIXME comment to above.

gdb/testsuite/ChangeLog:

* gdb.base/info-types.c: New file.
* gdb.base/info-types.exp: New file.

gdb: Switch "info types" over to use the gdb::options framework

Adds a new -q flag to "info types" using the gdb::option framework.
This -q flag is similar to the -q flag already present for "info
variables" and "info functions".

gdb/ChangeLog:

* NEWS: Mention adding -q option to "info types".
* symtab.c (struct info_types_options): New struct.
(info_types_options_defs): New variable.
(make_info_types_options_def_group): New function.
(info_types_command): Use gdb::option framework to parse options.
(info_types_command_completer): New function.
(_initialize_symtab): Extend the help text on "info types" and
register command completer.

gdb/doc/ChangeLog:

* gdb.texinfo (Symbols): Add information about -q flag to "info
types".

Add ChangeLog entry for the last commit

Forgot to commit before pushing :(

Use block_enum instead of int for better typesafety

gdb/ChangeLog:

2019-07-21  Christian Biesinger  <cbiesinger@google.com>

* symtab.c (lookup_symbol_in_objfile_symtabs): Change int to block_enum.
(lookup_symbol_in_objfile): Change int to block_enum and add a
gdb_assert to make sure block_index is GLOBAL_BLOCK or STATIC_BLOCK.

[FYI] Add myself to gdb/MAINTAINERS

gdb/Changelog:

* MAINTAINERS (Write After Approval): Add myself.

Automatic date update in version.in

Make documentation of "python" command match actual behavior

The example in the documentation for the "python" command shows GDB
outputting instructions for how to terminate a sequence of python
commands entered from the command line.  The documentation shows that
the following two lines are being output, though this does not occur
when actually using the "python" command from GDB:

    Type python script
    End with a line saying just "end".

While display of this text might be helpful, GDB has several other
commands which also use the "end" terminator that offer no such text.
Examples include the "if" and "while" commands.  For example,

(gdb) if 1==1
 >print "a"
 >end
$1 = "a"

This seems similar to doing:

(gdb) python
 >print 23
 >end
23

If we decide that we want the "python" command to print such a message,
we should also adjust the behavior for other GDB commands which also use
"end" to terminate a command list.  I.e, if this decision is made, the
"if" and "while" commands ought to also print similar messages.

So, for the moment anyway, this commit adjusts the documentation of the
python command to match its implementation.

This patch was taken from a larger body of work originating from the
Archer project.  I haven't been able to determine its original author,
though I did find a commit log from Jan Kratochvil (in the Archer
repository) which suggests that the change had originally been made to
gdb.texinfo, but got inadvertently dropped when the python related
documentation was split out to python.texi.

gdb/doc/ChangeLog:

* python.texi (python command): Revise example to match
command behavior.

Automatic date update in version.in

PR24827, Linker loops forever if unterminated multi-line comment in script

YY_INPUT returns 0 on end of input, not EOF.

PR 24827
* ldlex.l (comment): Check for 0 return from input(), not EOF.

Automatic date update in version.in

gdb/riscv: Write 4-byte nop to dummy code region before inferior calls

When making inferior function calls GDB sets up a dummy code region on
the stack, and places a breakpoint within that region.  If the random
stack contents appear to be a compressed instruction then GDB  will
place a compressed breakpoint, which can cause problems if the target
doesn't support compressed instructions.

This commit prevents this issue by writing a 4-byte nop instruction to
the dummy region at the time the region is allocated.  With this nop
instruction in place, when we come to insert the breakpoint then an
uncompressed breakpoint will be used.

This is similar to other targets, for example mips.

gdb/ChangeLog:

* riscv-tdep.c (riscv_push_dummy_code): Write a 4-byte nop
instruction to the dummy code region.

gdb/testsuite/ChangeLog:

* gdb.arch/riscv-bp-infcall.c: New file.
* gdb.arch/riscv-bp-infcall.exp: New file.

x86: Pass -O0 to assembler in noextreg.d

* testsuite/gas/i386/noextreg.d: Pass -O0 to assembler.

Change ARI to mention C++11, and remove some rules

I noticed that ARI mentions "ISO C 90", but now gdb uses C++11.  This
patch updates some text to reflect this change.

I also noticed that a few rules can be removed now.  ARGSUSED doesn't
seem to be an issue any more (there's no code mentioning this and I
doubt most of us even remember this convention); PARAMS was specific
to K&R C; and __func__ is available in C++11.

gdb/ChangeLog
2019-07-19  Tom Tromey  <tromey@adacore.com>

* contrib/ari/gdb_ari.sh: Mention C++11, not ISO C 90.
(ARGSUSED, PARAMS, __func__): Remove rules.