binutils_os216

Fork

Merge remote-tracking branch 'origin/users/hjl/linux/master' into users/hjl/linux/applied

Revert "Add "-z textonly" option to ELF linker"

This reverts commit e87d0965bb97fa186749c8386822cdeb9752df38.

"-z separate-code" has been checked into master branch.

Merge remote-tracking branch 'origin/master' into users/hjl/linux/master

Optimize the performance of the group_setup function.

When processing a section that is a member of a group, the group
that contains it is looked up using a linear search. The resulting
O(n^2) complexity causes significant performance issues when
dealing with object files with very many groups.

By remembering the index of the last found group and restarting
the next search from that index, the search instead becomes O(n)
in common cases.

* elf.c (setup_group): Optimize search for group by remembering
last found group and restarting search at that index.
* elf-bfd.h (struct elf_obj_tdata): Add group_search_offset field.

Fix compile time warning building aout targeted architectures.

Occasionally I build an out-of-tree a.out target (m68k-amigaos). After
a system upgrade which included a newer compiler (clang 4) the build
produces warnings like this:

warning: macro expansion producing 'defined' has undefined behavior
[-Wexpansion-to-defined]

This is caused by the macro gas/config/aout_gnu.h:USE_EXTENDED_RELOC.
Since it is in a header file, the warning triggers for several files.
I am unsure what solution is preferable, thus I am suggesting two
patches:

a) keep the offending macro but define it explicitly to 0 and 1
b) replace the macro usage with its value where it is used.

Either patch removes the warning for clang. I did not check with a
recent GCC.

* gas/config/aout_gnu.h (USE_EXTENDED_RELOC): Explicitly
define to 0 and 1. Remove a dangling reference to "AMD 29000"
in a comment.

pr22374 function pointer initialization

When I added this test I said I'd look at fixing more targets.
That hasn't happened yet, so xfail to tidy results.

* testsuite/ld-elf/elf.exp: xfail "pr22374 function pointer
initialization" for currently failing targets.

Fix override of common symbols for a.out

The default should be bfd_link_common_skip_none, as in the original
patch at https://sourceware.org/ml/binutils/2002-07/msg00717.html

* aoutx.h (aout_link_check_ar_symbols): Remove default and handle
bfd_link_common_skip_none in switch.

Fixes for "Ignore dynamic references on forced local symbols"

PowerPC64 has its own mark_dynamic_ref, which needs the same change as
made by d664fd41e1 to the generic ELF version. Some other targets
discard more than just .data, so allow for that too in expected ld
messages.

bfd/
PR ld/22649
* elf64-ppc.c (ppc64_elf_gc_mark_dynamic_ref): Ignore dynamic
references on forced local symbols.
ld/
PR ld/22649
* testsuite/ld-elf/pr22649.msg: Allow other messages.
* testsuite/ld-elf/shared.exp: Check that --gc-sections is
supported before running ld/22649 tests.

_bfd_mips_elf_final_link: Notify user about wrong .reginfo size

One of assertions in _bfd_mips_elf_final_link could be triggered by
a combination of input files and a linker script. This happens when
either the input doesn't contain .reginfo section or when this section
is oversized. This patch replaces the assertion with a more useful
error message.

* elfxx-mips.c (_bfd_mips_elf_final_link): Notify user when
.reginfo section has wrong size.

Add -z undefs option to the ELF linker.

Currently we have no obvious way to revert the action of the "-z defs"
command line option. The "--unresolved-symbols=ignore-in-object-files"
does pretty much what is needed, but it is non-obvious and it also
touches the setting for reporting unresolved symbol references from
shared libraries. So I am proposing adding a "-z undefs" option to be
the inverse of "-z defs". (I thought that "-z nodefs" might be
confusing since it implies banning all definitions, rather than
allowing them).

In addition the description of the "-z defs" option in the linker
documentation is misleading in one place, where it says:

'defs'
Disallows undefined symbols in object files. Undefined
symbols in shared libraries are still allowed.

whereas later on it gets it right:

'-z defs'
Report unresolved symbol references from regular object files.
This is done even if the linker is creating a non-symbolic shared
library. The switch '--[no-]allow-shlib-undefined' controls the
behaviour for reporting unresolved references found in shared
libraries being linked in.

* emultempl/elf32.em (_handle_option): Add support for "-z undefs"
as the opposite of "-z defs".
* ld.texinfo: Document the new option. Update the description of
the -z defs option to make it clear that it does generate an error
if an undefined symbol reference is found in an object file whilst
creating a shared library.
* NEWS: Document this new feature.

ld: Replace "-z textonly" with "-z separate-code"

Although they aren't passed to linker, we should get it right.

* testsuite/ld-elf/pr22393-2a.rd: Replace "-z textonly" with
"-z separate-code".
* testsuite/ld-elf/pr22393-2b.rd: Likewise.
* testsuite/ld-x86-64/pr22393-3a.rd: Likewise.
* testsuite/ld-x86-64/pr22393-3b.rd: Likewise.

x86-64: Add tests for -z separate-code -z max-page-size=0x1000

PR ld/22393
* testsuite/ld-x86-64/pr22393-3a.c: New file.
* testsuite/ld-x86-64/pr22393-3a.rd: Likewise.
* testsuite/ld-x86-64/pr22393-3b.c: Likewise.
* testsuite/ld-x86-64/pr22393-3b.rd: Likewise.
* testsuite/ld-x86-64/x86-64.exp: Run tests for -z separate-code
-z max-page-size=0x1000.

ld: Add tests for -z separate-code and -z noseparate-code

Verify that -z separate-code works and -z noseparate-code doesn't disable
-z relro.

PR ld/22393
* testsuite/ld-elf/pr16322.d: Add -z noseparate-code.
* testsuite/ld-elf/pr22393-1.s: New file.
* testsuite/ld-elf/pr22393-1a.d: Likewise.
* testsuite/ld-elf/pr22393-1b.d: Likewise.
* testsuite/ld-elf/pr22393-1c.d: Likewise.
* testsuite/ld-elf/pr22393-1d.d: Likewise.
* testsuite/ld-elf/pr22393-1e.d: Likewise.
* testsuite/ld-elf/pr22393-1f.d: Likewise.
* testsuite/ld-elf/pr22393-2a.c: Likewise.
* testsuite/ld-elf/pr22393-2a.rd: Likewise.
* testsuite/ld-elf/pr22393-2b.c: Likewise.
* testsuite/ld-elf/pr22393-2b.rd: Likewise.
* testsuite/ld-elf/shared.exp: Run tests for -z separate-code.

ld: Create a new LOAD segment for separate code segment

When generating separate code LOAD segment, create a new LOAD segment
if the previous section contains text and the current section doesn't
or vice versa:

Elf file type is DYN (Shared object file)
Entry point 0x200020
There are 7 program headers, starting at offset 52

Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000000 0x00000000 0x00000000 0x00200 0x00200 R 0x200000
LOAD 0x200000 0x00200000 0x00200000 0x00036 0x00036 R E 0x200000
LOAD 0x400000 0x00400000 0x00400000 0x00064 0x00064 R 0x200000
LOAD 0x400f80 0x00600f80 0x00600f80 0x000a0 0x000a0 RW 0x200000
DYNAMIC 0x400f80 0x00600f80 0x00600f80 0x00080 0x00080 RW 0x4
GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x10
GNU_RELRO 0x400f80 0x00600f80 0x00600f80 0x00080 0x00080 R 0x1

Section to Segment mapping:
Segment Sections...
00 .hash .gnu.hash .dynsym .dynstr .rela.plt
01 .plt .text
02 .rodata .eh_frame
03 .dynamic .got.plt
04 .dynamic
05
06 .dynamic

to prevent fetching or executing data in code pages as instructions.

Also don't put a writable section in a read-only segment if there is a
RELRO segment.

Since code segment is aligned and padded to the maximum page size on
disk, the minimum file size is bigger than the maximum page size which
is 2MB (0x200000):

-rwxr-xr-x 1 hjl hjl 4201932 Jan 10 10:41 libfoo.so

"-z max-page-size=0x1000" can be used to reduce the maximum page size to
4KB (0x1000):

-rwxr-xr-x 1 hjl hjl 15820 Jan 10 10:44 libfoo.so

PR ld/22393
* elf.c (_bfd_elf_map_sections_to_segments): When generating
separate code and read-only data LOAD segments, create a new
LOAD segment if the previous section contains text and the
current section doesn't or vice versa. Don't put a writable
section in a read-only segment if there is a RELRO segment.

ld: Add "-z separate-code" option to ELF linker

The new "-z separate-code" option will generate separate code LOAD
segment which must be in wholly disjoint pages from any other data.

include/

PR ld/22393
* bfdlink.h (bfd_link_info): Add separate_code.

ld/

PR ld/22393
* NEWS: Mention "-z separate-code".
* emultempl/elf32.em (gld${EMULATION_NAME}_get_script): Get
builtin linker scripts and return linker scripts from disk for
"-z separate-code".
(gld${EMULATION_NAME}_handle_option): Handle "-z separate-code"
and "-z noseparate-code".
* genscripts.sh: Generate linker scripts for "-z separate-code".
(LD_FLAG): Set to *textonly for "-z separate-code".
* ld.texinfo: Document "-z separate-code".
* lexsup.c (elf_shlib_list_options): Add linker help messsages
for "-z separate-code" and "-z noseparate-code".
* scripttempl/elf.sc (SEPARATE_TEXT): New
(TEXT_SEGMENT_ALIGN): Likewise.
Use ${TEXT_SEGMENT_ALIGN} to align and pad text segment to
${MAXPAGESIZE}.

gdb_compile_shlib: Only consider shlib= options when building executables

Trying to use gdb_compile_shlib with the shlib= option to build a shared
library that depends on another shared library does not work as of
today. See:

https://sourceware.org/ml/gdb-patches/2017-10/msg00733.html

The problem is that building the lib is done in two steps, compilation
(.c -> .o) and linking (.o -> .so) and the shlib= options are passed to
both steps. When compiling the object file (.o), it results in gcc
complaining:

gcc: warning: .../solib-vanish-lib2.so: linker input file unused because linking not done

The first solution I came up with was to filter the options inside
gdb_compile_shlib to remove the shlib= options from the options we pass
when compiling the .o file.

I then thought it would be simpler to ignore the shlib= options in
gdb_compile when not building an executable (the executable category
includes the shared libraries). For other compilation types (object
file, preprocess and generate assembly), it doesn't make sense to add
shared libraries to the source file list.

Regtested on the buildbot.

gdb/testsuite/ChangeLog:

* lib/gdb.exp (gdb_compile): Ignore shlib= and shlib_load
options when not creating an executable.

Automatic date update in version.in

Ignore dynamic references on forced local symbols

We should ignore dynamic references on forced local symbols during
garbage collection since they can never be referenced dynamically.

bfd/

PR ld/22649
* elflink.c (bfd_elf_gc_mark_dynamic_ref_symbol): Ignore dynamic
references on forced local symbols.

ld/

PR ld/22649
* testsuite/ld-elf/pr22649-1.s: New file.
* testsuite/ld-elf/pr22649-2a.s: Likewise.
* testsuite/ld-elf/pr22649-2b.s: Likewise.
* testsuite/ld-elf/pr22649.msg: Likewise.
* testsuite/ld-elf/shared.exp: Run ld/22649 tests.

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.

ld: Keep PREINIT_ARRAY/INIT_ARRAY/FINI_ARRAY sections for -r --gc-sections

We must keep all PREINIT_ARRAY, INIT_ARRAY as well as FINI_ARRAY sections
for ld -r --gc-sections.

bfd/

PR ld/22677
* elflink.c (bfd_elf_gc_sections): Keep all PREINIT_ARRAY,
INIT_ARRAY as well as FINI_ARRAY sections for ld -r --gc-sections.

ld/

PR ld/22677
* scripttempl/elf.sc (PREINIT_ARRAY): New.
Don't add .preinit_array for ld -r.
* testsuite/ld-elf/pr22677.d: New file.
* testsuite/ld-elf/pr22677.s: Likewise.

ld: Remove unused expression state

Previous commit removed all uses of the defsym field within the linker
expression union. This commit cleans up the now redundant state.

ld/ChangeLog:

* ldexp.h (union etree_union): Remove defsym field.
* ldexp.c (exp_assop): Remove defsym parameter, and use of defsym
parameter.
(exp_assign): Remove passing of defsym parameter.
(exp_defsym): Likewise.
(exp_provide): Likewise.

ld: Fix issue where PROVIDE overrides defined symbol

In a linker script, a sequence like this:

foo = ADDR (.some_section);
bar = foo;
PROVIDE (foo = 0);

will result in 'bar = ADDR (.some_section)' and 'foo = 0', which seems
like incorrect behaviour, foo is clearly defined elsewhere, and so the
PROVIDE should not trigger.

The problem is that an expression like this:

foo = ADDR (.some_section);

can't be evaluated until a late phase of the linker, due to the need
for the section '.some_section' to have been placed, then the PROVIDE
was being marked as being used during an earlier phase. At the end of
the link, both lines:

foo = ADDR (.some_section);
PROVIDE (foo = 0);

are active, and this causes the final value of 'foo' to be 0.

The solution proposed in this commit is that, during earlier phases of
the linker, when we see the expression 'foo = ADDR (.some_section);',
instead of ignoring the expression, we create a "fake" definition of
'foo'. The existence of this "fake" definition prevents the PROVIDE
from being marked used, and during the final phase the real definition
of 'foo' will replace the "fake" definition.

The new test provide-6 covers the exact case described above. The
provide-7 test is similar to the above, but using constant
expressions, this was never broken, but is added here to increase
coverage.

The provide-8 case also didn't fail before this commit, but I did
manage to break this case during development of this patch. This case
was only covered by a mmix test before, so I've added this here to
increase coverage.

ld/ChangeLog:

* ldexp.c (exp_fold_tree_1): Rework condition underwhich provide
nodes are ignored in the tree walk, and move the location at which
we change provide nodes into provided nodes.
(exp_init_os): Add etree_provided.
* testsuite/ld-scripts/provide-6.d: New file.
* testsuite/ld-scripts/provide-6.t: New file.
* testsuite/ld-scripts/provide-7.d: New file.
* testsuite/ld-scripts/provide-7.t: New file.
* testsuite/ld-scripts/provide-8.d: New file.
* testsuite/ld-scripts/provide-8.t: New file.

ld: Find and run some tests using a wildcard pattern

Find the ld-script/provide-*.d tests using a wildcard, then run them in
a loop. This will make it easier to add more tests in the future. Some
associated clean up is required.

ld/ChangeLog:

* testsuite/ld-scripts/provide-3.d: Add xfail directive.
* testsuite/ld-scripts/provide-4.d: Use new map file name.
* testsuite/ld-scripts/provide-5.d: Use new map file name.
* testsuite/ld-scripts/provide-4-map.d: Renamed to...
* testsuite/ld-scripts/provide-4.map: ...this.
* testsuite/ld-scripts/provide-5-map.d: Renamed to...
* testsuite/ld-scripts/provide-5.map: ...this.
* testsuite/ld-scripts/provide.exp: Move xfail into provide-3.d
file, and run tests in a loop.

ld: In map file use '=' in PROVIDE statements

Currently when recording a PROVIDE statement in a linker map file we
display something like:

PROVIDE (SYMBOL, VALUE)

However, in a linker script we write these statements like this:

PROVIDE (SYMBOL = VALUE);

This commit changes the output in the map file to be closer to linker
script format, the map file now contains:

PROVIDE (SYMBOL = VALUE)

The ';' is still missing from the end, but map files are not intended
to be valid linker script input, so adding the ';' just seems like
clutter.

ld/ChangeLog:

* ldexp.c (exp_print_tree): Use '=' instead of ',' when printing
PROVIDE statements.
* testsuite/ld-scripts/provide-4.map: Update expected output.
* testsuite/ld-scripts/provide-5.map: Likewise.

Fix the order of SHLIB_RODATA_ADDR in elf.sc

elf.sc has

if test -n "${RODATA_ADDR}"; then
RODATA_ADDR="\
SEGMENT_START(\"rodata-segment\", ${RODATA_ADDR}) + SIZEOF_HEADERS"
else
RODATA_ADDR="ALIGN(${SEGMENT_SIZE}) + (. & (${MAXPAGESIZE} - 1))"
^^^^^^^^^^ Set RODATA_ADDR
RODATA_ADDR="SEGMENT_START(\"rodata-segment\", ${RODATA_ADDR})"
^^^^^^^^^^ Set RODATA_ADDR with ${RODATA_ADDR}
fi
if test -n "${SHLIB_RODATA_ADDR}"; then
SHLIB_RODATA_ADDR="\
SEGMENT_START(\"rodata-segment\", ${SHLIB_RODATA_ADDR}) + SIZEOF_HEADERS"
else
SHLIB_RODATA_ADDR="SEGMENT_START(\"rodata-segment\", ${SHLIB_RODATA_ADDR})"
^^^^^^^^^^ Set SHLIB_RODATA_ADDR
SHLIB_RODATA_ADDR="ALIGN(${SEGMENT_SIZE}) + (. & (${MAXPAGESIZE} - 1))"
^^^^^^^^^^ Override SHLIB_RODATA_ADDR
fi

The order should be:

if test -n "${SHLIB_RODATA_ADDR}"; then
SHLIB_RODATA_ADDR="\
SEGMENT_START(\"rodata-segment\", ${SHLIB_RODATA_ADDR}) + SIZEOF_HEADERS"
else
SHLIB_RODATA_ADDR="ALIGN(${SEGMENT_SIZE}) + (. & (${MAXPAGESIZE} - 1))"
SHLIB_RODATA_ADDR="SEGMENT_START(\"rodata-segment\", ${SHLIB_RODATA_ADDR})"
fi

PR ld/22696
* scripttempl/elf.sc: Fix the order of SHLIB_RODATA_ADDR.

Fix gdb.texinfo for old makeinfo

With old makeinfo (version 4.13) the changes introduced in

commit 2d97a5d9d33aea87c3bd02fd1fa417f5d4e1fa05
Author: John Baldwin <jhb@FreeBSD.org>

Document support for 'info proc' on FreeBSD.

fail to build.

gdb/doc/ChangeLog:

* gdb.texinfo (pwd): Fix whitespace.

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.

Remove VL variants for 4FMAPS and 4VNNIW insns.

AVX512_4FMAPS and AVX512_4VNNIW insns are marked as having AVX512VL
variants. That is wrong as SDM doesn't define such instructions. The
patch removes these VL variants.

gas/
* testsuite/gas/i386/avx512_4fmaps-warn.l: Change xmm to zmm.
* testsuite/gas/i386/avx512_4fmaps-warn.s: Likewise.
* testsuite/gas/i386/avx512_4fmaps_vl-intel.d: Delete.
* testsuite/gas/i386/avx512_4fmaps_vl-warn.l: Likewise.
* testsuite/gas/i386/avx512_4fmaps_vl-warn.s: Likewise.
* testsuite/gas/i386/avx512_4fmaps_vl.d: Likewise.
* testsuite/gas/i386/avx512_4fmaps_vl.s: Likewise.
* testsuite/gas/i386/avx512_4vnniw_vl-intel.d: Likewise.
* testsuite/gas/i386/avx512_4vnniw_vl.d: Likewise.
* testsuite/gas/i386/avx512_4vnniw_vl.s: Likewise.
* testsuite/gas/i386/i386.exp: Delete _vl tests for 4fmaps an
4vnniw tests.
* testsuite/gas/i386/x86-64-avx512_4fmaps_vl-intel.d: Delete.
* testsuite/gas/i386/x86-64-avx512_4fmaps_vl-warn.l: Likewise.
* testsuite/gas/i386/x86-64-avx512_4fmaps_vl-warn.s: Likewise.
* testsuite/gas/i386/x86-64-avx512_4fmaps_vl.d: Likewise.
* testsuite/gas/i386/x86-64-avx512_4fmaps_vl.s: Likewise.
* testsuite/gas/i386/x86-64-avx512_4vnniw_vl-intel.d: Likewise.
* testsuite/gas/i386/x86-64-avx512_4vnniw_vl.d: Likewise.
* testsuite/gas/i386/x86-64-avx512_4vnniw_vl.s: Likewise.

opcodes/
* i386-opc.tbl: Remove VL variants for 4FMAPS and 4VNNIW
insns.
* i386-tbl.h: Regenerate.

Automatic date update in version.in

gas tc-arm.c warning fix

* config/tc-arm.c (aeabi_set_public_attributes): Avoid false
positive "‘profile’ may be used uninitialized".