aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-02-19_bfd_mul_overflowAlan Modra21-353/+541
This patch removes the bfd_alloc2 series of memory allocation functions, replacing them with __builtin_mul_overflow followed by bfd_alloc. Why do that? Well, a followup patch will implement _bfd_alloc_and_read and I don't want to implement alloc2 variants as well. * coffcode.h (buy_and_read, coff_slurp_line_table), (coff_slurp_symbol_table, coff_slurp_reloc_table): Replace bfd_[z][m]alloc2 calls with _bfd_mul_overflow followed by the corresponding bfd_alloc call. Adjust variables to suit. * coffgen.c (_bfd_coff_get_external_symbols): Likewise. * ecoff.c (_bfd_ecoff_slurp_symbolic_info), (_bfd_ecoff_slurp_symbol_table, READ): Likewise. * elf.c (bfd_elf_get_elf_syms, setup_group, bfd_section_from_shdr), (swap_out_syms, _bfd_elf_slurp_version_tables): Likewise. * elf32-m32c.c (m32c_elf_relax_section): Likewise. * elf32-rl78.c (rl78_elf_relax_section): Likewise. * elf32-rx.c (elf32_rx_relax_section): Likewise. * elf64-alpha.c (READ): Likewise. * elfcode.h (elf_object_p, elf_write_relocs, elf_write_shdrs_and_ehdr), (elf_slurp_symbol_table, elf_slurp_reloc_table), (bfd_from_remote_memory): Likewise. * elfcore.h (core_find_build_id): Likewise. * elfxx-mips.c (READ): Likewise. * mach-o.c (bfd_mach_o_mangle_sections), (bfd_mach_o_read_symtab_symbols, bfd_mach_o_read_thread), (bfd_mach_o_read_dysymtab, bfd_mach_o_flatten_sections), (bfd_mach_o_scan, bfd_mach_o_fat_archive_p): Likewise. * som.c (setup_sections, som_prep_for_fixups) (som_build_and_write_symbol_table, som_slurp_symbol_table), (som_slurp_reloc_table, som_bfd_count_ar_symbols), (som_bfd_fill_in_ar_symbols, som_slurp_armap), (som_bfd_ar_write_symbol_stuff): Likewise. * vms-alpha.c (vector_grow1): Likewise. * vms-lib.c (vms_add_index): Likewise. * wasm-module.c (wasm_scan_name_function_section): Likewise. * libbfd.c (bfd_malloc2, bfd_realloc2, bfd_zmalloc2): Delete. * opncls.c (bfd_alloc2, bfd_zalloc2): Delete. * libbfd-in.h (bfd_malloc2, bfd_realloc2, bfd_zmalloc2), (bfd_alloc2, bfd_zalloc2): Delete. (_bfd_mul_overflow): Define. * libbfd.h: Regenerate.
2020-02-19alloc2 used unnecessarilyAlan Modra3-22/+39
The bfd_alloc2 series of functions were invented to handle cases where nmemb * size can overflow. This patch changes some places where the calculation can't overflow. * elf.c (bfd_section_from_shdr): Use bfd_zalloc rather than bfd_zalloc2. (assign_section_numbers): Likewise. (elf_map_symbols): Likewise, and bfd_alloc rather than bfd_alloc2. (_bfd_elf_map_sections_to_segments): Use bfd_malloc rather than bfd_malloc2, size_t amt, and unsigned tls_count. (rewrite_elf_program_header): Use bfd_malloc and size_t amt. * elflink.c (elf_create_symbuf): Use bfd_malloc. (elf_output_implib): Use bfd_alloc.
2020-02-19bfd_get_size cacheAlan Modra5-20/+59
We have calls to bfd_get_size when swapping in ELF section headers. Since object files can have a large number of sections, it's worth caching the file size rather than making lots of stat system calls. * bfd.c (struct bfd): Move format and direction to other bitfields. Add "size". * bfdio.c (bfd_get_size): Cache size when not writing file. * opncls.c (bfd_get_debug_link_info_1): Allow for bfd_get_size returning zero, ie. unknown. (bfd_get_alt_debug_link_info): Likewise. * bfd-in2.h: Regenerate.
2020-02-19bfd_get_file_size callsAlan Modra4-13/+38
bfd_get_file_size can return 0, meaning the file size is unknown. * coffgen.c (_bfd_coff_get_external_symbols): Don't call bfd_get_file_size twice. (_bfd_coff_read_string_table): Allow for bfd_get_file_size zero, ie. unknown, return. * elf-attrs.c (_bfd_elf_parse_attributes): Likewise. * elfcode.h (elf_swap_shdr_in): Likewise. (elf_object_p): Don't call bfd_get_file_size twice and correct file size check.
2020-02-19Check return status of memory alloc functionsAlan Modra5-54/+112
This fixes a number of places that call a memory allocation function without checking for a NULL return before using. * mach-o.c (bfd_mach_o_flatten_sections): Return a bfd_boolean, FALSE if memory alloc fails. Adjust calls. * som.c (som_prep_for_fixups): Likewise. * vms-alpha.c (alpha_vms_add_fixup_lp, alpha_vms_add_fixup_ca), (alpha_vms_add_fixup_qr, alpha_vms_add_fixup_lr), (alpha_vms_add_lw_reloc, alpha_vms_add_qw_reloc): Likewise. * som.c (som_build_and_write_symbol_table): Return via error_return on seek failure. * vms-alpha.c (VEC_APPEND): Adjust for vector_grow1 changes. (VEC_APPEND_EL): Delete. (vector_grow1): Return pointer to element. Catch overflow. Return NULL on memory allocation failure. (alpha_vms_add_fixup_lp): Replace VEC_APPEND_EL with VEC_APPEND. (alpha_vms_add_fixup_ca): Likewise. (alpha_vms_link_add_object_symbols): Check VEC_APPEND result before using. * elf.c (bfd_section_from_shdr): Check bfd_zalloc2 result.
2020-02-19bfd_size_type to size_tAlan Modra93-260/+420
bfd_size_type was invented a long time ago in the K&R days. Many places in binutils ought to be using size_t instead (and there are lots of places that use long or unsigned long that really ought to use size_t too). Note that you can't change everything over to size_t: A 32-bit host needs a larger type than size_t to support reading and processing of 64-bit ELF object files. This patch just tidies some of the more obvious uses of bfd_size_type that could be size_t. There no doubt are more lurking in the source. Incidentally, practically all functions used for output of object files can use size_t and don't need to worry about overflow of size expressions. If you have something like symcount * sizeof (void *) when symcount is counting symbols already in memory then you know that this expression can't overflow since the size of a symbol in memory is larger by far than that of a pointer. * aix386-core.c (aix386_core_file_p): Use size_t for "amt". * aout-target.h (object_p): Likewise. * aout-tic30.c (tic30_aout_object_p): Likewise. * aoutx.h (some_aout_object_p, mkobject, make_empty_symbol), (emit_stringtab, write_syms, link_hash_table_create), (aout_link_write_other_symbol): Likewise. * archive.c (_bfd_generic_mkarchive, bfd_generic_archive_p), (bfd_ar_hdr_from_filesystem, _bfd_write_archive_contents), (_bfd_compute_and_write_armap): Likewise. * archures.c (bfd_arch_list): Likewise. * bfd.c (bfd_record_phdr): Likewise. * binary.c (binary_canonicalize_symtab): Likewise. * cisco-core.c (cisco_core_file_validate): Likewise. * coff-arm.c (coff_arm_link_hash_table_create, find_thumb_glue), (find_arm_glue, record_arm_to_thumb_glue), (record_thumb_to_arm_glue): Likewise. * coff-ppc.c (ppc_coff_link_hash_table_create, record_toc), (ppc_allocate_toc_section): Likewise. * coff-rs6000.c (_bfd_xcoff_mkobject, _bfd_xcoff_archive_p): Likewise. * coff-sh.c (sh_relax_section): Likewise. * coff64-rs6000.c (xcoff64_archive_p): Likewise. * coffcode.h (handle_COMDAT, coff_new_section_hook), (coff_set_alignment_hook, coff_mkobject), (coff_compute_section_file_positions): Likewise. * coffgen.c (coff_make_empty_symbol, coff_bfd_make_debug_symbol), (coff_find_nearest_line_with_names), ( bfd_coff_set_symbol_class): Likewise. * cofflink.c (_bfd_coff_link_hash_table_create), (_bfd_coff_link_input_bfd): Likewise. * dwarf1.c (alloc_dwarf1_unit, alloc_dwarf1_func): Likewise. * dwarf2.c (read_abbrevs, read_attribute_value, add_line_info), (build_line_info_table, sort_line_sequences), (line_info_add_include_dir, line_info_add_file_name), (decode_line_info, scan_unit_for_symbols, parse_comp_unit), (place_sections, _bfd_dwarf2_slurp_debug_info): Likewise. * ecoff.c (_bfd_ecoff_mkobject, _bfd_ecoff_make_empty_symbol), (_bfd_ecoff_find_nearest_line), (_bfd_ecoff_bfd_link_hash_table_create): Likewise. * ecofflink.c (bfd_ecoff_debug_init): Likewise. * elf-hppa.h (_bfd_elf_hppa_gen_reloc_type): Likewise. * elf-m10300.c (mn10300_elf_relax_section), (elf32_mn10300_link_hash_table_create): Likewise. * elf-strtab.c (_bfd_elf_strtab_init): Likewise. * elf.c (make_mapping, copy_elf_program_header): Likewise. * elf32-arm.c (elf32_arm_link_hash_table_create), (elf32_arm_setup_section_lists, elf32_arm_check_relocs), (elf32_arm_new_section_hook): Likewise. * elf32-avr.c (elf_avr_new_section_hook), (elf32_avr_link_hash_table_create, get_local_syms), (elf32_avr_setup_section_lists): Likewise. * elf32-bfin.c (bfinfdpic_elf_link_hash_table_create), (bfin_link_hash_table_create): Likewise. * elf32-cr16.c (elf32_cr16_link_hash_table_create): Likewise. * elf32-cris.c (elf_cris_link_hash_table_create): Likewise. * elf32-csky.c (csky_elf_link_hash_table_create), (csky_elf_check_relocs, elf32_csky_setup_section_lists): Likewise. * elf32-frv.c (frvfdpic_elf_link_hash_table_create): Likewise. * elf32-hppa.c (elf32_hppa_link_hash_table_create), (elf32_hppa_setup_section_lists, get_local_syms): Likewise. * elf32-i386.c (elf_i386_check_relocs): Likewise. * elf32-lm32.c (lm32_elf_link_hash_table_create): Likewise. * elf32-m32r.c (m32r_elf_link_hash_table_create), (m32r_elf_check_relocs): Likewise. * elf32-m68hc1x.c (m68hc11_elf_hash_table_create), (elf32_m68hc11_setup_section_lists), (elf32_m68hc11_size_stubs): Likewise. * elf32-m68k.c (elf_m68k_link_hash_table_create): Likewise. * elf32-metag.c (elf_metag_link_hash_table_create), (elf_metag_setup_section_lists): Likewise. * elf32-microblaze.c (microblaze_elf_link_hash_table_create), (microblaze_elf_check_relocs): Likewise. * elf32-nds32.c (nds32_elf_link_hash_table_create), (nds32_elf_check_relocs): Likewise. * elf32-nios2.c (nios2_elf32_setup_section_lists), (get_local_syms, nios2_elf32_check_relocs), (nios2_elf32_link_hash_table_create): Likewise. * elf32-or1k.c (or1k_elf_link_hash_table_create), (or1k_elf_check_relocs): Likewise. * elf32-ppc.c (ppc_elf_modify_segment_map, update_plt_info): Likewise. * elf32-pru.c (pru_elf32_link_hash_table_create): Likewise. * elf32-s390.c (elf_s390_link_hash_table_create), (elf_s390_check_relocs): Likewise. * elf32-score.c (score_elf_create_got_section), (s3_elf32_score_new_section_hook), (elf32_score_link_hash_table_create): Likewise. * elf32-score7.c (score_elf_create_got_section), (s7_elf32_score_new_section_hook): Likewise. * elf32-sh.c (sh_elf_link_hash_table_create), (sh_elf_check_relocs): Likewise. * elf32-tic6x.c (elf32_tic6x_link_hash_table_create), (elf32_tic6x_new_section_hook, elf32_tic6x_check_relocs): Likewise. * elf32-tilepro.c (tilepro_elf_link_hash_table_create), (tilepro_elf_check_relocs): Likewise. * elf32-v850.c (remember_hi16s_reloc): Likewise. * elf32-vax.c (elf_vax_link_hash_table_create): Likewise. * elf32-xtensa.c (elf_xtensa_link_hash_table_create), (elf_xtensa_new_section_hook): Likewise. * elf64-alpha.c (elf64_alpha_bfd_link_hash_table_create), (get_got_entry, elf64_alpha_check_relocs): Likewise. * elf64-hppa.c (elf64_hppa_hash_table_create): Likewise. * elf64-ia64-vms.c (elf64_ia64_object_p): Likewise. * elf64-mmix.c (mmix_elf_new_section_hook): Likewise. * elf64-ppc.c (ppc64_elf_new_section_hook), (ppc64_elf_link_hash_table_create, update_local_sym_info), (update_plt_info, ppc64_elf_check_relocs): Likewise. * elf64-s390.c (elf_s390_link_hash_table_create), (elf_s390_check_relocs): Likewise. * elf64-x86-64.c (elf_x86_64_check_relocs): Likewise. * elflink.c (bfd_elf_link_record_local_dynamic_symbol), (_bfd_elf_link_find_version_dependencies, elf_link_add_object_symbols), (elf_link_add_archive_symbols, compute_bucket_count), (bfd_elf_size_dynsym_hash_dynstr, _bfd_elf_link_hash_table_create), (bfd_elf_get_bfd_needed_list, elf_link_swap_symbols_out), (bfd_elf_final_link): Likewise. * elfnn-aarch64.c (elfNN_aarch64_link_hash_table_create), (elfNN_aarch64_setup_section_lists, elfNN_aarch64_check_relocs), (elfNN_aarch64_new_section_hook): Likewise. * elfnn-ia64.c (elfNN_ia64_object_p): Likewise. * elfnn-riscv.c (riscv_elf_link_hash_table_create), (riscv_elf_check_relocs): Likewise. * elfxx-mips.c (_bfd_mips_elf_new_section_hook), (_bfd_mips_elf_add_symbol_hook, _bfd_mips_elf_check_relocs), (_bfd_mips_elf_modify_segment_map, _bfd_mips_elf_set_section_contents), (_bfd_mips_elf_link_hash_table_create): Likewise. * elfxx-sparc.c (_bfd_sparc_elf_link_hash_table_create), (_bfd_sparc_elf_check_relocs), (_bfd_sparc_elf_new_section_hook): Likewise. * elfxx-tilegx.c (tilegx_elf_link_hash_table_create), (tilegx_elf_check_relocs): Likewise. * elfxx-x86.c (_bfd_x86_elf_link_hash_table_create): Likewise. * format.c (bfd_check_format_matches): Likewise. * hash.c (_bfd_stringtab_init): Likewise. * ihex.c (ihex_scan): Likewise. * irix-core.c (irix_core_core_file_p): Likewise. * linker.c (bfd_wrapped_link_hash_lookup), (_bfd_generic_link_hash_table_create), (_bfd_generic_reloc_link_order): Likewise. * lynx-core.c (lynx_core_file_p): Likewise. * netbsd-core.c (netbsd_core_file_p): Likewise. * osf-core.c (osf_core_core_file_p): Likewise. * pdp11.c (some_aout_object_p, mkobject, make_empty_symbol), (link_hash_table_create, aout_link_write_other_symbol): Likewise. * peXXigen.c (_bfd_XX_bfd_copy_private_section_data): Likewise. * peicode.h (pe_mkobject): Likewise. * ppcboot.c (ppcboot_mkobject, ppcboot_canonicalize_symtab): Likewise. * ptrace-core.c (ptrace_unix_core_file_p): Likewise. * sco5-core.c (read_uarea): Likewise. * som.c (hppa_som_gen_reloc_type, som_object_p, som_prep_headers), (som_write_fixups, som_write_space_strings, som_write_symbol_strings), (som_finish_writing, som_canonicalize_symtab, som_new_section_hook), (som_bfd_copy_private_section_data, bfd_som_set_section_attributes), (bfd_som_attach_aux_hdr, som_write_armap): Likewise. * srec.c (srec_scan): Likewise. * syms.c (_bfd_generic_make_empty_symbol): Likewise. * targets.c (bfd_target_list): Likewise. * tekhex.c (first_phase, tekhex_sizeof_headers): Likewise. * trad-core.c (trad_unix_core_file_p): Likewise. * vms-alpha.c (vms_initialize, alpha_vms_bfd_link_hash_table_create), (vms_new_section_hook): Likewise. * wasm-module.c (wasm_make_empty_symbol): Likewise. * xcofflink.c (xcoff_get_section_contents), (_bfd_xcoff_bfd_link_hash_table_create, xcoff_set_import_path), (xcoff_find_function, bfd_xcoff_link_record_set, xcoff_build_ldsym), (bfd_xcoff_size_dynamic_sections, xcoff_link_input_bfd): Likewise.
2020-02-19c99 elfxx-riscv.c fixAlan Modra2-5/+9
We can't use c99 without enabling c99 support for older compilers that don't enable c99 by default. So if you want to use c99 contructs in binutils you'll need to first arrange for -std=c99 to be passed to older compilers. * elfxx-riscv.c (riscv_multi_letter_ext_valid_p): Don't use C99.
2020-02-19Adjust PR25355 testcaseAlan Modra2-2/+6
* testsuite/ld-plugin/pr25355.d: Allow alpha-linux nm result.
2020-02-19gdbserver: Add RISC-V/Linux supportMaciej W. Rozycki6-0/+311
Implement RISC-V/Linux support for both RV64 and RV32 systems, including XML target description handling based on features determined, GPR and FPR regset support including dynamic sizing of the latter, and software breakpoint handling. Define two NT_FPREGSET regsets of a different size matching the FPR sizes supported for generic `gdbserver' code to pick from according to what the OS supplies. Also handle a glibc bug where ELF_NFPREG is defined in terms of NFPREG, however NFPREG is nowhere defined. 2020-02-19 Maciej W. Rozycki <macro@wdc.com> Andrew Burgess <andrew.burgess@embecosm.com> gdb/ * NEWS: Mention RISC-V GNU/Linux GDBserver support. gdbserver/ * linux-riscv-low.cc: New file. * Makefile.in (SFILES): Add linux-riscv-low.cc, arch/riscv.c, and nat/riscv-linux-tdesc.c. * configure.srv <riscv*-*-linux*> (srv_tgtobj) (srv_linux_regsets, srv_linux_usrregs, srv_linux_thread_db): Define.
2020-02-19gdb/riscv: Update API for looking up target descriptionsAndrew Burgess7-40/+103
In preparation for adding the RISC-V gdbserver, this commit restructures the API for looking up target descriptions. The current API is riscv_create_target_description, which creates a target description from a riscv_gdbarch_features, but also caches the created target descriptions so that for a given features object we always get back the same target description object. This is important for GDB due to the way gdbarch objects are reused. As the same target description is always returned to GDB, and can be returned multiple times, it is returned as a const, however, the current cache actually stores a non-const target description. This is improved in this patch so that the cache holds a const target description. For gdbsever, this caching of the target descriptions is not needed, the gdbserver looks up one target description to describe the target it is actually running on and that is it. Further the gdbserver actually needs to modify the target description that is looked up, so for the gdbsever, returning a const target description is not acceptable. This commit aims to address this by creating two parallel target description APIs, on is the old riscv_create_target_description, however, this no longer performs any caching, and just creates a new target description, and returns it as non-const. The second API is riscv_lookup_target_description, this one performs the caching, and calls riscv_create_target_description to create a target description when needed. In order to make sure the correct API is used in the correct place I have guarded the code using the GDBSERVER define. For GDB the riscv_create_target_description is static, and not generally usable throughout GDB, only the lookup API is global. In gdbserver, the lookup functions, and the cache are not defined or created at all, only the riscv_create_target_description API is available. There should be no user visible changes after this commit. gdb/ChangeLog: * arch/riscv.c (struct riscv_gdbarch_features_hasher): Only define if GDBSERVER is not defined. (riscv_tdesc_cache): Likewise, also store const target_desc. (STATIC_IN_GDB): Define. (riscv_create_target_description): Update declaration with STATIC_IN_GDB. (riscv_lookup_target_description): New function, only define if GDBSERVER is not defined. * arch/riscv.h (riscv_create_target_description): Declare only when GDBSERVER is defined. (riscv_lookup_target_description): New declaration when GDBSERVER is not defined. * nat/riscv-linux-tdesc.c (riscv_linux_read_description): Rename to... (riscv_linux_read_features): ...this, and return riscv_gdbarch_features instead of target_desc. * nat/riscv-linux-tdesc.h: Include 'arch/riscv.h'. (riscv_linux_read_description): Rename to... (riscv_linux_read_features): ...this. * riscv-linux-nat.c (riscv_linux_nat_target::read_description): Update to use riscv_gdbarch_features and riscv_lookup_target_description. * riscv-tdep.c (riscv_find_default_target_description): Use riscv_lookup_target_description instead of riscv_create_target_description.
2020-02-19Automatic date update in version.inGDB Administrator1-1/+1
2020-02-19[gdb/testsuite] Be quiet about untested dtrace-prob.expTom de Vries2-2/+9
When running gdb.base/dtrace-probe.exp, I get this on stdout/stderr: ... Running src/gdb/testsuite/gdb.base/dtrace-probe.exp ... gdb compile failed, ld: error in \ build/gdb/testsuite/outputs/gdb.base/dtrace-probe/dtrace-probe.o\ (.eh_frame); no .eh_frame_hdr table will be created ld: crt1.o: in function `_start': start.S:110: undefined reference to `main' ld: build/gdb/testsuite/outputs/gdb.base/dtrace-probe/dtrace-probe-p.o:\ (.SUNW_dof+0x88): undefined reference to `main' ld: build/gdb/testsuite/outputs/gdb.base/dtrace-probe/dtrace-probe-p.o:\ (.SUNW_dof+0xb8): undefined reference to `main' collect2: error: ld returned 1 exit status === gdb Summary === nr of untested testcases 1 ... There is no reason to be this verbose about the failure to compile. Fix this by using quiet as additional option to gdb_compile in dtrace_build_usdt_test_program. Note that the error message still occurs in gdb.log. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-02-19 Tom de Vries <tdevries@suse.de> * lib/dtrace.exp (dtrace_build_usdt_test_program): Use quiet as gdb_compile option.
2020-02-18gdb: change print format of flag enums with value 0Simon Marchi4-8/+36
If a flag enum has value 0 and the enumeration type does not have an enumerator with value 0, we currently print: $1 = (unknown: 0x0) I don't like the display of "unknown" here, since for flags, 0 is a an expected value. It just means that no flags are set. This patch makes it so that we print it as a simple 0 in this situation: $1 = 0 If there is an enumerator with value 0, it is still printed using that enumerator, for example (from the test): $1 = FE_NONE gdb/ChangeLog: * valprint.c (generic_val_print_enum_1): When printing a flag enum with value 0 and there is no enumerator with value 0, print just "0" instead of "(unknown: 0x0)". gdb/testsuite/ChangeLog: * gdb.base/printcmds.exp (test_print_enums): Update expected output.
2020-02-18gdb: print unknown part of flag enum in hexSimon Marchi4-4/+14
When we print the "unknown" part of a flag enum, it is printed in decimal. I think it would be more useful if it was printed in hex, as it helps to determine which bits are set more than a decimal value. gdb/ChangeLog: * valprint.c (generic_val_print_enum_1): Print unknown part of flag enum in hex. gdb/testsuite/ChangeLog: * gdb.base/printcmds.exp (test_print_enums): Expect hex values for "unknown".
2020-02-18gdb: allow duplicate enumerators in flag enumsSimon Marchi5-11/+19
I have come across some uses cases where it would be desirable to treat an enum that has duplicate values as a "flag enum". For example, this one here [1]: enum membarrier_cmd { MEMBARRIER_CMD_QUERY = 0, MEMBARRIER_CMD_GLOBAL = (1 << 0), MEMBARRIER_CMD_GLOBAL_EXPEDITED = (1 << 1), MEMBARRIER_CMD_REGISTER_GLOBAL_EXPEDITED = (1 << 2), MEMBARRIER_CMD_PRIVATE_EXPEDITED = (1 << 3), MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED = (1 << 4), MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE = (1 << 5), MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED_SYNC_CORE = (1 << 6), /* Alias for header backward compatibility. */ MEMBARRIER_CMD_SHARED = MEMBARRIER_CMD_GLOBAL, }; The last enumerator is kept for backwards compatibility. Without this patch, this enumeration wouldn't be considered a flag enum, because two enumerators collide. With this patch, it would be considered a flag enum, and the value 3 would be printed as: MEMBARRIER_CMD_GLOBAL | MEMBARRIER_CMD_GLOBAL_EXPEDITED Although if people prefer, we could display both MEMBARRIER_CMD_GLOBAL and MEMBARRIER_CMD_SHARED in the result. It wouldn't be wrong, and could perhaps be useful in case a bit may have multiple meanings (depending on some other bit value). [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/membarrier.h?id=0bf999f9c5e74c7ecf9dafb527146601e5c848b9#n125 gdb/ChangeLog: * dwarf2/read.c (update_enumeration_type_from_children): Allow flag enums to contain duplicate enumerators. * valprint.c (generic_val_print_enum_1): Update comment. gdb/testsuite/ChangeLog: * gdb.base/printcmds.c (enum flag_enum): Add FE_TWO_LEGACY enumerator.
2020-02-18gdb: fix printing of flag enums with multi-bit enumeratorsSimon Marchi6-9/+81
GDB has this feature where if an enum looks like it is meant to represent binary flags, it will present the values of that type as a bitwise OR of the flags that are set in the value. The original motivation for this patch is to fix this behavior: enum hello { AAA = 0x1, BBB = 0xf0 }; (gdb) p (enum hello) 0x11 $1 = (AAA | BBB) This is wrong because the bits set in BBB (0xf0) are not all set in the value 0x11, but GDB presents it as if they all were. I think that enumerations with enumerators that have more than one bit set should simply not qualify as "flag enum", as far as this heuristic is concerned. I'm not sure what it means to have flags of more than one bit. So this is what this patch implements. I have added an assert in generic_val_print_enum_1 to make sure the flag enum types respect that, in case they are used by other debug info readers, in the future. I've enhanced the gdb.base/printcmds.exp test to cover this case. I've also added tests for printing flag enums with value 0, both when the enumeration has and doesn't have an enumerator for value 0. gdb/ChangeLog: * dwarf2/read.c: Include "count-one-bits.h". (update_enumeration_type_from_children): If an enumerator has multiple bits set, don't treat the enumeration as a "flag enum". * valprint.c (generic_val_print_enum_1): Assert that enumerators of flag enums have 0 or 1 bit set. gdb/testsuite/ChangeLog: * gdb.base/printcmds.c (enum flag_enum): Prefix enumerators with FE_, add FE_NONE. (three): Update. (enum flag_enum_without_zero): New enum. (flag_enum_without_zero): New variable. (enum not_flag_enum): New enum. (three_not_flag): New variable. * gdb.base/printcmds.exp (test_artificial_arrays): Update. (test_print_enums): Add more tests for printing flag enums.
2020-02-18Fix build with gcc-4.8.xBernd Edlinger7-6/+22
Use an explicit conversion from unique_ptr<T> to displaced_step_closure_up to avoid a compiler bug with gcc-4.8.4: ../../binutils-gdb/gdb/amd64-tdep.c:1514:10: error: cannot bind 'std::unique_ptr<amd64_displaced_step_closure>' lvalue to 'std::unique_ptr<amd64_displaced_step_closure>&&' gdb: 2020-02-18 Bernd Edlinger <bernd.edlinger@hotmail.de> * aarch64-tdep.c (aarch64_displaced_step_copy_insn): Use an explicit conversion. * amd64-tdep.c (amd64_displaced_step_copy_insn): Likewise. * arm-linux-tdep.c (arm_linux_displaced_step_copy_insn): Likewise. * i386-tdep.c (i386_displaced_step_copy_insn): Likewise. * rs6000-tdep.c (ppc_displaced_step_copy_insn): Likewise. * s390-tdep.c (s390_displaced_step_copy_insn): Likewise.
2020-02-18gdb: update email address for Palmer DabbeltSimon Marchi2-1/+5
gdb/ChangeLog: * MAINTAINERS: Change palmer@sifive.com to palmer@dabbelt.com.
2020-02-18[gdb/testsuite] Handle missing gnatmake in gnat_runtime_has_debug_infoTom de Vries2-4/+19
After de-installing gnatmake, I get on stdout/stderr: ... Running src/gdb/testsuite/gdb.base/gdb-caching-proc.exp ... FAIL: gdb-caching-proc.exp: failed to compile gnat-debug-info test binary ... FAIL: gdb-caching-proc.exp: failed to compile gnat-debug-info test binary ... In gdb.sum, we see these FAILs (each paired with an UNSUPPORTED as well) followed by: ... PASS: gdb-caching-proc.exp: gnat_runtime_has_debug_info consistency ... Likewise, after re-installing gnatmake, I get a PASS for each of the UNSUPPORTEDs, and the FAILs disappear. The FAIL comes from gnat_runtime_has_debug_info, the PASS/UNSUPPORTED comes from gdb_compile_ada. Fix this by removing the corresponding fail call in gnat_runtime_has_debug_info, as well as using a new variant gdb_compile_ada_1 that doesn't call pass/unsupported. Tested on x86_64-linux, with gnatmake installed and de-installed. gdb/testsuite/ChangeLog: 2020-02-18 Tom de Vries <tdevries@suse.de> * lib/ada.exp (gdb_compile_ada_1): Factor out of ... (gdb_compile_ada): ... here. (gnat_runtime_has_debug_info): Remove fail call for gdb_compile_ada failure. Use gdb_compile_ada_1 instead of gdb_compile_ada.
2020-02-18Automatic date update in version.inGDB Administrator1-1/+1
2020-02-17Fix gdbserver-without-gdb buildTom Tromey3-14/+28
An earlier patch changed gdbserver to use the already-built top-level gnulib and gdbsupport. However, if one did a build that did not include gdb, then gdbserver would fail to build. The problem is that configure.ac only adds gnulib and gdbsupport to the build when gdb is being built. This patch fixes the problem by arranging for this to happen when gdbserver is built. ChangeLog 2020-02-17 Tom Tromey <tom@tromey.com> * configure: Rebuild. * configure.ac (configdirs): Add gnulib and gdbsupport when building gdbserver.
2020-02-17x86: Remove CpuABM and add CpuPOPCNTH.J. Lu9-2827/+2862
AMD ABM has 2 instructions: popcnt and lzcnt. ABM CPUID feature bit has been reused for lzcnt and a POPCNT CPUID feature bit is added for popcnt which used to be the part of SSE4.2. This patch removes CpuABM and adds CpuPOPCNT. It changes ABM to enable both lzcnt and popcnt, changes SSE4.2 to also enable popcnt. gas/ * config/tc-i386.c (cpu_arch): Add .popcnt. * doc/c-i386.texi: Remove abm and .abm. Add popcnt and .popcnt. Add a tab before @samp{.sse4a}. opcodes/ * i386-gen.c (cpu_flag_init): Replace CpuABM with CpuLZCNT|CpuPOPCNT. Add CpuPOPCNT to CPU_SSE4_2_FLAGS. Add CPU_POPCNT_FLAGS. (cpu_flags): Remove CpuABM. Add CpuPOPCNT. * i386-opc.h (CpuABM): Removed. (CpuPOPCNT): New. (i386_cpu_flags): Remove cpuabm. Add cpupopcnt. * i386-opc.tbl: Replace CpuABM|CpuSSE4_2 with CpuPOPCNT on popcnt. Remove CpuABM from lzcnt. * i386-init.h: Regenerated. * i386-tbl.h: Likewise.
2020-02-17x86: fold certain VCVT{,U}SI2S{S,D} templatesJan Beulich3-133/+38
There don't really need to be separate Cpu64 and CpuNo64 templates for these. One small issue with this is that slightly strange code .intel_syntax noprefix .code16 .arch i286 .arch .avx vcvtsi2sd xmm0, xmm0, dword ptr [bx] vcvtsi2sd xmm0, xmm0, qword ptr [bx] vcvtsi2sd xmm0, xmm0, ebx vcvtsi2sd xmm0, xmm0, rbx now will match in behavior with the AVX512 counterparts in that not only the 2nd vcvtsi2sd won't assemble, but also the first. The last two, otoh, will continue to assemble fine (due to the lack of any memory operand size specifier). As a result, another way to make things behave more consistently would be to avoid the folding and add IgnoreSize to the CpuNo64 AVX512 variants. A 3rd way to do so would be to add Cpu386 to any such insn template. While doing this also make the usual cosmetic adjustments for the insns touched anyway. Additionally drop the redundant Cpu64 from the SAE forms of VCVT{,U}SI2SD - they won't assemble outside of 64-bit mode due to there not being anything to match the Reg64 operand.
2020-02-17x86: fold AddrPrefixOpReg templatesJan Beulich5-249/+124
There's no need to have separate Cpu64 and CpuNo64 templates: There already is special logic handling the attribute, and all that's needed is rejecting 16-bit address registers in 64-bit mode. Suppress suffix guessing and group all involved logic together, outside of suffix processing (arguably it doesn't even belong in process_suffix()). Also, since no AddrPrefixOpReg template permits any suffixes, move the No_*Suf specifiers for them to a central place. Along with this drop the no longer relevant NoRex64 from there.
2020-02-17x86/Intel: don't swap operands of MONITOR{,X} and MWAIT{,X}Jan Beulich9-4/+124
Generally, the documentation doesn't allow for any explicit operands to be specified with MONITOR/MWAIT. To permit the more legible overriding of the address size via specifying operands, the option is being retained even in Intel mode, but operand swapping is being suppressed by this patch. This is both because it makes no sense here (all of the operands are inputs) and because, as a result, old gcc (prior to 4.8) actually expects it this way with -mintel-syntax (and hence gets fixed by this change rather than, as claimed by a reply in the bug report, broken).
2020-02-17x86/Intel: improve diagnostics for ambiguous VCVT* operandsJan Beulich13-78/+309
Conversions which shrink element size and which have a memory source can't be disambiguated between their 128- and 256-bit variants by looking at the register operand. "operand size mismatch", however, is a pretty misleading diagnostic. Generalize the logic introduced for VFPCLASSP{S,D} such that, with suitable similar adjustments to the respective templates, it'll cover these cases too. For VCVTNEPS2BF16 also fold the two previously separate AVX512VL templates to achieve the intended effect. This is then also accompanied by a respective addition to the inval-avx512f testcase.
2020-02-16x86: Don't disable SSE3 when disabling SSE4aH.J. Lu3-2/+7
Since SSE3 is independent of SSE4a, don't disable SSE3 when disabling SSE4a. * i386-gen.c (cpu_flag_init): Remove CPU_ANY_SSE3_FLAGS from CPU_ANY_SSE4A_FLAGS.
2020-02-17Re: x86: Don't disable SSE4a when disabling SSE4Alan Modra2-2/+6
* i386-gen.c (cpu_flag_init): Correct last change.
2020-02-17Automatic date update in version.inGDB Administrator1-1/+1
2020-02-16x86: Don't disable SSE4a when disabling SSE4H.J. Lu6-6/+22
commit 7deea9aad8 changed nosse4 to include CpuSSE4a. But AMD SSE4a is a superset of SSE3 and Intel SSE4 is a superset of SSSE3. Disable Intel SSE4 shouldn't disable AMD SSE4a. This patch restores nosse4. It also adds .sse4a and nosse4a. gas/ * config/tc-i386.c (cpu_arch): Add .sse4a and nosse4a. Restore nosse4. * doc/c-i386.texi: Document sse4a and nosse4a. opcodes/ * i386-gen.c (cpu_flag_init): Add CPU_ANY_SSE4A_FLAGS. Remove CPU_ANY_SSE4_FLAGS.
2020-02-16Automatic date update in version.inGDB Administrator1-1/+1
2020-02-15Automatic date update in version.inGDB Administrator1-1/+1
2020-02-14gdb: introduce displaced_step_closure_up type aliasSimon Marchi15-18/+46
To help with readability, add the type displaced_step_closure_up, an alias for std::unique_ptr<displaced_step_closure>, and use it throughout the code base. gdb/ChangeLog: * aarch64-tdep.c (aarch64_displaced_step_copy_insn): Use displaced_step_closure_up. * aarch64-tdep.h (aarch64_displaced_step_copy_insn): Likewise. (struct displaced_step_closure_up): * amd64-tdep.c (amd64_displaced_step_copy_insn): Likewise. * amd64-tdep.h (amd64_displaced_step_copy_insn): Likewise. * arm-linux-tdep.c (arm_linux_displaced_step_copy_insn): Likewise. * gdbarch.sh (displaced_step_copy_insn): Likewise. * gdbarch.c, gdbarch.h: Re-generate. * i386-linux-tdep.c (i386_linux_displaced_step_copy_insn): Use displaced_step_closure_up. * i386-tdep.c (i386_displaced_step_copy_insn): Likewise. * i386-tdep.h (i386_displaced_step_copy_insn): Likewise. * infrun.h (displaced_step_closure_up): New type alias. (struct displaced_step_inferior_state) <step_closure>: Change type to displaced_step_closure_up. * rs6000-tdep.c (ppc_displaced_step_copy_insn): Use displaced_step_closure_up. * s390-tdep.c (s390_displaced_step_copy_insn): Likewise.
2020-02-14Change gdbserver to use existing gnulib and libibertyTom Tromey10-293/+41
This changes gdbserver so that it no longer builds its own gnulib and libiberty. Instead, it now relies on the ones that were already built at the top level. gdbsupport is still built specially for gdbserver. This is more complicated and will be tackled in a subsequent patch. ChangeLog 2020-02-14 Tom Tromey <tom@tromey.com> * Makefile.in: Rebuild. * Makefile.def: Make gdbserver require gnulib and libiberty. gdbserver/ChangeLog 2020-02-14 Tom Tromey <tom@tromey.com> * acinclude.m4: Don't include acx_configure_dir.m4. * Makefile.in (LIBIBERTY_BUILDDIR, GNULIB_BUILDDIR): Update. (SUBDIRS, CLEANDIRS, REQUIRED_SUBDIRS): Remove. (all, install-only, uninstall, clean-info, clean) (maintainer-clean): Don't recurse. (subdir_do, all-lib): Remove. ($(LIBGNU) $(LIBIBERTY) $(GNULIB_H)): Remove rule. (GNULIB_H): Remove. (generated_files): Update. ($(GNULIB_BUILDDIR)/Makefile): Remove rule. * configure: Rebuild. * configure.ac: Don't configure gnulib or libiberty. (GNULIB): Update. gdbsupport/ChangeLog 2020-02-14 Tom Tromey <tom@tromey.com> * common-defs.h: Change path to gnulib/config.h. Change-Id: I469cbbf5db2ab37109c058e9e3a1e4f4dabdfc98
2020-02-14Cache .gnu_debugdata BFDTom Tromey2-0/+16
While looking at the output of "maint info bfd" with multiple inferiors, I noticed that there were duplicate entries for .gnu_debugdata. There is no reason to re-create this BFD each time it is needed. This patch arranges to share the data. gdb/ChangeLog 2020-02-14 Tom Tromey <tom@tromey.com> * minidebug.c (gnu_debug_key): New global. (find_separate_debug_file_in_section): Use it. Change-Id: If139f89f0f07db33f399afdbcfbf5aaeffe4de46
2020-02-14Have testsuite find gdbserver in new locationTom Tromey3-7/+15
This updates the gdb testsuite to look for gdbserver in its new location. The old location is also checked for, on the theory that perhaps someone sets GDB to a full path for install testing. gdb/testsuite/ChangeLog 2020-02-14 Tom Tromey <tom@tromey.com> * lib/gdbserver-support.exp (find_gdbserver): Find gdbserver in build directory. * boards/gdbserver-base.exp: Update path to gdbserver. Change-Id: If03db762ba53882ddfaf2d2d516de14c3fa03938
2020-02-14gdb: make gdbarch_displaced_step_copy_insn return an std::unique_ptrSimon Marchi15-32/+52
This callback dynamically allocates a specialized displaced_step_closure, and gives the ownership of the object to its caller. So I think it would make sense for the callback to return an std::unique_ptr, this is what this patch implements. gdb/ChangeLog: * gdbarch.sh (displaced_step_copy_insn): Change return type to an std::unique_ptr. * gdbarch.c: Re-generate. * gdbarch.h: Re-generate. * infrun.c (displaced_step_prepare_throw): Adjust to std::unique_ptr change. * aarch64-tdep.c (aarch64_displaced_step_copy_insn): Change return type to std::unique_ptr. * aarch64-tdep.h (aarch64_displaced_step_copy_insn): Likewise. * amd64-tdep.c (amd64_displaced_step_copy_insn): Likewise. * amd64-tdep.h (amd64_displaced_step_copy_insn): Likewise. * arm-linux-tdep.c (arm_linux_displaced_step_copy_insn): Likewise. * i386-linux-tdep.c (i386_linux_displaced_step_copy_insn): Likewise. * i386-tdep.c (i386_displaced_step_copy_insn): Likewise. * i386-tdep.h (i386_displaced_step_copy_insn): Likewise. * rs6000-tdep.c (ppc_displaced_step_copy_insn): Likewise. * s390-tdep.c (s390_displaced_step_copy_insn): Likewise.
2020-02-14gdb: cleanup of displaced_step_inferior_state::reset/displaced_step_clearSimon Marchi3-29/+44
displaced_step_inferior_state::reset and displaced_step_clear appear to have the same goal, but they don't do the same thing. displaced_step_inferior_state::reset clears more things than displaced_step_clear, but it misses free'ing the closure, which displaced_step_clear does. This patch replaces displaced_step_clear's implementation with just a call to displaced_step_inferior_state::reset. It then changes displaced_step_inferior_state::step_closure to be a unique_ptr, to indicate the fact that displaced_step_inferior_state owns the closure (and so that it is automatically freed when the field is reset). The test gdb.base/step-over-syscall.exp caught a problem when doing this, which I consider to be a latent bug which my cleanup exposes. In handle_inferior_event, in the TARGET_WAITKIND_FORKED case, if we displaced-step over a fork syscall, we make sure to restore the memory that we used as a displaced-stepping buffer in the child. We do so using the displaced_step_inferior_state of the parent. However, we do it after calling displaced_step_fixup for the parent, which clears the information in the parent's displaced_step_inferior_state. It worked fine before, because displaced_step_clear didn't completely clear the displaced_step_inferior_state structure, so the required information (in this case the gdbarch) was still available after clearing. I fixed it by making GDB restore the child's memory before calling the displaced_step_fixup on the parent. This way, the data in the displaced_step_inferior_state structure is still valid when we use it for the child. This is the error you would get in gdb.base/step-over-syscall.exp without this fix: /home/smarchi/src/binutils-gdb/gdb/gdbarch.c:3911: internal-error: ULONGEST gdbarch_max_insn_length(gdbarch*): Assertion `gdbarch != NULL' failed. gdb/ChangeLog: * infrun.c (get_displaced_step_closure_by_addr): Adjust to std::unique_ptr. (displaced_step_clear): Rename to... (displaced_step_reset): ... this. Just call displaced->reset (). (displaced_step_clear_cleanup): Rename to... (displaced_step_reset_cleanup): ... this. (displaced_step_prepare_throw): Adjust to std::unique_ptr. (displaced_step_fixup): Likewise. (resume_1): Likewise. (handle_inferior_event): Restore child's memory before calling displaced_step_fixup on the parent. * infrun.h (displaced_step_inferior_state) <reset>: Adjust to std::unique_ptr. <step_closure>: Change type to std::unique_ptr.
2020-02-14gnulib: import count-one-bits module and use itSimon Marchi17-103/+303
For a fix I intend to submit, I would need a function that counts the number of set bits in a word. There is __builtin_popcount that is supported by gcc and clang, but there is also a gnulib module that wraps that and provides a fallback for other compilers, so I think it would be good to use it. I also noticed that there is a bitcount function in arch/arm.c, so I thought that as a first step I would replace that one with the gnulib count-one-bits module. This is what this patch does. The gnulib module provides multiple functions, with various parameter length (unsigned int, unsigned long int, unsigned long long int), I chose the one that made sense for each call site based on the argument type. gnulib/ChangeLog: * update-gnulib.sh (IMPORTED_GNULIB_MODULES): Import count-one-bits module. * configure: Re-generate. * aclocal.m4: Re-generate. * Makefile.in: Re-generate. * import/count-one-bits.c: New file. * import/count-one-bits.h: New file. * import/Makefile.am: Re-generate. * import/Makefile.in: Re-generate. * import/m4/gnulib-cache.m4: Re-generate. * import/m4/gnulib-comp.m4: Re-generate. * import/m4/count-one-bits.m4: New file. gdb/ChangeLog: * arm-tdep.c: Include count-one-bits.h. (cleanup_block_store_pc): Use count_one_bits. (cleanup_block_load_pc): Use count_one_bits. (arm_copy_block_xfer): Use count_one_bits. (thumb2_copy_block_xfer): Use count_one_bits. (thumb_copy_pop_pc_16bit): Use count_one_bits. * arch/arm-get-next-pcs.c: Include count-one-bits.h. (thumb_get_next_pcs_raw): Use count_one_bits. (arm_get_next_pcs_raw): Use count_one_bits_l. * arch/arm.c (bitcount): Remove. * arch/arm.h (bitcount): Remove.
2020-02-14Return unique_xmalloc_ptr from call_site_find_chainTom Tromey4-19/+22
call_site_find_chain returns a pointer that the caller must deallocate. It seemed better here to return a unique_xmalloc_ptr instead. gdb/ChangeLog 2020-02-14 Tom Tromey <tromey@adacore.com> * dwarf2/frame-tailcall.c (dwarf2_tailcall_sniffer_first): Update. * dwarf2/loc.h (call_site_find_chain): Return unique_xmalloc_ptr. * dwarf2/loc.c (call_site_find_chain_1): Return unique_xmalloc_ptr. (call_site_find_chain): Likewise.
2020-02-14Remove the old movsx and movzx documentation for AT&T syntaxH.J. Lu2-16/+5
* doc/c-i386.texi: Remove the old movsx and movzx documentation for AT&T syntax.
2020-02-14Remove Intel syntax comments on movsx and movzxH.J. Lu2-3/+7
Since movsx and movzx are valid mnemonic in AT&T syntax, remove Intel syntax comments on movsx and movzx to avoid confusing other readers. * i386-opc.tbl (movsx): Remove Intel syntax comments. (movzx): Likewise.
2020-02-14x86: replace adhoc (partly wrong) ambiguous operand checking for MOVSX/MOVZXJan Beulich32-205/+1694
For these to get treatment consistent with other operand size checking the special logic shouldn't live in md_assemble(), but process_suffix(). And there's more logic involved than simply zapping the suffix. Note however that MOVS[BW]* and MOVZ[BW]* still won't be fully consistent, due to the objection to fold MOVS* templates just like was done for MOVZ* in c07315e0c6 ("x86: allow suffix-less movzw and 64-bit movzb"). Note further that it is against my own intentions to have MOVSX/MOVZX silently default to a byte source in AT&T mode. This should happen only when the destination register is a 16-bit one. In all other cases there is an ambiguity, and the user should be warned. But it was explicitly requested for this to be done in a way inconsistent with everything else. Note finally that the assembler change points out (and this patch fixes) a wrong Intel syntax test introduced by bc31405ebb2c ("x86-64: Properly encode and decode movsxd"): When source code specifies a 16-bit destination register, disassembly expectations shouldn't have been to find a 32-bit one.
2020-02-14x86: adjust segment override prefix emissionJan Beulich4-6/+29
Since we already suppress the prefix altogether when it's the default one for the chosen addressing mode, let's do so also when instruction prefix and override specified with the memory operand match. (Note that insn prefix specified segment overrides never get discarded.)
2020-02-14x86: optimize away pointless segment overridesJan Beulich4-3/+31
When optimizing there's no point keeping the segment overrides when we warn about their presence in the first place.
2020-02-14x86: extend LEA's segment override warningJan Beulich6-3/+33
For one both possible forms should be warned about. And then, to guard against future surprises, qualify the original opcode check by excluding VEX/EVEX-like templates.
2020-02-14x86: Document movsx/movsxd/movzx for AT&T syntaxH.J. Lu2-0/+59
Document different mnemonics of movsx, movsxd and movzx in AT&T syntax. PR gas/25438 * doc/c-i386.texi: Document movsx, movsxd and movzx for AT&T syntax.
2020-02-14Fix argv[] in programs invoked by gdbserver on MS-WindowsEli Zaretskii2-18/+33
gdbserver/ChangeLog 2020-02-14 Eli Zaretskii <eliz@gnu.org> * win32-low.c (create_process): Prepend PROGRAM to ARGS when preparing the command line for CreateProcess. (win32_create_inferior): Reflect the program name in debugging output that shows the process and its command line.
2020-02-14[gdb] Speedup lnp_state_machine::handle_special_opcodeRichard Biener2-5/+10
I see for some program at gdb startup: ... Samples: 102K of event 'cycles:pu', Event count (approx.): 91710925103 Overhead Command Shared Object Symbol 15.21% gdb gdb [.] lnp_state_machine::handle_special ... where the divisions are the places we stall. The following micro-optimizes things but it smells like m_line_header->line_range is constant, likewise probably m_line_header->maximum_ops_per_instruction so eventually the divisions could be avoided completely with some lookup table. Well. Micro-optimizing with this patch improves things (don't expect [load] CSE over the gdbarch_adjust_dwarf2_line call). Build and reg-tested on x86_64-linux. gdb/ChangeLog: 2020-02-14 Richard Biener <rguenther@suse.de> * dwarf2/read.c (lnp_state_machine::handle_special_opcode): Apply CSE on expression with division operators.
2020-02-14Automatic date update in version.inGDB Administrator1-1/+1