Tom de Vries [Mon, 13 Jul 2020 12:14:47 +0000 (14:14 +0200)]
[gdb/testsuite] Handle missing gold linker in gdb.base/morestack.exp
When running test-case gdb.base/morestack.exp without the gold linker
installed, we run into:
...
Running src/gdb/testsuite/gdb.base/morestack.exp ...
gdb compile failed, collect2: fatal error: cannot find 'ld'
compilation terminated.
FAIL: gdb.base/morestack.exp: continue
=== gdb Summary ===
nr of expected passes 1
nr of unexpected failures 1
nr of untested testcases 1
...
The test-case needs the gold linker to run correctly (as explained in commit
b8d38ee425 "testsuite: Fix false FAIL for gdb.base/morestack.exp"), but
only prefers it, and doesn't require it.
Fix this by requiring the gold linker in the test-case. Furthermore, silence
the compilation error by introducing a caching proc have_fuse_ld_gold and
using it in this and other test-cases that use -fuse-ld=gold.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-07-13 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (have_fuse_ld_gold): New caching proc.
* gdb.base/gcore-tls-pie.exp: Use have_fuse_ld_gold.
* gdb.base/gold-gdb-index.exp: Same.
* gdb.base/morestack.exp: Same.
Simon Marchi [Mon, 13 Jul 2020 03:05:08 +0000 (23:05 -0400)]
gdb: make type::bounds work for array and string types
Getting the bounds of an array (or string) type is a common operation,
and is currently done through its index type:
my_array_type->index_type ()->bounds ()
I think it would make sense to let the `type::bounds` methods work for
arrays and strings, as a shorthand for this. It's natural that when
asking for the bounds of an array, we get the bounds of the range type
used as its index type. In a way, it's equivalent as the now-removed
TYPE_ARRAY_{LOWER,UPPER}_BOUND_IS_UNDEFINED and
TYPE_ARRAY_{LOWER,UPPER}_BOUND_VALUE, except it returns the
`range_bounds` object. The caller is then responsible for getting the
property it needs in it.
I updated all the spots I could find that could take advantage of this.
Note that this also makes `type::bit_stride` work on array types, since
`type::bit_stride` uses `type::bounds`. `my_array_type->bit_stride ()`
now returns the bit stride of the array's index type. So some spots
are also changed to take advantage of this.
gdb/ChangeLog:
* gdbtypes.h (struct type) <bounds>: Handle array and string
types.
* ada-lang.c (assign_aggregate): Use type::bounds on
array/string type.
* c-typeprint.c (c_type_print_varspec_suffix): Likewise.
* c-varobj.c (c_number_of_children): Likewise.
(c_describe_child): Likewise.
* eval.c (evaluate_subexp_for_sizeof): Likewise.
* f-typeprint.c (f_type_print_varspec_suffix): Likewise.
(f_type_print_base): Likewise.
* f-valprint.c (f77_array_offset_tbl): Likewise.
(f77_get_upperbound): Likewise.
(f77_print_array_1): Likewise.
* guile/scm-type.c (gdbscm_type_range): Likewise.
* m2-typeprint.c (m2_array): Likewise.
(m2_is_long_set_of_type): Likewise.
* m2-valprint.c (get_long_set_bounds): Likewise.
* p-typeprint.c (pascal_type_print_varspec_prefix): Likewise.
* python/py-type.c (typy_range): Likewise.
* rust-lang.c (rust_internal_print_type): Likewise.
* type-stack.c (type_stack::follow_types): Likewise.
* valarith.c (value_subscripted_rvalue): Likewise.
* valops.c (value_cast): Likewise.
Change-Id: I5c0c08930bffe42fd69cb4bfcece28944dd88d1f
Simon Marchi [Mon, 13 Jul 2020 02:58:53 +0000 (22:58 -0400)]
gdb: remove TYPE_ARRAY_BIT_STRIDE
Remove it and update all callers to use the equivalent accessor methods.
A subsequent patch will make type::bit_stride work for array types
(effectively replacing this macro), but I wanted to keep this patch a
simple mechanical change.
gdb/ChangeLog:
* gdbtypes.c (TYPE_ARRAY_BIT_STRIDE): Remove. Update all
callers to use the equivalent accessor methods.
Change-Id: I09e14bd45075f98567adce8a0b93edea7722f812
Simon Marchi [Mon, 13 Jul 2020 02:58:53 +0000 (22:58 -0400)]
gdb: remove TYPE_BIT_STRIDE
Remove the macro and add a `bit_stride` method to `struct range_bounds`,
which does the byte -> bit conversion if needed.
Add a convenience `bit_stride` method to `struct type` as well. I don't
really understand why the bit/byte stride is stored in the data
structure for bounds. Maybe it was just put there because
`range_bounds` was already a data structure specific to TYPE_CODE_RANGE
types? If the stride is indeed not related to the bounds, then I find
it more logical to do `my_range_type->bit_stride ()` than
`my_range_type->bounds ()->bit_stride ()`, hence the convenience
function on `struct type`.
gdb/ChangeLog:
* gdbtypes.h (struct range_bounds) <bit_stride>: New method.
(struct type) <bit_stride>: New method.
(TYPE_BIT_STRIDE): Remove.
* gdbtypes.c (update_static_array_size): Use type::bit_stride.
Change-Id: I6ecc1cfefdc20711fa8f188a94a05c1e116c9922
Simon Marchi [Mon, 13 Jul 2020 02:58:53 +0000 (22:58 -0400)]
gdb: remove TYPE_ARRAY_{LOWER,UPPER}_BOUND_VALUE
Remove the macros, use the various equivalent getters instead.
gdb/ChangeLog:
* gdbtypes.h (TYPE_ARRAY_LOWER_BOUND_VALUE,
TYPE_ARRAY_UPPER_BOUND_VALUE): Remove. Update all
callers to use the equivalent accessor methods instead.
Change-Id: I7f96d988f872170e7a2f58095832710e62b85cfd
Simon Marchi [Mon, 13 Jul 2020 02:58:52 +0000 (22:58 -0400)]
gdb: remove TYPE_ARRAY_{UPPER,LOWER}_BOUND_IS_UNDEFINED
Remove the macros, use the various equivalent getters instead.
gdb/ChangeLog:
* gdbtypes.h (TYPE_ARRAY_UPPER_BOUND_IS_UNDEFINED,
TYPE_ARRAY_LOWER_BOUND_IS_UNDEFINED): Remove. Update all
callers to use the equivalent accessor methods instead.
Change-Id: Ifb4c36f440b82533bde5d15a5cbb2fc91f467292
Simon Marchi [Mon, 13 Jul 2020 02:58:52 +0000 (22:58 -0400)]
gdb: remove TYPE_LOW_BOUND_KIND and TYPE_HIGH_BOUND_KIND
Remove the macros, use the getters of `struct dynamic_prop` instead.
gdb/ChangeLog:
* gdbtypes.h (TYPE_LOW_BOUND_KIND,
TYPE_HIGH_BOUND_KIND): Remove. Update all callers
to use dynamic_prop::kind.
Change-Id: Icb1fc761f675bfac934209f8102392504d905c44
Simon Marchi [Mon, 13 Jul 2020 02:58:52 +0000 (22:58 -0400)]
gdb: remove TYPE_LOW_BOUND_UNDEFINED and TYPE_HIGH_BOUND_UNDEFINED
Remove the macros, use the getters of `struct dynamic_prop` instead.
gdb/ChangeLog:
* gdbtypes.h (TYPE_LOW_BOUND_UNDEFINED,
TYPE_HIGH_BOUND_UNDEFINED): Remove. Update all callers
to get the bound property's kind and check against
PROP_UNDEFINED.
Change-Id: I6a7641ac1aa3fa7fca0c21f00556f185f2e2d68c
Simon Marchi [Mon, 13 Jul 2020 02:58:51 +0000 (22:58 -0400)]
gdb: remove TYPE_HIGH_BOUND and TYPE_LOW_BOUND
Remove the macros, use the getters of `struct dynamic_prop` instead.
gdb/ChangeLog:
* gdbtypes.h (TYPE_LOW_BOUND, TYPE_HIGH_BOUND): Remove. Update
all callers to use type::range_bounds followed by
dynamic_prop::{low,high}.
Change-Id: I31beeed65d94d81ac4f999244a8b859e2ee961d1
Simon Marchi [Mon, 13 Jul 2020 02:58:51 +0000 (22:58 -0400)]
gdb: add accessors to struct dynamic_prop
Add setters, to ensure that the kind and value of the property are
always kept in sync (a caller can't forget one or the other). Add
getters, such that we can assert that when a caller accesses a data bit
of the property, the property is indeed of the corresponding kind.
Note that because of the way `struct dynamic_prop` is allocated
currently, we can't make the `m_kind` and `m_data` fields private. That
would make the type non-default-constructible, and we would have to call
the constructor when allocating them. However, I still prefixed them
with `m_` to indicate that they should not be accessed from outside the
class (and also to be able to use the name `kind` for the method).
gdb/ChangeLog:
* gdbtypes.h (struct dynamic_prop) <kind, set_undefined,
const_val, set_const_val, baton, set_locexpr, set_loclist,
set_addr_offset, variant_parts, set_variant_parts,
original_type, set_original_type>: New methods.
<kind>: Rename to...
<m_kind>: ... this. Update all users to use the new methods
instead.
<data>: Rename to...
<m_data>: ... this. Update all users to use the new methods
instead.
Change-Id: Ib72a8eb440dfeb1a5421d0933334230d7f2478f9
Simon Marchi [Mon, 13 Jul 2020 02:58:51 +0000 (22:58 -0400)]
gdb: make get_discrete_bounds check for non-constant range bounds
The next patch adds getters to the `dynamic_prop` structure. These
getters validate that the accessed data matches the property kind (for
example, to access the `const_val` field, the property must be of kind
`PROP_CONST`). It found one instance where we are accessing the
`const_val` data of a property that has the undefined kind.
This happens in function `get_discrete_bounds`, and is exposed by test
gdb.base/ptype.exp, amongst others. Without this patch, we would get:
$ ./gdb -q -nx --data-directory=data-directory testsuite/outputs/gdb.base/ptype/ptype -ex "ptype t_char_array"
Reading symbols from testsuite/outputs/gdb.base/ptype/ptype...
type = char [
/home/smarchi/src/binutils-gdb/gdb/gdbtypes.h:526: internal-error: LONGEST dynamic_prop::const_val() const: Assertion `m_kind == PROP_CONST' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
The `get_discrete_bounds` function returns the bounds of a type (not
only range types). For range types, it naturally uses the bound
properties that are intrinsic to the range type. It accesses these
properties using TYPE_LOW_BOUND and TYPE_HIGH_BOUND, which assume the
properties are defined and have constant values. This is sometimes not
the case, and the passed range type (as in the example above) has an
undefined high/upper bound.
Given its current interface (returning two LONGEST values for low and
high), `get_discrete_bounds` can't really work if the range type's
bounds are not both defined and both constant values.
This patch changes the function to return -1 (failure to get the bounds)
if any of the range type's bounds is not a constant value. It is
sufficient to fix the issue and it seems to keep the callers happy, at
least according to the testsuite.
A bit in `get_array_bounds` could be removed, since
`get_discrete_bounds` no longer returns 1 if a bound is undefined.
gdb/ChangeLog:
* gdbtypes.c (get_discrete_bounds): Return failure if
the range type's bounds are not both defined and constant
values.
(get_array_bounds): Update comment. Remove undefined bound check.
Change-Id: I047a3beee2c1e275f888cfc4778228339922bde9
Simon Marchi [Mon, 13 Jul 2020 02:58:51 +0000 (22:58 -0400)]
gdb: remove TYPE_RANGE_DATA macro
Remove it in favor of using type::bounds directly.
gdb/ChangeLog:
* gdbtypes.h (TYPE_RANGE_DATA): Remove. Update callers to use
the type::bounds method directly.
Change-Id: Id4fab22af0a94cbf505f78b01b3ee5b3d682fba2
Simon Marchi [Mon, 13 Jul 2020 02:58:50 +0000 (22:58 -0400)]
gdb: add type::bounds / type::set_bounds
Add the `bounds` and `set_bounds` methods on `struct type`, in order to
remove the `TYPE_RANGE_DATA` macro. In this patch, the
`TYPE_RANGE_DATA` macro is changed to use `type::bounds`, so all the
call sites that are used to set a range type's bounds are changed to use
`type::set_bounds`. The next patch will remove `TYPE_RANGE_DATA`
completely.
gdb/ChangeLog:
* gdbtypes.h (struct type) <bounds, set_bounds>: New methods.
(TYPE_RANGE_DATA): Use type::bounds. Change all uses that
are used to set the range type's bounds to use set_bounds.
Change-Id: I62e15506239b98404e62bbea8120db184ed87847
GDB Administrator [Mon, 13 Jul 2020 00:00:11 +0000 (00:00 +0000)]
Automatic date update in version.in
GDB Administrator [Sun, 12 Jul 2020 00:00:12 +0000 (00:00 +0000)]
Automatic date update in version.in
Daniel Xu [Sat, 4 Jul 2020 03:59:53 +0000 (20:59 -0700)]
rust: Fix rust modules test
I noticed that the modules test was failing. Some choice use of `nm`
revealed `TWENTY_THREE` was not in the final binary. Fix by taking a
pointer to the global, forcing the linker to keep the symbol in.
gdb/testsuite/ChangeLog
2020-07-11 Daniel Xu <dxu@dxuuu.xyz>
PR rust/26121
* gdb.rust/modules.rs: Prevent linker from discarding test
symbol.
Signed-off-by: Daniel Xu <dxu@dxuuu.xyz>
Philippe Waroquiers [Sat, 27 Jun 2020 20:08:50 +0000 (22:08 +0200)]
Fine tune exec-file-mismatch help and documentation.
It was deemed better to explicitly mention in help and doc that build IDs
are used for comparison, and that symbols are loaded when asking to
load the exec-file.
This is V2, fixing 2 typos and replacing 'If the user asks to load'
by 'If the user confirms loading', as suggested by Pedro.
gdb/ChangeLog
2020-07-11 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* exec.c (_initialize_exec): Update exec-file-mismatch help.
gdb/doc/ChangeLog
2020-07-11 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.texinfo (Attach): Update exec-file-mismatch doc.
H.J. Lu [Sat, 11 Jul 2020 11:04:08 +0000 (04:04 -0700)]
x86: Support GNU_PROPERTY_X86_FEATURE_2_TMM
Support GNU_PROPERTY_X86_FEATURE_2_TMM in
https://gitlab.com/x86-psABIs/x86-64-ABI/-/merge_requests/1
#define GNU_PROPERTY_X86_FEATURE_2_TMM (1U << 10)
binutils/
* readelf.c (decode_x86_feature_2): Handle
GNU_PROPERTY_X86_FEATURE_2_TMM.
gas/
* config/tc-i386.c (output_insn): Check i.xstate to set
GNU_PROPERTY_X86_FEATURE_2_TMM.
* testsuite/gas/i386/i386.exp: Run x86-64-property-7,
x86-64-property-8 and x86-64-property-9.
* testsuite/gas/i386/x86-64-property-7.d: New file.
* testsuite/gas/i386/x86-64-property-7.s: Likewise.
* testsuite/gas/i386/x86-64-property-8.d: Likewise.
* testsuite/gas/i386/x86-64-property-8.s: Likewise.
* testsuite/gas/i386/x86-64-property-9.d: Likewise.
* testsuite/gas/i386/x86-64-property-9.s: Likewise.
include/
* elf/common.h (GNU_PROPERTY_X86_FEATURE_2_TMM): New.
GDB Administrator [Sat, 11 Jul 2020 00:00:13 +0000 (00:00 +0000)]
Automatic date update in version.in
Pedro Alves [Thu, 9 Jul 2020 17:14:09 +0000 (18:14 +0100)]
Fix crash if connection drops in scoped_restore_current_thread's ctor, part 2
Running the testsuite against an Asan-enabled build of GDB makes
gdb.base/multi-target.exp expose this bug.
scoped_restore_current_thread's ctor calls get_frame_id to record the
selected frame's ID to restore later. If the frame ID hasn't been
computed yet, it will be computed on the spot, and that will usually
require accessing the target's memory and registers. If the remote
connection closes, while we're computing the frame ID, the remote
target exits its inferiors, unpushes itself, and throws a
TARGET_CLOSE_ERROR error. Exiting the inferiors deletes the
inferior's threads.
scoped_restore_current_thread increments the current thread's refcount
to prevent the thread from being deleted from under its feet.
However, the code that does that isn't considering the case of the
thread being deleted from within get_frame_id. It only increments the
refcount _after_ get_frame_id returns. So if the current thread is
indeed deleted, the
tp->incref ();
statement references a stale TP pointer.
Incrementing the refcounts earlier fixes it.
We should probably also let the TARGET_CLOSE_ERROR error propagate in
this case. That alone would fix it, though it seems better to tweak
the refcount handling too. And to avoid having to manually decref
before throwing, convert to use gdb::ref_ptr.
Unfortunately, we can't define inferior_ref in inferior.h and then use
it in scoped_restore_current_thread, because
scoped_restore_current_thread is defined before inferior is
(inferior.h includes gdbthread.h). To break that dependency, we would
have to move scoped_restore_current_thread to its own header. I'm not
doing that here.
gdb/ChangeLog:
* gdbthread.h (inferior_ref): Define.
(scoped_restore_current_thread) <m_thread>: Now a thread_info_ref.
(scoped_restore_current_thread) <m_inf>: Now an inferior_ref.
* thread.c
(scoped_restore_current_thread::restore):
Adjust to gdb::ref_ptr.
(scoped_restore_current_thread::~scoped_restore_current_thread):
Remove manual decref handling.
(scoped_restore_current_thread::scoped_restore_current_thread):
Adjust to use
inferior_ref::new_reference/thread_info_ref::new_reference.
Incref the thread before calling get_frame_id instead of after.
Let TARGET_CLOSE_ERROR propagate.
Pedro Alves [Wed, 8 Jul 2020 14:43:02 +0000 (15:43 +0100)]
Fix crash if connection drops in scoped_restore_current_thread's ctor, part 1
Running the testsuite against an Asan-enabled build of GDB makes
gdb.base/multi-target.exp expose this bug.
scoped_restore_current_thread's ctor calls get_frame_id to record the
selected frame's ID to restore later. If the frame ID hasn't been
computed yet, it will be computed on the spot, and that will usually
require accessing the target's memory and registers, which requires
remote accesses. If the remote connection closes while we're
computing the frame ID, the remote target exits its inferiors,
unpushes itself, and throws a TARGET_CLOSE_ERROR error.
If that happens, GDB can currently crash, here:
> ==18555==ERROR: AddressSanitizer: heap-use-after-free on address 0x621004670aa8 at pc 0x0000007ab125 bp 0x7ffdecaecd20 sp 0x7ffdecaecd10
> READ of size 4 at 0x621004670aa8 thread T0
> #0 0x7ab124 in dwarf2_frame_this_id src/binutils-gdb/gdb/dwarf2/frame.c:1228
> #1 0x983ec5 in compute_frame_id src/binutils-gdb/gdb/frame.c:550
> #2 0x9841ee in get_frame_id(frame_info*) src/binutils-gdb/gdb/frame.c:582
> #3 0x1093faa in scoped_restore_current_thread::scoped_restore_current_thread() src/binutils-gdb/gdb/thread.c:1462
> #4 0xaee5ba in fetch_inferior_event(void*) src/binutils-gdb/gdb/infrun.c:3968
> #5 0xaa990b in inferior_event_handler(inferior_event_type, void*) src/binutils-gdb/gdb/inf-loop.c:43
> #6 0xea61b6 in remote_async_serial_handler src/binutils-gdb/gdb/remote.c:14161
> #7 0xefca8a in run_async_handler_and_reschedule src/binutils-gdb/gdb/ser-base.c:137
> #8 0xefcd23 in fd_event src/binutils-gdb/gdb/ser-base.c:188
> #9 0x15a7416 in handle_file_event src/binutils-gdb/gdbsupport/event-loop.cc:548
> #10 0x15a7c36 in gdb_wait_for_event src/binutils-gdb/gdbsupport/event-loop.cc:673
> #11 0x15a5dbb in gdb_do_one_event() src/binutils-gdb/gdbsupport/event-loop.cc:215
> #12 0xbfe62d in start_event_loop src/binutils-gdb/gdb/main.c:356
> #13 0xbfe935 in captured_command_loop src/binutils-gdb/gdb/main.c:416
> #14 0xc01d39 in captured_main src/binutils-gdb/gdb/main.c:1253
> #15 0xc01dc9 in gdb_main(captured_main_args*) src/binutils-gdb/gdb/main.c:1268
> #16 0x414ddd in main src/binutils-gdb/gdb/gdb.c:32
> #17 0x7f590110b82f in __libc_start_main ../csu/libc-start.c:291
> #18 0x414bd8 in _start (build/binutils-gdb/gdb/gdb+0x414bd8)
What happens is that above, we're in dwarf2_frame_this_id, just after
the dwarf2_frame_cache call. The "cache" variable that the
dwarf2_frame_cache function returned is already stale. It's been
released here, from within the dwarf2_frame_cache:
(top-gdb) bt
#0 reinit_frame_cache () at src/gdb/frame.c:1855
#1 0x00000000014ff7b0 in switch_to_no_thread () at src/gdb/thread.c:1301
#2 0x0000000000f66d3e in switch_to_inferior_no_thread (inf=0x615000338180) at src/gdb/inferior.c:626
#3 0x00000000012f3826 in remote_unpush_target (target=0x6170000c5900) at src/gdb/remote.c:5521
#4 0x00000000013097e0 in remote_target::readchar (this=0x6170000c5900, timeout=2) at src/gdb/remote.c:9137
#5 0x000000000130be4d in remote_target::getpkt_or_notif_sane_1 (this=0x6170000c5900, buf=0x6170000c5918, forever=0, expecting_notif=0, is_notif=0x0) at src/gdb/remote.c:9683
#6 0x000000000130c8ab in remote_target::getpkt_sane (this=0x6170000c5900, buf=0x6170000c5918, forever=0) at src/gdb/remote.c:9790
#7 0x000000000130bc0d in remote_target::getpkt (this=0x6170000c5900, buf=0x6170000c5918, forever=0) at src/gdb/remote.c:9623
#8 0x000000000130838e in remote_target::remote_read_bytes_1 (this=0x6170000c5900, memaddr=0x7fffffffcdc0, myaddr=0x6080000ad3bc "", len_units=64, unit_size=1, xfered_len_units=0x7fff6a29b9a0) at src/gdb/remote.c:8860
#9 0x0000000001308bd2 in remote_target::remote_read_bytes (this=0x6170000c5900, memaddr=0x7fffffffcdc0, myaddr=0x6080000ad3bc "", len=64, unit_size=1, xfered_len=0x7fff6a29b9a0) at src/gdb/remote.c:8987
#10 0x0000000001311ed1 in remote_target::xfer_partial (this=0x6170000c5900, object=TARGET_OBJECT_MEMORY, annex=0x0, readbuf=0x6080000ad3bc "", writebuf=0x0, offset=
140737488342464, len=64, xfered_len=0x7fff6a29b9a0) at src/gdb/remote.c:10988
#11 0x00000000014ba969 in raw_memory_xfer_partial (ops=0x6170000c5900, readbuf=0x6080000ad3bc "", writebuf=0x0, memaddr=
140737488342464, len=64, xfered_len=0x7fff6a29b9a0) at src/gdb/target.c:918
#12 0x00000000014bb720 in target_xfer_partial (ops=0x6170000c5900, object=TARGET_OBJECT_RAW_MEMORY, annex=0x0, readbuf=0x6080000ad3bc "", writebuf=0x0, offset=
140737488342464, len=64, xfered_len=0x7fff6a29b9a0) at src/gdb/target.c:1148
#13 0x00000000014bc3b5 in target_read_partial (ops=0x6170000c5900, object=TARGET_OBJECT_RAW_MEMORY, annex=0x0, buf=0x6080000ad3bc "", offset=
140737488342464, len=64, xfered_len=0x7fff6a29b9a0) at src/gdb/target.c:1380
#14 0x00000000014bc593 in target_read (ops=0x6170000c5900, object=TARGET_OBJECT_RAW_MEMORY, annex=0x0, buf=0x6080000ad3bc "", offset=
140737488342464, len=64) at src/gdb/target.c:1419
#15 0x00000000014bbd4d in target_read_raw_memory (memaddr=0x7fffffffcdc0, myaddr=0x6080000ad3bc "", len=64) at src/gdb/target.c:1252
#16 0x0000000000bf27df in dcache_read_line (dcache=0x6060001eddc0, db=0x6080000ad3a0) at src/gdb/dcache.c:336
#17 0x0000000000bf2b72 in dcache_peek_byte (dcache=0x6060001eddc0, addr=0x7fffffffcdd8, ptr=0x6020001231b0 "") at src/gdb/dcache.c:403
#18 0x0000000000bf3103 in dcache_read_memory_partial (ops=0x6170000c5900, dcache=0x6060001eddc0, memaddr=0x7fffffffcdd8, myaddr=0x6020001231b0 "", len=8, xfered_len=0x7fff6a29bf20) at src/gdb/dcache.c:484
#19 0x00000000014bafe9 in memory_xfer_partial_1 (ops=0x6170000c5900, object=TARGET_OBJECT_STACK_MEMORY, readbuf=0x6020001231b0 "", writebuf=0x0, memaddr=
140737488342488, len=8, xfered_len=0x7fff6a29bf20) at src/gdb/target.c:1034
#20 0x00000000014bb212 in memory_xfer_partial (ops=0x6170000c5900, object=TARGET_OBJECT_STACK_MEMORY, readbuf=0x6020001231b0 "", writebuf=0x0, memaddr=
140737488342488, len=8, xfered_len=0x7fff6a29bf20) at src/gdb/target.c:1076
#21 0x00000000014bb6b3 in target_xfer_partial (ops=0x6170000c5900, object=TARGET_OBJECT_STACK_MEMORY, annex=0x0, readbuf=0x6020001231b0 "", writebuf=0x0, offset=
140737488342488, len=8, xfered_len=0x7fff6a29bf20) at src/gdb/target.c:1133
#22 0x000000000164564d in read_value_memory (val=0x60f000029440, bit_offset=0, stack=1, memaddr=0x7fffffffcdd8, buffer=0x6020001231b0 "", length=8) at src/gdb/valops.c:956
#23 0x0000000001680fff in value_fetch_lazy_memory (val=0x60f000029440) at src/gdb/value.c:3764
#24 0x0000000001681efd in value_fetch_lazy (val=0x60f000029440) at src/gdb/value.c:3910
#25 0x0000000001676143 in value_optimized_out (value=0x60f000029440) at src/gdb/value.c:1411
#26 0x0000000000e0fcb8 in frame_register_unwind (next_frame=0x6210066bfde0, regnum=16, optimizedp=0x7fff6a29c200, unavailablep=0x7fff6a29c240, lvalp=0x7fff6a29c2c0, addrp=0x7fff6a29c300, realnump=0x7fff6a29c280, bufferp=0x7fff6a29c3a0 "@\304)j\377\177") at src/gdb/frame.c:1144
#27 0x0000000000e10418 in frame_unwind_register (next_frame=0x6210066bfde0, regnum=16, buf=0x7fff6a29c3a0 "@\304)j\377\177") at src/gdb/frame.c:1196
#28 0x0000000000f00431 in i386_unwind_pc (gdbarch=0x6210043d0110, next_frame=0x6210066bfde0) at src/gdb/i386-tdep.c:1969
#29 0x0000000000e39724 in gdbarch_unwind_pc (gdbarch=0x6210043d0110, next_frame=0x6210066bfde0) at src/gdb/gdbarch.c:3056
#30 0x0000000000c2ea90 in dwarf2_tailcall_sniffer_first (this_frame=0x6210066bfde0, tailcall_cachep=0x6210066bfee0, entry_cfa_sp_offsetp=0x0) at src/gdb/dwarf2/frame-tailcall.c:423
#31 0x0000000000c36bdb in dwarf2_frame_cache (this_frame=0x6210066bfde0, this_cache=0x6210066bfdf8) at src/gdb/dwarf2/frame.c:1198
#32 0x0000000000c36eb3 in dwarf2_frame_this_id (this_frame=0x6210066bfde0, this_cache=0x6210066bfdf8, this_id=0x6210066bfe40) at src/gdb/dwarf2/frame.c:1226
Note that remote_target::readchar in frame #4 throws
TARGET_CLOSE_ERROR after the remote_unpush_target in frame #3 returns.
The problem is that the TARGET_CLOSE_ERROR is swallowed by
value_optimized_out in frame #25.
If we fix that one, then we run into dwarf2_tailcall_sniffer_first
swallowing the exception in frame #30 too.
The attached patch fixes it by making those spots swallow fewer kinds
of errors.
gdb/ChangeLog:
* frame-tailcall.c (dwarf2_tailcall_sniffer_first): Only swallow
NO_ENTRY_VALUE_ERROR / MEMORY_ERROR / OPTIMIZED_OUT_ERROR /
NOT_AVAILABLE_ERROR.
* value.c (value_optimized_out): Only swallow MEMORY_ERROR /
OPTIMIZED_OUT_ERROR / NOT_AVAILABLE_ERROR.
Simon Marchi [Sat, 4 Jul 2020 12:33:19 +0000 (13:33 +0100)]
Fix GDB busy loop when interrupting non-stop program (PR 26199)
When interrupting a program in non-stop, the program gets interrupted
correctly, but GDB busy loops (the event loop is always woken up).
Here is how to reproduce it:
1. Start GDB: ./gdb -nx --data-directory=data-directory -ex "set non-stop 1" --args /bin/sleep 60
2. Run the program with "run"
3. Interrupt with ^C.
4. Look into htop, see GDB taking 100% CPU
Debugging `handle_file_event`, we see that the event source that wakes
up the event loop is the linux-nat one:
(top-gdb) p file_ptr.proc
$5 = (handler_func *) 0xb9cccd <handle_target_event(int, gdb_client_data)>
^^^^^^^^^^^^^^^^^^^
|
\-- the linux-nat callback
Debugging fetch_inferior_event and do_target_wait, we see that we
don't actually call `wait` on the linux-nat target, because
inferior_matches returns false:
auto inferior_matches = [&wait_ptid] (inferior *inf)
{
return (inf->process_target () != NULL
&& (threads_are_executing (inf->process_target ())
|| threads_are_resumed_pending_p (inf))
&& ptid_t (inf->pid).matches (wait_ptid));
};
because `threads_are_executing` is false.
What happens is:
1. User types ctrl-c, that writes in the linux-nat pipe, waking up
the event source.
2. linux-nat's wait gets called, the SIGINT event is returned, but
before returning, it marks the pipe again, in order for wait to
get called again:
/* If we requested any event, and something came out, assume there
may be more. If we requested a specific lwp or process, also
assume there may be more. */
if (target_is_async_p ()
&& ((ourstatus->kind != TARGET_WAITKIND_IGNORE
&& ourstatus->kind != TARGET_WAITKIND_NO_RESUMED)
|| ptid != minus_one_ptid))
async_file_mark ();
3. The SIGINT event is handled, the program is stopped, the stop
notification is printed.
4. The event loop is woken up again because of the `async_file_mark`
of step 2.
5. Because `inferior_matches` returns false, we never call
linux-nat's wait, so the pipe stays readable.
6. Goto 4.
Pedro says:
This commit fixes it by letting do_target_wait call target_wait even
if threads_are_executing is false. This will normally result in the
target returning TARGET_WAITKIND_NO_RESUMED, and _not_ marking its
event source again. This results in infrun only calling into the
target only once (i.e., breaking the busy loop).
Note that the busy loop bug didn't trigger in all-stop mode because
all-stop handles this by unregistering the target from the event loop
as soon as it was all stopped -- see
inf-loop.c:inferior_event_handler's INF_EXEC_COMPLETE handling. If we
remove that non-stop check from inferior_event_handler, and replace
the target_has_execution check for threads_are_executing instead, it
also fixes the issue for non-stop. I considered that as the final
solution, but decided that the solution proposed here instead is just
simpler and more future-proof design. With the
TARGET_WAITKIND_NO_RESUMED handling fixes done in the previous
patches, I think it should be possible to always keep the target
registered in the event loop, meaning we could eliminate the
target_async(0) call from inferior_event_handler as well as most of
the target_async(1) calls in the target backends. That would allow in
the future e.g., the remote target reporting asynchronous
notifications even if all threads are stopped. I haven't attempted
that, though.
gdb/ChangeLog:
yyyy-mm-dd Simon Marchi <simon.marchi@polymtl.ca>
Pedro Alves <pedro@palves.net>
PR gdb/26199
* infrun.c (threads_are_resumed_pending_p): Delete.
(do_target_wait): Remove threads_are_executing and
threads_are_resumed_pending_p checks from the inferior_matches
lambda. Update comments.
Pedro Alves [Sat, 4 Jul 2020 18:26:59 +0000 (19:26 +0100)]
Testcase for previous handle_no_resumed fixes
This adds a testcase that covers the scenarios described in the
previous two commits.
gdb/testsuite/ChangeLog:
PR gdb/26199
* gdb.multi/multi-target.c (exit_thread): New.
(thread_start): Break loop if EXIT_THREAD.
* gdb.multi/multi-target.exp (test_no_unwaited_for): New proc.
(top level) Call test_no_resumed.
Pedro Alves [Sat, 4 Jul 2020 19:51:36 +0000 (20:51 +0100)]
Make handle_no_resumed transfer terminal
Let's consider the same use case as in the previous commit:
Say you have two inferiors 1 and 2, each connected to a different
target, A and B.
Now say you set inferior 2 running, with "continue &".
Now you select a thread of inferior 1, say thread 1.2, and continue in
the foreground. All other threads of inferior 1 are left stopped.
Thread 1.2 exits, and thus target A has no other resumed thread, so it
reports TARGET_WAITKIND_NO_RESUMED.
At this point, because the threads of inferior 2 are still executing
the TARGET_WAITKIND_NO_RESUMED event is ignored.
Now, the user types Ctrl-C. Because GDB had previously put inferior 1
in the foreground, the kernel sends the SIGINT to that inferior.
However, no thread in that inferior is executing right now, so ptrace
never intercepts the SIGINT -- it is never dequeued by any thread.
The result is that GDB's CLI is stuck. There's no way to get back the
prompt (unless inferior 2 happens to report some event).
The fix in this commit is to make handle_no_resumed give the terminal
to some other inferior that still has threads executing so that a
subsequent Ctrl-C reaches that target first (and then GDB intercepts
the SIGINT). This is a bit hacky, but seems like the best we can do
with the current design.
I think that putting all native inferiors in their own session would
help fixing this in a clean way, since with that a Ctrl-C on GDB's
terminal will _always_ reach GDB first, and then GDB can decide how to
pause the inferior. But that's a much larger change.
The testcase added by the following patch needs this fix.
gdb/ChangeLog:
PR gdb/26199
* infrun.c (handle_no_resumed): Transfer terminal to inferior with
executing threads.
Pedro Alves [Sat, 4 Jul 2020 18:26:59 +0000 (19:26 +0100)]
Fix handle_no_resumed w/ multiple targets
handle_no_resumed is currently not considering multiple targets.
Say you have two inferiors 1 and 2, each connected to a different
target, A and B.
Now say you set inferior 2 running, with "continue &".
Now you select a thread of inferior 1, say thread 1.2, and continue in
the foreground. All other threads of inferior 1 are left stopped.
Thread 1.2 exits, and thus target A has no other resumed thread, so it
reports TARGET_WAITKIND_NO_RESUMED.
At this point, if both inferiors were running in the same target,
handle_no_resumed would realize that threads of inferior 2 are still
executing, so the TARGET_WAITKIND_NO_RESUMED event should be ignored.
But because handle_no_resumed only walks the threads of the current
target, it misses noticing that threads of inferior 2 are still
executing. The fix is just to walk over all threads of all targets.
A testcase covering the use case above will be added in a following
patch. It can't be added yet because it depends on yet another fix to
handle_no_resumed not included here.
gdb/ChangeLog:
PR gdb/26199
* infrun.c (handle_no_resumed): Handle multiple targets.
Pedro Alves [Sat, 4 Jul 2020 18:31:21 +0000 (19:31 +0100)]
Avoid constant stream of TARGET_WAITKIND_NO_RESUMED
If we hit the synchronous execution command case described by
handle_no_resumed, and handle_no_resumed determines that the event
should be ignored, because it found a thread that is executing, we end
up in prepare_to_wait.
There, if the current target is not registered in the event loop right
now, we call mark_infrun_async_event_handler. With that event handler
marked, the event loop calls again into fetch_inferior_event, which
calls target_wait, which returns TARGET_WAITKIND_NO_RESUMED, and we
end up in handle_no_resumed, again ignoring the event and marking
infrun_async_event_handler. The result is that GDB is now always
keeping the CPU 100% busy in this loop, even though it continues to be
able to react to input and to real target events, because we still go
through the event-loop.
The problem is that marking of the infrun_async_event_handler in
prepare_to_wait. That is there to handle targets that don't support
asynchronous execution. So the correct predicate is whether async
execution is supported, not whether the target is async right now.
gdb/ChangeLog:
PR gdb/26199
* infrun.c (prepare_to_wait): Check target_can_async_p instead of
target_is_async_p.
Pedro Alves [Sat, 4 Jul 2020 18:12:30 +0000 (19:12 +0100)]
Fix latent bug in target_pass_ctrlc
We were checking the thr->executing of an exited thread.
gdb/ChangeLog:
PR gdb/26199
* target.c (target_pass_ctrlc): Look at the inferior's non-exited
threads, not all threads.
Pedro Alves [Fri, 10 Jul 2020 22:39:34 +0000 (23:39 +0100)]
Fix spurious unhandled remote %Stop notifications
In non-stop mode, remote targets mark an async event source whose
callback is supposed to result in calling remote_target::wait_ns to
either process the event queue, or acknowledge an incoming %Stop
notification.
The callback in question is remote_async_inferior_event_handler, where
we call inferior_event_handler, to end up in fetch_inferior_event ->
target_wait -> remote_target::wait -> remote_target::wait_ns.
A problem here however is that when debugging multiple targets,
fetch_inferior_event can pull events out of any target picked at
random, for event fairness. This means that when
remote_async_inferior_event_handler returns, remote_target::wait may
have not been called at all, and thus pending notifications may have
not been acked. Because async event sources auto-clear, when
remote_async_inferior_event_handler returns the async event handler is
no longer marked, so the event loop won't automatically call
remote_async_inferior_event_handler again to try to process the
pending remote notifications/queue. The result is that stop events
may end up not processed, e.g., "interrupt -a" seemingly not managing
to stop all threads.
Fix this by making remote_async_inferior_event_handler mark the event
handler again before returning, if necessary.
Maybe a better fix would be to make async event handlers not
auto-clear themselves, make that the responsibility of the callback,
so that the event loop would keep calling the callback automatically.
Or, we could try making so that fetch_inferior_event would optionally
handle events only for the target that it got passed down via
parameter. However, I don't think now just before branching is the
time to try to do any such change.
gdb/ChangeLog:
PR gdb/26199
* remote.c (remote_target::open_1): Pass remote target pointer as
data to create_async_event_handler.
(remote_async_inferior_event_handler): Mark async event handler
before returning if the remote target still has either pending
events or unacknowledged notifications.
John Baldwin [Fri, 10 Jul 2020 16:05:28 +0000 (09:05 -0700)]
Enable multi-process mode in the FreeBSD native target.
gdb/ChangeLog:
* fbsd-nat.h (fbsd_nat_target::supports_multi_process): New
declaration.
* fbsd-nat.c (fbsd_nat_target::supports_multi_process): New
function.
H.J. Lu [Fri, 10 Jul 2020 15:43:37 +0000 (08:43 -0700)]
x86: Extract extended states from instruction template
Extract extended states from operand types in instruction template. Set
xstate_zmm for master register move.
* config/tc-i386.c (_i386_insn): Remove has_regmmx, has_regxmm,
has_regymm, has_regzmm and has_regtmm. Add xstate.
(md_assemble): Set i.xstate from operand types in instruction
template.
(build_modrm_byte): Updated.
(output_insn): Check i.xstate.
* testsuite/gas/i386/i386.exp: Run property-6 and
x86-64-property-6.
* testsuite/gas/i386/property-6.d: New file.
* testsuite/gas/i386/property-6.s: Updated.
* testsuite/gas/i386/x86-64-property-6.d: Likewise.
H.J. Lu [Fri, 10 Jul 2020 12:58:42 +0000 (05:58 -0700)]
gas/i386/property-5.d: Correct test name
* testsuite/gas/i386/property-5.d: Correct test name.
Lili Cui [Fri, 10 Jul 2020 12:17:29 +0000 (05:17 -0700)]
x86: Add support for Intel AMX instructions
gas/
* doc/c-i386.texi: Document amx_int8, amx_bf16 and amx_tile.
* config/tc-i386.c (i386_error): Add invalid_sib_address.
(cpu_arch): Add .amx_int8, .amx_bf16 and .amx_tile.
(cpu_noarch): Add noamx_int8, noamx_bf16 and noamx_tile.
(match_simd_size): Add tmmword check.
(operand_type_match): Add tmmword.
(type_names): Add rTMM.
(i386_error): Add invalid_tmm_register_set.
(check_VecOperands): Handle invalid_sib_address and
invalid_tmm_register_set.
(match_template): Handle invalid_sib_address.
(build_modrm_byte): Handle non-vector SIB and zmmword.
(i386_index_check): Disallow RegIP for non-vector SIB.
(check_register): Handle zmmword.
* testsuite/gas/i386/i386.exp: Add AMX new tests.
* testsuite/gas/i386/intel-regs.d: Add tmm.
* testsuite/gas/i386/intel-regs.s: Add tmm.
* testsuite/gas/i386/x86-64-amx-intel.d: New.
* testsuite/gas/i386/x86-64-amx-inval.l: New.
* testsuite/gas/i386/x86-64-amx-inval.s: New.
* testsuite/gas/i386/x86-64-amx.d: New.
* testsuite/gas/i386/x86-64-amx.s: New.
* testsuite/gas/i386/x86-64-amx-bad.d: New.
* testsuite/gas/i386/x86-64-amx-bad.s: New.
opcodes/
* i386-dis.c (TMM): New.
(EXtmm): Likewise.
(VexTmm): Likewise.
(MVexSIBMEM): Likewise.
(tmm_mode): Likewise.
(vex_sibmem_mode): Likewise.
(REG_VEX_0F3849_X86_64_P_0_W_0_M_1): Likewise.
(MOD_VEX_0F3849_X86_64_P_0_W_0): Likewise.
(MOD_VEX_0F3849_X86_64_P_2_W_0): Likewise.
(MOD_VEX_0F3849_X86_64_P_3_W_0): Likewise.
(MOD_VEX_0F384B_X86_64_P_1_W_0): Likewise.
(MOD_VEX_0F384B_X86_64_P_2_W_0): Likewise.
(MOD_VEX_0F384B_X86_64_P_3_W_0): Likewise.
(MOD_VEX_0F385C_X86_64_P_1_W_0): Likewise.
(MOD_VEX_0F385E_X86_64_P_0_W_0): Likewise.
(MOD_VEX_0F385E_X86_64_P_1_W_0): Likewise.
(MOD_VEX_0F385E_X86_64_P_2_W_0): Likewise.
(MOD_VEX_0F385E_X86_64_P_3_W_0): Likewise.
(RM_VEX_0F3849_X86_64_P_0_W_0_M_1_R_0): Likewise.
(PREFIX_VEX_0F3849_X86_64): Likewise.
(PREFIX_VEX_0F384B_X86_64): Likewise.
(PREFIX_VEX_0F385C_X86_64): Likewise.
(PREFIX_VEX_0F385E_X86_64): Likewise.
(X86_64_VEX_0F3849): Likewise.
(X86_64_VEX_0F384B): Likewise.
(X86_64_VEX_0F385C): Likewise.
(X86_64_VEX_0F385E): Likewise.
(VEX_LEN_0F3849_X86_64_P_0_W_0_M_0): Likewise.
(VEX_LEN_0F3849_X86_64_P_0_W_0_M_1_REG_0_RM_0): Likewise.
(VEX_LEN_0F3849_X86_64_P_2_W_0_M_0): Likewise.
(VEX_LEN_0F3849_X86_64_P_3_W_0_M_0): Likewise.
(VEX_LEN_0F384B_X86_64_P_1_W_0_M_0): Likewise.
(VEX_LEN_0F384B_X86_64_P_2_W_0_M_0): Likewise.
(VEX_LEN_0F384B_X86_64_P_3_W_0_M_0): Likewise.
(VEX_LEN_0F385C_X86_64_P_1_W_0_M_0): Likewise.
(VEX_LEN_0F385E_X86_64_P_0_W_0_M_0): Likewise.
(VEX_LEN_0F385E_X86_64_P_1_W_0_M_0): Likewise.
(VEX_LEN_0F385E_X86_64_P_2_W_0_M_0): Likewise.
(VEX_LEN_0F385E_X86_64_P_3_W_0_M_0): Likewise.
(VEX_W_0F3849_X86_64_P_0): Likewise.
(VEX_W_0F3849_X86_64_P_2): Likewise.
(VEX_W_0F3849_X86_64_P_3): Likewise.
(VEX_W_0F384B_X86_64_P_1): Likewise.
(VEX_W_0F384B_X86_64_P_2): Likewise.
(VEX_W_0F384B_X86_64_P_3): Likewise.
(VEX_W_0F385C_X86_64_P_1): Likewise.
(VEX_W_0F385E_X86_64_P_0): Likewise.
(VEX_W_0F385E_X86_64_P_1): Likewise.
(VEX_W_0F385E_X86_64_P_2): Likewise.
(VEX_W_0F385E_X86_64_P_3): Likewise.
(names_tmm): Likewise.
(att_names_tmm): Likewise.
(intel_operand_size): Handle void_mode.
(OP_XMM): Handle tmm_mode.
(OP_EX): Likewise.
(OP_VEX): Likewise.
* i386-gen.c (cpu_flag_init): Add entries for CpuAMX_INT8,
CpuAMX_BF16 and CpuAMX_TILE.
(operand_type_shorthands): Add RegTMM.
(operand_type_init): Likewise.
(operand_types): Add Tmmword.
(cpu_flag_init): Add CPU_AMX_INT8, CpuAMX_BF16 and CpuAMX_TILE.
(cpu_flags): Add CpuAMX_INT8, CpuAMX_BF16 and CpuAMX_TILE.
* i386-opc.h (CpuAMX_INT8): New.
(CpuAMX_BF16): Likewise.
(CpuAMX_TILE): Likewise.
(SIBMEM): Likewise.
(Tmmword): Likewise.
(i386_cpu_flags): Add cpuamx_int8, cpuamx_bf16 and cpuamx_tile.
(i386_opcode_modifier): Extend width of fields vexvvvv and sib.
(i386_operand_type): Add tmmword.
* i386-opc.tbl: Add AMX instructions.
* i386-reg.tbl: Add AMX registers.
* i386-init.h: Regenerated.
* i386-tbl.h: Likewise.
Tom de Vries [Fri, 10 Jul 2020 10:25:44 +0000 (11:25 +0100)]
[readelf] Fix end_seq entry in -wL. Specifically stop the display of a line number and is_statement/has-view fields for the End of Sequence operator, as these have no meaning.
binutils* dwarf.c (display_debug_lines_decoded): Don't emit meaningless
information in the end_sequence row.
* testsuite/binutils-all/dw5.W: Update.
* testsuite/binutils-all/objdump.WL: Update.
gas * testsuite/gas/elf/dwarf2-11.d: Update expected output from
readelf's line table decoding.
* testsuite/gas/elf/dwarf2-12.d: Likewise.
* testsuite/gas/elf/dwarf2-13.d: Likewise.
* testsuite/gas/elf/dwarf2-14.d: Likewise.
* testsuite/gas/elf/dwarf2-15.d: Likewise.
* testsuite/gas/elf/dwarf2-16.d: Likewise.
* testsuite/gas/elf/dwarf2-17.d: Likewise.
* testsuite/gas/elf/dwarf2-18.d: Likewise.
* testsuite/gas/elf/dwarf2-19.d: Likewise.
* testsuite/gas/elf/dwarf2-5.d: Likewise.
* testsuite/gas/elf/dwarf2-6.d: Likewise.
* testsuite/gas/elf/dwarf2-7.d: Likewise.
Alan Modra [Fri, 10 Jul 2020 07:28:49 +0000 (16:58 +0930)]
Document powerpc64 ld options
* ld.texi (PowerPC64 ELF64): Document --no-inline-optimize,
--power10-stubs and --no-power10-stubs.
Alan Modra [Fri, 10 Jul 2020 01:18:45 +0000 (10:48 +0930)]
PowerPC64 ld --no-power10-stubs
Needed for libraries that use ifuncs or other means to support
cpu-optimized versions of functions, some power10, some not, and those
functions make calls using linkage stubs.
bfd/
* elf64-ppc.h (struct ppc64_elf_params): Add power10_stubs.
* elf64-ppc.c (struct ppc_link_hash_table): Delete
power10_stubs.
(ppc64_elf_check_relocs): Adjust setting of power10_stubs.
(plt_stub_size, ppc_build_one_stub, ppc_size_one_stub): Adjust
uses of power10_stubs.
ld/
* emultempl/ppc64elf.em (params): Init new field.
(enum ppc64_opt): Add OPTION_POWER10_STUBS and OPTION_NO_POWER10_STUBS.
(PARSE_AND_LIST_LONGOPTS): Support --power10-stubs and
--no-power10-stubs.
(PARSE_AND_LIST_OPTIONS, PARSE_AND_LIST_ARGS_CASES): Likewise.
* testsuite/ld-powerpc/callstub-3.d: New test.
* testsuite/ld-powerpc/powerpc.exp: Run it.
GDB Administrator [Fri, 10 Jul 2020 00:00:09 +0000 (00:00 +0000)]
Automatic date update in version.in
John Baldwin [Thu, 9 Jul 2020 19:40:40 +0000 (12:40 -0700)]
Don't compare the pid returned from 'wait' against inferior_ptid.
'inf_ptrace::wait' needs to discard termination events reported by
detached child processes. Previously it compared the returned pid
against the pid in inferior_ptid to determine if a termination event
should be discarded or reported. The multi-target changes cleared
inferior_ptid to null_ptid in 'wait' target methods, so this was
always failing and never reporting exit events. Instead, report
termination events whose pid matches any inferior belonging to the
current target.
Several tests started failing on FreeBSD after the multi-target
changes and pass again after this change.
gdb/ChangeLog:
* inf-ptrace.c (inf_ptrace_target::wait): Don't compare against
inferior_ptid.
H.J. Lu [Thu, 9 Jul 2020 17:33:25 +0000 (10:33 -0700)]
x86: Properly set YMM/ZMM features
Since VEX/EVEX vector instructions will always update the full YMM/ZMM
registers, set YMM/ZMM features for VEX/EVEX vector instructions.
* config/tc-i386.c (output_insn): Set YMM/ZMM features for
VEX/EVEX vector instructions.
* testsuite/gas/i386/property-4.d: New file.
* testsuite/gas/i386/property-4.s: Likewise.
* testsuite/gas/i386/property-5.d: Likewise.
* testsuite/gas/i386/property-5.s: Likewise.
* testsuite/gas/i386/x86-64-property-4.d: Likewise.
* testsuite/gas/i386/x86-64-property-5.d: Likewise.
John Baldwin [Thu, 9 Jul 2020 16:39:05 +0000 (09:39 -0700)]
Support several new ELF auxiliary vector types on FreeBSD.
FreeBSD's kernel recently added several ELF auxiliary vector entries
to describe the arguments passed to new executable images during
exec(). The AT_FREEBSD_ARGC and AT_FREEBSD_ARGV entries give the
length and address of the process argument array. AT_FREEBSD_ENVC and
AT_FREEBSD_ENVV entries give the length and address of the initial
process environment. AT_FREEBSD_PS_STRINGS gives the address of the
'struct ps_strings' object.
include/ChangeLog:
* elf/common.h (AT_FREEBSD_ARGC, AT_FREEBSD_ARGV, AT_FREEBSD_ENVC)
(AT_FREEBSD_ENVV, AT_FREEBSD_PS_STRINGS): Define.
gdb/ChangeLog:
* fbsd-tdep.c (fbsd_print_auxv_entry): Handle AT_FREEBSD_ARGC,
AT_FREEBSD_ARGV, AT_FREEBSD_ENVC, AT_FREEBSD_ENVV,
AT_FREEBSD_PS_STRINGS.
H.J. Lu [Thu, 9 Jul 2020 15:29:25 +0000 (08:29 -0700)]
Linux/x86: Configure gas with --enable-x86-used-note by default
* configure.ac: Configure with --enable-x86-used-note by default
for Linux/x86.
* configure: Regenerated.
Alan Modra [Wed, 8 Jul 2020 11:51:32 +0000 (21:21 +0930)]
Remove powerpc PE support
Plus some leftover powerpc lynxos support.
bfd/
* coff-ppc.c: Delete.
* pe-ppc.c: Delete.
* pei-ppc.c: Delete.
* Makefile.am (BFD32_BACKENDS, BFD32_BACKENDS_CFILES): Remove PE PPC.
* coffcode.h (coff_set_arch_mach_hook, coff_set_flags): Remove
PPCMAGIC code.
(coff_write_object_contents): Remove PPC_PE code.
* config.bfd: Move powerpcle-pe to removed targets.
* configure.ac: Remove powerpc PE entries.
* libcoff-in.h (ppc_allocate_toc_section): Delete.
(ppc_process_before_allocation): Delete.
* peXXigen.c: Remove POWERPC_LE_PE code and comments.
* targets.c: Remove powerpc PE vectors.
* po/SRC-POTFILES.in: Regenerate.
* libcoff.h: Regenerate.
* Makefile.in: Regenerate.
* configure: Regenerate.
binutils/
* dlltool.c: Remove powerpc PE support and comments.
* configure.ac: Remove powerpc PE dlltool config.
* configure: Regenerate.
gas/
* config/obj-coff.h: Remove TE_PE support.
* config/tc-ppc.c: Likewise.
* config/tc-ppc.h: Likewise.
* configure.tgt: Remove powerpc PE and powerpc lynxos.
* testsuite/gas/cfi/cfi.exp (cfi-common-6): Remove powerpc PE
condition.
* testsuite/gas/macros/macros.exp: Don't xfail powerpc PE.
include/
* coff/powerpc.h: Delete.
ld/
* emulparams/ppcpe.sh: Delete.
* scripttempl/ppcpe.sc: Delete.
* emulparams/ppclynx.sh: Delete.
* Makefile.am (ALL_EMULATION_SOURCES): Remove ppc PE and lynxos.
* configure.tgt: Likewise.
* emultempl/beos.em: Remove powerpc PE support.
* emultempl/pe.em: Likewise.
* po/BLD-POTFILES.in: Regenerate.
* Makefile.in: Regenerate.
Alan Modra [Thu, 9 Jul 2020 13:18:10 +0000 (22:48 +0930)]
powerpc garbage collect test
ld's garbage collection test on powerpc64 catered for old compilers
(pre -mcmodel=medium support), setting options that caused the test to
fail. Which meant the test wasn't really testing anything. Get rid
of that old compiler support, and avoid -fPIE fails on ppc32.
* testsuite/ld-gc/gc.exp: Don't set -mminimal-toc for powerpc64,
and remove powerpc64 xfail. Use -fno-PIE for ppc32.
Alan Modra [Thu, 9 Jul 2020 07:05:27 +0000 (16:35 +0930)]
pr18841 tests on powerpc64
The PR18841 test does cross-module calls from within an ifunc
resolver, which is nasty, and not supported in general since the
called function may not be relocated. In this case the called
function (zoo) is just a stub so doesn't need relocating, but on ppc64
the function descriptor for zoo in the executable won't be relocated
at the time the shared library ifunc resolver runs. That means the
test will fail if your compiler generates PIEs by default.
PR 18841
* testsuite/ld-ifunc/ifunc.exp: Run pr18841 tests non-pie.
Nick Clifton [Thu, 9 Jul 2020 13:25:11 +0000 (14:25 +0100)]
Update Turkish translation in the gprof sub-directory
Nick Clifton [Thu, 9 Jul 2020 13:20:58 +0000 (14:20 +0100)]
Update French translation in the bfd sub-directory
Nick Clifton [Thu, 9 Jul 2020 12:45:01 +0000 (13:45 +0100)]
Update the Windows Resource compiler (windres) to support the OWNERDRAW and BITMAP menuitem flags.
binutils* rclex.c: Add OWNERDRAW keyword.
* rcparse.y: Add OWNERDRAW token.
(menuitem_flag) Add BITMAP and OWNERDRAW entries.
* resrc.c (write_rc_menuitems): Add support for OWNERDRAW and
BITMAP flags.
* windres.c (extended_menuitems): Likewise.
* testsuite/binutils-all/windres/menuitem_flags.rc: New test.
Alan Modra [Thu, 9 Jul 2020 03:48:37 +0000 (13:18 +0930)]
asan: readelf: heap buffer overflow in slurp_hppa_unwind_table
This one isn't just a weird corner case requiring multiple
.PARISC.unwind sections in an object file to trigger the buffer
overflow, it's also a simple bug that would prevent relocations being
applied in the normal case of a single .PARISC.unwind section.
* readelf (slurp_hppa_unwind_table): Set table_len before use
in relocation sanity checks.
GDB Administrator [Thu, 9 Jul 2020 00:00:10 +0000 (00:00 +0000)]
Automatic date update in version.in
Hannes Domani [Wed, 13 May 2020 10:35:51 +0000 (12:35 +0200)]
Handle Windows drives in auto-load script paths
Fixes this testsuite fail on Windows:
FAIL: gdb.base/auto-load.exp: print $script_loaded
Converts the debugfile path from c:/dir/file to /c/dir/file, so it can be
appended to the auto-load path.
gdb/ChangeLog:
2020-07-08 Hannes Domani <ssbssa@yahoo.de>
* auto-load.c (auto_load_objfile_script_1): Convert drive part
of debugfile path on Windows.
gdb/doc/ChangeLog:
2020-07-08 Hannes Domani <ssbssa@yahoo.de>
* gdb.texinfo: Document Windows drive conversion of
'set auto-load scripts-directory'.
John Baldwin [Wed, 8 Jul 2020 15:55:20 +0000 (08:55 -0700)]
Rename the 'obfd' argument to fbsd_nat_target::find_memory_regions.
The argument is passed as a generic cookie value to the supplied
callback and is not necessarily a pointer to a bfd.
gdb/ChangeLog:
* fbsd-nat.c (fbsd_nat_target::find_memory_regions): Rename 'obfd'
argument to 'data'.
Tom Tromey [Wed, 8 Jul 2020 13:16:59 +0000 (07:16 -0600)]
Use read_memory in ada_exception_message_1
Testing using the internal AdaCore test suite showed a regression from
the target string reading changes. In particular, now
ada_exception_message_1 can get the wrong answer in some cases. In
particular, when an Ada exception catchpoint is hit, sometimes the
exception name will be incorrect. The case I was seeing changed from
the correct:
Catchpoint 2, CONSTRAINT_ERROR (catch C_E) at [...]
to:
Catchpoint 2, CONSTRAINT_ERROR (catch C_EE) at [...]
I was not able to reproduce this failure with the Fedora gnat.
Perhaps it is related to some local change to gnat; I do not know.
Meanwhile, because ada_exception_message_1 knows the length of the
string to read, we can use read_memory here. This fixes the bug.
I've updated the test suite to at least exercise this code path.
However, as mentioned above, the new test does not actually provoke
the failure.
gdb/ChangeLog
2020-07-08 Tom Tromey <tromey@adacore.com>
* ada-lang.c (ada_exception_message_1): Use read_memory.
gdb/testsuite/ChangeLog
2020-07-08 Tom Tromey <tromey@adacore.com>
* gdb.ada/catch_ex/foo.adb: Pass string to raise.
* gdb.ada/catch_ex.exp: Examine catchpoint text.
Nick Clifton [Wed, 8 Jul 2020 10:08:05 +0000 (11:08 +0100)]
Commit: Fix GOLD testsuite failures for 2.35 branch.
* testsuite/script_test_7.sh: Adjust expected address of the .bss
section.
* testsuite/script_test_9.sh: Do not expect the .init section to
immediately follow the .text section in the mapping of sections to
segments.
Jan Beulich [Wed, 8 Jul 2020 09:20:09 +0000 (11:20 +0200)]
x86: various XOP insns lack L and/or W bit decoding
While some insns support both XOP.W based operand swapping and 256-bit
operation (XOP.L=1), many others don't support one or both.
For {L,S}LWPCB also fix the so far not decoded ModRM.mod == 3
restriction.
Take the opportunity and replace the custom OP_LWP_E() and OP_LWPCB_E()
routines by suitable other, non-custom operanbd specifiers.
Jan Beulich [Wed, 8 Jul 2020 09:19:26 +0000 (11:19 +0200)]
x86: FMA4 scalar insns ignore VEX.L
Just like other VEX-encoded scalar insns do.
Besides a testcase for this behavior also introduce one to verify that
XOP scalar insns don't honor -mavxscalar=256, as they don't ignore
XOP.L.
Jan Beulich [Wed, 8 Jul 2020 09:03:07 +0000 (11:03 +0200)]
x86: re-work operand swapping for XOP shift/rotate insns
There's no need for custom operand handling here, except for the VEX.W
controlled operand swapping.
Jan Beulich [Wed, 8 Jul 2020 09:02:40 +0000 (11:02 +0200)]
x86: re-work operand handling for 5-operand XOP insns
There's no need for custom operand handling here, except for the VEX.W
controlled operand swapping and the printing of the remaining 4-bit
immediate. VEX.W can be handled just like 4-operand insns.
Also take the opportunity and drop the stray indirection through
vex_w_table[].
Jan Beulich [Wed, 8 Jul 2020 09:02:08 +0000 (11:02 +0200)]
x86: re-work operand swapping for FMA4 and 4-operand XOP insns
There's no need for custom operand handling here, except for the VEX.W
controlled operand swapping. The latter can be easily integrated into
OP_REG_VexI4().
Alan Modra [Wed, 8 Jul 2020 05:41:24 +0000 (15:11 +0930)]
powerpc-aix5.2 tests
git commit
bbd0c8e20472 broke many of these tests, and there have been
other changes that caused failures too.
* testsuite/lib/ld-lib.exp (ar_simple_create): Pass options before
ar command.
* testsuite/ld-powerpc/aix52.exp: Run for rs6000-aix5.2. Update
match files.
* testsuite/ld-powerpc/aix-abs-branch-1.dd: Update.
* testsuite/ld-powerpc/aix-core-sec-1.hd: Update.
* testsuite/ld-powerpc/aix-gc-1-32.dd: Update.
* testsuite/ld-powerpc/aix-gc-1-64.dd: Update.
* testsuite/ld-powerpc/aix-glink-1-32.dd: Update.
* testsuite/ld-powerpc/aix-glink-1-64.dd: Update.
* testsuite/ld-powerpc/aix-glink-2-32.dd: Update.
* testsuite/ld-powerpc/aix-glink-2-64.dd: Update.
* testsuite/ld-powerpc/aix-no-dup-syms-1-rel.rd: Update.
* testsuite/ld-powerpc/aix-ref-1-32.od: Update.
* testsuite/ld-powerpc/aix-ref-1-64.od: Update.
* testsuite/ld-powerpc/aix-toc-1-32.dd: Update.
* testsuite/ld-powerpc/aix-toc-1-64.dd: Update.
* testsuite/ld-powerpc/aix-weak-3-32.dd: Update.
* testsuite/ld-powerpc/aix-weak-3-64.dd: Update.
* testsuite/ld-powerpc/aix-abs-branch-1.nd: Delete, replace with..
* testsuite/ld-powerpc/aix-abs-branch-1-32.nd,
* testsuite/ld-powerpc/aix-abs-branch-1-64.nd: ..these new files.
* testsuite/ld-powerpc/aix-abs-reloc-1.nd: Delete, replace with..
* testsuite/ld-powerpc/aix-abs-reloc-1-32.nd,
* testsuite/ld-powerpc/aix-abs-reloc-1-64.nd: ..these new files.
* testsuite/ld-powerpc/aix-abs-reloc-1.od: Delete, replace with..
* testsuite/ld-powerpc/aix-abs-reloc-1-32.od,
* testsuite/ld-powerpc/aix-abs-reloc-1-64.od: ..these new files.
* testsuite/ld-powerpc/aix-export-1-all.dd: Delete, replace with..
* testsuite/ld-powerpc/aix-export-1-all-32.dd,
* testsuite/ld-powerpc/aix-export-1-all-64.dd: ..these new files.
* testsuite/ld-powerpc/aix-export-1-full.dd: Delete, replace with..
* testsuite/ld-powerpc/aix-export-1-full-32.dd,
* testsuite/ld-powerpc/aix-export-1-full-64.dd: ..these new files.
* testsuite/ld-powerpc/aix-export-2.nd: Delete, replace with..
* testsuite/ld-powerpc/aix-export-2-32.nd,
* testsuite/ld-powerpc/aix-export-2-64.nd: ..these new files.
* testsuite/ld-powerpc/aix-gc-1.nd: Delete, replace with..
* testsuite/ld-powerpc/aix-gc-1-32.nd,
* testsuite/ld-powerpc/aix-gc-1-64.nd: ..these new files.
* testsuite/ld-powerpc/aix-glink-3.dd: Delete, replace with..
* testsuite/ld-powerpc/aix-glink-3-32.dd,
* testsuite/ld-powerpc/aix-glink-3-64.dd: ..these new files.
* testsuite/ld-powerpc/aix-lineno-1a.dd: Delete, replace with..
* testsuite/ld-powerpc/aix-lineno-1a-32.dd,
* testsuite/ld-powerpc/aix-lineno-1a-64.dd: ..these new files.
* testsuite/ld-powerpc/aix-lineno-1a.nd: Delete, replace with..
* testsuite/ld-powerpc/aix-lineno-1a-32.nd,
* testsuite/ld-powerpc/aix-lineno-1a-64.nd: ..these new files.
* testsuite/ld-powerpc/aix-lineno-1b.dd: Delete, replace with..
* testsuite/ld-powerpc/aix-lineno-1b-32.dd,
* testsuite/ld-powerpc/aix-lineno-1b-64.dd: ..these new files.
* testsuite/ld-powerpc/aix-lineno-1b.nd: Delete, replace with..
* testsuite/ld-powerpc/aix-lineno-1b-32.nd,
* testsuite/ld-powerpc/aix-lineno-1b-64.nd: ..these new files.
* testsuite/ld-powerpc/aix-no-dup-syms-1-dso.dnd: Delete, replace with..
* testsuite/ld-powerpc/aix-no-dup-syms-1-dso-32.dnd,
* testsuite/ld-powerpc/aix-no-dup-syms-1-dso-64.dnd: ..these new files.
* testsuite/ld-powerpc/aix-no-dup-syms-1-dso.drd: Delete, replace with..
* testsuite/ld-powerpc/aix-no-dup-syms-1-dso-32.drd,
* testsuite/ld-powerpc/aix-no-dup-syms-1-dso-64.drd: ..these new files.
* testsuite/ld-powerpc/aix-no-dup-syms-1-dso.nd: Delete, replace with..
* testsuite/ld-powerpc/aix-no-dup-syms-1-dso-32.nd,
* testsuite/ld-powerpc/aix-no-dup-syms-1-dso-64.nd: ..these new files.
* testsuite/ld-powerpc/aix-no-dup-syms-1-dso.rd: Delete, replace with..
* testsuite/ld-powerpc/aix-no-dup-syms-1-dso-32.rd,
* testsuite/ld-powerpc/aix-no-dup-syms-1-dso-64.rd: ..these new files.
* testsuite/ld-powerpc/aix-weak-1-dso.dnd: Delete, replace with..
* testsuite/ld-powerpc/aix-weak-1-dso-32.dnd,
* testsuite/ld-powerpc/aix-weak-1-dso-64.dnd: ..these new files.
* testsuite/ld-powerpc/aix-weak-1-dso.hd: Delete, replace with..
* testsuite/ld-powerpc/aix-weak-1-dso-32.hd,
* testsuite/ld-powerpc/aix-weak-1-dso-64.hd: ..these new files.
* testsuite/ld-powerpc/aix-weak-1-dso.nd: Delete, replace with..
* testsuite/ld-powerpc/aix-weak-1-dso-32.nd,
* testsuite/ld-powerpc/aix-weak-1-dso-64.nd: ..these new files.
* testsuite/ld-powerpc/aix-weak-1-gcdso.dnd: Delete, replace with..
* testsuite/ld-powerpc/aix-weak-1-gcdso-32.dnd,
* testsuite/ld-powerpc/aix-weak-1-gcdso-64.dnd: ..these new files.
* testsuite/ld-powerpc/aix-weak-1-gcdso.hd: Delete, replace with..
* testsuite/ld-powerpc/aix-weak-1-gcdso-32.hd,
* testsuite/ld-powerpc/aix-weak-1-gcdso-64.hd: ..these new files.
* testsuite/ld-powerpc/aix-weak-1-gcdso.nd: Delete, replace with..
* testsuite/ld-powerpc/aix-weak-1-gcdso-32.nd,
* testsuite/ld-powerpc/aix-weak-1-gcdso-64.nd: ..these new files.
* testsuite/ld-powerpc/aix-weak-2a.nd: Delete, replace with..
* testsuite/ld-powerpc/aix-weak-2a-32.nd,
* testsuite/ld-powerpc/aix-weak-2a-64.nd: ..these new files.
* testsuite/ld-powerpc/aix-weak-2b.nd: Delete, replace with..
* testsuite/ld-powerpc/aix-weak-2b-32.nd,
* testsuite/ld-powerpc/aix-weak-2b-64.nd: ..these new files.
* testsuite/ld-powerpc/aix-weak-2c.nd: Delete, replace with..
* testsuite/ld-powerpc/aix-weak-2c-32.nd,
* testsuite/ld-powerpc/aix-weak-2c-64.nd: ..these new files.
* testsuite/ld-powerpc/aix-weak-2c.od: Delete, replace with..
* testsuite/ld-powerpc/aix-weak-2c-32.od,
* testsuite/ld-powerpc/aix-weak-2c-64.od: ..these new files.
GDB Administrator [Wed, 8 Jul 2020 00:00:09 +0000 (00:00 +0000)]
Automatic date update in version.in
Claudiu Zissulescu [Tue, 7 Jul 2020 13:01:48 +0000 (16:01 +0300)]
arc: Improve error messages when assembling
gas/
xxxx-xx-xx Claudiu Zissulescu <claziss@synopsys.com>
* config/tc-arc.c (find_opcode_match): Add error messages.
* testsuite/gas/arc/add_s-err.s: Update test.
* testsuite/gas/arc/asm-errors.err: Likewise.
* testsuite/gas/arc/cpu-em-err.s: Likewise.
* testsuite/gas/arc/hregs-err.s: Likewise.
* testsuite/gas/arc/warn.s: Likewise.
Claudiu Zissulescu [Tue, 7 Jul 2020 13:01:48 +0000 (16:01 +0300)]
arc: Update vector instructions.
Update vadd2, vadd4h, vmac2h, vmpy2h, vsub4h vector instructions
arguments to discriminate between double/single register operands.
opcodes/
xxxx-xx-xx Claudiu Zissulescu <claziss@synopsys.com>
* arc-opc.c (insert_rbd): New function.
(RBD): Define.
(RBDdup): Likewise.
* arc-tbl.h (vadd2, vadd4h, vmac2h, vmpy2h, vsub4h): Update
instructions.
Signed-off-by: Claudiu Zissulescu <claziss@gmail.com>
Alan Modra [Tue, 7 Jul 2020 12:23:03 +0000 (21:53 +0930)]
Re: Use is_xcoff_format in ld testsuite
git commit
7193487fa8 took h8300 out of the notarget list, resulting in
h8300-elf +FAIL: ld-scripts/section-match-1
h8300-linux +FAIL: ld-scripts/section-match-1
* testsuite/ld-scripts/section-match-1.d: xfail h8300.
H.J. Lu [Tue, 7 Jul 2020 12:06:38 +0000 (05:06 -0700)]
x86: Remove an incorrect AVX2 entry
The upper 16 vector registers were added by AVX512.
PR gas/26212
* doc/c-i386.texi: Remove an incorrect AVX2 entry.
Alan Modra [Mon, 6 Jul 2020 06:45:35 +0000 (16:15 +0930)]
XCOFF ld testsuite fixes
* testsuite/ld-scripts/align.exp: Don't exclude xcoff. Pass
-bnogc ld option for xcoff.
* testsuite/ld-scripts/provide.exp: Likewise.
* testsuite/ld-scripts/data.exp: Pass -bnogc ld option for xcoff.
* testsuite/ld-scripts/default-script.exp: Likewise.
* testsuite/ld-scripts/defined.exp: Likewise.
* testsuite/ld-scripts/empty-address.exp: Likewise.
* testsuite/ld-scripts/expr.exp: Likewise.
* testsuite/ld-scripts/include.exp: Likewise.
* testsuite/ld-scripts/script.exp: Likewise.
* testsuite/ld-scripts/assign-loc.d: Don't exclude xcoff.
* testsuite/ld-scripts/defined3.d: Likewise.
* testsuite/ld-scripts/defined4.d: Likewise.
* testsuite/ld-scripts/pr18963.d: Likewise.
* testsuite/ld-scripts/sane1.d: Likewise.
* testsuite/ld-scripts/segment-start.d: Likewise.
* testsuite/ld-scripts/include-1.d: Likewise, and relax text vma.
* testsuite/ld-scripts/defined5.d: Update xfail and comment.
* testsuite/ld-scripts/defined5.s: Tweak "defined" to be at
non-zero section offset.
* testsuite/ld-scripts/fill16.d: xfail for xcoff.
* testsuite/ld-scripts/provide-2.d: Accept more symbols.
* testsuite/ld-scripts/provide-4.d: Likewise.
* testsuite/ld-scripts/provide-5.d: Likewise.
* testsuite/ld-scripts/provide-6.d: Likewise.
* testsuite/ld-scripts/provide-7.d: Likewise.
* testsuite/ld-scripts/align.t: Accept xcoff mapped .text and .data.
* testsuite/ld-scripts/defined3.t: Likewise.
* testsuite/ld-scripts/defined4.t: Likewise.
* testsuite/ld-scripts/defined5.t: Likewise.
* testsuite/ld-scripts/fill.t: Likewise.
* testsuite/ld-scripts/include-subdata.t: Likewise.
* testsuite/ld-scripts/provide-1.t: Likewise.
* testsuite/ld-scripts/provide-2.t: Likewise.
* testsuite/ld-scripts/provide-3.t: Likewise.
* testsuite/ld-scripts/provide-4.t: Likewise.
* testsuite/ld-scripts/provide-5.t: Likewise.
* testsuite/ld-scripts/provide-6.t: Likewise.
* testsuite/ld-scripts/provide-7.t: Likewise.
* testsuite/ld-scripts/provide-8.t: Likewise.
* testsuite/ld-scripts/assign-loc.t: Add required xcoff sections.
* testsuite/ld-scripts/sizeof.t: Likewise.
* testsuite/ld-scripts/align2.t: Likewise, and mapped sections.
* testsuite/ld-scripts/align5.t: Likewise.
* testsuite/ld-scripts/default-script.t: Likewise.
* testsuite/ld-scripts/empty-address-1.t: Likewise.
* testsuite/ld-scripts/empty-address-2a.t: Likewise.
* testsuite/ld-scripts/empty-address-2b.t: Likewise.
* testsuite/ld-scripts/empty-address-3a.t: Likewise.
* testsuite/ld-scripts/empty-address-3b.t: Likewise.
* testsuite/ld-scripts/empty-address-3c.t: Likewise.
* testsuite/ld-scripts/include-sections.t: Likewise.
* testsuite/ld-scripts/pr14962.t: Likewise.
* testsuite/ld-scripts/sane1.t: Likewise.
Alan Modra [Tue, 7 Jul 2020 03:28:12 +0000 (12:58 +0930)]
Use is_pecoff_format in ld testsuite
--image-base 0 is not just for x86_64 mingw. This patch fixes that,
and a case where a changed LDFLAGS leaked out of one script to the next.
* testsuite/ld-scripts/align.exp: Use is_pecoff_format.
* testsuite/ld-scripts/defined.exp: Likewise.
* testsuite/ld-scripts/provide.exp: Likewise.
* testsuite/ld-scripts/weak.exp: Likewise.
* testsuite/ld-scripts/empty-address.exp: Likewise. Reset LDFLAGS
on exit.
* testsuite/ld-scripts/expr.exp: Set LDFLAGS earlier, and with
--image-base for PE.
* testsuite/ld-scripts/include.exp: Set LDFLAGS for PE.
* testsuite/ld-scripts/script.exp: Use is_pecoff_format, and
set LDFLAGS as well as flags.
Alan Modra [Tue, 7 Jul 2020 03:11:55 +0000 (12:41 +0930)]
Use is_xcoff_format in ld testsuite
* testsuite/ld-checks/checks.exp: Use is_xcoff_format.
* testsuite/ld-powerpc/powerpc.exp: Likewise.
* testsuite/ld-scripts/print-memory-usage.exp: Likewise.
* testsuite/ld-srec/srec.exp: Likewise.
* testsuite/ld-undefined/require-defined.exp: Likewise.
* testsuite/ld-scripts/expr2.d: Likewise.
* testsuite/ld-scripts/section-match-1.d: Only run for ELF.
* testsuite/ld-elfvers/vers.exp: Delete dead code.
* testsuite/ld-elfvsb/elfvsb.exp: Likewise.
* testsuite/ld-elfweak/elfweak.exp: Likewise.
Alan Modra [Tue, 7 Jul 2020 02:20:52 +0000 (11:50 +0930)]
Use is_xcoff_format in gas testsuite
* testsuite/gas/all/gas.exp: Use is_xcoff_format.
* testsuite/gas/ppc/ppc.exp: Likewise.
* testsuite/gas/all/weakref1l.d: Likewise.
Alan Modra [Tue, 7 Jul 2020 02:00:12 +0000 (11:30 +0930)]
Use is_xcoff_format in binutils testsuite
and restrict some other tests using is_*_format.
* testsuite/binutils-all/ar.exp: Use is_xcoff_format.
* testsuite/binutils-all/nm.exp: Likewise.
* testsuite/binutils-all/copy-2.d: Run only for elf and pe targets.
* testsuite/binutils-all/copy-3.d: Run only for elf targets.
* testsuite/binutils-all/set-section-alignment.d: Likewise.
* testsuite/binutils-all/copy-4.d: Don't run for xcoff.
Alan Modra [Tue, 7 Jul 2020 00:53:06 +0000 (10:23 +0930)]
XCOFF binutils testsuite fix
Avoid an UNRESOLVED test due to "Error: the XCOFF file format does not
support arbitrary sections".
* testsuite/lib/binutils-common.exp (is_xcoff_format): New.
* testsuite/binutils-all/objcopy.exp (pr25662): Exclude xcoff.
Alan Modra [Tue, 7 Jul 2020 00:47:21 +0000 (10:17 +0930)]
XCOFF linker script PROVIDE support
Fixes bit rot from git commit
b46a87b1606.
* emultempl/aix.em (gld${EMULATION_NAME}_find_exp_assignment): Handle
etree_provided.
Alan Modra [Tue, 7 Jul 2020 00:28:10 +0000 (09:58 +0930)]
XCOFF ld segfaults when running ld testsuite
The binutils XCOFF support doesn't handle random linker scripts very
well at all. These tweaks to final_link fix segfaults when some
linker created sections are discarded due to "/DISCARD/ : { *(.*) }"
in scripts. The xcoff_mark change is necessary to not segfault on
symbols defined in scripts, which may be bfd_link_hash_defined yet
have u.def.section set to bfd_und_section_ptr. (Which might seem odd,
but occurs during early stages of linking before input sections are
mapped.)
* xcofflink.c (xcoff_mark): Don't mark const sections.
(bfd_xcoff_record_link_assignment): Add FIXME.
(_bfd_xcoff_bfd_final_link): Don't segfault on assorted magic
sections being discarded by linker script.
Alan Modra [Tue, 7 Jul 2020 00:22:21 +0000 (09:52 +0930)]
XCOFF deterministic archives
Adds support for "ar -D".
* coff-rs6000.c (xcoff_write_archive_contents_old): Set default
time, uid, gid and mode for deterministic archive.
(xcoff_write_archive_contents_big): Likewise.
Alan Modra [Mon, 6 Jul 2020 23:57:17 +0000 (09:27 +0930)]
XCOFF C_HIDEXT and C_AIX_WEAKEXT classification
If C_HIDEXT and C_AIX_WEAKEXT symbols aren't handled as globals by
coff_classify_symbol then we run into "warning: .. local symbol `some
garbage name' has no section". These are of course both global
symbols, but C_HIDEXT is like a local in some respects and returning
COFF_SYMBOL_LOCAL for C_HIDEXT keeps nm output looking the same.
Fixes these fails on rs6000-aix5.1:
-FAIL: weakref tests, relocations
-FAIL: weakref tests, global syms
-FAIL: weakref tests, strong undefined syms
-FAIL: weakref tests, weak undefined syms
* coffcode.h (coff_classify_symbol): Handle C_HIDEXT and
C_AIX_WEAKEXT.
Alan Modra [Mon, 6 Jul 2020 23:55:38 +0000 (09:25 +0930)]
sh vxworks tests
These tests were failing only due to not being updated for readelf
output changes.
* testsuite/ld-sh/vxworks1-lib.rd: Update expected output.
* testsuite/ld-sh/vxworks4.d: Likewise.
Nick Clifton [Tue, 7 Jul 2020 08:54:09 +0000 (09:54 +0100)]
Stop the GOLD linker from complaining about relocations from .gnu.build.attributes sections to discarded code sections.
* target-reloc.h (Default_comdat_behaviour:get): Ignore discarded
relocs that refer to the .gnu.build.attributes section.
Nick Clifton [Tue, 7 Jul 2020 08:37:38 +0000 (09:37 +0100)]
Fix recent failures in the ARM assembler testsuite due to the correction of a spelling mistake.
* testsuite/gas/arm/cde-missing-fp.l: Fix spelling mistake in
expected output.
Jan Beulich [Tue, 7 Jul 2020 06:08:09 +0000 (08:08 +0200)]
x86: introduce %BW to avoid going through vex_w_table[]
This parallels %LW and %XW.
GDB Administrator [Tue, 7 Jul 2020 00:00:09 +0000 (00:00 +0000)]
Automatic date update in version.in
Andrew Burgess [Mon, 8 Jun 2020 10:36:13 +0000 (11:36 +0100)]
gdb: Python unwinders, inline frames, and tail-call frames
This started with me running into the bug described in python/22748,
in summary, if the frame sniffing code accessed any registers within
an inline frame then GDB would crash with this error:
gdb/frame.c:579: internal-error: frame_id get_frame_id(frame_info*): Assertion `fi->level == 0' failed.
The problem is that, when in the Python unwinder I write this:
pending_frame.read_register ("register-name")
This is translated internally into a call to `value_of_register',
which in turn becomes a call to `value_of_register_lazy'.
Usually this isn't a problem, `value_of_register_lazy' requires the
next frame (more inner) to have a valid frame_id, which will be the
case (if we're sniffing frame #1, then frame #0 will have had its
frame-id figured out).
Unfortunately if frame #0 is inline within frame #1, then the frame-id
for frame #0 can't be computed until we have the frame-id for #1. As
a result we can't create a lazy register for frame #1 when frame #0 is
inline.
Initially I proposed a solution inline with that proposed in bugzilla,
changing value_of_register to avoid creating a lazy register value.
However, when this was discussed on the mailing list I got this reply:
https://sourceware.org/pipermail/gdb-patches/2020-June/169633.html
Which led me to look at these two patches:
[1] https://sourceware.org/pipermail/gdb-patches/2020-April/167612.html
[2] https://sourceware.org/pipermail/gdb-patches/2020-April/167930.html
When I considered patches [1] and [2] I saw that all of the issues
being addressed here were related, and that there was a single
solution that could address all of these issues.
First I wrote the new test gdb.opt/inline-frame-tailcall.exp, which
shows that [1] and [2] regress the inline tail-call unwinder, the
reason for this is that these two patches replace a call to
gdbarch_unwind_pc with a call to get_frame_register, however, this is
not correct. The previous call to gdbarch_unwind_pc takes THIS_FRAME
and returns the $pc value in the previous frame. In contrast
get_frame_register takes THIS_FRAME and returns the value of the $pc
in THIS_FRAME; these calls are not equivalent.
The reason these patches appear (or do) fix the regressions listed in
[1] is that the tail call sniffer depends on identifying the address
of a caller and a callee, GDB then looks for a tail-call sequence that
takes us from the caller address to the callee, if such a series is
found then tail-call frames are added.
The bug that was being hit, and which was address in patch [1] is that
in order to find the address of the caller, GDB ended up creating a
lazy register value for an inline frame with to frame-id. The
solution in patch [1] is to instead take the address of the callee and
treat this as the address of the caller. Getting the address of the
callee works, but we then end up looking for a tail-call series from
the callee to the callee, which obviously doesn't return any sane
results, so we don't insert any tail call frames.
The original patch [1] did cause some breakage, so patch [2] undid
patch [1] in all cases except those where we had an inline frame with
no frame-id. It just so happens that there were no tests that fitted
this description _and_ which required tail-call frames to be
successfully spotted, as a result patch [2] appeared to work.
The new test inline-frame-tailcall.exp, exposes the flaw in patch [2].
This commit undoes patch [1] and [2], and replaces them with a new
solution, which is also different to the solution proposed in the
python/22748 bug report.
In this solution I propose that we introduce some special case logic
to value_of_register_lazy. To understand what this logic is we must
first look at how inline frames unwind registers, this is very simple,
they do this:
static struct value *
inline_frame_prev_register (struct frame_info *this_frame,
void **this_cache, int regnum)
{
return get_frame_register_value (this_frame, regnum);
}
And remember:
struct value *
get_frame_register_value (struct frame_info *frame, int regnum)
{
return frame_unwind_register_value (frame->next, regnum);
}
So in all cases, unwinding a register in an inline frame just asks the
next frame to unwind the register, this makes sense, as an inline
frame doesn't really exist, when we unwind a register in an inline
frame, we're really just asking the next frame for the value of the
register in the previous, non-inline frame.
So, if we assume that we only get into the missing frame-id situation
when we try to unwind a register from an inline frame during the frame
sniffing process, then we can change value_of_register_lazy to not
create lazy register values for an inline frame.
Imagine this stack setup, where #1 is inline within #2.
#3 -> #2 -> #1 -> #0
\______/
inline
Now when trying to figure out the frame-id for #1, we need to compute
the frame-id for #2. If the frame sniffer for #2 causes a lazy
register read in #2, either due to a Python Unwinder, or for the
tail-call sniffer, then we call value_of_register_lazy passing in
frame #2.
In value_of_register_lazy, we grab the next frame, which is #1, and we
used to then ask for the frame-id of #1, which was not computed, and
this was our bug.
Now, I propose we spot that #1 is an inline frame, and so lookup the
next frame of #1, which is #0. As #0 is not inline it will have a
valid frame-id, and so we create a lazy register value using #0 as the
next-frame-id. This will give us the exact same result we had
previously (thanks to the code we inspected above).
Encoding into value_of_register_lazy the knowledge that reading an
inline frame register will always just forward to the next frame
feels.... not ideal, but this seems like the cleanest solution to this
recursive frame-id computation/sniffing issue that appears to crop
up.
The following two commits are fully reverted with this commit, these
correspond to patches [1] and [2] respectively:
commit
5939967b355ba6a940887d19847b7893a4506067
Date: Tue Apr 14 17:26:22 2020 -0300
Fix inline frame unwinding breakage
commit
991a3e2e9944a4b3a27bd989ac03c18285bd545d
Date: Sat Apr 25 00:32:44 2020 -0300
Fix remaining inline/tailcall unwinding breakage for x86_64
gdb/ChangeLog:
PR python/22748
* dwarf2/frame-tailcall.c (dwarf2_tailcall_sniffer_first): Remove
special handling for inline frames.
* findvar.c (value_of_register_lazy): Skip inline frames when
creating lazy register values.
* frame.c (frame_id_computed_p): Delete definition.
* frame.h (frame_id_computed_p): Delete declaration.
gdb/testsuite/ChangeLog:
PR python/22748
* gdb.opt/inline-frame-tailcall.c: New file.
* gdb.opt/inline-frame-tailcall.exp: New file.
* gdb.python/py-unwind-inline.c: New file.
* gdb.python/py-unwind-inline.exp: New file.
* gdb.python/py-unwind-inline.py: New file.
Andrew Burgess [Sun, 7 Jun 2020 09:08:01 +0000 (10:08 +0100)]
gdb/python: New method to access list of register groups
Add a new method gdb.Architecture.register_groups which returns a new
object of type gdb.RegisterGroupsIterator. This new iterator then
returns objects of type gdb.RegisterGroup.
Each gdb.RegisterGroup object just wraps a single reggroup pointer,
and (currently) has just one read-only property 'name' that is a
string, the name of the register group.
As with the previous commit (adding gdb.RegisterDescriptor) I made
gdb.RegisterGroup an object rather than just a string in case we want
to add additional properties in the future.
gdb/ChangeLog:
* NEWS: Mention additions to Python API.
* python/py-arch.c (archpy_register_groups): New function.
(arch_object_methods): Add 'register_groups' method.
* python/py-registers.c (reggroup_iterator_object): New struct.
(reggroup_object): New struct.
(gdbpy_new_reggroup): New function.
(gdbpy_reggroup_to_string): New function.
(gdbpy_reggroup_name): New function.
(gdbpy_reggroup_iter): New function.
(gdbpy_reggroup_iter_next): New function.
(gdbpy_new_reggroup_iterator): New function
(gdbpy_initialize_registers): Register new types.
(reggroup_iterator_object_type): Define new Python type.
(gdbpy_reggroup_getset): New static global.
(reggroup_object_type): Define new Python type.
* python/python-internal.h
gdb/testsuite/ChangeLog:
* gdb.python/py-arch-reg-groups.exp: New file.
gdb/doc/ChangeLog:
* gdb.texi (Registers): Add @anchor for 'info registers
<reggroup>' command.
* python.texi (Architectures In Python): Document new
register_groups method.
(Registers In Python): Document two new object types related to
register groups.
Andrew Burgess [Fri, 5 Jun 2020 16:52:10 +0000 (17:52 +0100)]
gdb/python: Add gdb.Architecture.registers method
This commit adds a new method gdb.Architecture.registers that returns
an object of the new type gdb.RegisterDescriptorIterator. This
iterator returns objects of the new type gdb.RegisterDescriptor.
A RegisterDescriptor is not a way to read the value of a register,
this is already covered by Frame.read_register, a RegisterDescriptor
is simply a way to discover from Python, which registers are
available for a given architecture.
I did consider just returning a string, the name of each register,
instead of a RegisterDescriptor, however, I'm aware that it we don't
want to break the existing Python API in any way, so if I return just
a string now, but in the future we want more information about a
register then we would have to add a second API to get that
information. By going straight to a descriptor object now, it is easy
to add additional properties in the future should we wish to.
Right now the only property of a register that a user can access is
the name of the register.
In future we might want to be able to ask the register about is
register groups, or its type.
gdb/ChangeLog:
* Makefile.in (SUBDIR_PYTHON_SRCS): Add py-registers.c
* python/py-arch.c (archpy_registers): New function.
(arch_object_methods): Add 'registers' method.
* python/py-registers.c: New file.
* python/python-internal.h
(gdbpy_new_register_descriptor_iterator): Declare.
(gdbpy_initialize_registers): Declare.
* python/python.c (do_start_initialization): Call
gdbpy_initialize_registers.
* NEWS: Mention additions to the Python API.
gdb/testsuite/ChangeLog:
* gdb.python/py-arch-reg-names.exp: New file.
gdb/doc/ChangeLog:
* python.texi (Python API): Add new section the menu.
(Frames In Python): Add new @anchor.
(Architectures In Python): Document new registers method.
(Registers In Python): New section.
Andrew Burgess [Sun, 7 Jun 2020 22:07:52 +0000 (23:07 +0100)]
gdb/python: Add architecture method to gdb.PendingFrame
It could be useful to determine the architecture of a frame being
unwound during the frame unwind process, that is, before we have a
gdb.Frame, but when we only have a gdb.PendingFrame.
The PendingFrame already has a pointer to the gdbarch internally, this
commit just exposes an 'architecture' method to Python, and has this
return a gdb.Architecture object (list gdb.Frame.architecture does).
gdb/ChangeLog:
* NEWS: Mention new Python API method.
* python/py-unwind.c (pending_framepy_architecture): New function.
(pending_frame_object_methods): Add architecture method.
gdb/testsuite/ChangeLog:
* gdb.python/py-unwind.py (TestUnwinder::__call__): Add test for
gdb.PendingFrame.architecture method.
gdb/doc/ChangeLog:
* python.texi (Unwinding Frames in Python): Document
PendingFrame.architecture method.
Andrew Burgess [Mon, 8 Jun 2020 13:06:08 +0000 (14:06 +0100)]
gdb: Remove deprecated_set_gdbarch_data
There are currently two remaining uses of deprecated_set_gdbarch_data,
both of which are needed because during gdbarch initialisation we call
gdbarch_data for a data field that is registered using:
gdbarch_data_register_post_init (....)
However, in both of these cases, the only thing that the call back
needs from the gdbarch struct is its obstack. Given this there is
nothing stopping us changing the post-init hooks into pre-init hooks.
The pre-init hooks don't get passed the full gdbarch, they only get
passed its obstack.
The IA64 change is completely untested. The user-regs change has been
tested a little by locally adding some user-regs to the x86-64 target,
and also by running the RISC-V tests, which do use user-regs.
gdb/ChangeLog:
* gdbarch.c: Regenerate.
* gdbarch.h: Regenerate.
* gdbarch.sh (deprecated_set_gdbarch_data): Delete.
(gdbarch_data): Use internal_error for the case where
deprecated_set_gdbarch_data was originally needed.
* ia64-libunwind-tdep.c (libunwind_descr_init): Update parameters,
and use passed in obstack.
(libunwind_frame_set_descr): Should no longer get back NULL from
gdbarch_data.
(_initialize_libunwind_frame): Register as a pre-init gdbarch data
type.
* user-regs.c (user_regs_init): Update parameters, and use passed
in obstack.
(user_reg_add): Should no longer get back NULL from gdbarch_data.
(_initialize_user_regs): Register as a pre-init gdbarch data type.
Tom de Vries [Mon, 6 Jul 2020 12:28:58 +0000 (14:28 +0200)]
[gdb/symtab] Fix line-table end-of-sequence sorting
Consider test-case gdb.dwarf2/dw2-ranges-base.exp. It has (ignoring
non-sensical entries that are filtered out by buildsym_compunit::record_line)
a line-table for dw2-ranges-base.c like this:
...
Line Number Statements:
[0x0000014e] Extended opcode 2: set Address to 0x4004ba
[0x00000159] Advance Line by 10 to 11
[0x0000015b] Copy
[0x0000015c] Advance PC by 12 to 0x4004c6
[0x0000015e] Extended opcode 1: End of Sequence
[0x00000161] Extended opcode 2: set Address to 0x4004ae
[0x0000016c] Advance Line by 20 to 21
[0x0000016e] Copy
[0x0000016f] Advance PC by 12 to 0x4004ba
[0x00000171] Extended opcode 1: End of Sequence
[0x00000174] Extended opcode 2: set Address to 0x4004a7
[0x0000017f] Advance Line by 30 to 31
[0x00000181] Copy
[0x00000182] Advance PC by 7 to 0x4004ae
[0x00000184] Extended opcode 1: End of Sequence
...
If we disable the sorting in buildsym_compunit::end_symtab_with_blockvector,
we have the unsorted line table:
...
INDEX LINE ADDRESS IS-STMT
0 11 0x00000000004004ba Y
1 END 0x00000000004004c6 Y
2 21 0x00000000004004ae Y
3 END 0x00000000004004ba Y
4 31 0x00000000004004a7 Y
5 END 0x00000000004004ae Y
...
It contains 3 sequences, 11/END, 21/END and 31/END.
We want to sort the 3 sequences relative to each other, while sorting on
address, to get:
...
INDEX LINE ADDRESS IS-STMT
0 31 0x00000000004004a7 Y
1 END 0x00000000004004ae Y
2 21 0x00000000004004ae Y
3 END 0x00000000004004ba Y
4 11 0x00000000004004ba Y
5 END 0x00000000004004c6 Y
...
However, if we re-enable the sorting, we have instead:
...
INDEX LINE ADDRESS IS-STMT
0 31 0x00000000004004a7 Y
1 21 0x00000000004004ae Y
2 END 0x00000000004004ae Y
3 11 0x00000000004004ba Y
4 END 0x00000000004004ba Y
5 END 0x00000000004004c6 Y
...
This is a regression since commit
3d92a3e313 "gdb: Don't reorder line table
entries too much when sorting", that introduced sorting on address while
keeping entries with the same address in pre-sort order.
Indeed the entries 1 and 2 are in pre-sort order (they map to entries 2 and 5
in the unsorted line table), but entry 1 does not belong in the sequence
terminated by 2.
Fix this by handling End-Of-Sequence entries in the sorting function, such
that they are sorted before other entries with the same address.
Also, revert the find_pc_sect_line workaround introduced in commit
3d92a3e313,
since that's no longer necessary.
Tested on x86_64-linux.
gdb/ChangeLog:
2020-07-06 Tom de Vries <tdevries@suse.de>
* buildsym.c (buildsym_compunit::end_symtab_with_blockvector): Handle
End-Of-Sequence in lte_is_less_than.
* symtab.c (find_pc_sect_line): Revert change from commit
3d92a3e313
"gdb: Don't reorder line table entries too much when sorting".
gdb/testsuite/ChangeLog:
2020-07-06 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/dw2-ranges-base.exp: Test line-table order.
Jan Beulich [Mon, 6 Jul 2020 11:44:35 +0000 (13:44 +0200)]
x86: adjust/correct VFRCZ{P,S}{S,D} decoding
The unnecessary XOP.L decoding had caught my eye, together with the not
really expected operand specifiers. Drop this decode step, and instead
make sure XOP.W and XOP.PP don't get ignored. For the latter, do this in
a form applicable to all XOP insns, rather than adding extra table
layers - there are no encodings with the field non-zero. Besides these
two, for the scalar forms XOP.L actually needs to also be zero.
Jan Beulich [Mon, 6 Jul 2020 11:44:03 +0000 (13:44 +0200)]
x86: use %LW / %XW instead of going through vex_w_table[]
Since we have these macros, there's no point having unnecessary table
depth.
VFPCLASSP{S,D} are now the first instance of using two %-prefixed
macros, which has pointed out a problem with the implementation. Instead
of using custom code in various case blocks, do the macro accumulation
centralized at the top of the main loop of putop(), and zap the
accumulated macros at the bottom of that loop once it has been
processed.
Jan Beulich [Mon, 6 Jul 2020 11:43:34 +0000 (13:43 +0200)]
x86: most VBROADCAST{F,I}{32,64}x* only accept memory operands
VBROADCAST{F,I}32x2 are the only exceptions here.
Jan Beulich [Mon, 6 Jul 2020 11:43:05 +0000 (13:43 +0200)]
x86: adjust/correct V*{F,I}{32x8,64x4}
For all of these only the 512-bit forms are valid, so drop 256-bit ones
from the integer insert/extract variants.
Also replace EXxmmq by the more natural (here) EXymm.
Jan Beulich [Mon, 6 Jul 2020 11:42:33 +0000 (13:42 +0200)]
x86: drop EVEX table entries that can be made served by VEX ones
By doing the EVEX.W decode first, in various cases VEX table entries can
be re-used.
Jan Beulich [Mon, 6 Jul 2020 11:41:58 +0000 (13:41 +0200)]
x86: AVX512 VPERM{D,Q,PS,PD} insns need to honor EVEX.L'L
Just like (where they exist) their AVX counterparts do for VEX.L. For
all of them the 128-bit forms are invalid.
Jan Beulich [Mon, 6 Jul 2020 11:41:27 +0000 (13:41 +0200)]
x86: AVX512 extract/insert insns need to honor EVEX.L'L
Just like their AVX counterparts do for VEX.L.
At this occasion also make EVEX.W have the same effect as VEX.W on the
printing of VPINSR{B,W}'s operands, bringing them also in sync with
VPEXTR{B,W}.
Jan Beulich [Mon, 6 Jul 2020 11:40:40 +0000 (13:40 +0200)]
x86: honor VEX.W for VCVT{PH2PS,PS2PH}
Unlike for the EVEX-encoded versions, the VEX ones failed to decode
VEX.W. Once the necessary adjustments are done, it becomes obvious that
the EVEX and VEX table entries for VCVTPS2PH are identical and can hence
be folded.
Jan Beulich [Mon, 6 Jul 2020 11:40:13 +0000 (13:40 +0200)]
x86: drop EVEX table entries that can be served by VEX ones
The duplication is not only space inefficient, but also risks entries
going out of sync (some of which that I became aware of while doing this
work will get addressed subsequently). Right here note that for
VGF2P8MULB this also addresses the prior lack of EVEX.W decoding (i.e. a
first example of out of sync entries).
This introduces EXxEVexR to some VEX templates, on the basis that this
operand is benign there and only relevant when EVEX encoding ends up
reaching these entries.
Jan Beulich [Mon, 6 Jul 2020 11:35:38 +0000 (13:35 +0200)]
x86: replace EXqScalarS by EXqVexScalarS
There's only a single user, that that one can do fine with the
alternative, as the "Vex" aspect of the other operand kind is meaningful
only on 3-operand insns.
While doing this I noticed that I didn't need to do the same adjustment
in the EVEX tables, and voilà - there was a bug, which gets fixed at the
same time (see the testsuite changes).
Jan Beulich [Mon, 6 Jul 2020 11:34:36 +0000 (13:34 +0200)]
x86: replace EX{d,q}Scalar by EXxmm_m{d,q}
Along the lines of
4102be5cf925 ("x86: replace EXxmm_mdq by
EXVexWdqScalar"), but in the opposite direction, replace EXdScalar/
EXqScalar by EXxmm_md/EXxmm_mq respectively, rendering d_scalar_mode and
q_scalar_mode unused. The change is done this way to improve telling
apart operands affected here from ones using EXbScalar/EXwScalar, which
work sufficiently differently. Additionally this increases similarity
between several VEX-encoded insns and their EVEX-encoded counterparts.
Nick Clifton [Mon, 6 Jul 2020 09:54:36 +0000 (10:54 +0100)]
Fix spelling mistakes in some of the binutils sub-directories.
PR 26204
gas * config/tc-arm.c: Fix spelling mistake.
* config/tc-riscv.c: Likewise.
* config/tc-z80.c: Likewise.
* po/gas.pot: Regenerate.
ld * lexsup.c: Fix spelling mistake.
* po/ld.pot: Regenerate.
opcodes * arc-dis.c: Fix spelling mistake.
* po/opcodes.pot: Regenerate.
Nick Clifton [Mon, 6 Jul 2020 09:43:35 +0000 (10:43 +0100)]
Updated translations for various binutils sub-directories
Tom de Vries [Mon, 6 Jul 2020 07:54:43 +0000 (09:54 +0200)]
[gdb/tui,c++17] Fix NULL string_view in tui_partial_win_by_name
When building gdb with CFLAGS=-std=gnu17 and CXXFLAGS=-std=gnu++17 and running
test-case gdb.tui/new-layout.exp, we run into:
...
UNRESOLVED: gdb.tui/new-layout.exp: left window box after shrink (ll corner)
FAIL: gdb.tui/new-layout.exp: right window box after shrink (ll corner)
...
In a minimal form, we run into an abort when issuing a winheight command:
...
$ gdb -tui -ex "winheight src - 5"
<tui stuff>
Aborted (core dumped)
$
...
with this backtrace at the abort:
...
\#0 0x0000000000438db0 in std::char_traits<char>::length (__s=0x0)
at /usr/include/c++/9/bits/char_traits.h:335
\#1 0x000000000043b72e in std::basic_string_view<char, \
std::char_traits<char> >::basic_string_view (this=0x7fffffffd4f0, \
__str=0x0) at /usr/include/c++/9/string_view:124
\#2 0x000000000094971b in tui_partial_win_by_name (name="src")
at src/gdb/tui/tui-win.c:663
...
due to a NULL comparison which constructs a string_view object from NULL:
...
657 /* Answer the window represented by name. */
658 static struct tui_win_info *
659 tui_partial_win_by_name (gdb::string_view name)
660 {
661 struct tui_win_info *best = nullptr;
662
663 if (name != NULL)
...
In gdbsupport/gdb_string_view.h, we either use:
- gdb's copy of libstdc++-v3/include/experimental/string_view, or
- the standard implementation of string_view, when built with C++17 or later
(which in gcc's case comes from libstdc++-v3/include/std/string_view)
In the first case, there's support for constructing a string_view from a NULL
pointer:
...
/*constexpr*/ basic_string_view(const _CharT* __str)
: _M_len{__str == nullptr ? 0 : traits_type::length(__str)},
_M_str{__str}
{ }
...
but in the second case, there's not:
...
__attribute__((__nonnull__)) constexpr
basic_string_view(const _CharT* __str) noexcept
: _M_len{traits_type::length(__str)},
_M_str{__str}
{ }
...
Fix this by removing the NULL comparison altogether.
Build on x86_64-linux with CFLAGS=-std=gnu17 and CXXFLAGS=-std=gnu++17, and
tested.
gdb/ChangeLog:
2020-07-06 Tom de Vries <tdevries@suse.de>
PR tui/26205
* tui/tui-win.c (tui_partial_win_by_name): Don't test for NULL name.
Alan Modra [Sun, 5 Jul 2020 23:30:29 +0000 (09:00 +0930)]
asan: readelf: stack buffer overflow
* readelf.c (print_dynamic_symbol): Don't sprintf to buffer to
find string length.
GDB Administrator [Mon, 6 Jul 2020 00:00:07 +0000 (00:00 +0000)]
Automatic date update in version.in
projects / binutils-gdb.git / log