aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-07-22gdb/jit: split jit_objfile_data in twoSimon Marchi4-31/+57
The jit_objfile_data is currently used to hold information about both objfiles that are the result of JIT compilation (JITed) and objfiles that can produce JITed objfiles (JITers). I think that this double use of the type is confusing, and that things would be more obvious if we had one type for each role. This patch splits it into: - jited_objfile_data: for data about an objfile that is the result of a JIT compilation - jiter_objfile_data: for data about an objfile which produces JITed objfiles There are now two JIT-related fields in an objfile, one for each kind. With this change, the following invariants hold: - an objfile has a non-null `jiter_data` field iff it defines the required symbols of the JIT interface - an objfile has a non-null `jited_data` field iff it is the product of JIT compilation (has been produced by some JITer) gdb/ChangeLog: 2020-07-22 Simon Marchi <simon.marchi@polymtl.ca> * jit.h (struct jit_objfile_data): Split into... (struct jiter_objfile_data): ... this ... (struct jited_objfile_data): ... and this. * objfiles.h (struct objfile) <jit_data>: Remove. <jiter_data, jited_data>: New fields. * jit.c (jit_objfile_data::~jit_objfile_data): Rename to ... (jiter_objfile_data::~jiter_objfile_data): ... this. (get_jit_objfile_data): Rename to ... (get_jiter_objfile_data): ... this. (add_objfile_entry): Update. (jit_read_descriptor): Use get_jiter_objfile_data. (jit_find_objf_with_entry_addr): Use objfile's jited_data field. (jit_breakpoint_re_set_internal): Use get_jiter_objfile_data. (jit_inferior_exit_hook): Use objfile's jited_data field.
2020-07-22gdb/jit: link to jit_objfile_data directly from the objfile structSimon Marchi4-61/+72
Remove the use of objfile_data to associate a jit_objfile_data with an objfile. Instead, directly link to a jit_objfile_data from an objfile struct. The goal is to eliminate unnecessary abstraction. The free_objfile_data function naturally becomes the destructor of jit_objfile_data. However, free_objfile_data accesses the objfile to which the data is attached, which the destructor of jit_objfile_data doesn't have access to. To work around this, add a backlink to the owning objfile in jit_objfile_data. This is however temporary, it goes away in a subsequent patch. gdb/ChangeLog: 2020-07-22 Simon Marchi <simon.marchi@polymtl.ca> * jit.h: Forward-declare `struct minimal_symbol`. (struct jit_objfile_data): Migrate to here from jit.c; also add a constructor, destructor, and an objfile* field. * jit.c (jit_objfile_data): Remove. (struct jit_objfile_data): Migrate from here to jit.h. (jit_objfile_data::~jit_objfile_data): New destructor implementation with code moved from free_objfile_data. (free_objfile_data): Delete. (get_jit_objfile_data): Update to use the jit_data field of objfile. (jit_find_objf_with_entry_addr): Ditto. (jit_inferior_exit_hook): Ditto. (_initialize_jit): Remove the call to register_objfile_data_with_cleanup. * objfiles.h (struct objfile) <jit_data>: New field.
2020-07-22gdb/jit: pass the jiter objfile as an argument to jit_event_handlerTankut Baris Aktemur4-15/+34
This is a refactoring that adds a new parameter to the `jit_event_handler` function: the JITer objfile. The goal is to distinguish which JITer triggered the JIT event, in case there are multiple JITers -- a capability that is added in a subsequent patch. gdb/ChangeLog: 2020-07-22 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * jit.h: Forward-declare `struct objfile`. (jit_event_handler): Add a second parameter, the JITer objfile. * jit.c (jit_read_descriptor): Change the signature to take the JITer objfile as an argument instead of the jit_program_space_data. (jit_inferior_init): Update the call to jit_read_descriptor. (jit_event_handler): Use the new JITer objfile argument when calling jit_read_descriptor. * breakpoint.c (handle_jit_event): Update the call to jit_event_handler to pass the JITer objfile.
2020-07-22MIPS/GAS/testsuite: Fix JALR relocation tests for IRIX targetsMaciej W. Rozycki26-12/+1857
With IRIX targets the JALR hint relocation is not produced for the o32 ABI, where it is considered a GNU extension. Consequently several tests fail as the output produced by GAS fails to match patterns expecting the relocation to be present where appropriate, even though output produced is indeed correct. As the absence of the relocation is expected, fix the tests by providing respective alternative dump patterns with any JALR relocations removed, removing numerous failures with `*-*-irix*' targets: FAIL: MIPS jal-svr4pic (interaptiv-mr2) FAIL: MIPS jal-svr4pic (micromips) FAIL: MIPS jal-svr4pic (mips1) FAIL: MIPS jal-svr4pic (mips2) FAIL: MIPS jal-svr4pic (mips3) FAIL: MIPS jal-svr4pic (mips4) FAIL: MIPS jal-svr4pic (mips5) FAIL: MIPS jal-svr4pic (mips32) FAIL: MIPS jal-svr4pic (mips32r2) FAIL: MIPS jal-svr4pic (mips32r3) FAIL: MIPS jal-svr4pic (mips32r5) FAIL: MIPS jal-svr4pic (mips32r6) FAIL: MIPS jal-svr4pic (mips64) FAIL: MIPS jal-svr4pic (mips64r2) FAIL: MIPS jal-svr4pic (mips64r3) FAIL: MIPS jal-svr4pic (mips64r5) FAIL: MIPS jal-svr4pic (mips64r6) FAIL: MIPS jal-svr4pic (octeon) FAIL: MIPS jal-svr4pic (octeon2) FAIL: MIPS jal-svr4pic (octeon3) FAIL: MIPS jal-svr4pic (octeonp) FAIL: MIPS jal-svr4pic (r3000) FAIL: MIPS jal-svr4pic (r3900) FAIL: MIPS jal-svr4pic (r4000) FAIL: MIPS jal-svr4pic (r5900) FAIL: MIPS jal-svr4pic (sb1) FAIL: MIPS jal-svr4pic (vr5400) FAIL: MIPS jal-svr4pic (xlr) FAIL: MIPS jal-svr4pic noreorder (interaptiv-mr2) FAIL: MIPS jal-svr4pic noreorder (micromips) FAIL: MIPS jal-svr4pic noreorder (mips1) FAIL: MIPS jal-svr4pic noreorder (mips2) FAIL: MIPS jal-svr4pic noreorder (mips3) FAIL: MIPS jal-svr4pic noreorder (mips4) FAIL: MIPS jal-svr4pic noreorder (mips5) FAIL: MIPS jal-svr4pic noreorder (mips32) FAIL: MIPS jal-svr4pic noreorder (mips32r2) FAIL: MIPS jal-svr4pic noreorder (mips32r3) FAIL: MIPS jal-svr4pic noreorder (mips32r5) FAIL: MIPS jal-svr4pic noreorder (mips32r6) FAIL: MIPS jal-svr4pic noreorder (mips64) FAIL: MIPS jal-svr4pic noreorder (mips64r2) FAIL: MIPS jal-svr4pic noreorder (mips64r3) FAIL: MIPS jal-svr4pic noreorder (mips64r5) FAIL: MIPS jal-svr4pic noreorder (mips64r6) FAIL: MIPS jal-svr4pic noreorder (octeon) FAIL: MIPS jal-svr4pic noreorder (octeon2) FAIL: MIPS jal-svr4pic noreorder (octeon3) FAIL: MIPS jal-svr4pic noreorder (octeonp) FAIL: MIPS jal-svr4pic noreorder (r3000) FAIL: MIPS jal-svr4pic noreorder (r3900) FAIL: MIPS jal-svr4pic noreorder (r4000) FAIL: MIPS jal-svr4pic noreorder (r5900) FAIL: MIPS jal-svr4pic noreorder (sb1) FAIL: MIPS jal-svr4pic noreorder (vr5400) FAIL: MIPS jal-svr4pic noreorder (xlr) FAIL: MIPS R3000 jal-xgot FAIL: MIPS -mabi=32 test 2 (SVR4 PIC) FAIL: gas/mips/jalr2 FAIL: Relax microMIPS branches (pic) FAIL: Relax microMIPS branches (insn32 mode, pic) Strictly speaking no MIPSr6 or microMIPS target is supported by IRIX, but GAS supports such configurations on the basis of uniformity, so provide the relevant patterns too rather than excluding the combinations from testing. gas/ * testsuite/gas/mips/jal-svr4pic-irix.d: New file. * testsuite/gas/mips/mips1@jal-svr4pic-irix.d: New file. * testsuite/gas/mips/mipsr6@jal-svr4pic-irix.d: New file. * testsuite/gas/mips/micromips@jal-svr4pic-irix.d: New file. * testsuite/gas/mips/r3000@jal-svr4pic-irix.d: New file. * testsuite/gas/mips/jal-svr4pic-local-irix.d: New file. * testsuite/gas/mips/mips1@jal-svr4pic-local-irix.d: New file. * testsuite/gas/mips/micromips@jal-svr4pic-local-irix.d: New file. * testsuite/gas/mips/r3000@jal-svr4pic-local-irix.d: New file. * testsuite/gas/mips/jal-svr4pic-noreorder-irix.d: New file. * testsuite/gas/mips/mips1@jal-svr4pic-noreorder-irix.d: New file. * testsuite/gas/mips/mipsr6@jal-svr4pic-noreorder-irix.d: New file. * testsuite/gas/mips/micromips@jal-svr4pic-noreorder-irix.d: New file. * testsuite/gas/mips/r3000@jal-svr4pic-noreorder-irix.d: New file. * testsuite/gas/mips/jal-xgot-irix.d: New file. * testsuite/gas/mips/jalr2-irix.d: New file. * testsuite/gas/mips/micromips-branch-relax-insn32-pic-irix.d: New file. * testsuite/gas/mips/micromips-branch-relax-pic-irix.d: New file. * testsuite/gas/mips/mips-abi32-pic2-irix.d: New file. * testsuite/gas/mips/jal-svr4pic-local.d: Don't exclude `*-*-irix*' targets. Add source file designator. * testsuite/gas/mips/mips1@jal-svr4pic-local.d: Don't exclude `*-*-irix*' targets. * testsuite/gas/mips/r3000@jal-svr4pic-local.d: Likewise. * testsuite/gas/mips/micromips@jal-svr4pic-local.d: Likewise. * testsuite/gas/mips/jalr2.d: Add name designator. * testsuite/gas/mips/mips.exp: Use respective IRIX variants for tests involving the JALR relocation throughout.
2020-07-22MIPS/GAS/testsuite: Use a helper variable for IRIX/non-IRIX test selectionMaciej W. Rozycki2-5/+7
Define a helper variable for IRIX/non-IRIX test selection and use it with the PR 14798 test case. gas/ * testsuite/gas/mips/mips.exp: Use a helper variable for IRIX/non-IRIX test selection.
2020-07-22gdbserver: handle running threads in qXfer:threads:readPedro Alves5-13/+68
On some systems, the gdb.multi/multi-target.exp testcase occasionally fails like so: Running src/gdb/testsuite/gdb.multi/multi-target.exp ... FAIL: gdb.multi/multi-target.exp: info-inferiors: multi_process=on: inferior 1: info connections FAIL: gdb.multi/multi-target.exp: info-inferiors: multi_process=on: inferior 1: info inferiors FAIL: gdb.multi/multi-target.exp: info-inferiors: multi_process=on: inferior 2: info connections FAIL: gdb.multi/multi-target.exp: info-inferiors: multi_process=on: inferior 2: info inferiors FAIL: gdb.multi/multi-target.exp: info-inferiors: multi_process=on: inferior 3: inferior 3 ... many more cascading fails. The problem starts when the testcase runs an inferior against GDBserver: (gdb) run Starting program: build/gdb/testsuite/outputs/gdb.multi/multi-target/multi-target Reading /lib64/ld-linux-x86-64.so.2 from remote target... warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead. Reading /lib64/ld-linux-x86-64.so.2 from remote target... Reading /lib64/ld-2.31.so from remote target... Reading /lib64/.debug/ld-2.31.so from remote target... Reading /usr/lib/debug//lib64/ld-2.31.so from remote target... Reading /usr/lib/debug/lib64//ld-2.31.so from remote target... Reading target:/usr/lib/debug/lib64//ld-2.31.so from remote target... Reading /lib/x86_64-linux-gnu/libpthread.so.0 from remote target... Reading /lib/x86_64-linux-gnu/libc.so.6 from remote target... Reading /lib/x86_64-linux-gnu/libc-2.31.so from remote target... Reading /lib/x86_64-linux-gnu/.debug/libc-2.31.so from remote target... Reading /usr/lib/debug//lib/x86_64-linux-gnu/libc-2.31.so from remote target... Reading /usr/lib/debug//lib/x86_64-linux-gnu/libc-2.31.so from remote target... Remote connection closed ... Note the "Remote connection closed" message. That means GDBserver exited abruptly. I traced it down to the fact that GDB fetches the thread list from GDBserver while the main thread of the process is still running. On my main system where I wrote the testcase, I have not observed the failure because it is slow enough that the thread stops before GDBserver fetches the thread list in the problem scenario which I'll describe below. With some --remote-debug logging from GDBserver side, we see the last packets before the connection closes: ... getpkt ("vCont;c"); [no ack sent] putpkt ("$OK#9a"); [noack mode] getpkt ("Tp10f9a.10f9a"); [no ack sent] putpkt ("$OK#9a"); [noack mode] getpkt ("Hgp0.0"); [no ack sent] putpkt ("$OK#9a"); [noack mode] getpkt ("qXfer:threads:read::0,1000"); [no ack sent] Note the vCont;c , which sets the program running, and then a qXfer:threads:read packet at the end. The problem happens when the thread list refresh (qXfer:threads:read) is sent just while the main thread is running and it still hasn't initialized its libpthread id internally. In that state, the main thread's lwp will remain with the thread_known flag clear. See in find_one_thread: /* If the new thread ID is zero, a final thread ID will be available later. Do not enable thread debugging yet. */ if (ti.ti_tid == 0) return 0; Now, back in server.cc, to handle the qXfer:threads:read, we reach handle_qxfer_threads -> handle_qxfer_threads_proper, and the latter then calls handle_qxfer_threads_worker for each known thread. In handle_qxfer_threads_worker, we call target_thread_handle. This ends up in thread_db_thread_handle, here: if (!lwp->thread_known && !find_one_thread (thread->id)) return false; Since the thread ID isn't known yet, we call find_one_thread. This calls into libthread_db.so, which accesses memory. Because the current thread is running, that fails and we throw an error, here: /* Get information about this thread. */ err = thread_db->td_ta_map_lwp2thr_p (thread_db->thread_agent, lwpid, &th); if (err != TD_OK) error ("Cannot get thread handle for LWP %d: %s", lwpid, thread_db_err_str (err)); The current design is that whenever GDB-facing packets/requests need to accesses memory, server.cc is supposed to prepare the target for the access. See gdb_read_memory / gdb_write_memory. This preparation means pausing threads if in non-stop mode (someday we could lift this requirement, but we will still need to pause to access registers or do other related ptrace accesses like PTRACE_GET_THREAD_AREA). Note that the multi-target.exp testcase forces "maint set target-non-stop on". So the fix here is to prepare the target to access memory when handling qXfer:threads:read too. gdbserver/ChangeLog: * inferiors.cc (switch_to_process): New, moved here from thread-db.cc, and made extern. * inferiors.h (switch_to_process): Declare. * server.cc: Include "gdbsupport/scoped_restore.h". (handle_qxfer_threads_proper): Now returns bool. Prepare to access memory around target calls. (handle_qxfer_threads): Handle errors. * thread-db.cc (switch_to_process): Moved to inferiors.cc.
2020-07-22ld: Properly override the IR definitionH.J. Lu13-6/+167
We change the previous definition in the IR object to undefweak only after all LTO symbols have been read. include/ PR ld/26262 PR ld/26267 * bfdlink.h (bfd_link_info): Add lto_all_symbols_read. ld/ PR ld/26262 PR ld/26267 * ldlang.c (lang_process): Set lto_all_symbols_read after all LTO IR symbols have been read. * plugin.c (plugin_notice): Override the IR definition only if all LTO IR symbols have been read or the new definition is non-weak and the the IR definition is weak * testsuite/ld-plugin/lto.exp: Run PR ld/26262 and ld/26267 tests. * testsuite/ld-plugin/pr26262a.c: New file. * testsuite/ld-plugin/pr26262b.c: Likewise. * testsuite/ld-plugin/pr26262c.c: Likewise. * testsuite/ld-plugin/pr26267.err: Likewise. * testsuite/ld-plugin/pr26267a.c: Likewise. * testsuite/ld-plugin/pr26267b.c: Likewise. * testsuite/ld-plugin/pr26267c.c: Likewise.
2020-07-22bfd: xtensa: pr26246: fix removed_literal_compareMax Filippov2-4/+11
2020-07-22 Max Filippov <jcmvbkbc@gmail.com> bfd/ PR 26246 * elf32-xtensa.c (removed_literal_compare): Use correct pointer type for the first function argument. Rename pointers to reflect that they have distinct types.
2020-07-21Retire the now-unused gdbarch handle_segmentation_fault hook.John Baldwin5-66/+9
* gdbarch.c: Regenerate. * gdbarch.h: Regenerate. * gdbarch.sh (handle_segmentation_fault): Remove method. * infrun.c (handle_segmentation_fault): Remove. (print_signal_received_reason): Remove call to handle_segmentation_fault.
2020-07-21Migrate the sparc64 ADI handle_segmentation_fault hook to report_signal_info.John Baldwin2-6/+14
gdb/ChangeLog: * sparc64-linux-tdep.c (sparc64_linux_handle_segmentation_fault): Rename to sparc64_linux_report_signal_info and add siggnal argument. (sparc64_linux_init_abi): Use sparc64_linux_report_signal_info instead of sparc64_linux_handle_segmentation_fault.
2020-07-21Migrate the x86 MPX handle_segmentation_fault hook to report_signal_info.John Baldwin4-10/+21
gdb/ChangeLog: * amd64-linux-tdep.c (amd64_linux_init_abi_common): Use i386_linux_report_signal_info instead of i386_linux_handle_segmentation_fault. * i386-linux-tdep.c (i386_linux_handle_segmentation_fault): Rename to i386_linux_report_signal_info and add siggnal argument. (i386_linux_init_abi): Use i386_linux_report_signal_info instead of i386_linux_handle_segmentation_fault. * i386-linux-tdep.h (i386_linux_handle_segmentation_fault): Rename to i386_linux_report_signal_info and add siggnal argument.
2020-07-21Report architecture-specific signal information for core files.John Baldwin2-1/+9
When opening a core file, if the process terminated due to a signal, invoke the gdbarch report_signal_info hook to report architecture-specific information about the signal. gdb/ChangeLog: * corelow.c (core_target_open): Invoke gdbarch report_signal_info hook if present.
2020-07-21Add a new gdbarch hook to report additional signal information.John Baldwin5-0/+60
This is a more general version of the existing handle_segmentation_fault hook that is able to report information for an arbitrary signal, not just SIGSEGV. gdb/ChangeLog: * gdbarch.c: Regenerate. * gdbarch.h: Regenerate. * gdbarch.sh (report_signal_info): New method. * infrun.c (print_signal_received_reason): Invoke gdbarch report_signal_info hook if present.
2020-07-22Automatic date update in version.inGDB Administrator1-1/+1
2020-07-21gdb/python: Reuse gdb.RegisterGroup objects where possibleAndrew Burgess4-11/+61
Only create one gdb.RegisterGroup Python object for each of GDB's reggroup objects. I could have added a field into the reggroup object to hold the Python object pointer for each reggroup, however, as reggroups are never deleted within GDB, and are global (not per-architecture) a simpler solution seemed to be just to hold a single global map from reggroup pointer to a Python object representing the reggroup. Then we can reuse the objects out of this map. After this commit it is possible for a user to tell that two gdb.RegisterGroup objects are now identical when previously they were unique, however, as both these objects are read-only I don't think this should be a problem. There should be no other user visible changes after this commit. gdb/ChangeLog: * python/py-registers.c : Add 'unordered_map' include. (gdbpy_new_reggroup): Renamed to... (gdbpy_get_reggroup): ...this. Update to only create register group descriptors when needed. (gdbpy_reggroup_iter_next): Update. gdb/testsuite/ChangeLog: * gdb.python/py-arch-reg-groups.exp: Additional tests.
2020-07-21gdb/python: Reuse gdb.RegisterDescriptor objects where possibleAndrew Burgess4-13/+82
Instead of having the gdb.RegisterDescriptorIterator creating new gdb.RegisterDescriptor objects for each regnum, instead cache gdb.RegisterDescriptor objects on the gdbarch object and reuse these. This means that for every gdbarch/regnum pair there is a single unique gdb.RegisterDescriptor, this feels like a neater implementation than the existing one. It is possible for a user to see (in Python code) that the descriptors are now identical, but as the descriptors are read-only this should make no real difference. There should be no other user visible changes. gdb/ChangeLog: * python/py-registers.c (gdbpy_register_object_data): New static global. (gdbpy_register_object_data_init): New function. (gdbpy_new_register_descriptor): Renamed to... (gdbpy_get_register_descriptor): ...this, and update to reuse existing register descriptors where possible. (gdbpy_register_descriptor_iter_next): Update. (gdbpy_initialize_registers): Register new gdbarch data. gdb/testsuite/ChangeLog: * gdb.python/py-arch-reg-names.exp: Additional tests.
2020-07-21gdb, gdbserver: make stopped_pids global variables staticSimon Marchi4-2/+10
I noticed that my IDE was confusing the two stopped_pids variables. There is one in GDB and one in GDBserver. They should be static, make them so. gdb/ChangeLog: * linux-nat.c (stopped_pids): Make static. gdbserver/ChangeLog: * linux-low.cc (stopped_pids): Make static. Change-Id: If4a2bdcd45d32eb3a732d266a0f686a4e4c23672
2020-07-21gdb: handle undefined properties in ada_discrete_type_{low,high}_boundSimon Marchi2-2/+36
This patch fixes a failure in test `gdb.ada/access_to_packed_array.exp`. The failure was introduced by 8c2e4e0689ea24 ("gdb: add accessors to struct dynamic_prop"), but I think it in fact exposed a latent buglet. Note that to reproduce it, I had to use AdaCore's Ada "distribution" [1]. The one that comes with my distro doesn't have debug info for the standard library stuff, so the bug wouldn't trigger. The bug is that while executing the `maint print symbols` command, we are accessing the value of a range type's high bound dynamic prop as a "const" value (PROP_CONST), when it is actually undefined (PROP_UNDEFINED). It results in this failed assertion: /home/simark/src/binutils-gdb/gdb/gdbtypes.h:526: internal-error: LONGEST dynamic_prop::const_val() const: Assertion `m_kind == PROP_CONST' failed. `ada_discrete_type_high_bound` calls `resolve_dynamic_type`, which eventually calls `resolve_dynamic_range`. This one is responsible for evaluating a range type's dynamic bounds in the current context and returning static values. It returns a new range type with these static bounds. The resulting bounds are typically properties of the PROP_CONST kind. But when it's not possible to evaluate the properties, the properties are PROP_UNDEFINED. In the case we are looking at, it's not possible to evaluate the dynamic high bound, which is of type PROP_LOCLIST. It would require a target with registers and a frame, but we run `maint print symbols` without a live process. `ada_discrete_type_high_bound` then accesses the high bound unconditionally as a const value, which triggers the assert. Note that the previous code in resolve_dynamic_range (before commit 8c2e4e0689ea24) did this: prop = &TYPE_RANGE_DATA (dyn_range_type)->high; if (dwarf2_evaluate_property (prop, NULL, addr_stack, &value)) { high_bound.kind = PROP_CONST; high_bound.data.const_val = value; if (TYPE_RANGE_DATA (dyn_range_type)->flag_upper_bound_is_count) high_bound.data.const_val = low_bound.data.const_val + high_bound.data.const_val - 1; } else { high_bound.kind = PROP_UNDEFINED; high_bound.data.const_val = 0; } That did not really made sense, setting the kind to `PROP_UNDEFINED` but also setting the `const_val` field. The `const_val` field is only meaningful if the kind if `PROP_CONST`. The new code (post-8c2e4e0689ea24) simply calls `set_undefined ()`. Fix this by making the caller, `ada_discrete_type_high_bound`, consider that a range high bound could be of kind `PROP_UNDEFINED`, and return 0 in this case. I made the same change in ada_discrete_type_low_bound. I didn't encounter a problem with this function, but the same could in theory happen there. Returning 0 here is kind of a lie, but the goal here is just to restore the behavior of pre-8c2e4e0689ea24. The output of `maint print symbols` is: typedef <ada__exceptions__exception_data__append_info_basic_exception_information__TTnameSP1: range 1 .. 0; record ada__exceptions__exception_data__append_info_basic_exception_information__TTnameSP1: range 1 .. 0; end record; Instead of `1 .. 0`, which does not make sense, we could say something like `1 .. <dynamic>`. But that would require more changes than I'm willing to do at the moment. [1] https://www.adacore.com/download gdb/ChangeLog: PR ada/26235 * gdbtypes.c (ada_discrete_type_low_bound, ada_discrete_type_high_bound): Handle undefined bounds. Change-Id: Ia12167e61ef030941c0790f83294f3418e6a7c12
2020-07-21[gdb/testsuite] Fix gdb.reverse/solib-{precsave,reverse}.exp with gcc-8Tom de Vries3-6/+60
With gcc-8, we have the following FAILs, which are not there for gcc-7: ... FAIL: gdb.reverse/solib-precsave.exp: reverse-step into solib function one FAIL: gdb.reverse/solib-precsave.exp: reverse-step within solib function one FAIL: gdb.reverse/solib-precsave.exp: reverse-step back to main one FAIL: gdb.reverse/solib-precsave.exp: reverse-step into solib function two FAIL: gdb.reverse/solib-precsave.exp: reverse-step within solib function two FAIL: gdb.reverse/solib-precsave.exp: reverse-step back to main two FAIL: gdb.reverse/solib-precsave.exp: run until end part two FAIL: gdb.reverse/solib-precsave.exp: reverse-next over solib function one FAIL: gdb.reverse/solib-reverse.exp: reverse-step into solib function one FAIL: gdb.reverse/solib-reverse.exp: reverse-step within solib function one FAIL: gdb.reverse/solib-reverse.exp: reverse-step back to main one FAIL: gdb.reverse/solib-reverse.exp: reverse-step into solib function two FAIL: gdb.reverse/solib-reverse.exp: reverse-step within solib function two FAIL: gdb.reverse/solib-reverse.exp: reverse-step back to main two FAIL: gdb.reverse/solib-reverse.exp: run until end part two FAIL: gdb.reverse/solib-reverse.exp: reverse-next over solib function one ... Looking at the first FAIL for gdb.reverse/solib-precsave.exp, we have: ... (gdb) PASS: reverse-next first shr1 reverse-next^M 40 b[0] = 6; b[1] = 9; /* generic statement, end part two */^M (gdb) PASS: reverse-next generic reverse-step^M -shr2 (x=17) at gdb.reverse/shr2.c:23^M -23 }^M -(gdb) PASS: reverse-step into solib function one +38 b[1] = shr2(17); /* middle part two */^M +(gdb) FAIL: reverse-step into solib function one ... There's a difference in line number info for line 38, where for gcc-7 we have: ... Line number Starting address View Stmt 38 0x4005c6 x ... and for gcc-8: ... 38 0x4005c1 x 38 0x4005cb x ... which explains why we don't step directly into "solib function one". Fix this by recognizing the extra "recommended breakpoint location" and issuing an additional reverse-next/step. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-07-21 Tom de Vries <tdevries@suse.de> * gdb.reverse/solib-precsave.exp: Handle additional "recommended breakpoint locations". * gdb.reverse/solib-reverse.exp: Same.
2020-07-21[gdb/testsuite] Fix step-reverse.c with gcc-10Tom de Vries2-1/+5
The file gdb.reverse/step-reverse.c is used in test-cases: - gdb.reverse/step-reverse.exp - gdb.reverse/next-reverse-bkpt-over-sr.exp - gdb.reverse/step-precsave.exp With gcc-7, there are only PASSes (apart from one KFAIL), but with gcc-10, we have the following FAILs: ... FAIL: gdb.reverse/step-reverse.exp: reverse stepi from a function call \ (start statement) FAIL: gdb.reverse/step-reverse.exp: simple reverse stepi FAIL: gdb.reverse/step-reverse.exp: reverse step out of called fn FAIL: gdb.reverse/step-reverse.exp: reverse next over call FAIL: gdb.reverse/step-reverse.exp: reverse step test 1 FAIL: gdb.reverse/step-reverse.exp: reverse next test 1 FAIL: gdb.reverse/step-reverse.exp: reverse step test 2 FAIL: gdb.reverse/step-reverse.exp: reverse next test 2 FAIL: gdb.reverse/step-precsave.exp: reverse stepi from a function call \ (start statement) FAIL: gdb.reverse/step-precsave.exp: simple reverse stepi FAIL: gdb.reverse/step-precsave.exp: reverse step out of called fn FAIL: gdb.reverse/step-precsave.exp: reverse next over call FAIL: gdb.reverse/step-precsave.exp: reverse step test 1 FAIL: gdb.reverse/step-precsave.exp: reverse next test 1 FAIL: gdb.reverse/step-precsave.exp: reverse step test 2 FAIL: gdb.reverse/step-precsave.exp: reverse next test 2 ... Looking at the first step-precsave.exp FAIL, we have: ... (gdb) stepi^M 26 myglob++; return 0; /* ARRIVED IN CALLEE */^M (gdb) PASS: gdb.reverse/step-precsave.exp: reverse stepi thru function return stepi^M 0x000000000040055f 26 myglob++; return 0; /* ARRIVED IN CALLEE */^M (gdb) FAIL: gdb.reverse/step-precsave.exp: reverse stepi from a function call \ (start statement) ... There's a difference in line info for callee: ... 25 int callee() { /* ENTER CALLEE */ 26 myglob++; return 0; /* ARRIVED IN CALLEE */ 27 } /* RETURN FROM CALLEE */ ... between gcc-7: ... Line number Starting address View Stmt 25 0x400557 x 26 0x40055b x 27 0x40056f x ... and gcc-10: ... 25 0x400552 x 26 0x400556 x 26 0x400565 x 27 0x40056a x ... The two "recommend breakpoint location" entries at line 26 are for the two statements ("myglob++" and "return 0"), but the test-case expects to hit line 26 only once. Fix this by rewriting the two statements into a single statement: ... - myglob++; return 0; /* ARRIVED IN CALLEE */ + return myglob++; /* ARRIVED IN CALLEE */ ... Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-07-21 Tom de Vries <tdevries@suse.de> * gdb.reverse/step-reverse.c (callee): Merge statements.
2020-07-21Enable multi-process mode in the NetBSD native target.Kamil Rytarowski3-0/+16
This enables proper support for multiple inferiors and ptrace(2) assisted management of the inferior processes and their threads. (gdb) info inferior Num Description Connection Executable * 1 process 14952 1 (native) /usr/bin/dig 2 <null> 1 (native) 3 process 25684 1 (native) /bin/ls 4 <null> 1 (native) /bin/ls Without this patch, additional inferiors can be added, but not properly controlled. gdb/ChangeLog: * nbsd-nat.h (nbsd_nat_target::supports_multi_process): New declaration. * nbsd-nat.c (nbsd_nat_target::supports_multi_process): New function.
2020-07-21Revert "x86: Don't display eiz with no scale"Jan Beulich6-14/+25
This reverts commit 04c662e2b66bedd050f97adec19afe0fcfce9ea7. In my underlying suggestion I neglected the fact that in those cases (,%eiz,1) is the only visible indication that 32-bit addressing is in effect.
2020-07-21Fix Unreasonable arch and cpu conflict warning for ther CSky architecture.Cooper Qu2-2/+8
* config/tc-csky.c (md_begin): Fix tests of arch and mach flags.
2020-07-21Updated Swedish translation for the binutils sub-directoryNick Clifton2-1899/+2075
2020-07-21[gdb/testsuite] Fix gdb.fortran/info-modules.exp with gcc-8Tom de Vries2-2/+7
When using test-case gdb.fortran/info-modules.exp with gcc 8.4.0, I run into: ... FAIL: gdb.fortran/info-modules.exp: info module variables: check for entry \ 'info-types.f90', '35', 'Type m1t1 mod1::__def_init_mod1_M1t1;' FAIL: gdb.fortran/info-modules.exp: info module variables: check for entry \ 'info-types.f90', '35', 'Type __vtype_mod1_M1t1 mod1::__vtab_mod1_M1t1;' ... This is caused by this change in gdb output: ... (gdb) info module variables ... File gdb.fortran/info-types.f90: -35: Type m1t1 mod1::__def_init_mod1_M1t1; + Type m1t1 mod1::__def_init_mod1_M1t1; -35: Type __vtype_mod1_M1t1 mod1::__vtab_mod1_M1t1; + Type __vtype_mod1_M1t1 mod1::__vtab_mod1_M1t1; 21: real(kind=4) mod1::mod1_var_1; 22: integer(kind=4) mod1::mod1_var_2; ... caused by a change in debug info. Fix this by allowing those entries without line number. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-07-21 Tom de Vries <tdevries@suse.de> * gdb.fortran/info-modules.exp (info module variables): Allow missing line numbers for some variables.
2020-07-21Revert "x86: Replace evex-no-scale.s with evex-no-scale-[32|64].s"Jan Beulich6-9/+26
This reverts commit 19449d7c67690c641b1ec9c13ff3531677a5afcc, addressing the issue that was run into back then: There was no relationship to i686-* and/or cross builds on 64-bit hosts. The sole problem was the use of / as as comment character in certain ELF targets. Instead of division, use a comparison operation. At the same time also revert the ELF related part of 99c2d522f7a7 ("x86: Update assembler tests for non-ELF targets") by replacing the construct that's problematic for non-ELF, and by adding the "#pass" patterns to the expected output files to cover for the tail padding generated into COFF output.
2020-07-21[gdb/testsuite] Make inline-locals.c deterministicTom de Vries3-1/+16
When running testcase gdb.opt/inline-locals.exp on openSUSE Tumbleweed, I get: ... (gdb) info locals^M array = {0 <repeats 48 times>, 15775231, 0, 194, 0, -11497, 32767, 4199061, \ 0, 0, 0, 0, 0, 4198992, 0, 4198432, 0}^M (gdb) FAIL: gdb.opt/inline-locals.exp: info locals above bar 2 ... Fix this by: - completely initializing array before printing any value - updating the pattern to match "array = {0 <repeats 64 times>}" Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-07-21 Tom de Vries <tdevries@suse.de> * gdb.opt/inline-locals.c (init_array): New func. (func1): Use init_array. * gdb.opt/inline-locals.exp: Update pattern.
2020-07-21[gdb/testsuite] Don't leak env vars in gdb.debuginfod/fetch_src_and_symbols.expTom de Vries2-89/+125
Test-case gdb.debuginfod/fetch_src_and_symbols.exp leaks env vars DEBUGINFOD_URLS, DEBUGINFOD_TIMEOUT and DEBUGINFOD_CACHE_PATH, causing timeouts in subsequent tests. Fix this by using save_vars. Also, fix PATH and DUPLICATE errors. Finally, cleanup whitespace. gdb/testsuite/ChangeLog: 2020-07-21 Tom de Vries <tdevries@suse.de> * gdb.debuginfod/fetch_src_and_symbols.exp: Use save_vars for env vars. Fix PATH and DUPLICATE errors. Cleanup whitespace.
2020-07-21MIPS/GAS: Remove stale `prev_reloc_op_frag' variableMaciej W. Rozycki2-11/+7
Ever since commit 4d7206a284ee ("Rework MIPS macro relaxation, fix string merging bug"), <https://sourceware.org/ml/binutils/2004-01/msg00248.html>, `prev_reloc_op_frag' has only been set and never used. Remove it then. gas/ * config/tc-mips.c (prev_reloc_op_frag): Remove variable. (my_getSmallExpression): Adjust accordingly.
2020-07-21Automatic date update in version.inGDB Administrator1-1/+1
2020-07-20Implement the skip_solib_resolver gdbarch hook for FreeBSD architectures.John Baldwin4-0/+44
The ELF runtime linker on all FreeBSD architectures uses the "_rtld_bind" entry point for unresolved PTL entries. FreeBSD/mips has an additional entry point called "_mips_rtld_bind". gdb/ChangeLog: * fbsd-tdep.c (fbsd_skip_solib_resolver): New function. (fbsd_init_abi): Install gdbarch "skip_solib_resolver" method. * fbsd-tdep.h (fbsd_skip_solib_resolver): New prototype. * mips-fbsd-tdep.c (mips_fbsd_skip_solib_resolver): New function. (mips_fbsd_init_abi): Install gdbarch "skip_solib_resolver" method.
2020-07-20guile: Add support for Guile 3.0.Ludovic Courtès10-10/+29
gdb/ChangeLog 2020-06-28 Ludovic Courtès <ludo@gnu.org> * guile/scm-math.c (vlscm_integer_fits_p): Use 'uintmax_t' and 'intmax_t' instead of 'scm_t_uintmax' and 'scm_t_intmax', which are deprecated in Guile 3.0. * configure.ac (try_guile_versions): Add "guile-3.0". * configure (try_guile_versions): Regenerate. * NEWS: Update entry. gdb/testsuite/ChangeLog 2020-06-28 Ludovic Courtès <ludo@gnu.org> * gdb.guile/source2.scm: Add #f first argument to 'format'. * gdb.guile/types-module.exp: Remove "ERROR:" from regexps since Guile 3.0 no longer prints that. gdb/doc/ChangeLog 2020-06-28 Ludovic Courtès <ludo@gnu.org> * doc/guile.texi (Guile Introduction): Mention Guile 3.0. Change-Id: Iff116c2e40f334e4e0ca4e759a097bfd23634679
2020-07-20guile: Add support for Guile 2.2.Ludovic Courtès9-175/+542
This primarily updates code that uses the I/O port API of Guile. gdb/ChangeLog 2020-06-28 Ludovic Courtès <ludo@gnu.org> Doug Evans <dje@google.com> PR gdb/21104 * guile/scm-ports.c (USING_GUILE_BEFORE_2_2): New macro. (ioscm_memory_port)[read_buf_size, write_buf_size]: Wrap in #if USING_GUILE_BEFORE_2_2. (stdio_port_desc, memory_port_desc) [!USING_GUILE_BEFORE_2_2]: Change type to 'scm_t_port_type *'. (natural_buffer_size) [!USING_GUILE_BEFORE_2_2]: New variable. (ioscm_open_port) [USING_GUILE_BEFORE_2_2]: Add 'stream' parameter and honor it. Update callers. (ioscm_open_port) [!USING_GUILE_BEFORE_2_2]: New function. (ioscm_read_from_port, ioscm_write) [!USING_GUILE_BEFORE_2_2]: New functions. (ioscm_fill_input, ioscm_input_waiting, ioscm_flush): Wrap in #if USING_GUILE_BEFORE_2_2. (ioscm_init_gdb_stdio_port) [!USING_GUILE_BEFORE_2_2]: Use 'ioscm_read_from_port'. Call 'scm_set_port_read_wait_fd'. (ioscm_init_stdio_buffers) [!USING_GUILE_BEFORE_2_2]: New function. (gdbscm_stdio_port_p) [!USING_GUILE_BEFORE_2_2]: Use 'SCM_PORTP' and 'SCM_PORT_TYPE'. (gdbscm_memory_port_end_input, gdbscm_memory_port_seek) (ioscm_reinit_memory_port): Wrap in #if USING_GUILE_BEFORE_2_2. (gdbscm_memory_port_read, gdbscm_memory_port_write) (gdbscm_memory_port_seek, gdbscm_memory_port_close) [!USING_GUILE_BEFORE_2_2]: New functions. (gdbscm_memory_port_print): Remove use of 'SCM_PTOB_NAME'. (ioscm_init_memory_port_type) [!USING_GUILE_BEFORE_2_2]: Use 'gdbscm_memory_port_read'. Wrap 'scm_set_port_end_input', 'scm_set_port_flush', and 'scm_set_port_free' calls in #if USING_GUILE_BEFORE_2_2. (gdbscm_get_natural_buffer_sizes) [!USING_GUILE_BEFORE_2_2]: New function. (ioscm_init_memory_port): Remove. (ioscm_init_memory_port_stream): New function (ioscm_init_memory_port_buffers) [USING_GUILE_BEFORE_2_2]: New function. (gdbscm_memory_port_read_buffer_size) [!USING_GUILE_BEFORE_2_2]: Return scm_from_uint (0). (gdbscm_set_memory_port_read_buffer_size_x) [!USING_GUILE_BEFORE_2_2]: Call 'scm_setvbuf'. (gdbscm_memory_port_write_buffer_size) [!USING_GUILE_BEFORE_2_2]: Return scm_from_uint (0). (gdbscm_set_memory_port_write_buffer_size_x) [!USING_GUILE_BEFORE_2_2]: Call 'scm_setvbuf'. * configure.ac (try_guile_versions): Add "guile-2.2". * configure: Regenerate. * NEWS: Add entry. gdb/testsuite/ChangeLog 2020-06-28 Ludovic Courtès <ludo@gnu.org> * gdb.guile/scm-error.exp ("source $remote_guile_file_1"): Relax error regexp to match on Guile 2.2. gdb/doc/ChangeLog 2020-06-28 Ludovic Courtès <ludo@gnu.org> * guile.texi (Memory Ports in Guile): Mark 'memory-port-read-buffer-size', 'set-memory-port-read-buffer-size!', 'memory-port-write-buffer-size', 'set-memory-port-read-buffer-size!' as deprecated. * doc/guile.texi (Guile Introduction): Clarify which Guile versions are supported. Change-Id: Ib119b10a2787446e0ae482a5e1b36d809c44bb31
2020-07-20Skip tests requiring "alignof (void)" when compiling using clangGary Benson2-1/+17
As an extension, GCC allows void pointer arithmetic, with sizeof(void) and alignof(void) both 1. GDB supports this extension, but clang does not, and fails to compile the generated output of gdb.cp/align.exp with the following error: gdb compile failed, /gdbtest/build/gdb/testsuite/outputs/gdb.cp/align/align.cc:28:23: error: invalid application of 'alignof' to an incomplete type 'void' unsigned a_void = alignof (void); ^ ~~~~~~ 1 error generated. This commit adds preprocessor conditionals to the generated output, to omit the unsupported code when using clang, and supplies the expected value so the test can complete. gdb/testsuite/ChangeLog: * gdb.cp/align.exp: Fix "alignof (void)" tests when compiling with clang.
2020-07-20Fix problem running a few PowerPC linker tests when the .data section is ↵Nick Clifton2-3/+8
retained. * testsuite/ld-powerpc/powerpc.exp (ppcelftests): Use section name .PPC.EMB.apuinfo instead of section number 2 in apuinfo tests.
2020-07-20PR26265, Spurious 'gc-sections requires ... when --init or --finiAlan Modra5-10/+34
bfd/ * elflink.c (_bfd_elf_gc_keep): Use bfd_is_const_section. ld/ PR 26265 * ldlang.c (undef_from_cmdline): Delete. (ldlang_add_undef): Mark "cmdline" param unused. (lang_end): Traverse gc_sym_list to determine whether a symbol root has been specified. Update error message. * testsuite/ld-gc/noent.d: Adjust for changed error message.
2020-07-20[gdb/testsuite] Stabilize execution order in omp-par-scope.cTom de Vries2-0/+55
In openmp test-case gdb.threads/omp-par-scope.exp we xfail and kfail dependent on omp_get_thread_num (). Since execution order of the threads can vary from execution to execution, this can cause changes in test results. F.i., we can see this difference between two test runs: ... -KFAIL: single_scope: first thread: print i3 (PRMS: gdb/22214) +PASS: single_scope: first thread: print i3 -PASS: single_scope: second thread: print i3 +KFAIL: single_scope: second thread: print i3 (PRMS: gdb/22214) ... In both cases, the KFAIL is for omp_get_thread_num () == 1, but in one case that corresponds to the first thread executing that bit of code, and in the other case to the second thread. Get rid of this difference by stabilizing execution order. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-07-20 Tom de Vries <tdevries@suse.de> * gdb.threads/omp-par-scope.c (lock, lock2): New variable. (omp_set_lock_in_order): New function. (single_scope, multi_scope, nested_func, nested_parallel): Use omp_set_lock_in_order and omp_unset_lock. (main): Init and destroy lock and lock2.
2020-07-20x86: Update PR gas/26263 linker testsH.J. Lu4-9/+17
Update and run PR gas/26263 linker tests for all x86 ELF targets to accept any program header layout. PR gas/26263 * testsuite/ld-i386/pr26263.d: Updated. * testsuite/ld-x86-64/pr26263.d: Likewise. * testsuite/ld-x86-64/x86-64.exp: Run gas/26263 test for all ELF targets.
2020-07-20[gdb/testsuite] Fix valgrind-infcall-2.exp without libc debug infoTom de Vries2-1/+5
When running test-case gdb.base/valgrind-infcall-2.exp on a system without libc debug info installed, I run into: ... (gdb) p printf ("bla")^M 'printf' has unknown return type; cast the call to its declared return type^M (gdb) FAIL: gdb.base/valgrind-infcall-2.exp: do printf ... Fix this by casting the result of the printf call to int. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-07-20 Tom de Vries <tdevries@suse.de> * gdb.base/valgrind-infcall-2.exp: Handle printf unknown return type.
2020-07-20[gdb/testsuite] Bail out after gdb_start error in ↵Tom de Vries2-1/+10
gdb.threads/attach-slow-waitpid.exp When building gdb using CFLAGS/CXXFLAGS+=-fsanitizer=address and LDFLAGS+=-lasan, and running test-case gdb.threads/attach-slow-waitpid.exp, we get: ... spawn gdb -nw -nx -data-directory data-directory^M ==16079==ASan runtime does not come first in initial library list; \ you should either link runtime to your application or manually preload \ it with LD_PRELOAD.^M ERROR: (eof) GDB never initialized. ERROR: : spawn id exp10 not open while executing "expect { -i exp10 -timeout 120 -re "Kill the program being debugged. .y or n. $" { send_gdb "y\n" answer verbose "\t\tKilling previous pro..." ("uplevel" body line 1) invoked from within "uplevel $body" NONE : spawn id exp10 not open WARNING: remote_expect statement without a default case ERROR: : spawn id exp10 not open while executing "expect { -i exp10 -timeout 120 -re "Reading symbols from.*LZMA support was disabled.*$gdb_prompt $" { verbose "\t\tLoaded $arg into $GDB; .gnu_..." ("uplevel" body line 1) invoked from within "uplevel $body" NONE : spawn id exp10 not open ERROR: Couldn't load attach-slow-waitpid into GDB (eof). ERROR: Couldn't send attach 16070 to GDB. UNRESOLVED: gdb.threads/attach-slow-waitpid.exp: attach to target ... Bail out at the first ERROR, such that we have instead: ... ERROR: (eof) GDB never initialized. UNTESTED: gdb.threads/attach-slow-waitpid.exp: \ Couldn't start GDB with preloaded lib ... Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-07-20 Tom de Vries <tdevries@suse.de> * gdb.threads/attach-slow-waitpid.exp: Bail out if gdb_start fails.
2020-07-20x86: handle SVR4 escaped binary operatorsJan Beulich6-7/+95
PR gas/4572 When / is a comment character, its use as binary "divide" operator needs escaping by a backslash. Besides the scrubber needing to support this (addressed in an earlier change), there are also a few provisions needed in target specific operator handling. As the spec calls for % and * to also be escaped because of being "overloaded", also recognize these, despite the overloading there not really preventing their use as operators in most (%) or all (*) cases, given the way how the rest of the assembler works. To bring source and testsuite in line, also drop the TE_I386AIX part of the respective conditional, as i?86-*-aix* support had been removed a while ago.
2020-07-20gas: generalize comment character escaping recognitionJan Beulich2-18/+15
PR gas/4572 Generalize what ab1fadc6b2f0 ("PR22714, Assembler preprocessor loses track of \@") did to always honor escaped comment chars. Use this then to support escaped /, %, and * operators on x86, when / is a comment char (to match the Sun assembler's behavior).
2020-07-20x86: honor absolute section when emitting codeJan Beulich6-32/+189
Various provisions exist for insns to be placed in the absolute section, yet actually trying to do so didn't work. While data emission (of non- zero values) is not allowed by generic code, I think this functionality is useful for the programmer to be able to determine the size of insns. Therefore, rather than turning the silnet failure into a verbose one, make things mostly work; the one class of insns not supported (yet) are branches (JMP and Jcc) with dynamically determined displacement widths. In this one case, an error now gets reported instead of silently ignoring the code. Also avoid recording ISA / feature usage for insns emitted to the absolute section.
2020-07-20ix86: enable more ELF tests for VxWorksJan Beulich2-9/+19
The tree-wide is_elf_format predicate excludes VxWorks, but the majority of ELF specific tests is quite fine for this target.
2020-07-20Automatic date update in version.inGDB Administrator1-1/+1
2020-07-19gold: Update x32 testH.J. Lu2-4/+5
* testsuite/split_x32.sh: Likewise.
2020-07-19gold: Update x86-64 testsH.J. Lu5-14/+21
commit 36938cabf0efcb053d1585e8580a4b3db438ca4e Author: Jan Beulich <jbeulich@suse.com> Date: Wed Jul 15 08:53:55 2020 +0200 x86: avoid attaching suffixes to unambiguous insns removed the 'a' suffix on call and jmp from disassembler output. Update gold x86-64 tests. * testsuite/bnd_ifunc_1.sh: Updated. * testsuite/bnd_plt_1.sh: Likewise. * testsuite/split_x86_64.sh: Likewise. * testsuite/x86_64_indirect_call_to_direct.sh: Likewise.
2020-07-19x86: Change PLT32 reloc against section to PC32H.J. Lu10-6/+81
Commit 292676c1 resolved PLT32 reloc aganst local symbol to section. Since PLT32 relocation must be against symbols, turn such PLT32 relocation into PC32 relocation. gas/ PR gas/26263 * config/tc-i386.c (i386_validate_fix): Change PLT32 reloc against section to PC32 reloc. * testsuite/gas/i386/relax-5.d: Updated. * testsuite/gas/i386/x86-64-relax-4.d: Likewise. ld/ PR gas/26263 * testsuite/ld-i386/i386.exp: Run PR gas/26263 test. * testsuite/ld-x86-64/x86-64.exp: Likewise. * testsuite/ld-i386/pr26263.d: New file. * testsuite/ld-x86-64/pr26263.d: Likewise. * testsuite/ld-x86-64/pr26263.s: Likewise.
2020-07-19ld: optionally emit _etext last, before .dataHans-Peter Nilsson4-4/+21
So, here's my suggestion for making _init .. __etext cover .text + .rodata (including things like the read-only exception tables) for elf64mmix. A quick web search gives that __etext (and friends) isn't well defined, so each target can interpret the "end of text segment" to their own liking. It seems likely this change is also a better fit than the default for other ports, at least those with .rodata after .text in the same segment. The presence of a separate rodata-segment is optional (and not true for elf64mmix). This is reflected in the name as SEPARATE_TEXT / SEPARATE_CODE isn't considered, to keep it simple; each target has to make sure their settings of variables make sense. ld: * scripttempl/elf.sc (ETEXT_LAST_IN_RODATA_SEGMENT): New variable. * emulparams/elf64mmix.sh (ETEXT_LAST_IN_RODATA_SEGMENT): Define. * testsuite/ld-mmix/sec-1.d: Adjust.
2020-07-19Power10 stub selectionAlan Modra13-34/+359
This patch better supports mixing of power10 and non-power10 code, as might be seen in a cpu-optimized library using ifuncs to select functions optimized for a given cpu. Using -Wl,--no-power10-stubs isn't that good in this situation since non-power10 notoc stubs are slower and larger than the power10 variants, which you'd like to use on power10 code paths. With this change, power10 pc-relative code that makes calls marked @notoc uses power10 stubs if stubs are necessary, and other calls use non-power10 instructions in stubs. This will mean that if gcc is generating code for -mcpu=power10 but with pc-rel disabled then you'll get the older stubs even on power10 (unless you force with -Wl,--power10-stubs). That shouldn't be too big a problem: stubs that use r2 are reasonable. It's just the ones that set up addressing using "mflr 12; bcl 20,31,.+4; mflr 11; mtlr 12" that should be avoided if possible. bfd/ * elf64-ppc.c (struct ppc_link_hash_table): Add has_power10_relocs. (select_alt_stub): New function. (ppc_get_stub_entry): Use it here. (ppc64_elf_check_relocs): Set had_power10_relocs rather than power10_stubs. (ppc64_elf_size_stubs): Clear power10_stubs here instead. Don't merge notoc stubs with other varieties when power10_stubs is "auto". Instead dup the stub hash table entry. (plt_stub_size, ppc_build_one_stub, ppc_size_one_stub): Adjust tests of power10_stubs. ld/ * emultempl/ppc64elf.em (power10-stubs): Accept optional "auto" arg. * ld.texi (power10-stubs): Update. * testsuite/ld-powerpc/callstub-1.d: Force --power10-stubs. * testsuite/ld-powerpc/callstub-2.d: Relax branch offset comparison. * testsuite/ld-powerpc/callstub-4.d: New test. * testsuite/ld-powerpc/notoc.d: Force --no-power10-stubs. * testsuite/ld-powerpc/notoc3.d, * testsuite/ld-powerpc/notoc3.s, * testsuite/ld-powerpc/notoc3.wf: New test. * testsuite/ld-powerpc/powerpc.exp: Run new tests. Pass --no-power10-stubs for notoc link.
generated by cgit v1.1 at 2024-11-26 18:27:42 +0000