Signed-off-by: Clifford Wolf <clifford@clifford.at>

Signed-off-by: Clifford Wolf <clifford@clifford.at>

z subset parsing V2

This fixes binutils after rebasing from acdb5f34 to 612aac65



Signed-off-by: Clifford Wolf <clifford@clifford.at>

Signed-off-by: Clifford Wolf <clifford@clifford.at>

Signed-off-by: Clifford Wolf <clifford@clifford.at>

Signed-off-by: Clifford Wolf <clifford@clifford.at>

Signed-off-by: Clifford Wolf <clifford@clifford.at>

Signed-off-by: Clifford Wolf <clifford@clifford.at>

hppa-linux-nat.c fails to build due to the gdbarch stuff not being
declared, for example:

    hppa-linux-nat.c: In function ‘void fetch_register(regcache*, int)’:
    hppa-linux-nat.c:230:7: error: ‘gdbarch_cannot_fetch_register’ was not declared in this scope
       if (gdbarch_cannot_fetch_register (gdbarch, regno))

Include gdbarch.h to fix it.

gdb/ChangeLog:

	PR gdb/25045
	* hppa-linux-nat.c: Include gdbarch.h.

An R_386_GOTOFF relocation has an addend, typically used when a
symbol can be replaced by its section symbol plus an offset.
psymval->value(object,0) is quite wrong then, fix it.

	PR 16794
	* i386.cc (Target_i386::Relocate::relocate <R_386_GOTOFF>): Don't
	ignore addend, apply using pcrel32.
	* x86_64.cc (Target_x86_64::Relocate::relocate <R_X86_64_GOTOFF64>):
	Similarly use pcrel64.

The commit 68f7d34d "[gdb/testsuite] Add KFAIL for missing support of
reverse-debugging of vmovd" rewrites a gdb_test into a gdb_test_multiple but
forgets to add the $gdb_prompt part in the regexp.

Add the missing parts of the regexps.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2019-09-27  Tom de Vries  <tdevries@suse.de>

	* gdb.reverse/step-precsave.exp: Add missing $gdb_prompt in regexps.

On my openSUSE Leap 15.1 system I run into:
...
(gdb) PASS: gdb.reverse/step-precsave.exp: turn on process record
break 76^M
Breakpoint 2 at 0x400654: file step-reverse.c, line 76.^M
(gdb) PASS: gdb.reverse/step-precsave.exp: breakpoint at end of main
continue^M
Continuing.^M
Process record does not support instruction 0xc5 at address 0x7ffff783fc70.^M
Process record: failed to record execution log.^M
^M
Program stopped.^M
0x00007ffff783fc70 in __memset_avx2_unaligned_erms () from /lib64/libc.so.6^M
(gdb) FAIL: gdb.reverse/step-precsave.exp: run to end of main
...

The problem is that the vmovd instruction is not supported in
reverse-debugging (PR record/23188).

Add a KFAIL for this PR.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2019-09-27  Tom de Vries  <tdevries@suse.de>

	PR record/23188
	* gdb.reverse/step-precsave.exp: Add kfail for PR record/23188.

This reverts commit 381beca6.

The patch hasn't been fully reviewed yet, and Pedro would like to see
more fixes.

In Fedora GDB, we carry the following patch:

  https://src.fedoraproject.org/rpms/gdb/blob/8ac06474ff1e2aa4920d14e0666b083eeaca8952/f/gdb-attach-fail-reasons-5of5.patch

Its purpose is to try to detect a specific scenario where SELinux's
'deny_ptrace' option is enabled, which prevents GDB from ptrace'ing in
order to debug the inferior (PTRACE_ATTACH and PTRACE_TRACEME will
fail with EACCES in this case).

I like the idea of improving error detection and providing more
information to the user (a simple "Permission denied" can be really
frustrating), but I don't fully agree with the way the patch was
implemented: it makes GDB link against libselinux only for the sake of
consulting the 'deny_ptrace' setting, and then prints a warning if
ptrace failed and this setting is on.

My first thought (and attempt) was to make GDB print a generic warning
when a ptrace error happened; this message would just point the user
to our documentation, where she could find more information about
possible causes for the error (and try to diagnose/fix the problem).
This proved to be too simple, and I was convinced that it is actually
a good idea to go the extra kilometre and try to pinpoint the specific
problem (or problems) preventing ptrace from working, as well as
provide useful suggestions on how the user can fix things.

Here is the patch I came up with.  It implements a new function,
'linux_ptrace_restricted_fail_reason', which does a few things to
check what's wrong with ptrace:

  - It dlopen's "libselinux.so.1" and checks if the "deny_ptrace"
    option is enabled.

  - It reads the contents of "/proc/sys/kernel/yama/ptrace_scope" and
    checks if it's different than 0.

For each of these checks, if it succeeds, the user will see a message
informing about the restriction in place, and how it can be disabled.
For example, if "deny_ptrace" is enabled, the user will see:

  # gdb /usr/bin/true
  ...
  Starting program: /usr/bin/true
  warning: Could not trace the inferior process.
  warning: ptrace: Permission denied
  The SELinux 'deny_ptrace' option is enabled and preventing GDB
  from using 'ptrace'.  You can disable it by executing (as root):

    setsebool deny_ptrace off

  If you are debugging the inferior remotely, the ptrace restriction(s) need
  to be disabled in the target system (e.g., where GDBserver is running).
  During startup program exited with code 127.
  (gdb)

In case "/proc/sys/kernel/yama/ptrace_scope" is > 0:

  # gdb /usr/bin/true
  ...
  Starting program: /usr/bin/true
  warning: Could not trace the inferior process.
  warning: ptrace: Operation not permitted
  The Linux kernel's Yama ptrace scope is in effect, which can prevent
  GDB from using 'ptrace'.  You can disable it by executing (as root):

    echo 0 > /proc/sys/kernel/yama/ptrace_scope

  If you are debugging the inferior remotely, the ptrace restriction(s) need
  to be disabled in the target system (e.g., where GDBserver is running).
  During startup program exited with code 127.
  (gdb)

If both restrictions are enabled, both messages will show up.

This works for gdbserver as well, and actually fixes a latent bug I
found: when ptrace is restricted, gdbserver would hang due to an
unchecked ptrace call:

  # gdbserver :9988 /usr/bin/true
  gdbserver: linux_ptrace_test_ret_to_nx: Cannot PTRACE_TRACEME: Operation not permitted
  gdbserver: linux_ptrace_test_ret_to_nx: status 256 is not WIFSTOPPED!
  gdbserver: linux_ptrace_test_ret_to_nx: failed to kill child pid 2668100 No such process
  [ Here you would have to issue a C-c ]

Now, you will see:

  # gdbserver :9988 /usr/bin/true
  gdbserver: linux_ptrace_test_ret_to_nx: Cannot PTRACE_TRACEME: Permission denied
  gdbserver: linux_ptrace_test_ret_to_nx: status 256 is not WIFSTOPPED!
  gdbserver: linux_ptrace_test_ret_to_nx: failed to kill child pid 2766868 No such process
  gdbserver: Could not trace the inferior process.
  gdbserver: ptrace: Permission denied
  The SELinux 'deny_ptrace' option is enabled and preventing GDB
  from using 'ptrace'.  You can disable it by executing (as root):

    setsebool deny_ptrace off

  If you are debugging the inferior remotely, the ptrace restriction(s) need
  to be disabled in the target system (e.g., where GDBserver is running).
  #

(I decided to keep all the other messages, even though I find them a
bit distracting).

If GDB can't determine the cause for the failure, it will still print
the generic error message which tells the user to check our
documentation:

  There might be restrictions preventing ptrace from working.  Please see
  the appendix "Linux kernel ptrace restrictions" in the GDB documentation
  for more details.
  If you are debugging the inferior remotely, the ptrace restriction(s) need
  to be disabled in the target system (e.g., where GDBserver is running).

This means that the patch expands our documentation and creates a new
appendix section named "Linux kernel ptrace restrictions", with
sub-sections for each possible restriction that might be in place.

Notice how, on every message, we instruct the user to "do the right
thing" if gdbserver is being used.  This is because if the user
started gdbserver *before* any ptrace restriction was in place, and
then, for some reason, one or more restrictions get enabled, then the
error message will be displayed both on gdbserver *and* on the
connected GDB.  Since the user will be piloting GDB, it's important to
explicitly say that the ptrace restrictions are enabled in the target,
where gdbserver is running.

The current list of possible restrictions is:

  - SELinux's 'deny_ptrace' option (detected).

  - YAMA's /proc/sys/kernel/yama/ptrace_scope setting (detected).

  - seccomp on Docker containers (I couldn't find how to detect).

It's important to mention that all of this is Linux-specific; as far
as I know, SELinux, YAMA and seccomp are Linux-only features.

I tested this patch locally, on my Fedora 30 machine (actually, a
Fedora Rawhide VM), but I'm not proposing a testcase for it because of
the difficulty of writing one.

WDYT?

gdb/doc/ChangeLog:
2019-09-26  Sergio Durigan Junior  <sergiodj@redhat.com>

	* gdb.texinfo (Linux kernel ptrace restrictions): New appendix
	section.

gdb/ChangeLog:
2019-09-26  Sergio Durigan Junior  <sergiodj@redhat.com>
	    Jan Kratochvil  <jan.kratochvil@redhat.com>
	    Pedro Alves  <palves@redhat.com>

	* gdbsupport/gdb-dlfcn.h (gdb_dlopen): Update comment and
	mention that the function throws an error.
	* inf-ptrace.c (default_inf_ptrace_me_fail_reason): New
	function.
	(inf_ptrace_me_fail_reason): New variable.
	(inf_ptrace_me): Update call to 'trace_start_error_with_name'.
	* inf-ptrace.h (inf_ptrace_me_fail_reason): New variable.
	* linux-nat.c (attach_proc_task_lwp_callback): Call
	'linux_ptrace_attach_fail_reason_lwp'.
	(linux_nat_target::attach): Update call to
	'linux_ptrace_attach_fail_reason'.
	(_initialize_linux_nat): Set 'inf_ptrace_me_fail_reason'.
	* nat/fork-inferior.c (trace_start_error_with_name): Add
	optional 'append' argument.
	* nat/fork-inferior.h (trace_start_error_with_name): Update
	prototype.
	* nat/linux-ptrace.c: Include "gdbsupport/gdb-dlfcn.h",
	"gdbsupport/filestuff.h" and "nat/fork-inferior.h".
	(selinux_ftype): New typedef.
	(linux_ptrace_restricted_fail_reason): New function.
	(linux_ptrace_attach_fail_reason_1): New function.
	(linux_ptrace_attach_fail_reason): Change first argument type
	from 'ptid_t' to 'pid_t'.  Call
	'linux_ptrace_attach_fail_reason_1' and
	'linux_ptrace_restricted_fail_reason'.
	(linux_ptrace_attach_fail_reason_lwp): New function.
	(linux_ptrace_me_fail_reason): New function.
	(errno_pipe): New variable.
	(linux_fork_to_function): Initialize pipe before forking.
	(linux_child_function): Deal with errno-passing from child.
	Handle ptrace error.
	(linux_check_child_ptrace_errno): New function.
	(linux_check_child_ptrace_errno): Call
	'linux_check_child_ptrace_errno'.
	* nat/linux-ptrace.h (linux_ptrace_attach_fail_reason): Update
	prototype.
	(linux_ptrace_attach_fail_reason_lwp): New prototype.
	(linux_ptrace_me_fail_reason): New prototype.
	* remote.c (extended_remote_target::attach): Handle error
	message passed by the server when attach fails.

gdb/gdbserver/ChangeLog:
2019-09-26  Sergio Durigan Junior  <sergiodj@redhat.com>
	    Pedro Alves  <palves@redhat.com>

	* linux-low.c (linux_ptrace_fun): Call
	'linux_ptrace_me_fail_reason'.
	(attach_proc_task_lwp_callback): Call
	'linux_ptrace_attach_fail_reason_lwp'.
	(linux_attach): Call 'linux_ptrace_attach_fail_reason'.
	* server.c (handle_v_attach): Use try..catch when calling
	'attach_inferior', and send an error message to the client
	when needed.
	* thread-db.c (attach_thread): Call
	'linux_ptrace_attach_fail_reason_lwp'.

gdb/ChangeLog:

2019-09-26  Christian Biesinger  <cbiesinger@google.com>

	* blockframe.c (find_pc_partial_function): Change return type to bool.
	* elfread.c (elf_gnu_ifunc_resolve_name): Likewise.
	* minsyms.c (in_gnu_ifunc_stub): Likewise.
	(stub_gnu_ifunc_resolve_name): Likewise.
	* symtab.c (compare_filenames_for_search): Likewise.
	(compare_glob_filenames_for_search): Likewise.
	(matching_obj_sections): Likewise.
	(symbol_matches_domain): Likewise.
	(find_line_symtab): Change out param EXACT_MATCH to bool *.
	(find_line_pc): Change return type to bool.
	(find_line_pc_range): Likewise.
	(producer_is_realview): Likewise.
	* symtab.h (symbol_matches_domain): Likewise.
	(find_pc_partial_function): Likewise.
	(find_pc_line_pc_range): Likewise.
	(in_gnu_ifunc_stub): Likewise.
	(struct gnu_ifunc_fns) <gnu_ifunc_resolve_name>: Likewise.
	(find_line_pc): Likewise.
	(find_line_pc_range): Likewise.
	(matching_obj_sections): Likewise.
	(find_line_symtab): Change out parameter to bool.
	(producer_is_realview): Change return type to bool.
	(compare_filenames_for_search): Likewise.
	(compare_glob_filenames_for_search): Likewise.

I noticed that gdb_usleep is unused, so this patch removes it.

gdb/ChangeLog
2019-09-26  Tom Tromey  <tom@tromey.com>

	* Makefile.in (COMMON_SFILES): Remove gdb_usleep.c.
	(HFILES_NO_SRCDIR): Remove gdb_usleep.h.
	* gdb_usleep.h: Remove.
	* gdb_usleep.c: Remove.
	* utils.c: Don't include gdb_usleep.h.

dwarf2read.c will create stub types for Ada "Taft Amendment" types.
These stub types can currently be exposed to Python code, where they
show up as TYPE_CODE_VOID types (but that, mysteriously, can sometimes
be used in other ways).

While it's possible to work with such types by using strip_typedefs,
this seemed unpleasant to me.  This patch takes another approach
instead, which is to try not to expose stub types to Python users.

gdb/ChangeLog
2019-09-26  Tom Tromey  <tromey@adacore.com>

	* python/py-type.c (type_to_type_object): Call check_typedef
	for stub types.

gdb/testsuite/ChangeLog
2019-09-26  Tom Tromey  <tromey@adacore.com>

	* gdb.ada/py_taft.exp: New file.
	* gdb.ada/py_taft/main.adb: New file.
	* gdb.ada/py_taft/pkg.adb: New file.
	* gdb.ada/py_taft/pkg.ads: New file.

initialize_utils only registers some commands, so it isn't necessary
to run it at any particular time during startup.  This patch removes
it and merges its contents into _initialize_utils.

Tested by the buildbot.

gdb/ChangeLog
2019-09-26  Tom Tromey  <tom@tromey.com>

	* utils.h (initialize_utils): Don't declare.
	* top.c (gdb_init): Don't call initialize_utils.
	* utils.c (initialize_utils): Remove.  Move contents...
	(_initialize_utils): ... here.

bfd/
	PR 24262
	* Makefile.am (AM_CPPFLAGS): Add -DLIBDIR.
	* plugin.c (load_plugin): Search both ${libdir}/bfd-plugins and
	${bindir}/../lib/bfd-plugins if different.
	* Makefile.in: Regenerate.
ld/
	PR 24262
	* ld.texi (-plugin): Revert 2019-03-15 change.

I noticed that make_hex_string does essentially the same thing as
bin2hex, and furthermore is only called in a single spot.  This patch
removes make_hex_string.

Tested by the builtbot.

gdb/ChangeLog
2019-09-25  Tom Tromey  <tom@tromey.com>

	* python/py-objfile.c (objfpy_get_build_id): Use bin2hex.
	* utils.h (make_hex_string): Don't declare.
	* utils.c (make_hex_string): Remove.

I was looking at the implementation of this script keyword today and
couldn't remember why we do what we do in get_init_priority, because
the comments explain how the init_priority is encoded but don't say
why it is necessary to extract the priority and sort on that.  So
after figuring out why (again), I wrote some more comments.

Then I simplified get_init_priority a little, adding some sanity
checking on the strtoul result.  This actually makes get_init_priority
support sorting by numerical suffix more generally, but I figure this
feature would be better as a new keyword (without the .ctors/.dtors
special case), so haven't documented the extension.

	* ld.texi (SORT_BY_ALIGNMENT): Reword slightly.
	(SORT_BY_INIT_PRIORITY): Elucidate.
	* ldlang.c: Include limits.h.
	(get_init_priority): Comment.  Change param to a section,
	return an int.  Sanity check priority digits.  Support sorting
	more sections with trailing digits.  Return -1 on error.
	(compare_section): Adjust.

 * emultempl/avrelf.em (_before_allocation): Silence build warning
 using clang.

On my openSUSE Leap 15.1 x86_64 Skylake system with the default (4.12) kernel,
I run into:
...
FAIL: gdb.base/gcore.exp: corefile restored all registers
...

The problem is that there's a difference in the mxcsr register value before
and after the gcore command:
...
- mxcsr          0x0                 [ ]
+ mxcsr          0x400440            [ DAZ OM ]
...

This can be traced back to amd64_linux_nat_target::fetch_registers, where
xstateregs is partially initialized by the ptrace call:
...
          char xstateregs[X86_XSTATE_MAX_SIZE];
          struct iovec iov;

          amd64_collect_xsave (regcache, -1, xstateregs, 0);
          iov.iov_base = xstateregs;
          iov.iov_len = sizeof (xstateregs);
          if (ptrace (PTRACE_GETREGSET, tid,
                      (unsigned int) NT_X86_XSTATE, (long) &iov) < 0)
            perror_with_name (_("Couldn't get extended state status"));

          amd64_supply_xsave (regcache, -1, xstateregs);
...
after which amd64_supply_xsave is called.

The amd64_supply_xsave call is supposed to only use initialized parts of
xstateregs, but due to a kernel bug on intel skylake (fixed from 4.14 onwards
by commit 0852b374173b "x86/fpu: Add FPU state copying quirk to handle XRSTOR
failure on Intel Skylake CPUs") it can happen that the mxcsr part of
xstateregs is not initialized, while amd64_supply_xsave expects it to be
initialized, which explains the FAIL mentioned above.

Fix the undetermined behaviour by initializing xstateregs before calling
ptrace, which makes sure we get a 0x0 for mxcsr when this kernel bug occurs,
and which also happens to fix the FAIL.

Furthermore, add an xfail for this FAIL which triggers the same kernel bug:
...
FAIL: gdb.arch/amd64-init-x87-values.exp: check_setting_mxcsr_before_enable: \
  check new value of MXCSR is still in place
...

Both FAILs pass when using a 5.3 kernel instead on the system mentioned above.

Tested on x86_64-linux.

gdb/ChangeLog:

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

	PR gdb/23815
	* amd64-linux-nat.c (amd64_linux_nat_target::fetch_registers):
	Initialize xstateregs before ptrace PTRACE_GETREGSET call.

gdb/testsuite/ChangeLog:

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

	PR gdb/24598
	* gdb.arch/amd64-init-x87-values.exp: Add xfail.

The fix for PR12848 introduced an off by one error in the mask, this corrected
the negative overflows but not the positive overflows.  As a result the
conditional branch instructions accepted a too wide positive immediate which
resulted in it corrupting the instruction during encoding.

The relocation I believe has been incorrectly named, to be consistent with the
other relocations it should have been named BRANCH21 which is why the masks for
it are confusing.

I've replaced the masks with a function out_of_range_p which should make it
harder to make such mistakes.

The mask for BL/BLX on Armv6t+ is also wrong, the extended range is 25-bits
and so the mask should be checking for 24-bits for positive overflow.

gas/ChangeLog:

	PR gas/24991
	* config/tc-arm.c (out_of_range_p): New.
	(md_apply_fix): Use it in BFD_RELOC_THUMB_PCREL_BRANCH9,
	BFD_RELOC_THUMB_PCREL_BRANCH12, BFD_RELOC_THUMB_PCREL_BRANCH20,
	BFD_RELOC_THUMB_PCREL_BRANCH23, BFD_RELOC_THUMB_PCREL_BRANCH25
	* testsuite/gas/arm/pr24991.d: New test.
	* testsuite/gas/arm/pr24991.l: New test.
	* testsuite/gas/arm/pr24991.s: New test.

Using saved_format breaks when nm is presented with multiple object
files, some 32-bit and some 64-bit.

	PR 25031
	* nm.c (print_format_string): New.
	(get_print_format): Delete saved_format.  Move earlier.
	(set_print_width): Call get_print_format.
	(print_value): Use print_format_string.