aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-03-11[gdb] Fix segv in "maint print symbols" for ada execTom de Vries4-1/+25
When using the executable from test-case gdb.ada/access_to_packed_array.exp (read-in using -readnow) and printing the symbols using "maint print symbols", we run into a segv: ... $ gdb -readnow -batch access_to_packed_array/foo -ex "maint print symbols" ... info: array (<>) of character; computed at runtime ptr: range 0 .. 2147483647; computed at runtime Aborted (core dumped) ... What happens is that dwarf2_evaluate_property gets called and sets the local frame variable to the current frame, which happens to be NULL. Subsequently the PROP_LOCLIST handling code is executed, where get_frame_address_in_block gets called with argument NULL, and the segv is triggered. Fix this by handling a NULL frame in the PROP_LOCLIST handling code in dwarf2_evaluate_property. Build and reg-tested on x86_64-linux. gdb/ChangeLog: 2020-03-11 Tom de Vries <tdevries@suse.de> * dwarf2/loc.c (dwarf2_evaluate_property): Handle NULL frame in PROP_LOCLIST handling code. gdb/testsuite/ChangeLog: 2020-03-11 Tom de Vries <tdevries@suse.de> * gdb.ada/access_to_packed_array.exp: Test printing of expanded symtabs.
2020-03-10gdb: Add support for tracking the DWARF line table is-stmt fieldAndrew Burgess23-29/+1096
This commit brings support for the DWARF line table is_stmt field to GDB. The is_stmt field is used by the compiler when a single source line is split into multiple assembler instructions, especially if the assembler instructions are interleaved with instruction from other source lines. The compiler will set the is_stmt flag false from some instructions from the source lines, these instructions are not a good place to insert a breakpoint in order to stop at the source line. Instructions which are marked with the is_stmt flag true are a good place to insert a breakpoint for that source line. Currently GDB ignores all instructions for which is_stmt is false. This is fine in a lot of cases, however, there are some cases where this means the debug experience is not as good as it could be. Consider stopping at a random instruction, currently this instruction will be attributed to the last line table entry before this point for which is_stmt was true - as these are the only line table entries that GDB tracks. This can easily be incorrect in code with even a low level of optimisation. With is_stmt tracking in place, when stopping at a random instruction we now attribute the instruction back to the real source line, even when is_stmt is false for that instruction in the line table. When inserting breakpoints we still select line table entries for which is_stmt is true, so the breakpoint placing behaviour should not change. When stepping though code (at the line level, not the instruction level) we will still stop at instruction where is_stmt is true, I think this is more likely to be the desired behaviour. Instruction stepping is, of course, unchanged, stepping one instruction at a time, but we should now report more accurate line table information with each instruction step. The original motivation for this work was a patch posted by Bernd here: https://sourceware.org/ml/gdb-patches/2019-11/msg00792.html As part of that thread it was suggested that many issues would be resolved if GDB supported line table views, this isn't something I've attempted in this patch, though reading the spec, it seems like this would be a useful feature to support in GDB in the future. The spec is here: http://dwarfstd.org/ShowIssue.php?issue=170427.1 And Bernd gives a brief description of the benefits here: https://sourceware.org/ml/gdb-patches/2020-01/msg00147.html With that all said, I think that there is benefit to having proper is_stmt support regardless of whether we have views support, so I think we should consider getting this in first, and then building view support on top of this. The gdb.cp/step-and-next-inline.exp test is based off a test proposed by Bernd Edlinger in this message: https://sourceware.org/ml/gdb-patches/2019-12/msg00842.html gdb/ChangeLog: * buildsym-legacy.c (record_line): Pass extra parameter to record_line. * buildsym.c (buildsym_compunit::record_line): Take an extra parameter, reduce duplication in the line table, and record the is_stmt flag in the line table. * buildsym.h (buildsym_compunit::record_line): Add extra parameter. * disasm.c (do_mixed_source_and_assembly_deprecated): Ignore non-statement lines. * dwarf2/read.c (dwarf_record_line_1): Add extra parameter, pass this to the symtab builder. (dwarf_finish_line): Pass extra parameter to dwarf_record_line_1. (lnp_state_machine::record_line): Pass a suitable is_stmt flag through to dwarf_record_line_1. * infrun.c (process_event_stop_test): When stepping, don't stop at a non-statement instruction, and only refresh the step info when we land in the middle of a line's range. Also add an extra comment. * jit.c (jit_symtab_line_mapping_add_impl): Initialise is_stmt field. * record-btrace.c (btrace_find_line_range): Only record lines marked as is-statement. * stack.c (frame_show_address): Show the frame address if we are in a non-statement sal. * symmisc.c (dump_symtab_1): Print the is_stmt flag. (maintenance_print_one_line_table): Print a header for the is_stmt column, and include is_stmt information in the output. * symtab.c (find_pc_sect_line): Find lines marked as statements in preference to non-statements. (find_pcs_for_symtab_line): Prefer is-statement entries. (find_line_common): Likewise. * symtab.h (struct linetable_entry): Add is_stmt field. (struct symtab_and_line): Likewise. * xcoffread.c (arrange_linetable): Initialise is_stmt field when arranging the line table. gdb/testsuite/ChangeLog: * gdb.cp/step-and-next-inline.cc: New file. * gdb.cp/step-and-next-inline.exp: New file. * gdb.cp/step-and-next-inline.h: New file. * gdb.dwarf2/dw2-is-stmt.c: New file. * gdb.dwarf2/dw2-is-stmt.exp: New file. * gdb.dwarf2/dw2-is-stmt-2.c: New file. * gdb.dwarf2/dw2-is-stmt-2.exp: New file. * gdb.dwarf2/dw2-ranges-base.exp: Update line table pattern.
2020-03-10gdb/testsuite: Add is-stmt support to the DWARF compilerAndrew Burgess2-1/+12
This commit adds the ability to set and toggle the DWARF line table is-stmt flag. A DWARF line table can now be created with the attribute 'default_is_stmt' like this: lines {version 2 default_is_stmt 0} label { ... } If 'default_is_stmt' is not specified then the current default is 1, which matches the existing behaviour. Inside the DWARF line table program you can now make use of {DW_LNS_negate_stmt} to toggle the is-stmt flag, for example this meaningless program: lines {version 2 default_is_stmt 0} label { include_dir "some_directory" file_name "some_filename" 1 program { {DW_LNS_negate_stmt} {DW_LNE_end_sequence} } } This new functionality will be used in a later commit. gdb/testsuite/ChangeLog: * lib/dwarf.exp (Dwarf::lines) Add support for modifying the is-stmt flag in the line table. Change-Id: Ia3f61d523826382dd2333f65b9aae368ad29c4a5
2020-03-10More 1 << 31 signed overflowsAlan Modra6-9/+18
* config/tc-csky.c (get_operand_value): Rewrite 1 << 31 expressions to avoid signed overflow. * config/tc-mcore.c (md_assemble): Likewise. * config/tc-mips.c (gpr_read_mask, gpr_write_mask): Likewise. * config/tc-nds32.c (SET_ADDEND): Likewise. * config/tc-nios2.c (nios2_assemble_arg_R): Likewise.
2020-03-10ubsan: som: left shift of 1 by 31 placesAlan Modra3-5/+11
* som/aout.h (SOM_AUX_ID_MANDATORY, SOM_SPACE_IS_LOADABLE), (SOM_SYMBOL_HIDDEN, SOM_SYMBOL_HAS_LONG_RETURN): Use 1u << 31. * som/lst.h (LST_SYMBOL_HIDDEN): Likewise.
2020-03-10objdump disassembly of files without symbolsAlan Modra2-4/+14
ubsan complains about memcpy with a NULL src even when size is zero. * objdump.c (disassemble_section): Don't call qsort unless sym count is at least two. (disassemble_data): Don't call memcpy with NULL src.
2020-03-10PR25648, objcopy SIGSEGV in ihex_write_recordAlan Modra2-5/+10
ihex_set_section_contents sorts records stored on the tdata.ihex_data list by address, but ihex_write_object_contents went too far in assuming they were not overlapping. This patch fixes the problem by not assuming anything about addresses in ihex_write_object_contents. PR 25648 * ihex.c (ihex_write_object_contents): Don't assume ordering of addresses here. Remove dead code.
2020-03-09x86: Also pass -P to $(CPP) when processing i386-opc.tblH.J. Lu3-2/+7
Since i386-opc.tbl contains '\' to avoid very long lines and i386-gen requires that each instruction must be in one line, also pass -P to $(CPP) to inhibit generation of linemarkers in the output from the preprocessor to support i386-gen. * Makefile.am ($(srcdir)/i386-init.h): Also pass -P to $(CPP). * Makefile.in: Regenerated.
2020-03-09[gdb/testsuite] Fix tcl error in cached_fileTom de Vries2-0/+7
When trying to run tests using target board cc-with-dwz after a clean build, I run into: ... ERROR: tcl error sourcing board description file for target cc-with-tweaks.exp. couldn't open "build/gdb/testsuite/cache/gdb.sh.17028": \ no such file or directory couldn't open "build/gdb/testsuite/cache/gdb.sh.17028": \ no such file or directory while executing "open $tmp_filename w" (procedure "cached_file" line 9) invoked from within "cached_file gdb.sh "$GDB $INTERNAL_GDBFLAGS $GDBFLAGS \"\$@\"" 1" ... The problem is that cached_file is trying to create a file build/gdb/testsuite/cache/gdb.sh.17028 in a non-existing directory. Fix this by creating the cache dir in cached_file. Tested on x86_64-linux, with target board cc-with-tweaks, and native. gdb/testsuite/ChangeLog: 2020-03-09 Tom de Vries <tdevries@suse.de> * lib/gdb.exp (cached_file): Create cache dir.
2020-03-09PR25645, readelf segfault reading fuzzed alpha-vms binaryAlan Modra2-12/+22
PR 25645 * readelf.c (dump_ia64_vms_dynamic_fixups): Pass size and nmemb to get_data rather than multiplying. (dump_ia64_vms_dynamic_relocs): Likewise. (process_version_sections): Correct order of size and nmemb args in get_data call. (process_mips_specific): Likewise.
2020-03-09x86: use template for AVX512 integer comparison insnsJan Beulich3-80/+48
These all follow a common pattern.
2020-03-09x86: use template for XOP integer comparison, shift, and rotate insnsJan Beulich3-268/+187
These all follow common patterns.
2020-03-09x86: use template for AVX/AVX512 floating point comparison insnsJan Beulich8-3877/+4759
These all follow an almost common pattern, again with the exception of being commutative, which can be easily taken care of. Note that, as an intended side effect (and in fact one of the reason to introduce templates), AVX long-form pseudo-ops get introduced alongside the already existing AVX512 ones.
2020-03-09x86: use template for SSE floating point comparison insnsJan Beulich4-208/+165
These all follow an almost common pattern, with the exception of being commutative. This exception can be easily taken care of.
2020-03-09x86: allow opcode templates to be templatedJan Beulich4-151/+298
In order to reduce redundancy as well as the chance of things going out of sync (see a later patch for an example), make the opcode table generator capable of recognizing and expanding templated templates. Use the new capability for compacting the general purpose conditional insns.
2020-03-08readelf.c: Fix a typo in commentsH.J. Lu2-1/+6
* readelf.c (get_dynamic_data): Replace "memory chekers" with "memory checkers" in comments.
2020-03-09asan: wasm: Out-of-memoryAlan Modra2-12/+21
* wasm-module.c (wasm_scan): Sanity check file name length before allocating memory. Move common section setup code. Do without bfd_tell to calculate section size.
2020-03-08Fix two typos in gdb_binary_search.hTom Tromey2-2/+6
I noticed a couple of typos in gdb_binary_search.h. This fixes them. gdbsupport/ChangeLog 2020-03-08 Tom Tromey <tom@tromey.com> * gdb_binary_search.h: Fix two typos.
2020-03-07[gdb/testsuite] Fix testing build_executable resultTom de Vries3-2/+7
When running with target board unix/-feliminate-dwarf2-dups, we run into these FAILs: ... FAIL: gdb.cp/rvalue-ref-params.exp: print value of f1 on Child&& in f2 FAIL: gdb.cp/ref-params.exp: print value of f1 on Child in main FAIL: gdb.cp/ref-params.exp: print value of f2 on Child in main FAIL: gdb.cp/ref-params.exp: print value of f1 on Child& in f2 FAIL: gdb.cp/ref-params.exp: print mf1(MQ) FAIL: gdb.cp/ref-params.exp: print mf2(MQ) FAIL: gdb.cp/ref-params.exp: print f1(MQR) FAIL: gdb.cp/ref-params.exp: print mf1(MQR) FAIL: gdb.cp/ref-params.exp: print mf2(MQR) ... This is due to comparing the result of build_executable to 1, while build_executable returns either 0 for success, or -1 for failure. Fix this by comparing with -1 instead. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-03-07 Tom de Vries <tdevries@suse.de> * gdb.cp/ref-params.exp: Compare build_executable result with -1. * gdb.cp/rvalue-ref-params.exp: Same.
2020-03-07[gdb] Support anonymous typedef generated by gcc -feliminate-dwarf2-dupsTom de Vries2-0/+15
Gcc supports an option -feliminate-dwarf2-dups (up until gcc-7, removed in gcc-8). When running tests with target board unix/-feliminate-dwarf2-dups, we run into: ... (gdb) PASS: gdb.ada/arraydim.exp: print m'length(3) ptype global_3dim_for_gdb_testing^M type = array (Unexpected type in ada_discrete_type_low_bound.^M (gdb) FAIL: gdb.ada/arraydim.exp: ptype global_3dim_for_gdb_testing ... The DWARF for the variable global_3dim_for_gdb_testing looks as follows: ... <0><824>: Abbrev Number: 1 (DW_TAG_compile_unit) <825> DW_AT_name : src/gdb/testsuite/gdb.ada/arraydim/inc.c <1><832>: Abbrev Number: 2 (DW_TAG_array_type) <833> DW_AT_type : <0x874> <2><837>: Abbrev Number: 3 (DW_TAG_subrange_type) <838> DW_AT_type : <0x84a> <83c> DW_AT_upper_bound : 0 <2><83d>: Abbrev Number: 3 (DW_TAG_subrange_type) <83e> DW_AT_type : <0x84a> <842> DW_AT_upper_bound : 1 <2><843>: Abbrev Number: 3 (DW_TAG_subrange_type) <844> DW_AT_type : <0x84a> <848> DW_AT_upper_bound : 2 <2><849>: Abbrev Number: 0 <1><84a>: Abbrev Number: 4 (DW_TAG_typedef) <84b> DW_AT_type : <0x86d> <1><84f>: Abbrev Number: 0 <0><85b>: Abbrev Number: 5 (DW_TAG_compile_unit) <861> DW_AT_name : src/gdb/testsuite/gdb.ada/arraydim/inc.c <1><86d>: Abbrev Number: 6 (DW_TAG_base_type) <86e> DW_AT_byte_size : 8 <86f> DW_AT_encoding : 7 (unsigned) <870> DW_AT_name : long unsigned int <1><874>: Abbrev Number: 7 (DW_TAG_base_type) <875> DW_AT_byte_size : 4 <876> DW_AT_encoding : 5 (signed) <877> DW_AT_name : int <1><87b>: Abbrev Number: 8 (DW_TAG_variable) <87c> DW_AT_name : global_3dim_for_gdb_testing <882> DW_AT_type : <0x832> <886> DW_AT_external : 1 ... The DWARF contains an anonymous typedef at 0x84a, referring to 0x86d. Strictly speaking, the anonymous typedef is illegal DWARF, because a DW_TAG_typedef is defined to have an DW_AT_name attribute containing the name of the typedef as it appears in the source program. The DWARF reading code creates a corresponding type for this typedef, which goes on to confuse the code handling arrays. Rather than trying to support the type representing this anonymous typedef in all the locations where it causes problems, fix this by treating the anonymous typedef as a forwarder DIE in the DWARF reader. Tested on x86_64-linux, with target boards unix and unix/-feliminate-dwarf2-dups. This fixes ~85 failures for unix/-feliminate-dwarf2-dups. gdb/ChangeLog: 2020-03-07 Tom de Vries <tdevries@suse.de> * dwarf2/read.c (read_typedef): Treat anonymous typedef as forwarder DIE.
2020-03-07Remove some obsolete commentsTom Tromey3-6/+8
While working on complex number support, I found a couple of apparently obsolete coments. This removes them. 2020-03-07 Tom Tromey <tom@tromey.com> * valops.c (value_literal_complex): Remove obsolete comment. * gdbtypes.h (enum type_code) <TYPE_CODE_FLT>: Remove obsolete comment.
2020-03-07Re: Add support for a ".file 0" directive if supporting DWARF 5 or higher.Alan Modra2-9/+13
Fixes a fail on hppa64-hp-hpux, where anything in the first column is a label. * testsuite/gas/elf/dwarf-5-file0.s: Don't start directives in first column.
2020-03-06binutils: doc: move artifacts back to MAINTAINERCLEANFILESSimon Marchi3-3/+9
In commit 2b44a6a237 (" binutils: doc: make `make clean` clean more things"), I moved the doc build artifacts to MOSTLYCLEANFILES, which made them get removed by "make clean". Because generating binutils.info requires makeinfo, and we do not want to require makeinfo when building from the tarball, binutils.info should not get removed by "make clean" (otherwise, it won't be included in the tarball). And to be consistent with other projects (e.g. ld and gas), we also want to ship the built man pages in the tarball. This patch puts back all these in MAINTAINERCLEANFILES, so that they are bundled in the tarball, and only cleaned if you use "make maintainer-clean". Tested by building a source release and confirming they are present. binutils/ChangeLog: PR 25491 * doc/Makefile.am: Rename MOSTLYCLEANFILES to MAINTAINERCLEANFILES. * doc/Makefile.in: Re-generate.
2020-03-07Automatic date update in version.inGDB Administrator1-1/+1
2020-03-06Pass thread_info pointer to various inferior control functionsSimon Marchi4-23/+49
[ Migrating this from Gerrit: https://gnutoolchain-gerrit.osci.io/r/c/binutils-gdb/+/321 ] I noticed that some functions in infcmd and infrun call each other and all call inferior_thread, while they could just get the thread_info pointer from their caller. That means less calls to inferior_thread, so less reliance on global state, since inferior_thread reads inferior_ptid. The paths I am unsure about are: - fetch_inferior_event calls... - step_command_fsm::should_stop calls... - prepare_one_step and - process_event_stop_test calls... - set_step_info Before this patch, prepare_one_step gets the thread pointer using inferior_thread. After this patch, it gets it from the execution_control_state structure in fetch_inferior_event. Are we sure that the thread from the execution_control_state structure is the same as the one inferior_thread would return? This code path is used when a thread completes a step, but the user had specified a step count (e.g. "step 5") so we decide to do one more step. It would be strange (and even a bug I suppose) if the thread in the ecs structure in fetch_inferior_event was not the same thread that is prepared to stepped by prepare_one_step. So I believe passing the ecs thread is fine. The same logic applies to process_event_stop_test calling set_step_info. gdb/ChangeLog: * infrun.h: Forward-declare thread_info. (set_step_info): Add thread_info parameter, add doc. * infrun.c (set_step_info): Add thread_info parameter, move doc to header. * infrun.c (process_event_stop_test): Pass thread to set_step_info call. * infcmd.c (set_step_frame): Add thread_info pointer, pass it to set_step_info. (prepare_one_step): Add thread_info parameter, pass it to set_step_frame and prepare_one_step (recursive) call. (step_1): Pass thread to prepare_one_step call. (step_command_fsm::should_stop): Pass thread to prepare_one_step. (until_next_fsm): Pass thread to set_step_frame call. (finish_command): Pass thread to set_step_info call.
2020-03-06Don't try to get the TIB address without an inferiorHannes Domani2-1/+7
The target_get_tib_address call always fails in this case, and there is an error when changing the program with the file command: (gdb) file allocer64.exe Reading symbols from allocer64.exe... You can't do that when your target is `exec' Now it will skip this part, there is no need to rebase the executable without an inferior anyways. gdb/ChangeLog: 2020-03-06 Hannes Domani <ssbssa@yahoo.de> * windows-tdep.c (windows_solib_create_inferior_hook): Check if inferior is running.
2020-03-06Add support for a ".file 0" directive if supporting DWARF 5 or higher.Nick Clifton7-8/+57
PR 25614 * dwarf2dbg.c (dwarf2_directive_filename): Allow a file number of 0 if the dwarf_level is 5 or more. Complain if a filename follows a file 0. * testsuite/gas/elf/dwarf-5-file0.s: New test. * testsuite/gas/elf/dwarf-5-file0.d: New test driver. * testsuite/gas/elf/elf.exp: Run the new test. PR 25612 * config/tc-ia64.h (DWARF2_VERISION): Fix typo. * doc/as.texi: Fix another typo.
2020-03-06[gdb/testsuite] Fix "text file busy" errors with cc-with-tweaks.expTom de Vries3-4/+49
When using target board cc-with-gdb-index.exp and running tests in parallel, we run into: ... gdb compile failed, gdb/contrib/gdb-add-index.sh: line 86: \ build/gdb/testsuite/gdb.sh: Text file busy ... The problem is that because of the parallel test run, gdb.sh is created for every single test-case, and eventually gdb.sh is overwritten while being executed. Fix this by creating gdb.sh only once. Tested on x86_64-linux with target board cc-with-gdb-index.exp, using both a serial and parallel -j 5 test run. gdb/testsuite/ChangeLog: 2020-03-06 Tom de Vries <tdevries@suse.de> * lib/gdb.exp (tentative_rename, cached_file): New proc. * boards/cc-with-tweaks.exp: Use cached_file to create gdb.sh.
2020-03-06Add support for --dwarf-[3|4|5] to assembler command line.Nick Clifton6-11/+88
PR 25612 * as.c (dwarf_level): Define. (show_usage): Add --gdwarf-3, --gdwarf-4 and --gdwarf-5. (parse_args): Add support for the new options. as.h (dwarf_level): Prototype. * dwarf2dbg.c (DWARF2_VERSION): Use dwarf_level as default version value. * config/tc-ia64.h (DWARF2_VERISION): Update definition. (DWARF2_LINE_VERSION): Remove definition. * doc/as.texi: Document the new options.
2020-03-06[gdb,testsuite,doc,NEWS] Fix "the the".Tom de Vries8-9/+23
Replace "the the" by "the". gdb/ChangeLog: 2020-03-06 Tom de Vries <tdevries@suse.de> * NEWS: Fix "the the". * ctfread.c: Same. gdb/doc/ChangeLog: 2020-03-06 Tom de Vries <tdevries@suse.de> * gdb.texinfo: Fix "the the". gdb/testsuite/ChangeLog: 2020-03-06 Tom de Vries <tdevries@suse.de> * README: Fix "the the". * gdb.base/dprintf.exp: Same.
2020-03-06[gdb] Remove trailing "done" after "Reading symbols from" messageTom de Vries2-5/+5
Using verbose, we get some detail on symbol loading: ... $ gdb a.out -iex "set verbose on" Reading symbols from a.out... Reading in symbols for /home/vries/hello.c...done. (gdb) ... And using debug symtab-create, much more detail: ... $ gdb a.out -iex "set verbose on" -iex "set debug symtab-create 1" Reading symbols from a.out... Reading minimal symbols of objfile /data/gdb_versions/devel/lto/a.out ... Installing 30 minimal symbols of objfile /data/gdb_versions/devel/lto/a.out. Done reading minimal symbols. Creating one or more psymtabs for objfile /data/gdb_versions/devel/lto/a.out ... Created psymtab 0x35a3de0 for module ../sysdeps/x86_64/start.S. Created psymtab 0x353e4e0 for module init.c. Created psymtab 0x353e560 for module ../sysdeps/x86_64/crti.S. Created psymtab 0x353e5e0 for module /home/vries/hello.c. Created psymtab 0x35bd530 for module elf-init.c. Created psymtab 0x35bd5b0 for module ../sysdeps/x86_64/crtn.S. Reading in symbols for /home/vries/hello.c...Created compunit symtab 0x354bd20 for hello.c. done. (gdb) ... The "Created compunit symtab" message gets inbetween the "Reading in symbols" and the trailing "done.". [ Strictly speaking this is a regression since commit faa17681cc "Make gdb_flush also flush the wrap buffer", but the same problem happens when using -batch before this commit. ] Fix this by removing the trailing "done." altogether, such that we get: ... Created psymtab 0x3590520 for module ../sysdeps/x86_64/crtn.S. Reading in symbols for /home/vries/hello.c... Created compunit symtab 0x359dd20 for hello.c. (gdb) ... [ Alternatively, we could fix this emitting a "Done reading in symbols" line or some such, like is done for minimal symbols. See above. ] [ Note: Removing the trailing "done." for the "Reading symbols from" message was done in commit 3453e7e409 'Clean up "Reading symbols" output'. ] Build and reg-tested on x86_64-linux. gdb/ChangeLog: 2020-03-06 Tom de Vries <tdevries@suse.de> * psymtab.c (psymtab_to_symtab): Don't print "done.".
2020-03-06gdbserver/gdbsupport: Add .dir-locals.el fileAndrew Burgess6-0/+99
Copy the .dir-locls.el file from gdb/ to gdbserver/ and gdbsupport/ so that we get the GNU/GDB style when editing these files in Emacs. I initially wanted to remove the (c-mode . ((mode . c++))) that switches c-mode files into c++-mode as we store C++ code in *.cc files in the gdbserver/ directory, unlike gdb/ where we use *.c, however, I was forgetting about the header files - we still use *.h for our C++ header files, so for now I left the settings in place to open all C files in c++-mode. We now have three copies of this file, which are all identical. It would be nice if we could remove this duplication, however, for now we haven't found a good way to do this. Some options considered were: 1. Use symlinks to only have one copy of the file. This was rejected as not all targets support symlinks in the way. 2. Have two of the .dir-locals.el files contain some mechanism by which the third copy of the file is sourced. Though this would, in theory, be possible, it would involve some advanced Emacs scripting, would be fragile, and a maintenance burdon. 3. Move the .dir-locals up into top level src/ directory, then use Emacs dir-locals directory pattern matching to only apply the rules for the three directories we care about. The problem is that each directory has to be listed separately, so we still end up having to duplicate all the rules. In the end, it was decided that having three copies of the file, though not ideal, is probably easiest for now. This was all discussed in this mailing list thread: https://sourceware.org/ml/gdb-patches/2020-03/msg00024.html The copyright date in the new files is left as for gdb/.dir-locals.el, as the new files are a copy of the old, this is inline with this rule: https://sourceware.org/gdb/wiki/ContributionChecklist#Copyright_Header gdb/ChangeLog: * .dir-locals.el: Add a comment referencing the other copies of this file. gdbserver/ChangeLog: * .dir-locals.el: New file. gdbsupport/ChangeLog: * .dir-locals.el: New file.
2020-03-06Stop the assembler from complaining that the input and output files are the ↵Nick Clifton2-1/+13
same, if neither of them are regular files. PR 25572 * as.c (main): Allow matching input and outputs when they are not regular files.
2020-03-06Fix an abort triggered when objcopy is used to set the "share" section flag ↵Nick Clifton5-12/+84
on an ELF section. binutils* objcopy.c (check_new_section_flags): New function. Reject the SEC_COFF_SHARED flag if the target is not a COFF binary. (copy_object): Call check_new_section_flags. (setup_section): Likewise. * doc/binutils.texi (objcopy): Add a note that the 'share' section flag cannot be applied to ELF binaries. bfd * elf.c (_bfd_elf_set_section_contents): Replace call to abort with error messages and failure return values.
2020-03-06x86: reduce amount of various VCVT* templatesJan Beulich5-242/+116
Presumably as a result of various changes over the last several months, and - for some of them - with a generalization of logic in match_mem_size() plus mirroring of this generalization into the broadcast handling logic of check_VecOperands(), various register-only templates can be foled into their respective memory forms. This in particular then also allows dropping a few more instances of IgnoreSize.
2020-03-06x86: drop/replace IgnoreSizeJan Beulich5-1607/+1624
Even after commit dc2be329b950 ("i386: Only check suffix in instruction mnemonic"), by which many of its uses have become unnecessary (some were unnecessary even before), IgnoreSize is still used for various slightly different purposes: - to suppress emission of an operand size prefix, - in Intel syntax mode to zap "derived" suffixes in certain cases and to skip certain checks of remaining "derived" suffixes, - to suppress ambiguous operand size / missing suffix diagnostics, - for prefixes to suppress the "stand-alone ... prefix" warning. Drop entirely unnecessary ones and where possible also replace instances by the more focused (because of having just a single purpose) NoRex64. To further restrict when IgnoreSize is needed, also generalize the logic when to skip a template because of a present or derived L or Q suffix, by skipping immediate operands. Additionally consider mask registers and VecSIB there. Note that for the time being the attribute needs to be kept in place on MMX/SSE/etc insns (but not on VEX/EVEX encoded ones unless an operand template of them allows for only non-SIMD-register actuals) allowing for Dword operands - the logic when to emit a data size prefix would need further adjustment first. Note also that the memory forms of {,v}pinsrw get their permission for an L or Q suffix dropped. I can only assume that it being this way was a cut-and-paste mistake from the register forms, as the latter specifically have NoRex64 set, and the {,v}pextrw counterparts don't allow these suffixes either. Convert VexW= again to their respective VexW* on lines touched anyway.
2020-03-06x86: fold (supposed to be) identical codeJan Beulich2-27/+20
The Q and L suffix exclusion checks in match_template() ought to be (kept) in sync as far as their FPU and SIMD aspects go. This was already violated by only the Q one checking for active broadcast. Convert the code such that there'll be only one instance of the logic, the more that subsequently the logic is liable to need further refinement / extension. (The alternative would be to drop all SIMD-ness from the L part, but it is in principle possible to enable all sorts of SIMD support with just a pre-386 CPU, via suitable .arch directives.)
2020-03-06x86: don't accept FI{LD,STP,STTP}LL in Intel syntax modeJan Beulich3-9/+14
As of commit dc2be329b950 ("i386: Only check suffix in instruction mnemonic") these have been accepted even with "qword ptr" operand size specifier, but in 64-bit mode they're now wrongly having a REX prefix (with REX.W set) emitted in this case. These aren't Intel syntax mnemonics, so rather than fixing code generation, let's simply reject them. As a result, the Qword attribute can then be dropped, too.
2020-03-06x86: replace NoRex64 on VEX-encoded insnsJan Beulich11-100/+126
When the template specifies any of the possible VexW settings, we can use this instead of a separate NoRex64 to suppress the setting of REX_W. Note that this ends up addressing an inconsistency between VEX- and EVEX-encoded VEXTRACTPS, VPEXTR{B,W}, and VPINSR{B,W} - while the former avoided setting VEX.W, the latter pointlessly set EVEX.W when there is a 64-bit GPR operand. Adjust the testcase to cover both cases. Convert VexW= to their respective VexW* on lines touched anyway.
2020-03-06x86: drop Rex64 attributeJan Beulich7-6601/+6613
It is almost entirely redundant with Size64, and the sole case (CRC32) where direct replacement isn't possible can easily be taken care of in another way.
2020-03-06x86: correct MPX insn w/o base or index encoding in 16-bit modeJan Beulich7-4/+201
Since 16-bit addressing isn't allowed, Disp32 needs to be forced; Disp16 fails to match the templates. The SDM leaves open whether BNDC[LNU] with a GPR operand require an operand size override; this aspect is therefore left untouched here.
2020-03-06x86: add missing IgnoreSizeJan Beulich34-58/+330
For proper code generation in 16-bit mode (or to avoid the "same type of prefix used twice" diagnostic there), IgnoreSize is needed on certain templates allowing for just 32-(and maybe 64-)bit operands. Beyond adding tests for the previously broken cases, also add ones for the previously working cases where IgnoreSize is needed for the same reason (leaving out MPX for now, as that'll require an assembler change first). Some minor adjustments to tests get done such that re-use of the same code for 16-bit code generation testing becomes easier.
2020-03-06x86: refine TPAUSE and UMWAITJan Beulich11-26/+118
Allowing 64-bit registers is misleading here: Elsewhere these get allowed when there's no difference between either variant, because of 32-bit destination registers having their upper halves zeroed in 64-bit mode. Here, however, they're source registers, and hence specifying 64-bit registers would lead to the ambiguity of whether the upper 32 bits actually matter. Additionally, for proper code generation in 16-bit mode, IgnoreSize is needed on both. And finally, just like for e.g. MONITOR/MWAIT, add variants with all input registers explicitly specified.
2020-03-05bfd: xtensa: fix PR ld/25630Max Filippov2-4/+8
bfd/ 2020-03-05 Max Filippov <jcmvbkbc@gmail.com> * elf32-xtensa.c (shrink_dynamic_reloc_sections): Shrink dynamic relocation sections for any removed reference to a dynamic symbol.
2020-03-06PR25637, objcopy : SIGSEGV in copy_objectAlan Modra2-6/+12
PR 25637 * objcopy.c (filter_symbols): Correct rem_leading_char logic.
2020-03-06Automatic date update in version.inGDB Administrator1-1/+1
2020-03-05Use std::string for 'psargs'.John Baldwin2-5/+10
fbsd_make_corefile_notes leaked the memory for psargs previously. gdb/ChangeLog: * fbsd-tdep.c (fbsd_make_corefile_notes): Use std::string for psargs.
2020-03-05gdbsupport/configure.ac: source development.shVyacheslav Petrishchev3-0/+11
[Commit message by Simon Marchi] The GDB build in non-development mode (turn development to false in bfd/development.sh if you want to try) is currently broken: CXXLD gdb /home/smarchi/src/binutils-gdb/gdb/disasm-selftests.c:218: error: undefined reference to 'selftests::register_test_foreach_arch(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, void (*)(gdbarch*))' /home/smarchi/src/binutils-gdb/gdb/disasm-selftests.c:220: error: undefined reference to 'selftests::register_test_foreach_arch(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, void (*)(gdbarch*))' /home/smarchi/src/binutils-gdb/gdb/dwarf2/frame.c:2310: error: undefined reference to 'selftests::register_test_foreach_arch(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, void (*)(gdbarch*))' /home/smarchi/src/binutils-gdb/gdb/gdbarch-selftests.c:168: error: undefined reference to 'selftests::register_test_foreach_arch(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, void (*)(gdbarch*))' /home/smarchi/src/binutils-gdb/gdbsupport/selftest.cc:96: error: undefined reference to 'selftests::reset()' This is because the gdbsupport configure script doesn't source bfd/development.sh to set the development variable. When $development is unset, GDB_AC_SELFTEST defaults to enabling selftests. I don't think the macro was written with this intention in mind, it just happens to be that way. So gdbsupport thinks selftests are enabled, while gdb thinks they are disabled. gdbsupport compiles in code that calls selftests:: functions, which are normally provided by gdb, but gdb doesn't provide them, hence the undefined references. Fix this by sourcing bfd/development.sh in gdbsupport/configure.ac, so that the development variable is set. gdbsupport/ChangeLog: * configure.ac: Added call development.sh. * configure: Regenerate.
2020-03-05Add support for ELF files which contain multiple reloc sections which all ↵Nick Clifton7-13/+465
target the same section. * elf-bfd.h (struct elf_backend_data): Add new fields: init_secondary_reloc_section, slurp_secondary_reloc_section, write_secondary_reloc_section. (_bfd_elf_init_secondary_reloc_section): Prototype. (_bfd_elf_slurp_secondary_reloc_section): Prototype. (_bfd_elf_write_secondary_reloc_section): Prototype. * elf.c ( bfd_section_from_shdr): Invoke the new init_secondary_reloc_section backend function, if defined, when a second reloc section is encountered. (swap_out_syms): Invoke the new symbol_section_index function, if defined, when computing the section index of an OS/PROC specific symbol. (_bfd_elf_init_secondary_reloc_section): New function. (_bfd_elf_slurp_secondary_reloc_section): New function. (_bfd_elf_write_secondary_reloc_section): New function. (_bfd_elf_copy_special_section_fields): New function. * elfcode.h (elf_write_relocs): Invoke the new write_secondary_relocs function, if defined, in order to emit secondary relocs. (elf_slurp_reloc_table): Invoke the new slurp_secondary_relocs function, if defined, in order to read in secondary relocs. * elfxx-target.h (elf_backend_copy_special_section_fields): Provide a non-NULL default definition. (elf_backend_init_secondary_reloc_section): Likewise. (elf_backend_slurp_secondary_reloc_section): Likewise. (elf_backend_write_secondary_reloc_section): Likewise. (struct elf_backend_data elfNN_bed): Add initialisers for the new fields. * configure.ac (score_elf32_[bl]e_vec): Add elf64.lo * configure: Regenerate.
2020-03-05gdb, gdbserver, gdbsupport: add .gitattributes filesTankut Baris Aktemur6-0/+31
Create .gitattributes files in gdb/, gdbserver/, and gdbsupport/. The files specify cpp-style diffs for .h and .c files. This is particularly helpful if a class in a header file is modified. For instance, if the `stop_requested` field of `thread_info` in gdb/gdbthread.h is modified, we get the following diff with 'git diff' (using git version 2.17.1): @@ -379,7 +379,7 @@ public: struct target_waitstatus pending_follow; /* True if this thread has been explicitly requested to stop. */ - int stop_requested = 0; + bool stop_requested = 0; /* The initiating frame of a nexting operation, used for deciding which exceptions to intercept. If it is null_frame_id no Note that the context of the change shows up as 'public:'; not so useful. With the .gitattributes file, we get: @@ -379,7 +379,7 @@ class thread_info : public refcounted_object struct target_waitstatus pending_follow; /* True if this thread has been explicitly requested to stop. */ - int stop_requested = 0; + bool stop_requested = 0; /* The initiating frame of a nexting operation, used for deciding which exceptions to intercept. If it is null_frame_id no The context is successfully shown as 'class thread_info'. This patch creates a .gitattributes file per each of gdb, gdbserver, and gdbsupport folders. An alternative would be to define the attributes in the root folder -- this would impact all the top-level folders, though. I opted for the more conservative approach. gdb/ChangeLog: 2020-03-05 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * .gitattributes: New file. gdbserver/ChangeLog: 2020-03-05 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * .gitattributes: New file. gdbsupport/ChangeLog: 2020-03-05 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * .gitattributes: New file.