Add support for CPUID PREFETCHWT1

Latest AVX512 spec
http://download-software.intel.com/sites/default/files/managed/50/1a/319433-018.pdf
Has CPUID PREFETCHWT1 for prefetchwt1 instruction, which we list as AVX512PF.
This patch introduces CPUID PREFETCHWT1.

gas/

        * config/tc-i386.c (cpu_arch): Add .prefetchwt1.
        * doc/c-i386.texi: Document .prefetchwt1/prefetchwt1.

opcodes/

        * i386-gen.c (cpu_flag_init): Add CPU_PREFETCHWT1_FLAGS/
        (cpu_flags): Add CpuPREFETCHWT1.
        * i386-init.h: Regenerate.
        * i386-opc.h (CpuPREFETCHWT1): New.
        (i386_cpu_flags): Add cpuprefetchwt1.
        * i386-opc.tbl: Cahnge CPU of prefetchwt1 from CpuAVX512PF to CpuPREFETCHWT1.
        * i386-tbl.h: Regenerate.

gas/testsuite

        * gas/i386/avx512pf-intel.d: Remove prefetchwt1.
        * gas/i386/avx512pf.s: Ditto.
        * gas/i386/avx512pf.d: Ditto.
        * gas/i386/x86-64-avx512pf-intel.d: Ditto.
        * gas/i386/x86-64-avx512pf.s: Ditto.
        * gas/i386/x86-64-avx512pf.d: Ditto.
        * gas/i386/prefetchwt1-intel.d: New file.
        * gas/i386/prefetchwt1.s: Ditto.
        * gas/i386/prefetchwt1.d: Ditto.
        * gas/i386/x86-64-prefetchwt1-intel.d: Ditto.
        * gas/i386/x86-64-prefetchwt1.s: Ditto.
        * gas/i386/x86-64-prefetchwt1.d: Ditto.
Fix crash on process name "(sd-pam)" (PR 16594).

info os processes -fsanitize=address error
https://sourceware.org/bugzilla/show_bug.cgi?id=16594

info os processes
=================================================================
==5795== ERROR: AddressSanitizer: heap-use-after-free on address
0x600600214974 at pc 0x757a92 bp 0x7fff95dd9f00 sp 0x7fff95dd9ef0
READ of size 4 at 0x600600214974 thread T0
    #0 0x757a91 in get_cores_used_by_process (.../gdb/gdb+0x757a91)

At least Fedora 20 has process(es):
 6678 ?        Ss     0:00 /usr/lib/systemd/systemd --user
 6680 ?        S      0:00  \_ (sd-pam)

and GDB "info os processes" crashes on it as /proc/6680/stat contains:

6680 ((sd-pam)) S 6678 6678 6678 0 -1 1077961024 33 0 0 0 0 0 0 0 20 0 1 0 18568 73768960 120 18446744073709551615 1 1
0 0 0 0 0 4096 0 18446744073709551615 0 0 17 6 0 0 0 0 0 0 0 0 0 0 0 0 0

and GDB fails to find the proper end of the process name "((sd-pam))".
Therefore it reads core number off-by-one (it reads 17 instead of 6) and
overruns the array.

(1) Make the process name parsing more foolproof.

(2) Do not trust the parsed number from /proc/PID/stat and verify it against
    the array size.

I noticed that 'ps' gets this right, so I've peeked at its
sources, and it just looks for the first ')' starting at
the end.

https://gitorious.org/procps/procps/source/dc072aced7250fed9b01fb05f0d672678752a63e:proc/readproc.c

Look for stat2proc.

Given ps does that, I believe the kernel won't ever be changed
in a way that would break it.  So it sounds like could do strrchr
from the end of stat just as well without worry, which is simpler.

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

	PR gdb/16594
	* common/linux-osdata.c (linux_common_core_of_thread): Find the end of
	process name.
	(get_cores_used_by_process): New parameter num_cores, use it.
	(linux_xfer_osdata_processes): Pass num_cores to it.
	* linux-tdep.c (linux_info_proc, linux_fill_prpsinfo): Find the end of
	process name.

Message-ID: <20140217212826.GA15080@host2.jankratochvil.net>