aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-06-29Automatic date update in version.inGDB Administrator1-1/+1
2020-06-28Remove "cmd_type" functionTom Tromey5-34/+16
The cmd_type function only has a single caller, which is in the CLI implementation code. This patch removes the function, and moves the cmd_types enum definition from command.h to cli-decode.h, fixing an 18 year old FIXME. gdb/ChangeLog 2020-06-28 Tom Tromey <tom@tromey.com> * command.h (cmd_types): Remove. (cmd_type): Don't declare. * cli/cli-decode.h (enum cmd_types): Uncomment. No longer a typedef. * cli/cli-cmds.c (setting_cmd): Use cmd->type directly. * cli/cli-decode.c (cmd_type): Remove.
2020-06-28Automatic date update in version.inGDB Administrator1-1/+1
2020-06-27gdbsupport: add format attribute to print_xml_feature::add_lineSimon Marchi2-1/+6
Fixes this clang error: CXX tdesc.o /home/smarchi/src/binutils-gdb/gdbsupport/tdesc.cc:444:25: error: format string is not a string literal [-Werror,-Wformat-nonliteral] string_vappendf (tmp, fmt, ap); ^~~ There is already a but about GCC not emitting this warning: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82206 gdbsupport/ChangeLog: * tdesc.h (class print_xml_feature) <add_line>: Add ATTRIBUTE_PRINTF. Change-Id: I7014075e83717f6d7e19d044a3675ff9981ebe17
2020-06-27Make {get,set}_inferior_io_terminal inferior methodsPedro Alves9-54/+68
This converts the get_inferior_io_terminal and set_inferior_io_terminal free functions to inferior methods. Since the related commands are called "tty", "{set,show} inferior-tty", and MI's "-inferior-tty-{set,show}", to make the connection between the commands and the code more obvious, the methods are named set_tty/tty instead of set_io_terminal/io_terminal. gdb/ChangeLog: * fork-child.c (prefork_hook): Adjust. * infcmd.c (set_inferior_io_terminal, get_inferior_io_terminal): Delete. (set_inferior_tty_command, show_inferior_tty_command): Adjust. * inferior.c (inferior::set_tty, inferior::tty): New methods. * inferior.h (set_inferior_io_terminal, get_inferior_io_terminal): Remove declarations. (struct inferior) <set_tty, tty>: New methods. (struct inferior) <terminal>: Rename to ... (struct inferior) <m_terminal>: ... this and make private. * main.c (captured_main_1): Adjust. * mi/mi-cmd-env.c (mi_cmd_inferior_tty_set): Adjust. (mi_cmd_inferior_tty_show): Adjust. * nto-procfs.c (nto_procfs_target::create_inferior): Adjust. * windows-nat.c (windows_nat_target::create_inferior): Adjust.
2020-06-27asan: readelf: use after free in process_archiveAlan Modra2-1/+14
This tidies up in cases where fuzzed thin archives hit the error return path in setup_nested_archive. * elfcomm.c (setup_nested_archive): Set nested_arch->file to NULL after freeing. (release_archive): Set fields of arch to NULL after freeing.
2020-06-27Automatic date update in version.inGDB Administrator1-1/+1
2020-06-26Make test names unique in python.exp and guile.expPhilippe Waroquiers5-95/+95
Version 2, handles the comments of Simon and Pedro. Note that gdb_test_multiline and gdb_py_test_multiple are using the "input line" as the test name, and so when there is a duplicated input line (such as a line containing "end"), we have duplicated test names => as gdb_test_multiline and gdb_py_test_multiple are identical, as indicated in FIXME, move this to gdb.exp, and make the test name unique by adding the inputnr to the pass message for each input. 2020-06-26 Philippe Waroquiers <philippe.waroquiers@skynet.be> * lib/gdb.exp (gdb_test_multiline): New, moved from gdb-guile.exp, have a input seq nr in each pass message. * lib/gdb-guile.exp (gdb_test_multiline): Move to gdb.exp. * lib/gdb-python.exp (gdb_py_test_multiple): Remove. * gdb.python/python.exp: Make test names unique, use gdb_test_multiline instead of gdb_py_test_multiple, use $gdb_test_name. * gdb.guile/guile.exp: Make test names unique, use $gdb_test_name
2020-06-26x86: Process ImmExt without operandsH.J. Lu2-1/+10
To support Intel AMX instructions with 8-bit immediate opcode extension, but without operands: tilerelease, 0, 0x49, 0xc0, 1, CpuAMX_TILE|Cpu64, Vex|VexOpcode=1|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|ImmExt, { 0 } process ImmExt without operands. * config/tc-i386.c (md_assemble): Process ImmExt without operands.
2020-06-26i386-opc.tbl: Add a blank lineH.J. Lu2-0/+5
* i386-opc.tbl: Add a blank line.
2020-06-26x86: Correct VexSIB128 to VecSIB128H.J. Lu2-29/+29
2020-06-26x86: Rename VecSIB to SIB for Intel AMXH.J. Lu6-99/+127
Rename VecSIB to SIB to support Intel Advanced Matrix Extensions which introduces instructions with a mandatory SIB byte which isn't a vector SIB (VSIB). gas/ * config/tc-i386.c (check_VecOperands): Replace vecsib with sib. Replace VecSIB128, VecSIB256 and VecSIB512 with VECSIB128, VECSIB256 and VECSIB512, respectively. (build_modrm_byte): Replace vecsib with sib. opcodes/ * i386-gen.c (opcode_modifiers): Replace VecSIB with SIB. (VecSIB128): Renamed to ... (VECSIB128): This. (VecSIB256): Renamed to ... (VECSIB256): This. (VecSIB512): Renamed to ... (VECSIB512): This. (VecSIB): Renamed to ... (SIB): This. (i386_opcode_modifier): Replace vecsib with sib. * i386-opc.tbl (VexSIB128): New. (VecSIB256): Likewise. (VecSIB512): Likewise. Replace VecSIB=1, VecSIB=2 and VecSIB=3 with VexSIB128, VecSIB256 and VecSIB512, respectively.
2020-06-26libctf: support platforms with separate libintlNick Alcock6-2/+112
We were not using the right configure machinery to spot libintl on platforms where it was required, leading to the spurious failure of various configure tests (e.g. for things like ELF support in BFD). libctf/ * aclocal.m4: Add config/gettext-sister.m4: Shuffle into alphabetical order. * configure.ac: Add ZW_GNU_GETTEXT_SISTER_DIR. * config.h.in: Regenerated. * Makefile.in: Likewise. * configure: Likewise.
2020-06-26libctf: add some missing #includes.Nick Alcock3-0/+7
Causes warnings on (at least) recent FreeBSD. libctf/ * ctf-create.c: Include <unistd.h>. * ctf-open-bfd.c: Likewise.
2020-06-26libctf, elfcpp, gold: do not assume that <byteswap.h> contains bswap_*Nick Alcock11-59/+190
At least one C library (uclibc-ng) defines some of these only when the compiler is GCC. We might as well test for all three cases and handle any of them being missing. Very similar code exists in libctf and split between elfcpp and gold: fix both. (Also sync up elfcpp with a change made to libctf swap.h a few months ago: since there is no out-of-line definition of the bswap replacements, they should be declared static inline, not just inline, to prevent the linker generating out-of-line references to them.) PR libctf/25120 libctf/ * configure.ac: Check for bswap_16, bswap_32, and bswap_64 decls. * swap.h (bswap_16): Do not assume that presence of <byteswap.h> means this is declared. (bswap_32): Likewise. (bswap_64): Likewise. (bswap_identity_64): Remove, unused. * configure: Regenerated. * config.h.in: Likewise. gold/ * configure.ac: Check for bswap_16, bswap_32, and bswap_64 decls. * configure: Regenerated. * config.h.in: Likewise. elfcpp/ * elfcpp_swap.h (bswap_16): Do not assume that presence of <byteswap.h> means this is declared. Make static inline, matching recent change to libctf, since there is no non-inline definition of these functions. (bswap_32): Likewise. (bswap_64): Likewise.
2020-06-26libctf: work with compilers not supporting GNU C attributesNick Alcock2-0/+15
The obvious fallback __attribute__ stanza was missing. Thanks to Harald van Dijk. PR 25120 libctf/ * ctf-impl.h (_libctf_printflike_): Add non-GNU-C fallback. (_libctf_unlikely_): Likewise. (_libctf_unused): Likewise. (_libctf_malloc_): Likewise.
2020-06-26libctf: avoid nonportable __thread in CTF archive handlingNick Alcock2-9/+15
This keeps archive searching threadsafe using the new bsearch_r that was just added to libiberty. PR25120 libctf/ * ctf-archive.c (search_nametbl): No longer global: declare... (ctf_arc_open_by_name_internal): ... here. Use bsearch_r. (search_modent_by_name): Take and use ARG for the nametbl.
2020-06-26libctf, binutils: support CTF archives like objdumpNick Alcock9-109/+182
objdump and readelf have one major CTF-related behavioural difference: objdump can read .ctf sections that contain CTF archives and extract and dump their members, while readelf cannot. Since the linker often emits CTF archives, this means that readelf intermittently and (from the user's perspective) randomly fails to read CTF in files that ld emits, with a confusing error message wrongly claiming that the CTF content is corrupt. This is purely because the archive-opening code in libctf was needlessly tangled up with the BFD code, so readelf couldn't use it. Here, we disentangle it, moving ctf_new_archive_internal from ctf-open-bfd.c into ctf-archive.c and merging it with the helper function in ctf-archive.c it was already using. We add a new public API function ctf_arc_bufopen, that looks very like ctf_bufopen but returns an archive given suitable section data rather than a ctf_file_t: the archive is a ctf_archive_t, so it can be called on raw CTF dictionaries (with no archive present) and will return a single-member synthetic "archive". There is a tiny lifetime tweak here: before now, the archive code could assume that the symbol section in the ctf_archive_internal wrapper structure was always owned by BFD if it was present and should always be freed: now, the caller can pass one in via ctf_arc_bufopen, wihch has the usual lifetime rules for such sections (caller frees): so we add an extra field to track whether this is an internal call from ctf-open-bfd, in which case we still free the symbol section. include/ * ctf-api.h (ctf_arc_bufopen): New. libctf/ * ctf-impl.h (ctf_new_archive_internal): Declare. (ctf_arc_bufopen): Remove. (ctf_archive_internal) <ctfi_free_symsect>: New. * ctf-archive.c (ctf_arc_close): Use it. (ctf_arc_bufopen): Fuse into... (ctf_new_archive_internal): ... this, moved across from... * ctf-open-bfd.c: ... here. (ctf_bfdopen_ctfsect): Use ctf_arc_bufopen. * libctf.ver: Add it. binutils/ * readelf.c (dump_section_as_ctf): Support .ctf archives using ctf_arc_bufopen. Automatically load the .ctf member of such archives as the parent of all other members, unless specifically overridden via --ctf-parent. Split out dumping code into... (dump_ctf_archive_member): ... here, as in objdump, and call it once per archive member. (dump_ctf_indent_lines): Code style fix.
2020-06-26libctf: create: forwards are always in the namespace of their referentNick Alcock2-2/+14
The C namespace a forward is located in is always the same as the namespace of the corresponding complete type: 'struct foo' is in the struct namespace and does not collide with, say, 'union foo'. libctf allowed for this in many places, but inconsistently: in particular, forward *addition* never allowed for this, and was interning forwards in the default namespace, which is always wrong, since you can only forward structs, unions and enums, all of which are in their own namespaces in C. Forward removal needs corresponding adjustment to remove the names form the right namespace, as does ctf_rollback. libctf/ * ctf-create.c (ctf_add_forward): Intern in the right namespace. (ctf_dtd_delete): Remove correspondingly. (ctf_rollback): Likewise.
2020-06-26libctf: create: ctf_add_type should hand back already-added non-SoUsNick Alcock2-6/+15
When we add a type from a dictionary and then try to add it again, we should hand it back unchanged unless it is a structure, union or enum with a different number of members. That's what the comment says we do. Instead, we hand it back unchanged *only* if it is a structure, union or enum with the same number of members: non-structs, unions and enums are unconditionally added. This causes extreme type bloating and (in conjunction with the bug fixed by the next commit) can easily lead to the same type being mistakenly added to a dictionary more than once (which, for forwards, was not banned and led to dictionary corruption). libctf/ * ctf-create.c (ctf_add_type_internal): Hand back existing types unchanged.
2020-06-26libctf: create: don't add forwards if the type added already existsNick Alcock2-1/+9
This is what ctf_add_forward is documented to do, but it's not what it actually does: the code is quite happy to add forwards that duplicate existing structs, etc. This is obviously wrong and breaks both the nondeduplicating linker and the upcoming deduplicator, as well as allowing ordinary callers of ctf_add_type to corrupt the dictionary by just adding the same root- visible forward more than once. libctf/ * ctf-create.c (ctf_add_forward): Don't add forwards to types that already exist.
2020-06-26libctf: create: non-root-visible types should not appear in name tablesNick Alcock4-17/+53
We were accidentally interning newly-added and newly-opened non-root-visible types into name tables, and removing names from name tables when such types were removed. This is very wrong: the whole point of non-root-visible types is they do not go in name tables and cannot be looked up by name. This bug made non-root-visible types basically identical to root-visible types, right back to the earliest days of libctf in the Solaris era. libctf/ * ctf-open.c (init_types): Only intern root-visible types. * ctf-create.c (ctf_dtd_insert): Likewise. (ctf_dtd_delete): Only remove root-visible types. (ctf_rollback): Likewise. (ctf_add_generic): Adjust. (ctf_add_struct_sized): Adjust comment. (ctf_add_union_sized): Likewise. (ctf_add_enum): Likewise. * ctf-impl.h (ctf_dtd_insert): Adjust prototype.
2020-06-26binutils, ld: work with --disable-libctfNick Alcock19-10/+257
This unfortunately means conditionalizing out all the libctf code, but the result is not too unbearably ugly, if a bit repetitive. I have stubbed out code in the !ENABLE_LIBCTF path to avoid extra redundant ifdefs where it seems that might be helpful. (The stubs are not too disruptive, but I've tried to keep them on one line where possible to avoid filling up the screen with stubs that nobody would care about. If this is too much of a coding style violation I can change it.) Changes since v2: use GCC_ENABLE rather than repeating all the AC_ARG_ENABLE stuff over and over again. ld/ * configure.ac [--enable-libctf]: New, default yes. Set ENABLE_LIBCTF accordingly. * Makefile.am [!ENABLE_LIBCTF]: Empty LIBCTF. * configure: Regenerate. * config.in: Regenerate. * Makefile.in: Regenerate. * aclocal.m4: Regenerate. * ldlang.c (ctf_output): Conditionalize on ENABLE_LIBCTF. (ldlang_open_ctf): Likewise. (lang_merge_ctf): Likewise. (ldlang_ctf_apply_strsym): Likewise. (lang_write_ctf): Likewise. (ldlang_write_ctf_late): Likewise. (ldlang_open_ctf) [!ENABLE_LIBCTF]: Warn about the presence of CTF sections. (lang_merge_ctf) [!ENABLE_LIBCTF]: New stub. (ldlang_ctf_apply_strsym) [!ENABLE_LIBCTF]: Likewise. (lang_write_ctf) [!ENABLE_LIBCTF]: Likewise. (ldlang_write_ctf_late) [!ENABLE_LIBCTF]: Likewise. * ldelfgen.c (ldelf_emit_ctf_early): Conditionalize on ENABLE_LIBCTF. (struct ctf_strsym_iter_cb_arg): Likewise. (ldelf_ctf_strtab_iter_cb): Likewise. (ldelf_ctf_symbols_iter_cb): Likewise. (ldelf_examine_strtab_for_ctf): Likewise. (ldelf_emit_ctf_early) [!ENABLE_LIBCTF]: New stub. (ldelf_examine_strtab_for_ctf) [!ENABLE_LIBCTF]: New stub. binutils/ * configure.ac [--enable-libctf]: New, default yes. Set ENABLE_LIBCTF accordingly. * Makefile.am [!ENABLE_LIBCTF]: Empty LIBCTF and LIBCTF_NOBFD. * configure: Regenerate. * config.in: Regenerate. * Makefile.in: Regenerate. * aclocal.m4: Regenerate. * objdump.c (usage): Conditionalize portions on ENABLE_LIBCTF. (option_values): Likewise. (long_options): Likewise. (main): Likewise. (dump_ctf_indent_lines): Conditionalize out when !ENABLE_LIBCTF. (make_ctfsect): Likewise. (dump_ctf_archive_member): Likewise. (dump_ctf) [ENABLE_LIBCTF]: Likewise. (dump_ctf) [!ENABLE_LIBCTF]: New empty stub. * readelf.c (options): Conditionalize portions on ENABLE_LIBCTF. (usage): Likewise. (process_section_contents): Likewise. (shdr_to_ctf_sect): Conditionalize out when !ENABLE_LIBCTF. (dump_ctf_indent_lines): Likewise. (dump_section_as_ctf) [ENABLE_LIBCTF]: Likewise.
2020-06-26Fix --enable-libctf and --disable-staticNick Alcock15-6/+146
This fixes test runs and compilation when --disable-libctf, --disable-static, or --enable-shared are passed. Changes since v2: Use GCC_ENABLE and fix indentation. Fix prototype using 'void'. Use 'unsupported' and gdb_caching_proc. Changes since v3: Adapt to upstream changes providing skip_ctf_tests. Changes since v4: Adapt to upstream changes in the seven months (!) since I last looked at this. gdb/ChangeLog * configure.ac: Add --enable-libctf: handle --disable-static properly. * acinclude.m4: sinclude ../config/enable.m4. * Makefile.in (aclocal_m4_deps): Adjust accordingly. (LIBCTF): Substitute in. (CTF_DEPS): New, likewise. (CLIBS): libctf needs symbols from libbfd: move earlier. (CDEPS): Use CTF_DEPS, not LIBCTF, now LIBCTF can include rpath flags. * ctfread.c: Surround in ENABLE_LIBCTF. (elfctf_build_psymtabs) [!ENABLE_LIBCTF]: New stub. * configure: Regenerate. * config.in: Likewise. gdb/testsuite/ChangeLog * configure.ac: Add --enable-libctf. * aclocal.m4: sinclude ../config/enable.m4. * Makefile.in (site.exp): Add enable_libctf to site.exp. * lib/gdb.exp (skip_ctf_tests): Use it. * gdb.base/ctf-constvars.exp: Error message tweak. * gdb.base/ctf-ptype.exp: Likewise. * configure: Regenerate.
2020-06-26x86: make I disassembler macro available for new useJan Beulich2-13/+17
The {Q|Q} construct on lgdt/lidt and the slightly different {Q|IQ} struck me as odd when encountering. Realizing they both have the same effect, let's free up the I macro by using the former form of construct where needed (there aren't that many uses overall). With there now being several multi-character macros also re-do "alt" handling slightly: Terminate it when finding the closing brace, rather than after the next single character. Also set the flag only when actually in Intel syntax mode.
2020-06-26ld/x86: actually invoke k1om testsJan Beulich2-0/+7
Unlike claimed by the ChangeLog entries added by 7a9068fe1646 ("Add initial Intel K1OM support") these tests did never get enabled.
2020-06-26x86: fix processing of -M disassembler optionJan Beulich7-7/+84
Multiple -M options can be specified in any order. Therefore stright assignment to fields affected needs to be avoided, such that earlier options' effects won't be discarded. This was in particular a problem for -Msuffix followed by certain of the other sub-options. While updating documentation, take the liberty and also drop the redundant mentioning of being able to comma-separate multiple options.
2020-06-26Fix -Wstring-compare testcase build failureGary Benson3-2/+16
Clang fails to compile the file gdb/testsuite/gdb.cp/try_catch.cc with the following error: warning: result of comparison against a string literal is unspecified (use strncmp instead) [-Wstring-compare] This commit fixes the error, replacing the pointer comparison with a call to strcmp. This commit also adds a final check: the test program is run to the final return statement, and the value of "test" is checked to ensure it is still "true" at that point. gdb/testsuite/ChangeLog: * gdb.cp/try_catch.cc: Include string.h. (main): Replace comparison against string literal with strcmp, avoiding build failure with -Wstring-compare. Add "marker test-complete". * gdb.cp/try_catch.exp: Run the test to the above marker, then verify that the value of "test" is still true.
2020-06-26Improve documentation of which shell is used by GDB's shell commandsEli Zaretskii2-3/+9
gdb/doc/ChangeLog: 2020-06-26 Eli Zaretskii <eliz@gnu.org> * gdb.texinfo (Shell Commands): More accurate description of use of $SHELL. Reported by Sandra Loosemore <sandra@codesourcery.com>.
2020-06-26m68k: tag floating-point ABI usedPat Bernardi23-1/+263
This patch adds GNU attribute support to m68k and utilises it to tag the floating-point calling convention used (hard-float or soft-float). It enables the linker to ensure linked objects use a consistent floating-point ABI and allows tools like GDB to infer the ABI used from the ELF file. It is based on similar work done for PowerPC. bfd/ * elf32-m68k.c (m68k_elf_merge_obj_attributes): New function. (elf32_m68k_merge_private_bfd_data): Merge GNU attributes. binutils/ * readelf.c (display_m68k_gnu_attribute): New function. (process_arch_specific): Call display_m68k_gnu_attribute for EM_68K. gas/ * config/tc-m68k.c (m68k_elf_gnu_attribute): New function. (md_pseudo_table): Handle "gnu_attribute". * doc/as.texi: Document GNU attribute for M68K. include/ * elf/m68k.h: Add enum for GNU object attribute with floating point tag name and values. ld/ * testsuite/ld-m68k/attr-gnu-4-0.s: New file. * testsuite/ld-m68k/attr-gnu-4-1.s: Likewise. * testsuite/ld-m68k/attr-gnu-4-2.s: Likewise. * testsuite/ld-m68k/attr-gnu-4-00.d: Likewise. * testsuite/ld-m68k/attr-gnu-4-01.d: Likewise. * testsuite/ld-m68k/attr-gnu-4-02.d: Likewise. * testsuite/ld-m68k/attr-gnu-4-10.d: Likewise. * testsuite/ld-m68k/attr-gnu-4-11.d: Likewise. * testsuite/ld-m68k/attr-gnu-4-12.d: Likewise. * testsuite/ld-m68k/attr-gnu-4-20.d: Likewise. * testsuite/ld-m68k/attr-gnu-4-21.d: Likewise. * testsuite/ld-m68k/attr-gnu-4-22.d: Likewise. * testsuite/ld-m68k/m68k.exp: Run the new tests.
2020-06-26RISCV changes broke 32-bit --enable-targets=allAlan Modra3-95/+89
By the look of it, git commit 39ff0b812324 broke 32-bit host --enable-targets=all binutils builds. /usr/local/bin/ld: ../opcodes/.libs/libopcodes.a(riscv-dis.o): in function `parse_riscv_dis_option': /home/alan/src/binutils-gdb/opcodes/riscv-dis.c:102: undefined reference to `riscv_get_priv_spec_class' collect2: error: ld returned 1 exit status Makefile:925: recipe for target 'objdump' failed The problem is that elfxx-riscv.c is not built for a 32-bit host without --enable-64-bit-bfd or unless RISCV is given specifically as a target. No such trimming of 64-bit only targets is done in opcodes. One solution is to move these support functions to cpu-riscv.c, which runs into "error: implicit declaration of function ‘xmalloc’". Now, xmalloc is not supposed to be used in libbfd or libopcodes - it's rude to crash out of an application that calls libbfd or libopcodes functions without giving it a chance to deal with out-of-memory itself. So I removed the xmalloc and instead used a fixed size buffer. If you are worried about adding 36 bytes for the buffer to the riscv_get_priv_spec_class_from_numbers stack frame size, then you have no idea of the likely xmalloc + malloc stack frame size! Trying to reduce memory usage is commendable, but in this instance riscv_estimate_digit and malloc for a temp buffer uses a lot more memory than a fixed max-size buffer. * elfxx-riscv.c (struct priv_spec_t, priv_specs), (riscv_get_priv_spec_class, riscv_get_priv_spec_class_from_numbers), (riscv_get_priv_spec_name): Move to.. * cpu-riscv.c: ..here. (riscv_get_priv_spec_class_from_numbers): Don't xmalloc temp buffer. Use %u to print unsigned numbers.
2020-06-26Automatic date update in version.inGDB Administrator1-1/+1
2020-06-25gdb: use make_unique_xstrdup in set_inferior_io_terminalSimon Marchi2-1/+5
gdb/ChangeLog: * infcmd.c (set_inferior_io_terminal): Use make_unique_xstrdup. Change-Id: I38b6e753f58947531fe4a293d574bc27ec128f47
2020-06-25gdb: make inferior::terminal a unique ptrSimon Marchi4-6/+13
This changes the inferior::terminal field to be a unique pointer, so its deallocation is automatically managed. gdb/ChangeLog: * inferior.h (struct inferior) <terminal>: Change type to gdb::unique_xmalloc_ptr<char>. * inferior.c (inferior::~inferior): Don't free inf->terminal. * infcmd.c (set_inferior_io_terminal): Don't free terminal field, adjust to unique pointer. (get_inferior_io_terminal): Adjust to unique pointer. Change-Id: Iedb6459b4f9eeae812b0cb9d514b5707d5107cdb
2020-06-25cpu: fix offset16 type, update c-calls in bpf.cpuDavid Faust2-14/+15
Correct the type of the offset16 field to HI, and simplify memory accesses which use it. Also update c-calls in semantics for a few instructions. cpu/ChangeLog: 2020-06-25 David Faust <david.faust@oracle.com> * bpf.cpu (f-offset16): Change type from INT to HI. (dxli): Simplify memory access. (dxsi): Likewise. (define-endian-insn): Update c-call in semantics. (dlabs) Likewise. (dlind) Likewise.
2020-06-25gdb/riscv: Loop over all registers for 'info all-registers'Andrew Burgess4-4/+17
Currently the 'info all-registers' command only loops over those registers that are known to GDB. Any registers that are unknown, that is, are mentioned in the target description, but are not something GDB otherwise knows, will not be displayed. This feels wrong, so this commit fixes this mistake. The output of 'info all-registers' now matches 'info registers all'. gdb/ChangeLog: * riscv-tdep.c (riscv_print_registers_info): Loop over all registers, not just the known core set of registers. gdb/testsuite/ChangeLog: * gdb.arch/riscv-tdesc-regs.exp: New test cases.
2020-06-25gdb/riscv: Record information about unknown tdesc registersAndrew Burgess5-3/+145
Making use of the previous commit, record information about unknown registers in the target description, and use this to resolve two issues. 1. Some targets (QEMU) are reporting three register fflags, frm, and fcsr, twice, once in the FPU feature, and once in the CSR feature. GDB does create two registers with identical names, but this is (sort of) fine, we only ever use the first one, and as both registers access the same target state things basically work OK. The only real problem is that the register names show up twice in 'info registers all' output. In this commit we spot the duplicates of these registers and then return NULL when asked for the name of these registers. This causes GDB to hide these registers from the user, fixing this problem. 2. Some targets (QEMU) advertise CSRs that GDB then can't read. The problem is these targets also say these CSRs are part of the save/restore register groups. This means that before an inferior call GDB tries to save all of these CSRs, and a failure to read one causes the inferior call to be abandoned. We already work around this issue to some degree, known CSRs are removed from the save/restore groups, despite what the target might say. However, any unknown CSRs are (currently) not removed in this way. After this commit we keep a log of the register numbers for all unknown CSRs, then when asked about the register groups, we override the group information for unknown CSRs, removing them from the save and restore groups. gdb/ChangeLog: * riscv-tdep.c (riscv_register_name): Return NULL for duplicate fflags, frm, and fcsr registers. (riscv_register_reggroup_p): Remove unknown CSRs from save and restore groups. (riscv_tdesc_unknown_reg): New function. (riscv_gdbarch_init): Pass riscv_tdesc_unknown_reg to tdesc_use_registers. * riscv-tdep.h (struct gdbarch_tdep): Add unknown_csrs_first_regnum, unknown_csrs_count, duplicate_fflags_regnum, duplicate_frm_regnum, and duplicate_fcsr_regnum fields. gdb/testsuite/ChangeLog: * gdb.arch/riscv-tdesc-regs.exp: Extend test case.
2020-06-25gdb: Extend target description processing of unknown registersAndrew Burgess3-2/+64
This commit adds a new step to the processing of a target description done in tdesc_use_registers, this new step is about how unknown registers are processed. Currently an architecture looks through the target description and calls tdesc_numbered_register for each register is was expecting (or hoping) to find. This builds up a map from GDB's register numbers to the tdesc_reg object. Later the architecture calls tdesc_use_registers. In tdesc_use_registers we build a hash with keys being all the tdesc_reg object pointers, from this hash we remove all of the tdesc_reg objects that were assigned register numbers using tdesc_numbered_register. Finally we walk through all of the tdesc_reg objects, and if it was not already assigned a number we assign that register the next available number. The problem with this is that the architecture has no visibility of which unknown registers exist, and which tdesc_feature the register came from, in some cases this might be important. For example, on RISC-V GDB overrides the use of tdesc_register_reggroup_p, with riscv_register_reggroup_p to modify some of the register group choices. In this function GDB wants to treat all registers from a particular feature in a certain way. This is fine for registers that GDB knows might be in that feature, but for unknown registers the RISC-V parts of GDB have no easy way to figure out which unknown registers exist, and what numbers they were assigned. We could figure this information out by probing the register structures after calling tdesc_use_registers, but this would be horrible, much better to have tdesc_use_registers tell the architecture about unknown registers. This is what this commit does. A new phase of tdesc_use_registers, just before the unknown registers are assigned a number, we loop over each tdesc_reg object, if it has not been assigned a number then we figure out what number would be assigned and then call back into the architecture passing the tdesc_feature, register name, and the proposed register number. The architecture is free to return the proposed register number, or it can return a different number (which has a result identical to having called tdesc_numbered_register). Alternatively the architecture can return -1 to indicate the register should be numbered later. After calling the callback for every tdesc_reg object any registers still don't have a number assigned (because the architecture returned -1), then a new register number is assigned, which might be different from the proposed number that was suggested earlier. This commit adds the general target-description parts of this mechanism. No targets are currently using this code. The RISC-V target will make use of this in the next commit. There should be no user visible changes after this commit. gdb/ChangeLog: * target-descriptions.c (tdesc_use_registers): Add new parameter a callback, use the callback (when not null) to help number unknown registers. * target-descriptions.h (tdesc_unknown_register_ftype): New typedef. (tdesc_use_registers): Add extra parameter to declaration.
2020-06-25gdb/riscv: Improve support for matching against target descriptionsAndrew Burgess8-142/+578
For the RISC-V target it is desirable if the three floating pointer status CSRs fflags, frm, and fcsr can be placed into either the FPU feature or the CSR feature. This allows different targets to build the features in a way that better reflects their target. The change to support this within GDB is fairly simple, so this is done in this commit, and some tests added to check this new functionality. gdb/ChangeLog: * riscv-tdep.c (value_of_riscv_user_reg): Moved to here from later in the file. (class riscv_pending_register_alias): Likewise. (riscv_register_feature::register_info): Change 'required_p' field to 'required', and change its type. Add 'check' member function. (riscv_register_feature::register_info::check): Define new member function. (riscv_xreg_feature): Change initialisation of 'required' field. (riscv_freg_feature): Likewise. (riscv_virtual_feature): Likewise. (riscv_csr_feature): Likewise. (riscv_check_tdesc_feature): Take extra parameter, the csr tdesc_feature, rewrite the function to use the new riscv_register_feature::register_info::check function. (riscv_gdbarch_init): Pass the csr tdesc_feature where needed. gdb/testsuite/ChangeLog: * gdb.arch/riscv-tdesc-loading-01.xml: New file. * gdb.arch/riscv-tdesc-loading-02.xml: New file. * gdb.arch/riscv-tdesc-loading-03.xml: New file. * gdb.arch/riscv-tdesc-loading-04.xml: New file. * gdb.arch/riscv-tdesc-loading.exp: New file.
2020-06-25gdb/riscv: Remove CSR feature fileAndrew Burgess7-986/+10
There is currently a bug in the RISC-V CSR/FPU feature files. The CSRs containing the FPU status registers are mentioned in both the FPU feature file and the CSR feature file. My original thinking when adding the FPU feature file was that it made more sense to group the FPU status registers with the other FPU state. This opened up the possibility of debugging very simple (possibly simulator only) targets that had little more than CPU and FPU available for GDB to access. When I then added code to automatically generate the CSR XML file I forgot to filter out the FPU status CSRs, so these registers were mentioned twice. Now for GDB's default RISC-V target descriptions this doesn't actually matter. I did consider adding the CSRs to the default target description, but in the end I didn't bother. The reasoning again was simplicity; the default target description is only to be used when the target doesn't supply its own description, and NOT supplying the CSRs actually serves to encourage targets to supply an accurate description. Combine this with the fact that the CSRs change from revision to revision, sometimes in non-backward compatible ways, then having a "default" set of CSRs just feels like a path to confusion and complaints. However, having a broken CSR XML file in the GDB source tree has had one negative effect, QEMU has copied this file into its source tree, and is using this as its description that it passes to GDB. That is QEMU announces the FPU status registers twice, once in the FPU feature, and once in the CSR feature. This commit starts along the path back to sanity by deleting the default CSR XML files from within GDB. These files were not used in any way by current GDB, so there is absolutely no loss of functionality with this change. gdb/ChangeLog: * features/Makefile: Remove all references to the deleted files below. * features/riscv/32bit-csr.c: Deleted. * features/riscv/32bit-csr.xml: Deleted. * features/riscv/64bit-csr.c: Deleted. * features/riscv/64bit-csr.xml: Deleted. * features/riscv/rebuild-csr-xml.sh: Deleted.
2020-06-25gdb/riscv: Take CSR names from target descriptionAndrew Burgess4-30/+101
First, consider the RISC-V register $x1. This register has an alias $ra. When GDB processes an incoming target description we allow the target to use either register name to describe the target. However, within GDB's UI we want to use the $ra alias in preference to the $x1 architecture name. To achieve this GDB overrides the tdesc_register_name callback with riscv_register_name. In riscv_register_name we ensure that we always return the preferred name, so in this case "ra". To ensure the user can still access the register as $x1 if they want to, when in riscv_check_tdesc_feature we spot that the target has supplied the register, we add aliases for every name except the preferred one, so in this case we add the alias "x1". This scheme seems to work quite well, the targets have the flexibility to be architecture focused if they wish (using x0 - x31) while GDB is still using the ABI names ra, sp, gp, etc. When this code was originally added there was an attempt made to include the CSRs in the same scheme. At the time the CSRs only had two names, one pulled from riscv-opc.h, and one generated in GDB that had the pattern csr%d. The idea was that if the remote targets description described the CSRs as csr%d then GDB would rename these back to the real CSR name. This code was only included because if followed the same pattern as the x-regs and f-regs, not because I was actually aware of any target that did this. However, recent changes to add additional CSR aliases has made me rethink the position here. Lets consider the CSR $dscratch0. This register has an alias 'csr1970' (1970 is 0x7b2, which is the offset of the CSR register into the CSR address space). However, this register was originally called just 'dscratch', and so, after recent commits, this register also has the alias 'dscratch'. As the riscv-opc.h file calls this register 'dscratch0' GDB's preferred name for this register is 'dscratch0'. So, if the remote target description includes the register 'dscratch0', then GDB will add the aliases 'dscratch', and 'csr1970'. In the UI GDB will describe the register as 'dscratch0', and all it good. The problem I see in this case is where the target describes the register as 'dscratch'. In this case GDB will still spot the register and add the aliases 'dscratch', and 'csr1970', GDB will then give the register the preferred name 'dscratch0'. I don't like this. For the CSRs I think that we should stick with the naming scheme offered by the remote target description. As the RISC-V specification evolves and CSR register names evolve, insisting on referring to registers by the most up to date name makes it harder for a target to provide a consistent target description for an older version of the RISC-V architecture spec. In this precise case the target offers 'dscratch', which is from an older version of the RISC-V specification, the newer version of the spec has two registers 'dscratch0' and 'dscratch1'. If we insist on using 'dscratch0' it is then a little "weird" (or seems so to me) when 'dscratch1' is missing. This patch makes a distinction between the x and f registers and the other register sets. For x and f we still make use of the renaming scheme, forcing GDB to prefer the ABI name. But after this patch the CSR register group, and also the virtual register group, will always prefer to use the name given in the target description, adding other names as aliases, but not making any other name the preferred name. gdb/ChangeLog: * riscv-tdep.c (struct riscv_register_feature::register_info): Fix whitespace error for declaration of names member variable. (struct riscv_register_feature): Add new prefer_first_name member variable, and fix whitespace error in declaration of registers. (riscv_xreg_feature): Initialize prefer_first_name field. (riscv_freg_feature): Likewise. (riscv_virtual_feature): Likewise. (riscv_csr_feature): Likewise. (riscv_register_name): Expand on comments. Remove register name modifications for CSR and virtual registers. gdb/testsuite/ChangeLog: * gdb.arch/riscv-tdesc-regs.exp: Extend test case.
2020-06-25gdb/riscv: Fix whitespace errorAndrew Burgess2-2/+7
Should be 'std::vector<type>' not 'std::vector <type>'. gdb/ChangeLog: * riscv-tdep.c (struct riscv_register_feature): Fix whitespace errors.
2020-06-25gdb/riscv: Improved register alias name creationAndrew Burgess7-29/+370
This commit does two things: 1. Makes use of the DECLARE_CSR_ALIAS definitions in riscv-opc.h to add additional aliases for CSRs. 2. Only creates aliases for registers that are actually present on the target (as announced in the target XML description). This means that the 'csr%d' aliases that exist will only be created for those CSRs the target actually has, which is a nice improvement, as accessing one of the CSRs that didn't exist would cause GDB to crash with this error: valprint.c:1560: internal-error: bool maybe_negate_by_bytes(const gdb_byte*, unsigned int, bfd_endian, gdb::byte_vector*): Assertion `len > 0' failed. When we look at the DECLARE_CSR_ALIAS lines in riscv-opc.h, these can be split into three groups: DECLARE_CSR_ALIAS(misa, 0xf10, CSR_CLASS_I, PRIV_SPEC_CLASS_1P9, PRIV_SPEC_CLASS_1P9P1) The 'misa' register used to exist of offset 0xf10, but was moved to its current offset (0x301) in with privilege spec 1.9.1. We don't want GDB to create an alias called 'misa' as we will already have a 'misa' register created by the DECLARE_CSR(misa ....) call earlier in riscv-opc.h DECLARE_CSR_ALIAS(ubadaddr, CSR_UTVAL, CSR_CLASS_I, PRIV_SPEC_CLASS_1P9, PRIV_SPEC_CLASS_1P10) DECLARE_CSR_ALIAS(sbadaddr, CSR_STVAL, CSR_CLASS_I, PRIV_SPEC_CLASS_1P9, PRIV_SPEC_CLASS_1P10) DECLARE_CSR_ALIAS(sptbr, CSR_SATP, CSR_CLASS_I, PRIV_SPEC_CLASS_1P9, PRIV_SPEC_CLASS_1P10) DECLARE_CSR_ALIAS(mbadaddr, CSR_MTVAL, CSR_CLASS_I, PRIV_SPEC_CLASS_1P9, PRIV_SPEC_CLASS_1P10) DECLARE_CSR_ALIAS(mucounteren, CSR_MCOUNTINHIBIT, CSR_CLASS_I, PRIV_SPEC_CLASS_1P9, PRIV_SPEC_CLASS_1P10) These aliases are all CSRs that were removed in privilege spec 1.10, and whose addresses were reused by new CSRs. The names meaning of the old names is totally different to the new CSRs that have taken their place. I don't believe we should add these as aliases into GDB. If the new CSR exists in the target then that should be enough. DECLARE_CSR_ALIAS(dscratch, CSR_DSCRATCH0, CSR_CLASS_I, PRIV_SPEC_CLASS_1P9, PRIV_SPEC_CLASS_1P11) In privilege spec 1.11 the 'dscratch' register was renamed to 'dscratch0', however the meaning of the register didn't change. Adding the 'dscratch' alias makes sense I think. Looking then at the final PRIV_SPEC_CLASS_* field for each alias then we can see that currently we only want to take the alias from PRIV_SPEC_CLASS_1P11. For now then this is what I'm using to filter the aliases within GDB. In the future there's no telling how DECLARE_CSR_ALIAS will be used. I've heard it said that future RISC-V privilege specs will not reuse CSR offsets again. But it could happen. We just don't know. If / when it does we may need to revisit how aliases are created for GDB, but for now this seems to be OK. gdb/ChangeLog: * riscv-tdep.c (riscv_create_csr_aliases): Handle csr aliases from riscv-opc.h. (class riscv_pending_register_alias): New class. (riscv_check_tdesc_feature): Take vector of pending aliases and populate it as appropriate. (riscv_setup_register_aliases): Delete. (riscv_gdbarch_init): Create vector of pending aliases and pass it to riscv_check_tdesc_feature in all cases. Use the vector to create the register aliases. gdb/testsuite/ChangeLog: * gdb.arch/riscv-tdesc-regs-32.xml: New file. * gdb.arch/riscv-tdesc-regs-64.xml: New file. * gdb.arch/riscv-tdesc-regs.c: New file. * gdb.arch/riscv-tdesc-regs.exp: New file.
2020-06-25Remove obsolete gdbarch_static_transform_nameRainer Orth9-144/+18
gdbarch_static_transform_name is completely Solaris-specific or rather specific to the Studio compilers. Studio cc has deprecated Stabs support in the 12.4 release back in 2015, GCC has defaulted to DWARF-2 on Solaris 7+ since 2004 and Stabs themselves are pretty much obsolete, so the whole code can go. Tested on sparcv9-sun-solaris2.11 and x86_64-pc-linux-gnu with --enable-targets=all. * sol2-tdep.c (sol2_static_transform_name): Remove. (sol2_init_abi): Don't register it. * gdbarch.sh (static_transform_name): Remove. * gdbarch.c, gdbarch.h: Regenerate. * dbxread.c (read_dbx_symtab) <'S'>: Remove call to gdbarch_static_transform_name. * mdebugread.c (parse_partial_symbols) <'S'>: Likewise. * stabsread.c (define_symbol) <'X'>: Remove. (define_symbol) <'S'>: Remove gdbarch_static_transform_name handling. <'V'>: Likewise. * xcoffread.c (scan_xcoff_symtab): Remove gdbarch. <'S'>: Remove call to gdbarch_static_transform_name.
2020-06-25Use fork instead of vfork on SolarisRainer Orth2-1/+13
The gdb.mi/mi-exec-run.exp test never completed/timed out on Solaris for quite some time: FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=main: mi=main: force-fail=1: run failure detected (timeout) This is for gdb trying to exec mi-exec-run.nox, a copy of mi-exec-run with execute permissions removed. The process tree at this point looks like this: 21254 /vol/gcc/bin/expect -- /vol/gcc/share/dejagnu/runtest.exp GDB_PARALLEL=yes --outdir=outputs/gdb.mi/mi-exec-run-vfork gdb.mi/mi-exec-run.exp 21300 <defunct> 21281 <defunct> 21294 $obj/gdb/testsuite/../../gdb/gdb -nw -nx -data-directory $obj/gdb/testsuite/../data-directory -i=mi 21297 $obj/gdb/testsuite/../../gdb/gdb -nw -nx -data-directory $obj/gdb/testsuite/../data-directory -i=mi The parent gdb hangs here: 21294: $obj/gdb/testsuite/../../gdb/gdb -nw ------------ lwp# 1 / thread# 1 --------------- 0000000000000000 SYS#0 () 0000000000daeccd procfs_target::create_inferior(char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char**, int) () + 97 (procfs.c:2853) 0000000000ca63a7 run_command_1(char const*, int, run_how) () + 349 (basic_string.h:187) 0000000000ca6516 start_command(char const*, int) () + 26 (infcmd.c:584) 0000000000b3ca8e do_const_cfunc(cmd_list_element*, char const*, int) () + f (cli-decode.c:96) 0000000000b3ed77 cmd_func(cmd_list_element*, char const*, int) () + 32 (cli-decode.c:2113) 0000000000f2d219 execute_command(char const*, int) () + 455 (top.c:657) 0000000000d4ad77 mi_execute_cli_command(char const*, int, char const*) () + 242 (basic_string.h:187) 0000000000d4ae80 mi_cmd_exec_run(char const*, char**, int) () + ba (mi-main.c:473) with these process flags 21294: $obj/gdb/testsuite/../../gdb/gdb -nw data model = _LP64 flags = VFORKP|ORPHAN|MSACCT|MSFORK sigpend = 0x00004103,0x00000000,0x00000000 /1: flags = 0 sigmask = 0xffbffeff,0xffffffff,0x000000ff cursig = SIGKILL /2: flags = DETACH|STOPPED|ASLEEP lwp_park(0x0,0x0,0x0) why = PR_SUSPENDED sigmask = 0x000a2002,0x00000000,0x00000000 [...] while the child sits at 21297: $obj/gdb/testsuite/../../gdb/gdb -nw 00007fffbf078a0b execve (7fffbffff756, 7fffbfffec58, 7fffbfffec90, 0) 00007fffbef84cf6 execvpex () + f6 00007fffbef84f45 execvp () + 15 0000000000d60a44 fork_inferior(char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char**, void (*)(), gdb::function_view<void (int)>, void (*)(), char const*, void (*)(char const*, char* const*, char* const*)) () + 47f (fork-inferior.c:423) 0000000000daeccd procfs_target::create_inferior(char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char**, int) () + 97 (procfs.c:2853) 0000000000ca63a7 run_command_1(char const*, int, run_how) () + 349 (basic_string.h:187) 0000000000ca6516 start_command(char const*, int) () + 26 (infcmd.c:584) 0000000000b3ca8e do_const_cfunc(cmd_list_element*, char const*, int) () + f (cli-decode.c:96) 0000000000b3ed77 cmd_func(cmd_list_element*, char const*, int) () + 32 (cli-decode.c:2113) 0000000000f2d219 execute_command(char const*, int) () + 455 (top.c:657) 0000000000d4ad77 mi_execute_cli_command(char const*, int, char const*) () + 242 (basic_string.h:187) 0000000000d4ae80 mi_cmd_exec_run(char const*, char**, int) () + ba (mi-main.c:473) with 21297: $obj/gdb/testsuite/../../gdb/gdb -nw data model = _LP64 flags = MSACCT|MSFORK exitset = 0x00000000 0x04000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 /1: flags = STOPPED|ISTOP execve(0x7fffbffff756,0x7fffbfffec58,0x7fffbfffec90,0x0) why = PR_SYSEXIT what = execve We have a deadlock here: the execve in the child cannot return until the parent has handled the PR_SYSEXIT while the parent cannot run with a vfork'ed child as documented in proc(4): The child of a vfork(2) borrows the parent's address space. When a vfork(2) is executed by a traced process, all watched areas established for the parent are suspended until the child terminates or performs an exec(2). Any watched areas established independently in the child are cancelled when the parent resumes after the child's termination or exec(2). PCWATCH fails with EBUSY if applied to the parent of a vfork(2) before the child has terminated or performed an exec(2). The PR_VFORKP flag is set in the pstatus structure for such a parent process. In that situation, the parent cannot be killed even with SIGKILL (as runtest will attempt once the timeout occurs; the pending signal can be seen in the pflags output above), so the whole test hangs until one manually kills the child process. Fortunately, there's an easy way out: when using fork instead of vfork, the problem doesn't occur, and this is what the current patch does: it calls fork_inferior with a dummy pre_trace_fun arg. Tested on amd64-pc-solaris2.11 and sparcv9-sun-solaris2.11. * procfs.c (procfs_pre_trace): New function. (procfs_target::create_inferior): Pass it to fork_inferior.
2020-06-25Don't include *sol2-tdep.o on Linux/sparc*Rainer Orth6-12/+17
Linux/sparc* currently links Solaris-specific files (sparc-sol2-tdep.o, sparc64-sol2-tdep.o, sol2-tdep.o) for no apparent reason. It has no business doing so, and none of the functions/variables defined there are used explicitly. If support for the Solaris OSABI were desired, this should be done using --enable-targets instead. Since neither sparc{32,64}_sol2_init_abi currently declared in common headers (sparc*-tdep.h) are used outside their source files, they are made static and the declarations removed. Tested on sparcv9-sun-solaris2.11 and sparc64-unknown-linux-gnu. * configure.tgt <sparc-*-linux*> (gdb_target_obs): Remove sparc-sol2-tdep.o, sol2-tdep.o, sparc64-sol2-tdep.o. <sparc64-*-linux*> (gdb_target_obs): Remove sparc64-sol2-tdep.o, sol2-tdep.o, sparc-sol2-tdep.o. * sparc-sol2-tdep.c (sparc32_sol2_init_abi): Make static. * sparc-tdep.h (sparc32_sol2_init_abi): Remove. * sparc64-sol2-tdep.c (sparc64_sol2_init_abi): Make static. * sparc64-tdep.h (sparc64_sol2_init_abi): Remove.
2020-06-25Move common handlers to sol2_init_abiRainer Orth8-180/+158
There's some overlap and duplication between 32 and 64-bit Solaris/SPARC and x86 tdep files, in particular sol2_core_pid_to_str *_sol2_sigtramp_p sol2_skip_solib_resolver *_sol2_static_transform_name (forgotten on amd64) set_gdbarch_sofun_address_maybe_missing (likewise) This patch avoids this by centralizing common code in sol2-tdep.c. While sparc_sol2_pc_in_sigtramp and sparc_sol2_static_transform_name were declared in the shared sparc-tdep.h, they were only used in Solaris files. Tested on amd64-pc-solaris2.11, i386-pc-solaris2.11, sparcv9-sun-solaris2.11, and sparc-sun-solaris2.11, and sparc64-unknown-linux-gnu. * amd64-sol2-tdep.c (amd64_sol2_sigtramp_p): Remove. (amd64_sol2_init_abi): Use sol2_sigtramp_p. Call sol2_init_abi. Remove calls to set_gdbarch_skip_solib_resolver, set_gdbarch_core_pid_to_str. * i386-sol2-tdep.c (i386_sol2_sigtramp_p): Remove. (i386_sol2_static_transform_name): Remove. (i386_sol2_init_abi): Call sol2_init_abi. Remove calls to set_gdbarch_sofun_address_maybe_missing, set_gdbarch_static_transform_name, set_gdbarch_skip_solib_resolver, set_gdbarch_core_pid_to_str. Use sol2_sigtramp_p. * sol2-tdep.c (sol2_pc_in_sigtramp): New function. (sol2_sigtramp_p): New function. (sol2_static_transform_name): New function. (sol2_skip_solib_resolver, sol2_core_pid_to_str): Make static. (sol2_init_abi): New function. * sol2-tdep.h (sol2_sigtramp_p, sol2_init_abi): Declare. (sol2_skip_solib_resolver, sol2_core_pid_to_str): Remove. * sparc-sol2-tdep.c (sparc_sol2_pc_in_sigtramp): Remove. (sparc32_sol2_sigtramp_frame_sniffer): Just call sol2_sigtramp_p. (sparc_sol2_static_transform_name): Remove. (sparc32_sol2_init_abi): Call sol2_init_abi. Remove calls to set_gdbarch_sofun_address_maybe_missing, set_gdbarch_static_transform_name, set_gdbarch_skip_solib_resolver, set_gdbarch_core_pid_to_str. * sparc-tdep.h (sparc_sol2_pc_in_sigtramp) (sparc_sol2_static_transform_name): Remove * sparc64-sol2-tdep.c (sparc64_sol2_sigtramp_frame_sniffer): Just call sol2_sigtramp_p. (sparc64_sol2_init_abi): Call sol2_init_abi. Remove calls to set_gdbarch_sofun_address_maybe_missing, set_gdbarch_static_transform_name, set_gdbarch_skip_solib_resolver, set_gdbarch_core_pid_to_str.
2020-06-25Update the Swedish translation in the gprof/ subdirectory.Nick Clifton2-27/+31
* po/sv.po: Updated Swedish translation.
2020-06-25Remove the use of the register keyword in the libiberty.h header file - it ↵Nick Clifton2-3/+8
is deprecated and incompatible with C++17. * libiberty.h (bsearch_r): Remove use of the register keyword from the prototype.
2020-06-25Stop the assembler from generating R_ARM_THM_JMP11 relocations as these are ↵Nick Clifton3-8/+12
not supported by the kernel. PR 26141 * config/tc-arm.c (arm_force_relocation): Force resolution of BFD_RELOC_THUMB_PCREL_BRANCH12 relocations. * testsuite/gas/arm/plt-1.d: Adjust expected disassembly.