aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-07-13Updated French translation for the gas/ and binutils/ sub-directoriesNick Clifton4-4184/+4798
2020-07-13Use volatile pointers when attempting to trigger SIGSEGVsGary Benson6-5/+14
Clang fails to compile a number of files with the following warning: indirection of non-volatile null pointer will be deleted, not trap [-Wnull-dereference]. This commit qualifies the relevant pointers with 'volatile'. gdb/testsuite/ChangeLog: * gdb.base/bigcore.c (main): Use a volatile pointer when attempting to trigger a SIGSEGV. * gdb.base/gcore-relro-pie.c (break_here): Likewise. * gdb.base/gcore-tls-pie.c (break_here): Likewise. * gdb.base/savedregs.c (thrower): Likewise. * gdb.mi/mi-syn-frame.c (bar): Likewise.
2020-07-13Skip VLA structure field tests when compiling with clangGary Benson5-77/+180
Clang fails to compile gdb.base/vla-datatypes.c with the following error: fields must have a constant size: 'variable length array in structure' extension will never be supported. This commit factors the affected tests out into a new testcase, vla-struct-fields.{exp,c}, which is skipped when the testcase is compiled using clang, gdb/testsuite/ChangeLog: * gdb.base/vla-datatypes.c (vla_factory): Factor out sections defining and using VLA structure fields into... * gdb.base/vla-struct-fields.c: New file. * gdb.base/vla-datatypes.exp: Factor out VLA structure field tests into... * gdb.base/vla-struct-fields.exp: New file.
2020-07-13x86_64-cygwin testsAlan Modra10-29/+48
Tests just having "xfail: x86_64-*-cygwin" aren't good, since presumably if a test fails on x86_64-cygwin then it also fails on x86_64-*-pe* and x86_64-*-mingw*. binutils/ * testsuite/lib/binutils-common.exp (is_pecoff_format): Accept optional machine-os arg. ld/ * testsuite/ld-scripts/default-script1.d: Don't skip, xfail using is_pecoff_format. * testsuite/ld-scripts/default-script2.d: Likewise. * testsuite/ld-scripts/default-script3.d: Likewise. * testsuite/ld-scripts/default-script4.d: Likewise. * testsuite/ld-scripts/pr20302.d: Remove x86_64-*-cygwin from notarget. * testsuite/ld-scripts/provide-6.d: Remove x86_64-*-cygwin from xfail. * testsuite/ld-scripts/provide-8.d: Likewise.
2020-07-13gas DWARF2 test XPASSesAlan Modra5-8/+11
git commit af2b318648 introduced a number of XPASSes. This removes them. (It also introduces a FAIL on ft32-elf but the comment in the .d file didn't adequately explain why the failure should be expected.) * testsuite/gas/elf/dwarf2-7.d: Remove most xfails. * testsuite/gas/elf/dwarf2-12.d: Likewise. * testsuite/gas/elf/dwarf2-13.d: Likewise. * testsuite/gas/elf/dwarf2-14.d: Likewise.
2020-07-13[gdb/testsuite] Handle missing gold linker in gdb.base/morestack.expTom de Vries5-2/+29
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.
2020-07-12gdb: make type::bounds work for array and string typesSimon Marchi17-44/+69
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
2020-07-12gdb: remove TYPE_ARRAY_BIT_STRIDESimon Marchi4-9/+8
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
2020-07-12gdb: remove TYPE_BIT_STRIDESimon Marchi3-6/+22
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
2020-07-12gdb: remove TYPE_ARRAY_{LOWER,UPPER}_BOUND_VALUESimon Marchi5-12/+12
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
2020-07-12gdb: remove TYPE_ARRAY_{UPPER,LOWER}_BOUND_IS_UNDEFINEDSimon Marchi9-17/+20
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
2020-07-12gdb: remove TYPE_LOW_BOUND_KIND and TYPE_HIGH_BOUND_KINDSimon Marchi7-16/+18
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
2020-07-12gdb: remove TYPE_LOW_BOUND_UNDEFINED and TYPE_HIGH_BOUND_UNDEFINEDSimon Marchi5-12/+17
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
2020-07-12gdb: remove TYPE_HIGH_BOUND and TYPE_LOW_BOUNDSimon Marchi15-53/+58
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
2020-07-12gdb: add accessors to struct dynamic_propSimon Marchi12-135/+183
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
2020-07-12gdb: make get_discrete_bounds check for non-constant range boundsSimon Marchi2-16/+20
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
2020-07-12gdb: remove TYPE_RANGE_DATA macroSimon Marchi11-32/+34
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
2020-07-12gdb: add type::bounds / type::set_boundsSimon Marchi4-12/+39
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
2020-07-13Automatic date update in version.inGDB Administrator1-1/+1
2020-07-12Automatic date update in version.inGDB Administrator1-1/+1
2020-07-11rust: Fix rust modules testDaniel Xu2-1/+8
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>
2020-07-11Fine tune exec-file-mismatch help and documentation.Philippe Waroquiers4-2/+16
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.
2020-07-11x86: Support GNU_PROPERTY_X86_FEATURE_2_TMMH.J. Lu13-0/+66
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.
2020-07-11Automatic date update in version.inGDB Administrator1-1/+1
2020-07-10Fix crash if connection drops in scoped_restore_current_thread's ctor, part 2Pedro Alves3-19/+36
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.
2020-07-10Fix crash if connection drops in scoped_restore_current_thread's ctor, part 1Pedro Alves3-3/+36
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.
2020-07-10Fix GDB busy loop when interrupting non-stop program (PR 26199)Simon Marchi2-27/+20
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.
2020-07-10Testcase for previous handle_no_resumed fixesPedro Alves3-1/+87
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.
2020-07-10Make handle_no_resumed transfer terminalPedro Alves2-12/+60
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.
2020-07-10Fix handle_no_resumed w/ multiple targetsPedro Alves2-5/+22
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.
2020-07-10Avoid constant stream of TARGET_WAITKIND_NO_RESUMEDPedro Alves2-1/+11
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.
2020-07-10Fix latent bug in target_pass_ctrlcPedro Alves2-1/+7
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.
2020-07-10Fix spurious unhandled remote %Stop notificationsPedro Alves2-1/+23
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.
2020-07-10Enable multi-process mode in the FreeBSD native target.John Baldwin3-0/+15
gdb/ChangeLog: * fbsd-nat.h (fbsd_nat_target::supports_multi_process): New declaration. * fbsd-nat.c (fbsd_nat_target::supports_multi_process): New function.
2020-07-10x86: Extract extended states from instruction templateH.J. Lu6-73/+91
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.
2020-07-10gas/i386/property-5.d: Correct test nameH.J. Lu2-1/+5
* testsuite/gas/i386/property-5.d: Correct test name.
2020-07-10x86: Add support for Intel AMX instructionsLili Cui22-14339/+15523
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.
2020-07-10[readelf] Fix end_seq entry in -wL. Specifically stop the display of a line ↵Tom de Vries17-35/+95
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.
2020-07-10Document powerpc64 ld optionsAlan Modra2-0/+32
* ld.texi (PowerPC64 ELF64): Document --no-inline-optimize, --power10-stubs and --no-power10-stubs.
2020-07-10PowerPC64 ld --no-power10-stubsAlan Modra7-15/+92
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.
2020-07-10Automatic date update in version.inGDB Administrator1-1/+1
2020-07-09Don't compare the pid returned from 'wait' against inferior_ptid.John Baldwin2-1/+6
'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.
2020-07-09x86: Properly set YMM/ZMM featuresH.J. Lu9-2/+64
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.
2020-07-09Support several new ELF auxiliary vector types on FreeBSD.John Baldwin4-0/+21
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.
2020-07-09Linux/x86: Configure gas with --enable-x86-used-note by defaultH.J. Lu4-0/+23
* configure.ac: Configure with --enable-x86-used-note by default for Linux/x86. * configure: Regenerated.
2020-07-09Remove powerpc PE supportAlan Modra38-4421/+96
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.
2020-07-09powerpc garbage collect testAlan Modra2-6/+8
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.
2020-07-09pr18841 tests on powerpc64Alan Modra2-9/+14
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.
2020-07-09Update Turkish translation in the gprof sub-directoryNick Clifton2-5/+9
2020-07-09Update French translation in the bfd sub-directoryNick Clifton2-1676/+1895
generated by cgit v1.1 at 2025-08-10 15:25:55 +0000