aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-02-24gdb: make the target_sections table private within program_spaceAndrew Burgess5-22/+59
Following on from earlier commits which made access to the target_sections table more 'const', this commit makes the table private within the program_space class and provides member functions to access the table. Ideally I would have liked for the new target_sections member function (on program_space) to return a 'const' reference to the table within the program_space. Unfortunately, there are two places in solib-*.c, where code outside of the program_space class modifies the target_sections table, and so to support this we need to return a non-const reference. There should be no user visible changes after this commit. gdb/ChangeLog: * exec.c (exec_target::close): Call new clear_target_sections function. (program_space::add_target_sections): Update name of member variable. (program_space::foreach_target_section): New function. (program_space::add_target_sections): Update name of member variable. (program_space::remove_target_sections): Likewise. (exec_one_fork): Use new target_sections member function. (exec_target::get_section_table): Likewise. (exec_target::files_info): Likewise. (set_section_command): Use new foreach_target_section member function. (exec_set_section_address): Likewise. (exec_target::has_memory): Use new target_sections member function. * progspace.h (program_space::clear_target_sections): New member function. (program_space::target_sections): Rename member variable to m_target_sections, replace with a new member function. (program_space::foreach_target_section): Declare new member function. (program_space::m_target_sections): New member variable. * solib-dsbt.c (scan_dyntag): Use new member function. * solib-svr4.c (scan_dyntag): Likewise.
2021-02-24gdb/testsuite: enable gdb.base/sect-cmd.exp test for all targetsAndrew Burgess2-85/+56
During review of the next patch (which changes the 'section' command), a bug was pointed out. I wondered why no tests spotted this bug and I found that the 'section' command test (sect-cmd.exp) is only run on hppa targets! In this commit I have given this test script a bit of a spring clean, bringing it up to date with current testsuite style. I have made some of the patterns a little more robust, but in general my intention was not to change the underlying meaning of any of these tests. gdb/testsuite/ChangeLog: * gdb.base/sect-cmd.exp: Rewrite using modern testsuite techniques. Enable the test for all targets.
2021-02-24gdb: spread a little 'const' through the target_section_table codeAndrew Burgess14-38/+69
The code to access the target section table can be made more const, so lets do that. There should be no user visible changes after this commit. gdb/ChangeLog: * gdb/bfd-target.c (class target_bfd) <get_section_table>: Make return type const. * gdb/exec.c (struct exec_target) <get_section_table>: Likewise. (section_table_read_available_memory): Make local const. (exec_target::xfer_partial): Make local const. (print_section_info): Make parameter const. * gdb/exec.h (print_section_info): Likewise. * gdb/ppc64-tdep.c (ppc64_convert_from_func_ptr_addr): Make local const. * gdb/record-btrace.c (record_btrace_target::xfer_partial): Likewise. * gdb/remote.c (remote_target::remote_xfer_live_readonly_partial): Likewise. * gdb/s390-tdep.c (s390_load): Likewise. * gdb/solib-dsbt.c (scan_dyntag): Likewise. * gdb/solib-svr4.c (scan_dyntag): Likewise. * gdb/target-debug.h (target_debug_print_target_section_table_p): Rename to... (target_debug_print_const_target_section_table_p): ...this. * gdb/target-delegates.c: Regenerate. * gdb/target.c (target_get_section_table): Make return type const. (target_section_by_addr): Likewise. Also make some locals const. (memory_xfer_partial_1): Make some locals const. * gdb/target.h (struct target_ops) <get_section_table>: Make return type const. (target_section_by_addr): Likewise. (target_get_section_table): Likewise.
2021-02-24gdb: add a new 'maint info target-sections' commandAndrew Burgess7-1/+153
We already have a command 'maint info sections', this command prints all sections from all known object files. However, GDB maintains a second section table internally. This section table is used when GDB wants to read directly from an object file rather than actually reading memory on the target. As such only some sections (the allocatable ones) are added to this secondary section table. I recently ran into a situation where some of GDB's optimisations for reading directly from the files were not working. In 'maint info sections' I could see that GDB knew about the object file, and did know about the sections that it _should_ have been reading from. But I couldn't ask GDB which sections it had copied into its secondary section table. This commit adds a new command 'maint info target-sections' that fills this gap. This command lists only those sections that GDB has copied into its secondary table. You'll notice that the testsuite includes a comment indicating that there's a bug in GDB. Normally this is not something I would add to the testsuite, instead we should raise an actual bugzilla bug and then mark an xfail, however, a later patch in this series will remove this comment once the actual bug in GDB is fixed. gdb/ChangeLog: * NEWS: Mention new 'maint info target-sections' command. * maint.c (maintenance_info_target_sections): New function. (_initialize_maint_cmds): Register new command. gdb/doc/ChangeLog: * gdb.texinfo (Files): Document new 'maint info target-sections' command. gdb/testsuite/ChangeLog: * gdb.base/maint-info-sections.exp: Add new tests. (check_maint_info_target_sections_output): New proc.
2021-02-24gdb/riscv: select rv32 target by default when requestedAndrew Burgess4-15/+86
GDB for RISC-V always uses target descriptions. When the target doesn't provide a target description then a default is selected. Usually this default is selected based on the properties of the executable being debugged. However, when there is no executable being debugged we currently fallback to the riscv:rv64 target description as the default. This leads to strange behaviour like this: $ gdb (gdb) set architecture riscv:rv32 (gdb) p sizeof ($pc) $1 = 8 Despite the users specifically setting the architecture to riscv:rv32 GDB still thinks that the target has riscv:rv64 register sizes. The above is a bit of a contrived situation. I actually ran into this situation while trying to connect to a running riscv:rv32 target without supplying an executable (the target didn't provide a target description). When I tried to set a register on the target I ran into errors because GDB was passing 8 bytes to the target rather than the expected 4. Even when I manually specified the architecture (as above) I couldn't convince GDB to only send 4 bytes. This patch fixes this issue. Now, when we selected a default target description we will make use of the user selected architecture to guide our choice. In the above example we now get: $ gdb (gdb) set architecture riscv:rv32 (gdb) p sizeof ($pc) $1 = 4 And my real world example of connecting to a remote without an executable works fine. I've used the fact that we can ask GDB about $pc even when no executable is loaded as the basis for a test to cover this situation. gdb/ChangeLog: * riscv-tdep.c (riscv_features_from_gdbarch_info): Rename to... (riscv_features_from_bfd): ...this. Change parameter type to 'bfd*', and update as required. (riscv_find_default_target_description): Update call to riscv_features_from_bfd. Select a default xlen based on info.bfd_arch_info. (riscv_gdbarch_init): Update call to riscv_features_from_bfd. gdb/testsuite/ChangeLog: * gdb.arch/riscv-default-tdesc.exp: New file.
2021-02-24gdb: call value_ind for pointers to dynamic types in UNOP_IND evaluationAndrew Burgess4-23/+51
When evaluating and expression containing UNOP_IND in mode EVAL_AVOID_SIDE_EFFECTS, GDB currently (mostly) returns the result of a call to value_zero meaning we get back an object with the correct type, but its contents are all zero. If the target type contains fields with dynamic type then in order to resolve these dynamic fields GDB will need to read the value of the field from within the parent object. In this case the field value will be zero as a result of the call to value_zero mentioned above. The idea behind EVAL_AVOID_SIDE_EFFECTS is to avoid the chance that doing something like `ptype` will modify state within the target, for example consider: ptype i++. However, there is already precedence within GDB that sometimes, in order to get accurate type results, we can't avoid reading from the target, even when EVAL_AVOID_SIDE_EFFECTS is in effect. For example I would point to eval.c:evaluate_var_value, the handling of OP_REGISTER, the handling of value_x_unop in many places. I believe the Ada expression evaluator also ignore EVAL_AVOID_SIDE_EFFECTS in some cases. I am therefor proposing that, in the case where a pointer points at a dynamic type, we allow UNOP_IND to perform the actual indirection. This allows accurate types to be displayed in more cases. gdb/ChangeLog: * eval.c (evaluate_subexp_standard): Call value_ind for points to dynamic types in UNOP_IND. gdb/testsuite/ChangeLog: * gdb.fortran/pointer-to-pointer.exp: Additional tests.
2021-02-24Fix a potential integer overflow when adding together section sizes for the ↵Nick Clifton2-9/+58
AVR port of objdump. PR 27285 * od-elf32_avr.c (elf32_avr_get_memory_usage): Check for overflows when adding together the section sizes.
2021-02-24Remove support for old v1 & v2 style GNU build notes.Nick Clifton3-28/+10
* objcopy.c (merge_gnu_build_notes): Remove support for v1/v2 GNU build notes. * readelf.c (print_gnu_build_attribute_description): Likewise.
2021-02-24PR27459, segmentation fault in go32exe_check_formatAlan Modra2-1/+9
PR 27459 * coff-stgo32.c (go32exe_check_format): Sanity check size of header to avoid a buffer overflow.
2021-02-24Automatic date update in version.inGDB Administrator1-1/+1
2021-02-24PR23691, gas .y files vs. automatic make dependenciesAlan Modra8-216/+125
A number of targets, bfin, rl78, rx, can show odd failures when bfd/reloc.c changes BFD_RELOC_* enum values, if recompiling over a build dir with existing objects. The problem is caused by bfin-parse.o and similar not being recompiled and so using stale BFD_RELOC_* values. This isn't fixed by making bfin-parse.c depend on bfd/reloc.c, which isn't necessary anyway. bfin-parse.o should have been recompiled due to bfd/bfd.h changing when extracted bfd/reloc.c BFD_RELOC_* values change, but that wasn't happening. The problem is that automake generates a makefile that loads gas/config/.deps/ dependency file for objects with corresponding sources mentioned in EXTRA_as_new_SOURCES. Unless we want to mess around generating explicit dependencies, I think that mean moving some object files to the build gas/config/. This patch does that, removing some hacks for m68k-parse.c that should no longer be necessary, and removes some rules that catered to old bison producing code that triggers compiler warnings. PR 23691 * Makefile.am (TARGET_CPU_CFILES): Split off config/xtensa-relax.c.. (TARGET_CPU_HFILES): ..and config/xtensa-relax.h.. (TARGET_EXTRA_FILES): ..to here. Add config/bfin-lex-wrapper.c, and use alongside TARGET_CPU_CFILES. (EXTRA_DIST): Update location of generated .c files. (config/m68k-parse.c): New rule replacing m68k-parse.c rule. (config/bfin-parse.c, config/rl78-parse.cm config/rx-parse.c), (config/bfin-lex.c, config/bfin-lex-wrapper.@OBJEXT@): Similarly. (itbl-lex-wrapper.@OBJEXT@): Simplify to just the needed dependencies. (itbl-parse.@OBJEXT@): Delete rule using NO_WERROR. (itbl-parse.c, itbl-parse.h): Tidy. * config/bfin-lex-wrapper.c: Include config/bfin-lex.c. * config/bfin-lex.l: Include config/bfin-parse.h. * configure.ac (extra_objects): Move object files corresponding to .y and .l files now in config/ to config/. * Makefile.in: Regenerate. * configure: Regenerate. * po/POTFILES.in: Regenerate.
2021-02-24Use make_tempname file descriptor in smart_renameAlan Modra6-35/+83
This patch makes use of the temp file descriptor in smart_rename rather than reopening the file. I don't believe there is a security issue in reopening the file, but this way is one less directory operation. The patch also attempts to preserve S_ISUID and S_ISGID. PR 27456 * bucomm.h (smart_rename): Update prototype. * rename.c (smart_rename): Add fromfd and preserve_dates params. Pass fromfd and target_stat to simple_copy. Call set_times when preserve_dates. (simple_copy): Accept fromfd rather than from filename. Add target_stat param. Rewind fromfd rather than opening. Open "to" file without O_CREAT. Try to preserve S_ISUID and S_ISGID. * ar.c (write_archive): Rename ofd to tmpfd. Dup tmpfd before closing output temp file, and pass tmpfd to smart_rename. * arsup.c (temp_fd): Rename from real_fd. (ar_save): Dup temp_fd and pass to smart_rename. * objcopy.c (strip_main, copy_main): Likewise, and pass preserve_dates.
2021-02-24PR27456, lstat in rename.c on MinGWAlan Modra2-76/+41
PR 27456 * rename.c: Tidy throughout. (smart_rename): Always copy. Remove windows specific code.
2021-02-23gdb/dwarf: create and destroy dwarf2_per_bfd's CUs-to-expand queueSimon Marchi3-30/+57
As described in the log of patch "gdb/dwarf: add assertion in maybe_queue_comp_unit", it would happen that a call to maybe_queue_comp_unit would enqueue a CU in the to-expand queue while nothing up the stack was processing the queue. This is not desirable, as items are then left lingering in the queue when we exit the dwarf2/read code. This is an inconsistent state. The normal case of using the queue is when we go through dw2_do_instantiate_symtab and process_queue. As depended-on CUs are found, they get added to the queue. process_queue expands CUs until the queue is empty. To catch these cases where things are enqueued while nothing up the stack is processing the queue, change dwarf2_per_bfd::queue to be an optional. The optional is instantiated in dwarf2_queue_guard, just before where we call process_queue. In the dwarf2_queue_guard destructor, the optional gets reset. Therefore, the queue object is instantiated only when something up the stack is handling it. If another entry point tries to enqueue a CU for expansion, an assertion will fail and we know we have something to fix. dwarf2_queue_guard sounds like the good place for this, as it's currently responsible for making sure the queue gets cleared if we exit due to an error. This also allows asserting that when age_comp_units or remove_all_cus run, the queue is not instantiated, and gives us one more level of assurance that we won't free the DIEs of a CU that is in the CUs-to-expand queue. gdb/ChangeLog: PR gdb/26828 * dwarf2/read.c (dwarf2_queue_guard) <dwarf2_queue_guard>: Instantiate queue. (~dwarf2_queue_guard): Clear queue. (queue_comp_unit): Assert that queue is instantiated. (process_queue): Adjust. * dwarf2/read.h (struct dwarf2_per_bfd) <queue>: Make optional. Change-Id: I8fe3d77845bb4ad3d309eac906acebe79d9f0a9d
2021-02-23gdb/dwarf: don't enqueue CU in maybe_queue_comp_unit if already expandedSimon Marchi2-17/+61
The previous commit log described how items could be left lingering in the dwarf2_per_bfd::queue and how that could cause trouble. This patch fixes the issue by changing maybe_queue_comp_unit so that it doesn't put a CU in the to-expand queue if that CU is already expanded. This will make it so that when dwarf2_fetch_die_type_sect_off calls follow_die_offset and maybe_queue_comp_unit, it won't enqueue the target CU, because it will see the CU is already expanded. This assumes that if a CU is dwarf2_fetch_die_type_sect_off's target CU, it will have previously been expanded. I think it is the case, but I can't be 100% sure. If that's not true, the assertions added in the following patch will catch it, and it means we'll have to re-think a bit more how things work (it wouldn't be well handled at all today anyway). This fixes something else in maybe_queue_comp_unit that looks wrong. Imagine the DIEs of a CU are loaded in memory, but that CU is not expanded. In that case, maybe_queue_comp_unit will use this early return: /* If the compilation unit is already loaded, just mark it as used. */ dwarf2_cu *cu = per_objfile->get_cu (per_cu); if (cu != nullptr) { cu->last_used = 0; return 0; } ... so the CU won't be queued for expansion. Whether the DIEs of a CU are loaded in memory and whether that CU is expanded are two orthogonal things, but that function appears to mix them. So, move the queuing above that check / early return, so that if the CU's DIEs are loaded in memory but the CU is not expanded yet, it gets enqueued. I tried to improve maybe_queue_comp_unit's documentation to clarify what the return value means. By clarifying this, I noticed that two callers (follow_die_offset and follow_die_sig_1) access the CU's DIEs after calling maybe_queue_comp_unit, only relying on maybe_queue_comp_unit's return value to tell whether DIEs need to be loaded first or not. As explained in the new comment, this is problematic: maybe_queue_comp_unit's return value doesn't tell whether DIEs are currently loaded, it means whether maybe_queue_comp_unit requires the caller to load them. If the CU is already expanded but the DIEs to have been freed, maybe_queue_comp_unit returns 0, meaning "I don't need you to load the DIEs". So if these two functions (follow_die_offset and follow_die_sig_1) need to access the DIEs in any case, for their own usage, they should make sure to load them if they are not loaded already. I therefore added an extra check to the condition they use, making it so they will always load the DIEs if they aren't already. From what I found, other callers don't care for the CU's DIEs, they call maybe_queue_comp_unit to ensure the CU gets expanded eventually, but don't care for it after that. gdb/ChangeLog: PR gdb/26828 * dwarf2/read.c (maybe_queue_comp_unit): Check if CU is expanded to decide whether or not to enqueue it for expansion. (follow_die_offset, follow_die_sig_1): Ensure we load the DIEs after calling maybe_queue_comp_unit. Change-Id: Id98c6b60669f4b4b21b9be16d0518fc62bdf686a
2021-02-23gdbserver: linux-low: make linux_process_target::filter_event return voidSimon Marchi3-14/+21
Same as the previous patch, but for GDBserver. The return value of this method is never used, change it to return void. gdbserver/ChangeLog: * linux-low.cc (linux_process_target::filter_event): Return void. * linux-low.h (class linux_process_target) <filter_event>: Return void. Change-Id: I79e5dc04d9b21b9f01c6d675fa463d1b1a703b3a
2021-02-23gdb: linux-nat: make linux_nat_filter_event return voidSimon Marchi2-12/+16
I noticed that linux_nat_filter_event returns a value, but its caller doesn't use it. This has been since 9c02b52532ac ("linux-nat.c: better starvation avoidance, handle non-stop mode too"). Before that commit, the return value was used to tell the caller whether to continue processing that event or not. But since then, the model is that we pull all events from the kernel and linux_nat_filter_event just saves the status to the lwp_info structure if it thinks it's relevant. And the caller, linux_nat_wait_1, selects a status at random amongst the threads with a pending status. So essentially, the return value of linux_nat_filter_event does not have a reason to be anymore. Change it so it returns void. gdb/ChangeLog: * linux-nat.c (linux_nat_filter_event): Return void. Change-Id: I35662868910f5122772ed92a512adfbf4da12d87
2021-02-23Automatic date update in version.inGDB Administrator1-1/+1
2021-02-22Change target_bfd_reopen to take a gdb_bfd_ref_ptrTom Tromey4-13/+19
While looking at Andrew's recent target sections series, I saw that target_bfd_reopen took a "bfd *", leading to a call to new_reference. However, because the only caller of target_bfd_reopen is already using gdb_bfd_ref_ptr, this code can be simplified and the explicit call to new_reference can be removed. gdb/ChangeLog 2021-02-22 Tom Tromey <tromey@adacore.com> * solib-svr4.c (enable_break): Update. * bfd-target.c (class target_bfd) <target_bfd>: Change parameter type. (target_bfd_reopen): Change parameter type. * bfd-target.h (target_bfd_reopen): Change parameter type.
2021-02-22gdb: add asserts in thread codeSimon Marchi2-0/+9
Unlike the previous patch, I don't propose that we take this patch into gdb-10-branch. This patch adds two asserts, prompted by investigating and fixing the bug fixed by the previous patch. The assert in find_thread_ptid would have caught the original issue before the segfault (I think it's slightly more use friendly). The assert in add_thread_silent would have made it clear that the solution proposed in [1] isn't the right one. The solution ended up passing nullptr as a target to add_thread. We don't want that, because add_thread_silent uses it to look up the inferior to which to add the thread. If the target is nullptr, we could find an inferior with the same pid, but belonging to an unrelated target. So we always want a non-nullptr target in add_thread_silent. gdb/ChangeLog: * thread.c (add_thread_silent): Add assert. (find_thread_ptid): Add assert. [1] https://sourceware.org/pipermail/gdb-patches/2021-February/176202.html Change-Id: Ie593ee45c5eb02235e8e9fbcda612d48ce883852
2021-02-22gdb: push target earlier in procfs_target::attach (PR 27435)Simon Marchi4-18/+36
Since this is a GDB 9 -> 10 regression, I would like to push it to gdb-10-branch. This is a follow-up to: https://sourceware.org/pipermail/gdb-patches/2021-February/176202.html This patch fixes a segfault seen when attaching to a process on Solaris. The steps leading to the segfault are: - procfs_target::attach calls do_attach, at this point the inferior's process slot in the target stack is empty. - do_attach adds a thread with `add_thread (&the_procfs_target, ptid)` - in add_thread_silent, the passed target (&the_procfs_target) is passed to find_inferior_ptid - find_inferior_ptid returns nullptr, as there is no inferior with this ptid that has &the_procfs_target as its process target - the nullptr `inf` is passed to find_thread_ptid, which dereferences it, causing a segfault - back in procfs_target::attach, after do_attach, we push the the_procfs_target on the inferior's target stack, although we never reach this because the segfault happens before. To fix this, I think we need to do the same as is done in inf_ptrace_target::attach: push the target early and unpush it in case the attach fails (and keep it if the attach succeeds). Implement it by moving target_unpush_up to target.h, so it can be re-used here. Make procfs_target::attach use it. Note that just like is mentioned in inf_ptrace_target::attach, we should push the target before calling target_pid_to_str, so that calling target_pid_to_str ends up in procfs_target::pid_to_str. Tested by trying to attach on a process on gcc211 on the gcc compile farm. gdb/ChangeLog: PR gdb/27435 * inf-ptrace.c (struct target_unpusher): Move to target.h. (target_unpush_up): Likewise. * procfs.c (procfs_target::attach): Push target early. Use target_unpush_up to unpush target in case of error. * target.h (struct target_unpusher): Move here. (target_unpush_up): Likewise. Change-Id: I88aff8b20204e1ca1d792e27ac6bc34fc1aa0d52
2021-02-22Don't handle BFD_RELOC_16 in XCOFF reloc_type_lookupAlan Modra3-6/+5
It's not needed for sizing fixups since 0e2779e98dc, and wrong to emit this reloc to the object file. * coff-rs6000.c (_bfd_xcoff_reloc_type_lookup): Remove BFD_RELOC_16. * coff64-rs6000.c (xcoff64_reloc_type_lookup): Likewise.
2021-02-22Automatic date update in version.inGDB Administrator1-1/+1
2021-02-21sim: common: split up acinclude.m4 into individual m4 filesMike Frysinger144-1197/+2156
This file is quite large and is getting unmanageable. Split it apart to follow aclocal best practices by putting one-macro-per-file. There shouldn't be any real functional changes here as can be seen in the configure script regens.
2021-02-21Warn when a script redefines a symbolAlan Modra6-11/+32
Note that we don't even warn if scripts adjust a symbol as in ld-elf/var1 and ld-scripts/pr14962. include/ * bfdlink.h (struct bfd_link_info): Add warn_multiple_definition. ld/ * ldexp.c (exp_fold_tree_1): Warn on script defining a symbol defined in an object file. * ldmain.c (multiple_definition): Heed info->warn_multiple_definition. * testsuite/ld-scripts/defined5.d: Expect a warning.
2021-02-21libctf AC_CANONICAL_TARGETAlan Modra4-81/+142
AC_CANONICAL_TARGET is needed for @target@ substitution in the makefile. AC_CANONICAL_HOST and AC_CANONICAL_BUILD are alread invoked indirectly, make them explicit. * configure.ac: Invoke AC_CANONICAL_TARGET, AC_CANONICAL_HOST and AC_CANONICAL_BUILD. * configure: Regenerate. * Makefile.in: Regenerate.
2021-02-21Automatic date update in version.inGDB Administrator1-1/+1
2021-02-20libctf: add a NEWSNick Alcock1-0/+26
I'm dividing this into three groups for now: new features, bugfixes, and bugfixes also present on a stable branch. Only user-visible bugfixes, not build-system fixes, are listed.
2021-02-20libctf, include: find types of symbols by nameNick Alcock15-179/+576
The existing ctf_lookup_by_symbol and ctf_arc_lookup_symbol functions suffice to look up the types of symbols if the caller already has a symbol number. But the caller often doesn't have one of those and only knows the name of the symbol: also, in object files, the caller might not have a useful symbol number in any sense (and neither does libctf: the 'symbol number' we use in that case literally starts at 0 for the lexicographically first-sorted symbol in the symtypetab and counts those symbols, so it corresponds to nothing useful). This means that even though object files have a symtypetab (generated by the compiler or by ld -r), the only way we can look up anything in it is to iterate over all symbols in turn with ctf_symbol_next until we find the one we want. This is unhelpful and pointlessly inefficient. So add a pair of functions to look up symbols by name in a dict and in a whole archive: ctf_lookup_by_symbol_name and ctf_arc_lookup_symbol_name. These are identical to the existing functions except that they take symbol names rather than symbol numbers. To avoid insane repetition, we do some refactoring in the process, so that both ctf_lookup_by_symbol and ctf_arc_lookup_symbol turn into thin wrappers around internal functions that do both lookup by symbol index and lookup by name. This massively reduces code duplication because even the existing lookup-by-index stuff wants to use a name sometimes (when looking up in indexed sections), and the new lookup-by-name stuff has to turn it into an index sometimes (when looking up in non-indexed sections): doing it this way lets us share most of that. The actual name->index lookup is done by ctf_lookup_symbol_idx. We do not anticipate this lookup to be as heavily used as ld.so symbol lookup by many orders of magnitude, so using the ELF symbol hashes would probably take more time to read them than is saved by using the hashes, and it adds a lot of complexity. Instead, do a linear search for the symbol name, caching all the name -> index mappings as we go, so that future searches are likely to hit in the cache. To avoid having to repeat this search over and over in a CTF archive when ctf_arc_lookup_symbol_name is used, have cached archive lookups (the sort done by ctf_arc_lookup_symbol* and the ctf_archive_next iterator) pick out the first dict they cache in a given archive and store it in a new ctf_archive field, ctfi_crossdict_cache. This can be used to store cross-dictionary cached state that depends on things like the ELF symbol table rather than the contents of any one dict. ctf_lookup_symbol_idx then caches its name->index mappings in the dictionary named in the crossdict cache, if any, so that ctf_lookup_symbol_idx in other dicts in the same archive benefit from the previous linear search, and the symtab only needs to be scanned at most once. (Note that if you call ctf_lookup_by_symbol_name in one specific dict, and then follow it with a ctf_arc_lookup_symbol_name, the former will not use the crossdict cache because it's only populated by the dict opens in ctf_arc_lookup_symbol_name. This is harmless except for a small one-off waste of memory and time: it's only a cache, after all. We can fix this later by using the archive caching machinery more aggressively.) In ctf-archive, we do similar things, turning ctf_arc_lookup_symbol into a wrapper around a new function that does both index -> ID and name -> ID lookups across all dicts in an archive. We add a new ctfi_symnamedicts cache that maps symbol names to the ctf_dict_t * that it was found in (so that linear searches for symbols don't need to be repeated): but we also *remove* a cache, the ctfi_syms cache that was memoizing the actual ctf_id_t returned from every call to ctf_arc_lookup_symbol. This is pointless: all it saves is one call to ctf_lookup_by_symbol, and that's basically an array lookup and nothing more so isn't worth caching. (Equally, given that symbol -> index mappings are cached by ctf_lookup_by_symbol_name, those calls are nearly free after the first call, so there's no point caching the ctf_id_t in that case either.) We fix up one test that was doing manual symbol lookup to use ctf_arc_lookup_symbol instead, and enhance it to check that the caching layer is not totally broken: we also add a new test to do lookups in a .o file, and another to do lookups in an archive with conflicted types and make sure that sort of multi-dict lookup is actually working. include/ChangeLog 2021-02-17 Nick Alcock <nick.alcock@oracle.com> * ctf-api.h (ctf_arc_lookup_symbol_name): New. (ctf_lookup_by_symbol_name): Likewise. libctf/ChangeLog 2021-02-17 Nick Alcock <nick.alcock@oracle.com> * ctf-impl.h (ctf_dict_t) <ctf_symhash>: New. <ctf_symhash_latest>: Likewise. (struct ctf_archive_internal) <ctfi_crossdict_cache>: New. <ctfi_symnamedicts>: New. <ctfi_syms>: Remove. (ctf_lookup_symbol_name): Remove. * ctf-lookup.c (ctf_lookup_symbol_name): Propagate errors from parent properly. Make static. (ctf_lookup_symbol_idx): New, linear search for the symbol name, cached in the crossdict cache's ctf_symhash (if available), or this dict's (otherwise). (ctf_try_lookup_indexed): Allow the symname to be passed in. (ctf_lookup_by_symbol): Turn into a wrapper around... (ctf_lookup_by_sym_or_name): ... this, supporting name lookup too, using ctf_lookup_symbol_idx in non-writable dicts. Special-case name lookup in dynamic dicts without reported symbols, which have no symtab or dynsymidx but where name lookup should still work. (ctf_lookup_by_symbol_name): New, another wrapper. * ctf-archive.c (enosym): Note that this is present in ctfi_symnamedicts too. (ctf_arc_close): Adjust for removal of ctfi_syms. Free the ctfi_symnamedicts. (ctf_arc_flush_caches): Likewise. (ctf_dict_open_cached): Memoize the first cached dict in the crossdict cache. (ctf_arc_lookup_symbol): Turn into a wrapper around... (ctf_arc_lookup_sym_or_name): ... this. No longer cache ctf_id_t lookups: just call ctf_lookup_by_symbol as needed (but still cache the dicts those lookups succeed in). Add lookup-by-name support, with dicts of successful lookups cached in ctfi_symnamedicts. Refactor the caching code a bit. (ctf_arc_lookup_symbol_name): New, another wrapper. * ctf-open.c (ctf_dict_close): Free the ctf_symhash. * libctf.ver (LIBCTF_1.2): New version. Add ctf_lookup_by_symbol_name, ctf_arc_lookup_symbol_name. * testsuite/libctf-lookup/enum-symbol.c (main): Use ctf_arc_lookup_symbol rather than looking up the name ourselves. Fish it out repeatedly, to make sure that symbol caching isn't broken. (symidx_64): Remove. (symidx_32): Remove. * testsuite/libctf-lookup/enum-symbol-obj.lk: Test symbol lookup in an unlinked object file (indexed symtypetab sections only). * testsuite/libctf-writable/symtypetab-nonlinker-writeout.c (try_maybe_reporting): Check symbol types via ctf_lookup_by_symbol_name as well as ctf_symbol_next. * testsuite/libctf-lookup/conflicting-type-syms.*: New test of lookups in a multi-dict archive.
2021-02-20sim: merge configure.tgt into configure.acMike Frysinger4-324/+207
One fewer file to worry about & manage.
2021-02-20readelf: Replace procesor with processorH.J. Lu4-4/+4
binutils/ PR binutils/27445 * readelf.c (print_gnu_property_note): Replace procesor with processor. ld/ PR binutils/27445 * testsuite/ld-i386/property-x86-isa1.d: Replace procesor with processor. * testsuite/ld-x86-64/property-x86-isa1-x32.d: Likewise. * testsuite/ld-x86-64/property-x86-isa1.d: Likewise.
2021-02-20Fail run_dump_test when an error is expected but not seenAlan Modra2-343/+349
* testsuite/lib/binutils-common.exp: Whitespace fixes throughout. (run_dump_test): Fail if expecting errors from a file like we do for error strings, if no error is seen.
2021-02-20Include ld-lib.exp from ctf-lib.expAlan Modra3-172/+11
* testsuite/config/default.exp (ld_L_opt): Define. * testsuite/lib/ctf-lib.exp (load_common_lib): Delete. Instead load ld-lib.exp. (run_host_cmd, run_host_cmd_yesno, check_compiler_available): Delete. (compile_one_cc, check_ctf_available): Delete.
2021-02-20Automatic date update in version.inGDB Administrator1-1/+1
2021-02-19Fix compile time warnings when building riscv assembler.Nick Clifton2-3/+8
* config/tc-riscv.c (riscv_ip): Fix compile time warnings about misleading indentation.
2021-02-18amd64-linux-siginfo.c: Adjust include order to avoid gnulib errorKevin Buettner2-1/+7
On Fedora rawhide, after updating to glibc-2.33, I'm seeing the following build failure: CXX nat/amd64-linux-siginfo.o In file included from /usr/include/bits/sigstksz.h:24, from /usr/include/signal.h:315, from ../gnulib/import/signal.h:52, from /ironwood1/sourceware-git/rawhide-gnulib/bld/../../worktree-gnulib/gdbserver/../gdb/nat/amd64-linux-siginfo.c:20: ../gnulib/import/unistd.h:663:3: error: #error "Please include config.h first." 663 | #error "Please include config.h first." | ^~~~~ glibc-2.33 has changed signal.h to now include <bits/sigstksz.h> which, in turn, includes <unistd.h>. For a gdb build, this causes the gnulib version of unistd.h to be pulled in first. The build failure shown above happens because gnulib's config.h has not been included before the include of <signal.h>. The fix is simple - we just rearrange the order of the header file includes to make sure that gdbsupport/commondefs.h is included before attempting to include signal.h. Note that gdbsupport/commondefs.h includes <gnulib/config.h>. Build and regression tested on Fedora 33. On Fedora rawhide, GDB builds again. gdb/ChangeLog: * nat/amd64-linux-siginfo.c: Include "gdbsupport/common-defs.h" (which in turn includes <gnulib/config.h>) before include of <signal.h>.
2021-02-19RISC-V: PR27158, fixed UJ/SB types and added CSS/CL/CS types for .insn.Nelson Chu17-308/+417
* Renamed obsolete UJ/SB types and RVC types, also added CSS/CL(CS) types, [VALID/EXTRACT/ENCODE macros] BTYPE_IMM: Renamed from SBTYPE_IMM. JTYPE_IMM: Renamed from UJTYPE_IMM. CITYPE_IMM: Renamed from RVC_IMM. CITYPE_LUI_IMM: Renamed from RVC_LUI_IMM. CITYPE_ADDI16SP_IMM: Renamed from RVC_ADDI16SP_IMM. CITYPE_LWSP_IMM: Renamed from RVC_LWSP_IMM. CITYPE_LDSP_IMM: Renamed from RVC_LDSP_IMM. CIWTYPE_IMM: Renamed from RVC_UIMM8. CIWTYPE_ADDI4SPN_IMM: Renamed from RVC_ADDI4SPN_IMM. CSSTYPE_IMM: Added for .insn without special encoding. CSSTYPE_SWSP_IMM: Renamed from RVC_SWSP_IMM. CSSTYPE_SDSP_IMM: Renamed from RVC_SDSP_IMM. CLTYPE_IMM: Added for .insn without special encoding. CLTYPE_LW_IMM: Renamed from RVC_LW_IMM. CLTYPE_LD_IMM: Renamed from RVC_LD_IMM. RVC_SIMM3: Unused and removed. CBTYPE_IMM: Renamed from RVC_B_IMM. CJTYPE_IMM: Renamed from RVC_J_IMM. * Added new operands and removed the unused ones, C5: Unsigned CL(CS) immediate, added for .insn directive. C6: Unsigned CSS immediate, added for .insn directive. Ci: Unused and removed. C<: Unused and removed. bfd/ PR 27158 * elfnn-riscv.c (perform_relocation): Updated encoding macros. (_bfd_riscv_relax_call): Likewise. (_bfd_riscv_relax_lui): Likewise. * elfxx-riscv.c (howto_table): Likewise. gas/ PR 27158 * config/tc-riscv.c (riscv_ip): Updated encoding macros. (md_apply_fix): Likewise. (md_convert_frag_branch): Likewise. (validate_riscv_insn): Likewise. Also arranged operands, including added C5 and C6 operands, and removed unused Ci and C< operands. * doc/c-riscv.texi: Updated and added CSS/CL/CS types. * testsuite/gas/riscv/insn.d: Added CSS/CL/CS instructions. * testsuite/gas/riscv/insn.s: Likewise. gdb/ PR 27158 * riscv-tdep.c (decode_ci_type_insn): Updated encoding macros. (decode_j_type_insn): Likewise. (decode_cj_type_insn): Likewise. (decode_b_type_insn): Likewise. (decode): Likewise. include/ PR 27158 * opcode/riscv.h: Updated encoding macros. opcodes/ PR 27158 * riscv-dis.c (print_insn_args): Updated encoding macros. * riscv-opc.c (MASK_RVC_IMM): defined to ENCODE_CITYPE_IMM. (match_c_addi16sp): Updated encoding macros. (match_c_lui): Likewise. (match_c_lui_with_hint): Likewise. (match_c_addi4spn): Likewise. (match_c_slli): Likewise. (match_slli_as_c_slli): Likewise. (match_c_slli64): Likewise. (match_srxi_as_c_srxi): Likewise. (riscv_insn_types): Added .insn css/cl/cs. sim/ PR 27158 * riscv/sim-main.c (execute_i): Updated encoding macros.
2021-02-19Wrong ELF class plugin vs. gcc ld versionAlan Modra2-72/+79
When building 32-bit binutils with CC="gcc -m32" CXX="g++ -m32" we can fail the gcc ld version test due to an error attempting to load a 64-bit plugin into 32-bit ld-new. This results in bogus errors about "Your compiler driver ignores -B when choosing ld." * testsuite/lib/ld-lib.exp: Whitespace. (load_common_lib): Expand single use and delete this proc. (run_host_cmd): Use -fno-lto when getting gcc's ld version. Use -B for clang too.
2021-02-19pr26548 testAlan Modra2-1/+5
I forgot that .sleb128 handles bignums, so this test should run fine for 32-bit targets on 32-bit hosts. * testsuite/binutils-all/readelf.exp (pr26548): Run for 32-bit too.
2021-02-19binutils: Avoid renaming over existing filesSiddhesh Poyarekar6-142/+33
Renaming over existing files needs additional care to restore permissions and ownership, which may not always succeed. Additionally, other properties of the file such as extended attributes may be lost, making the operation flaky. For predictable results, resort to rename() only if the file does not exist, otherwise copy the file contents into the existing file. This ensures that no additional tricks are needed to retain file properties. This also allows dropping of the redundant set_times on the tmpfile in objcopy/strip since now we no longer rename over existing files. binutils/ * ar.c (write_archive): Remove TARGET_STAT. Adjust call to SMART_RENAME. * arsup.c (ar_save): Likewise. * objcopy (strip_main): Don't copy TMPFD. Don't set times on temporary file and adjust call to SMART_RENAME. (copy_main): Likewise. * rename.c [!S_ISLNK]: Remove definitions. (try_preserve_permissions): Remove function. (smart_rename): Remove FD, PRESERVE_DATES arguments. Use rename system call only if TO does not exist. * bucomm.h (smart_rename): Adjust declaration.
2021-02-19Automatic date update in version.inGDB Administrator1-1/+1
2021-02-18Introduce expression::evaluateTom Tromey3-22/+37
This introduces a new method, expression::evaluate, and changes the top-level expression-evaluation functions to use it. Stack temporary handling is moved into this new method, which makes sense because that handling was only done when "*pos == 0". This patch avoids some temporary regressions related to stack temporary in the larger expression rewrite series. I've pulled it out separately because it seems like a reasonable change in its own right, and because it's better to avoid making that series even longer. Regression tested on x86-64 Fedora 32. gdb/ChangeLog 2021-02-18 Tom Tromey <tom@tromey.com> * expression.h (struct expression) <evaluate>: Declare method. * eval.c (evaluate_subexp): Simplify. (expression::evaluate): New method. (evaluate_expression, evaluate_type): Use expression::evaluate.
2021-02-18Fix a problem merging empty annobin notes on ppc64le targets.Nick Clifton2-0/+10
* objcopy.c (merge_gnu_build_notes): Handle notes with a start address that is higher than the end address.
2021-02-18gdb/testsuite: only run gdb.arch/i386-biarch-core.exp on suitable targetsAndrew Burgess2-0/+9
Restrict the test gdb.arch/i386-biarch-core.exp to only run on suitable targets. gdb/testsuite/ChangeLog: * gdb.arch/i386-biarch-core.exp: Add target check.
2021-02-18ld: remove stray debug fprintfAndrew Burgess2-4/+5
In this commit: commit ace667e59aede65c400381f1cff704b61e8ccb0b Date: Mon Jul 18 21:00:00 2016 +0100 ld: Restore file offset after a plugin fails to claim a file I inadvertently left in a stray fprintf call. Removed in this commit. ld/ChangeLog: * testplugin.c (record_read_length): Remove debug fprintf.
2021-02-18gdb: add missing full stops in --helpMarco Barisione1-2/+2
The descriptions for most options printed by gdb --help end with a full stop but, before this patch, not the ones for --args and --interpreter. This makes the line containing --args a bit longer but still not longer than the previously longest line, that is the one for the --tty option. gdb/ChangeLog: * main.c (print_gdb_help): Add full stops at the end of the descriptions for the --args and --interpreter options.
2021-02-18RISC-V: Add bfd/cpu-riscv.h to support all spec versions controlling.Nelson Chu16-289/+306
Make the opcode/riscv-opc.c and include/opcode/riscv.h tidy, move the spec versions stuff to bfd/cpu-riscv.h. Also move the csr stuff and ext_version_table to gas/config/tc-riscv.c for internal use. To avoid too many repeated code, define general RISCV_GET_SPEC_NAME/SPEC_CLASS macros. Therefore, assembler/dis-assembler/linker/gdb can get all spec versions related stuff from cpu-riscv.h and cpu-riscv.c, since the stuff are defined there uniformly. bfd/ * Makefile.am: Added cpu-riscv.h. * Makefile.in: Regenerated. * po/SRC-POTFILES.in: Regenerated. * cpu-riscv.h: Added to support spec versions controlling. Also added extern arrays and functions for cpu-riscv.c. (enum riscv_spec_class): Define all spec classes here uniformly. (struct riscv_spec): Added for all specs. (RISCV_GET_SPEC_CLASS): Added to reduce repeated code. (RISCV_GET_SPEC_NAME): Likewise. (RISCV_GET_ISA_SPEC_CLASS): Added to get ISA spec class. (RISCV_GET_PRIV_SPEC_CLASS): Added to get privileged spec class. (RISCV_GET_PRIV_SPEC_NAME): Added to get privileged spec name. * cpu-riscv.c (struct priv_spec_t): Replaced with struct riscv_spec. (riscv_get_priv_spec_class): Replaced with RISCV_GET_PRIV_SPEC_CLASS. (riscv_get_priv_spec_name): Replaced with RISCV_GET_PRIV_SPEC_NAME. (riscv_priv_specs): Moved below. (riscv_get_priv_spec_class_from_numbers): Likewise, updated. (riscv_isa_specs): Moved from include/opcode/riscv.h. * elfnn-riscv.c: Included cpu-riscv.h. (riscv_merge_attributes): Initialize in_priv_spec and out_priv_spec. * elfxx-riscv.c: Included cpu-riscv.h and opcode/riscv.h. (RISCV_UNKNOWN_VERSION): Moved from include/opcode/riscv.h. * elfxx-riscv.h: Removed extern functions to cpu-riscv.h. gas/ * config/tc-riscv.c: Included cpu-riscv.h. (enum riscv_csr_clas): Moved from include/opcode/riscv.h. (struct riscv_csr_extra): Likewise. (struct riscv_ext_version): Likewise. (ext_version_table): Moved from opcodes/riscv-opc.c. (default_isa_spec): Updated type to riscv_spec_class. (default_priv_spec): Likewise. (riscv_set_default_isa_spec): Updated. (init_ext_version_hash): Likewise. (riscv_init_csr_hash): Likewise, also fixed indent. include/ * opcode/riscv.h: Moved stuff and make the file tidy. opcodes/ * riscv-dis.c: Included cpu-riscv.h, and removed elfxx-riscv.h. (default_priv_spec): Updated type to riscv_spec_class. (parse_riscv_dis_option): Updated. * riscv-opc.c: Moved stuff and make the file tidy.
2021-02-17Fix completion related libstdc++ assert when using -D_GLIBCXX_DEBUGKevin Buettner2-2/+8
This commit fixes a libstdc++ assertion failure encountered when running gdb.base/completion.exp. In order to see this problem, GDB must be built with the follow CFLAGS and CXXFLAGS as part of the configure line: CFLAGS='-D_GLIBCXX_DEBUG' CXXFLAGS='-D_GLIBCXX_DEBUG' (Also, this problem was encountered using Fedora rawhide. It might not be reproducible in Fedora versions prior to Fedora 34.) Using the gdb.base/completion.exp test program, the problem can be observed as follows: [kev@rawhide-1 gdb]$ ./gdb -q testsuite/outputs/gdb.base/completion/completion Reading symbols from testsuite/outputs/gdb.base/completion/completion... (gdb) start Temporary breakpoint 1 at 0x401179: file ../../worktree-master/gdb/testsuite/gdb.base/break.c, line 43. Starting program: testsuite/outputs/gdb.base/completion/completion Temporary breakpoint 1, main (argc=1, argv=0x7fffffffd718, envp=0x7fffffffd728) at ../../worktree-master/gdb/testsuite/gdb.base/break.c:43 43 if (argc == 12345) { /* an unlikely value < 2^16, in case uninited */ /* set breakpoint 6 here */ (gdb) p <TAB>/usr/include/c++/11/string_view:211: constexpr const value_type& std::basic_string_view<_CharT, _Traits>::operator[](std::basic_string_view<_CharT, _Traits>::size_type) const [with _CharT = char; _Traits = std::char_traits<char>; std::basic_string_view<_CharT, _Traits>::const_reference = const char&; std::basic_string_view<_CharT, _Traits>::size_type = long unsigned int]: Assertion '__pos < this->_M_len' failed. Aborted (core dumped) (Note that I added "<TAB>" to make it clear where the tab key was pressed.) gdb/ChangeLog: * ada-lang.c (ada_fold_name): Check for non-empty string prior to accessing it. (ada_lookup_name_info): Likewise.
2021-02-18Automatic date update in version.inGDB Administrator1-1/+1
2021-02-17[PR cli/17290] gdb/doc: Fix show remote interrupt-*.Lancelot SIX2-2/+8
Add the missing 'remote' in: - @item show remote interrupt-sequence - @item show remote interrupt-on-connect