aboutsummaryrefslogtreecommitdiff
path: root/gdb
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-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-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-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-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-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 Burgess2-0/+9
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-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-05gdb, gdbserver, gdbsupport: add .gitattributes filesTankut Baris Aktemur2-0/+11
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.
2020-03-05[gdb/testsuite] Update maint.exp for string cacheTom de Vries2-1/+5
When running gdb.base/maint.exp, I see: ... FAIL: gdb.base/maint.exp: maint print statistics ... This is due to commit be1e3d3eab "Introduce objfile::intern", which replaces the macro and filename caches with a string cache. Update maint.exp accordingly. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-03-05 Tom de Vries <tdevries@suse.de> * gdb.base/maint.exp: Update "main print statistics" expected output.
2020-03-04Introduce objfile::internTom Tromey8-52/+64
This introduces a string cache on the per-BFD object, replacing the macro and filename caches. Both of these caches just store strings, so this consolidation by itself saves a little memory (about the size of a bcache per objfile). Then this patch switches some allocations on the objfile obstack to use this bcache instead. This saves more space; and turns out to be a bit faster as well. Here are the before and after "maint time" + "maint space" results of "file ./gdb": Command execution time: 4.664021 (cpu), 4.728518 (wall) Space used: 39190528 (+29212672 for this command) Command execution time: 4.216209 (cpu), 4.107023 (wall) Space used: 36667392 (+26689536 for this command) The main interface to the string cache is a new pair of overloaded methods, objfile::intern. gdb/ChangeLog 2020-03-04 Tom Tromey <tom@tromey.com> * symmisc.c (print_symbol_bcache_statistics) (print_objfile_statistics): Update. * symfile.c (allocate_symtab): Use intern. * psymtab.c (partial_symtab::partial_symtab): Use intern. * objfiles.h (struct objfile_per_bfd_storage) <filename_cache, macro_cache>: Remove. <string_cache>: New member. (struct objfile) <intern>: New methods. * elfread.c (elf_symtab_read): Use intern. * dwarf2/read.c (fixup_go_packaging): Intern package name. (dwarf2_compute_name, dwarf2_physname) (create_dwo_unit_in_dwp_v1, create_dwo_unit_in_dwp_v2): Intern names. (guess_partial_die_structure_name): Update. (partial_die_info::fixup): Intern name. (dwarf2_canonicalize_name): Change parameter to objfile. Intern name. (dwarf2_name): Intern name. Update. * buildsym.c (buildsym_compunit::get_macro_table): Use string_cache.
2020-03-04Make "gnutarget" constTom Tromey4-3/+10
I noticed that gnutarget was not "const". Since writing through this pointer would probably be a bug, I think it ought to be. This patch makes the change. gdb/ChangeLog 2020-03-04 Tom Tromey <tom@tromey.com> * jit.c (bfd_open_from_target_memory): Make "target" const. * corefile.c (gnutarget): Now const. * gdbcore.h (gnutarget): Now const.
2020-03-04Implement debugging of WOW64 processesHannes Domani7-100/+463
For WOW64 processes, the Wow64* variants of SuspendThread, GetThreadContext, SetThreadContext, and GetThreadSelectorEntry have to be used instead. And instead of EnumProcessModules, EnumProcessModulesEx with LIST_MODULES_32BIT is necessary. gdb/ChangeLog: 2020-03-04 Hannes Domani <ssbssa@yahoo.de> * NEWS: Mention support for WOW64 processes. * amd64-windows-nat.c (amd64_mappings): Rename and remove static. (amd64_windows_segment_register_p): Remove static. (_initialize_amd64_windows_nat): Update. * configure.nat <windows> (NATDEPFILES): Add i386-windows-nat.o. * i386-windows-nat.c (context_offset): Update. (i386_mappings): Rename and remove static. (i386_windows_segment_register_p): Remove static. (_initialize_i386_windows_nat): Update. * windows-nat.c (STATUS_WX86_BREAKPOINT): New macro. (STATUS_WX86_SINGLE_STEP): New macro. (EnumProcessModulesEx): New macro. (Wow64SuspendThread): New macro. (Wow64GetThreadContext): New macro. (Wow64SetThreadContext): New macro. (Wow64GetThreadSelectorEntry): New macro. (windows_set_context_register_offsets): Add static. (windows_set_segment_register_p): Likewise. (windows_add_thread): Adapt for WOW64 processes. (windows_fetch_one_register): Likewise. (windows_nat_target::fetch_registers): Likewise. (windows_store_one_register): Likewise. (display_selector): Likewise. (display_selectors): Likewise. (handle_exception): Likewise. (windows_continue): Likewise. (windows_nat_target::resume): Likewise. (windows_add_all_dlls): Likewise. (do_initial_windows_stuff): Likewise. (windows_nat_target::attach): Likewise. (windows_get_exec_module_filename): Likewise. (windows_nat_target::create_inferior): Likewise. (windows_xfer_siginfo): Likewise. (_initialize_loadable): Initialize Wow64SuspendThread, Wow64GetThreadContext, Wow64SetThreadContext, Wow64GetThreadSelectorEntry and EnumProcessModulesEx. * windows-nat.h (windows_set_context_register_offsets): Remove declaration. (windows_set_segment_register_p): Likewise. (i386_windows_segment_register_p): Add declaration. (amd64_windows_segment_register_p): Likewise.
2020-03-04Revert "gdb: Do not print empty-group regs when printing general ones"Luis Machado2-8/+19
Revert the change since it breaks existing behavior of "info registers" for some architectures. At least AArch64 and ARM are impacted by this change. gdb/ChangeLog: 2020-03-04 Luis Machado <luis.machado@linaro.org> Revert aa66aac47b4dd38f9524ddb5546c08cc09930d37 due to regressions in "info registers" for AArch64/ARM. The change caused "info registers" to not print GPR's. gdb/ChangeLog: 2020-02-01 Shahab Vahedi <shahab@synopsys.com> * target-descriptions.c (tdesc_register_in_reggroup_p): Return 0 when reg->group is empty and reggroup is not.
2020-03-04[gdb/doc] Remove trailing done from "Reading symbols from" linesTom de Vries3-4/+9
Since commit 3453e7e409 'Clean up "Reading symbols" output' we no longer print "done." after the "Reading symbols from" message: ... $ gdb -q a.out Reading symbols from a.out... (gdb) ... Update docs accordingly. Build on x86_64-linux. gdb/doc/ChangeLog: 2020-03-04 Tom de Vries <tdevries@suse.de> * gdb.texinfo: Remove trailing "done." in "Reading symbols from" lines. * python.texi: Same.
2020-03-04gdb.fortran: Allow Flang kind printing in fortran testingAlok Kumar Sharma2-14/+31
In lib/fortran.exp, in the helper function fortran_int4, kind parameter is expected to be printed as (kind=4) for the LLVM Fortran compiler, Flang along with gfortran. And in the helper function fortran_int8 kind parameter is expected to be printed as (kind=8). But for the Flang compiler default kind is not printed and non default kind is printed differently than gfortran as below. integer(kind=4) => integer integer(kind=8) => integer*8 real(kind=4) => real real(kind=8) => double precision complex(kind=4) => complex logical(kind=4) => logical character(kind=1) => character This commit adds support for printing of kind parameter for the Flang. There should be no change when testing with gfortran. Note: The current patch overrides earlier patch with below details. commit c3b149eb7697b376df1b3a47d0102afda389ee6d Author Alok Kumar Sharma (alokkumar.sharma@amd.com) Earlier patch was incomplete and based on assumption that flang should be changed to dump a type with kind like the way gfortan does. Later it was realized that the way flang dumps this info is not incorrect but different. And changes in gdb test framework are finalized. gdb/testsuite/ChangeLog: * lib/fortran.exp (fortran_int4): Handle flang kind printing. (fortran_int8): Likewise. (fortran_real4): Likewise. (fortran_real8): Likewise. (fortran_complex4): Likewise. (fortran_logical4): Likewise. (fortran_character1): Likewise.
2020-03-03Find tailcall frames before inline framesTom Tromey3-32/+47
A customer reported a failure to unwind in a certain core dump. A lengthy investigation showed that the problem came from the interaction between the tailcall and inline frame sniffers. Normally, the regular DWARF unwinder may discover a chain of tail calls ending in the current frame. In this case, it sets a member on the dwarf2_frame_cache object, so that a subsequent call into the tailcall sniffer will create the tailcall frames. However, in this scenario, what happened is that the DWARF unwinder did find tailcall frames -- but then the PC of the first such frame was recognized and claimed by the inline frame sniffer. This then caused unwinding to go astray further up the stack. This patch fixes the problem by arranging for the tailcall sniffer to be called before the inline sniffer. This way, if a DWARF frame has tailcall information, the tailcalls will always be processed first. This is safe to do, because the tailcall sniffer can only claim a frame if the previous frame did in fact find this information. (So, for example, if no DWARF frame is ever found, then this sniffer will never trigger.) This patch also partially reverts: commit 1ec56e88aa9b052ab10b806d82fbdbc8d153d977 Author: Pedro Alves <palves@redhat.com> Date: Fri Nov 22 13:17:46 2013 +0000 Eliminate dwarf2_frame_cache recursion, don't unwind from the dwarf2 sniffer (move dwarf2_tailcall_sniffer_first elsewhere). That patch moved the call to dwarf2_tailcall_sniffer_first out of dwarf2_frame_cache, and into dwarf2_frame_prev_register. However, in this situation, this is too late -- by the time dwarf2_frame_prev_register is called, the frame in question is already recognized by the inline frame sniffer. Rather than fully revert that patch, though, this just arranges to call dwarf2_tailcall_sniffer_first from dwarf2_frame_cache -- which is called shortly after the DWARF frame sniffer succeeds, via compute_frame_id. I don't know how to write a test case for this. gdb/ChangeLog 2020-03-03 Tom Tromey <tromey@adacore.com> * dwarf2/frame.c (struct dwarf2_frame_cache) <checked_tailcall_bottom, entry_cfa_sp_offset, entry_cfa_sp_offset_p>: Remove members. (dwarf2_frame_cache): Call dwarf2_tailcall_sniffer_first. (dwarf2_frame_prev_register): Don't call dwarf2_tailcall_sniffer_first. (dwarf2_append_unwinders): Don't append tailcall unwinder. * frame-unwind.c (add_unwinder): New fuction. (frame_unwind_init): Use it. Add tailcall unwinder.
2020-03-03gdb/fortran: Fix printing of logical true values for FlangAndrew Burgess4-1/+53
GDB is not able to print logical true values for Flang compiler. Actual result: (gdb) p l $1 = 4294967295 Expected result: (gdb) p l $1 = .TRUE. This is due to GDB expecting representation of true value being 1. The Fortran standard doesnt specify how LOGICAL types are represented. Different compilers use different non-zero values to represent logical true. The gfortran compiler uses 1 to represent logical true and the flang compiler uses -1. GDB should accept all the non-zero values as true. This is achieved by handling TYPE_CODE_BOOL in f_val_print and printing any non-zero value as true. gdb/ChangeLog: * f-valprint.c (f_val_print): Handle TYPE_CODE_BOOL, any non-zero value should be printed as true. gdb/testsuite/ChangeLog: * gdb.fortran/logical.exp: Add tests that any non-zero value is printed as true.
2020-03-03Rebase executable to match relocated base addressHannes Domani2-1/+59
Windows executables linked with -dynamicbase get a new base address when loaded, which makes debugging impossible if the executable isn't also rebased in gdb. The new base address is read from the Process Environment Block. gdb/ChangeLog: 2020-03-03 Hannes Domani <ssbssa@yahoo.de> * windows-tdep.c (windows_solib_create_inferior_hook): New function. (windows_init_abi): Set and use windows_so_ops.
2020-03-03Fix printf of a convenience variable holding an inferior addressSergio Durigan Junior4-1/+20
Back at: commit 1f6f6e21fa86dc3411a6498608f32e9eb24b7851 Author: Philippe Waroquiers <philippe.waroquiers@skynet.be> Date: Mon Jun 10 21:41:51 2019 +0200 Ensure GDB printf command can print convenience var strings without a target. GDB was extended in order to allow the printing of convenience variables that are strings without a target. However, this introduced a regression that hasn't been caught by our testsuite (because there were no tests for it). The problem happens when we try to print a convenience variable that holds the address of a string in the inferior. The following two-liners can reproduce the issue: $ echo -e 'int main(){const char a[]="test";return 0;}' | gcc -x c - -O0-g3 $ ./gdb/gdb --data-directory ./gdb/data-directory -q ./a.out -ex 'start' -ex 'set $x = (const char *) (&a[0] + 2)' -ex 'printf "%s\n", $x' After some investigation, I found that the problem happens on printcmd.c:printf_c_string. In the case above, we're taking the first branch of the 'if' condition, which assumes that there will be a value to be printed at "value_contents (value)". There isn't. We actually need to obtain the address that the variable points to, and read the contents from memory. It seems to me that we should avoid this branch if the TYPE_CODE of "value_type (value)" is TYPE_CODE_PTR (i.e., a pointer to the inferior's memory). This is what this patch does. I took the liberty to extend the current testcase under gdb.base/printcmds.exp and create a test that exercises this scenario. No regressions have been found on Buildbot. gdb/ChangeLog: 2020-03-03 Sergio Durigan Junior <sergiodj@redhat.com> * printcmd.c (print_c_string): Check also for TYPE_CODE_PTR when verifying if dealing with a convenience variable. gdb/testsuite/ChangeLog: 2020-03-03 Sergio Durigan Junior <sergiodj@redhat.com> * gdb.base/printcmds.exp: Add test to verify printf of a variable holding an address.
2020-03-03Update GDB to use new AUXV entry typesLuis Machado2-0/+16
I noticed GDB didn't know a particular AT tag (51) when doing some debugging. Turns out we're missing a few entries compared to glibc's headers. This patch adds them to GDB and fixes a failure in gdb.base/auxv.exp as a result. gdb/ChangeLog: 2020-03-03 Luis Machado <luis.machado@linaro.org> * auxv.c (default_print_auxv_entry): Add new AUXV entries.
2020-03-03[gdb/testsuite] Fix gdb.mi/gdb2549.exp with check-read1Tom de Vries2-3/+34
When running gdb.mi/gdb2549.exp with check-read1, we get: ... Running src/gdb/testsuite/gdb.mi/gdb2549.exp ... FAIL: gdb.mi/gdb2549.exp: register values t (timeout) ... The problem is that the command generates a lot of output, which is matched by a single '.*': ... mi_gdb_test "666-data-list-register-values t" \ "666\\^done,register-values=\\\[\{number=\"$decimal\",value=\"$binary\"\}.*\\\]" \ "register values t" ... Fix this by splitting up the matching and calling exp_continue after each number/value pair. Tested on x86_64-linux with make targets check and check-read1. gdb/testsuite/ChangeLog: 2020-03-03 Tom de Vries <tdevries@suse.de> * gdb.mi/gdb2549.exp: Fix "register values t" check-read1 timeout.
2020-03-03[gdb/testsuite] Fix tcl error in gdb.mi/list-thread-groups-available.expTom de Vries2-2/+9
When running gdb.mi/list-thread-groups-available.exp, we get: ... Running gdb.mi/list-thread-groups-available.exp ... ERROR: tcl error sourcing gdb.mi/list-thread-groups-available.exp. ERROR: Too many arguments to gdb_test_multiple ... The problem is that the gdb_test_multiple call has as last argument a $mi_gdb_prompt, which is no longer supported syntax since 590003dc0e "[gdb/testsuite] Add -lbl option in gdb_test_multiple". Fix this by using the new -prompt syntax. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-03-03 Tom de Vries <tdevries@suse.de> * gdb.mi/list-thread-groups-available.exp: Use -prompt syntax for gdb_test_multiple call.
2020-03-03[gdb/testsuite] Fix mi-sym-info.exp with check-read1Tom de Vries2-2/+9
When running gdb.mi/mi-sym-info.exp with check-read1, we run into: ... FAIL: gdb.mi/mi-sym-info.exp: List all functions FAIL: gdb.mi/mi-sym-info.exp: List all variables ... The problem is that while the $mi_gdb_prompt is active, gdb_test_multiple is used without -prompt "$mi_gdb_prompt$", so it defaults to matching $gdb_prompt. Fix this by adding the missing gdb_test_multiple arguments. Reg-tested on x86_64-linux with make targets check and check-read1. gdb/testsuite/ChangeLog: 2020-03-03 Tom de Vries <tdevries@suse.de> * gdb.mi/mi-sym-info.exp: Add missing -prompt "$mi_gdb_prompt$" to gdb_test_multiple calls.
2020-03-02Small clean up of use_displaced_steppingSimon Marchi2-13/+50
This function returns the result of a quite big condition. I think it would be more readeable if it was broken up in smaller pieces and commented. This is what this patch does. I also introduced gdbarch_supports_displaced_stepping, since it shows the intent better than checking for gdbarch_displaced_step_copy_insn_p. I also used that new function in displaced_step_prepare_throw. I also updated the comment on top of can_use_displaced_stepping, which seemed a bit outdated with respect to non-stop. The comment likely dates from before it was possible to have targets that always operate non-stop under the hood, even when the user-visible mode is all-stop. No functional changes intended. gdb/ChangeLog: * infrun.c (gdbarch_supports_displaced_stepping): New. (use_displaced_stepping): Break up conditions in smaller pieces. Use gdbarch_supports_displaced_stepping. (displaced_step_prepare_throw): Use gdbarch_supports_displaced_stepping.
2020-03-02gdb: Allow GDB to _not_ load a previous command historyAndrew Burgess9-15/+259
This commit aims to give a cleaner mechanism by which the user can prevent GDB from trying to load any previous command history. Currently the user can change the path to the history file, either using a command line flag, or by setting the GDBHISTFILE environment variable, and if the path is set to a non-existent file, then obviously GDB wont load any command history. However, this feels like a bit of a bodge, I'd like to add an official mechanism by which we can disable command history loading. Why would we want to prevent command history loading? The specific use case I have is GDB starting with a CWD that is a network mounted directory, and there is no command history present. Still GDB will access the network in order to check for the file. In my particular use case I'm actually starting a large number of GDB instances in parallel, all in the same network mounted directory, the large number of network accesses looking for this file introduces a noticeable delay at GDB startup. The approach I'm proposing here is a slight adjustment to the current rules for setting up the history filename. Currently, if a user does this, they see an error: (gdb) set history filename Argument required (filename to set it to.). However, if a user does this: $ GDBHISTFILE= gdb --quiet (gdb) set history save on (gdb) q warning: Could not rename -gdb18416~ to : No such file or directory So, we already have a bug in this area. My plan is to allow the empty filename to be accepted, and for this to mean, neither load, nor save the command history. This does mean that we now have two mechanisms to prevent saving the command history: (gdb) set history filename or (gdb) set history save off But the only way to prevent loading the command history is to set the filename to the empty string _before_ you get to a GDB prompt, either using a command line option, or the environment variable. I've updated some of the show commands, for example this session: (gdb) set history filename (gdb) show history filename There is no filename currently set for recording the command history in. (gdb) show history save Saving of the history record on exit is off. (gdb) set history save on (gdb) show history save Saving of the history is disabled due to the value of 'history filename'. (gdb) set history filename /tmp/hist (gdb) show history save Saving of the history record on exit is on. I've updated the manual, and added some tests. gdb/ChangeLog: * NEWS: Mention new behaviour of the history filename. * top.c (write_history_p): Add comment. (show_write_history_p): Add header comment, give a different message when history writing is on, but the history filename is empty. (history_filename): Add comment. (history_filename_empty): New function. (show_history_filename): Add header comment, give a different message when the filename is empty. (init_history): Compare history_filename against nullptr, and only read history if the filename is not empty. (set_history_filename): Add header comment, and only make non-empty filenames absolute. (init_main): Make the filename argument to 'set history filename' optional. gdb/doc/ChangeLog: * gdb.texinfo (Command History): Extend description for GDBHISTFILE and GDBHISTSIZE, add detail about the filename for 'set history filename' being optional. Describe the effect of an empty history filename on 'set history save on'. gdb/testsuite/ChangeLog: * gdb.base/default.exp: Remove test of 'set history filename'. * gdb.base/gdbinit-history.exp: Add tests for setting the history filename to the empty string. * lib/gdb.exp (gdb_init): Unset environment variables GDBHISTFILE and GDBHISTSIZE. Change-Id: Ia586e4311182fac99113b60f11ef8a11fbd5450b
2020-03-02Fix arm-netbsd build error: convert from FPA to VFPChristian Biesinger2-53/+79
The floating point register interface has changed to this: https://github.com/NetBSD/src/blob/trunk/sys/arch/arm/include/reg.h It now uses VFP instead of FPA registers. This patch updates arm-nbsd-nat.c accordingly. Also implements read_description so that these registers are correctly printed by "info registers" et al. Tested by compiling & running on arm-netbsd on qemu. gdb/ChangeLog: 2020-03-02 Christian Biesinger <cbiesinger@google.com> * arm-nbsd-nat.c (arm_supply_fparegset): Rename to... (arm_supply_vfpregset): ...this, and update to use VFP registers. (fetch_fp_register): Update. (fetch_fp_regs): Update. (store_fp_register): Update. (store_fp_regs): Update. (arm_netbsd_nat_target::read_description): New function. (fetch_elfcore_registers): Update.
2020-03-02gdb/remote: Restore support for 'S' stop reply packetAndrew Burgess5-45/+101
With this commit: commit 5b6d1e4fa4fc6827c7b3f0e99ff120dfa14d65d2 Date: Fri Jan 10 20:06:08 2020 +0000 Multi-target support There was a regression in GDB's support for older aspects of the remote protocol. Specifically, when a target sends the 'S' stop reply packet (which doesn't include a thread-id) then GDB has to figure out which thread actually stopped. Before the above commit GDB figured this out by using inferior_ptid in process_stop_reply, which contained the ptid of the current process/thread. This would be fine for single threaded targets (which is the only place using an S packet makes sense), but in the general case, relying on inferior_ptid for processing a stop is wrong - there's no reason to believe that what was GDB's current thread will be the same thread that just stopped in the target. With the above commit the inferior_ptid now has the value null_ptid inside process_stop_reply, this can be seen in do_target_wait, where we call switch_to_inferior_no_thread before calling do_target_wait_1. The problem this causes can be seen in the new test that runs gdbserver using the flag --disable-packet=T, and causes GDB to throw this assertion: inferior.c:279: internal-error: inferior* find_inferior_pid(process_stratum_target*, int): Assertion `pid != 0' failed. A similar problem was fixed in this commit: commit 3cada74087687907311b52781354ff551e10a0ed Date: Thu Jan 11 00:23:04 2018 +0000 Fix backwards compatibility with old GDBservers (PR remote/22597) However, this commit deals with the case where the T packet doesn't include a thread-id, not the S packet case. This commit solves the problem providing a thread-id at the GDB side if the remote target doesn't provide one. The thread-id provided comes from remote_state::general_thread, however, though this does work, I don't think it is the ideal solution. The remote_state tracks two threads, the continue_thread and the general_thread, these are updated when GDB asks the remote target to switch threads. The general_thread is set before performing things like register or memory accesses, and the continue_thread is set before things like continue or step commands. Further, the general_thread is updated after a target stops to reference the thread that stopped. The first thing to note from the above description is that we have a cycle of dependency, when a T packet arrives without a thread-id we fill in the thread-id from the general_thread data. The thread-id from the stop event is then used to set the general_thread. This in itself feels a little weird. The second question is why use the general_thread at all? You'd think given how they are originally set that the continue thread would be a better choice. The problem with this is that the continue_thread, if the user just does "continue", will be set to the minus_one_ptid, in the remote protocol this means all threads. When the stop arrives with no thread-id and we use continue_thread we end up with a very similar assertion to before because we now end up trying to lookup a thread using the minus_one_ptid. By contrast, once GDB has connected to a remote target the general_thread will be set to a valid thread-id, after which, if the target is single threaded, and stop events arrive without a thread-id, everything works fine. There is one slight weirdness with the above behaviour though. When GDB first connects to the remote target inferior_ptid is null_ptid, however, upon connecting we query the remote for its threads. As the thread information arrives GDB adds the threads to its internal database, and this process involves setting inferior_ptid to the id of each new thread in turn. Once we know about all the threads we wait for a stop event from the remote target to indicate that GDB is now in control of the target. The problem is that after adding the new threads we don't reset inferior_ptid, and the code path we use to wait for a stop event from the target also doesn't reset inferior_ptid, so it turns out that during the initial connection inferior_ptid is not null_ptid. This is lucky, because during the initial connection the general_thread variable _is_ set to null_ptid. So, during the initial connection, if the first stop event is missing a thread-id then we "provide" a thead-id from general_thread. This turns out to be null_ptid meaning no thread-id is known, and then during process_stop_reply we fill in the missing thread-id using inferior_ptid. This was all discussed on the mailing list here: https://sourceware.org/ml/gdb-patches/2020-02/msg01011.html My proposal for a fix then is: 1. Move the call to switch_to_inferior_no_thread into do_target_wait_1, this means that in all cases where we are waiting for an inferior the inferior_ptid will be set to null_ptid. This is good as no wait code should rely on inferior_ptid. 2. Remove the use of general_thread from the 'T' packet processing. The general_thread read here was only ever correct by chance, and we shouldn't be using it this way. 3. Remove use of inferior_ptid from process_stop_event as this is wrong, and will always be null_ptid now anyway. 4. When a stop_event has null_ptid due to a lack of thread-id (either from a T packet or an S packet) then pick the first non exited thread in the target and use that. This will be fine for single threaded targets. A multi-thread or multi-inferior aware remote target should be using T packets with a thread-id, so we give a warning if the target is multi-threaded, and we are still missing a thread-id. 5. Extend the existing test that covered the T packet with missing thread-id to also cover the S packet. gdb/ChangeLog: * remote.c (remote_target::remote_parse_stop_reply): Don't use the general_thread if the stop reply is missing a thread-id. (remote_target::process_stop_reply): Use the first non-exited thread if the target didn't pass a thread-id. * infrun.c (do_target_wait): Move call to switch_to_inferior_no_thread to .... (do_target_wait_1): ... here. gdb/testsuite/ChangeLog: * gdb.server/stop-reply-no-thread.exp: Add test where T packet is disabled.
2020-03-02[gdb/testsuite] Add -lbl option in gdb_test_multipleTom de Vries3-53/+83
Add gdb_test_multiple option -lbl, that adds a regexp after the user code that reads one line, and discards it: ... -re "\r\n\[^\r\n\]*(?=\r\n)" { exp_continue } ... In order to be able to write: ... gdb_test_multiple "command" "testname" -lbl { ... } ... rewrite the promp_regexp argument usage into the similar: ... gdb_test_multiple "command" "testname" -prompt $prompt_regexp { ... } ... Build and reg-tested on x86_64-linux. Tested gdb.base/corefile-buildid.exp with both make targets check and check-read1. gdb/testsuite/ChangeLog: 2020-03-02 Pedro Alves <palves@redhat.com> Tom de Vries <tdevries@suse.de> * lib/gdb.exp (gdb_test_multiple): Handle prompt_regexp option using -prompt prefix, before user_code argument. Add -lbl option likewise. (skip_python_tests_prompt, skip_libstdcxx_probe_tests_prompt) (gdb_is_target_1): Add -prompt prefix and move to before user_code argument. * gdb.base/corefile-buildid.exp: Use -lbl option. Rewrite regexps to have "\r\n" at start-of-line, instead of at end-of-line.
2020-03-02gdb: Move defs.h before any system header in debuginfod-support.cJon Turney2-1/+5
* defs.h includes config.h * config.h may define _GNU_SOURCE * if _GNU_SOURCE is defined, that must be before including any system header (see feature_test_macro(7)) This is necessary to ensure that a prototype for mkostemp() is brought into scope by <stdlib.h> when compiling filestuff.h, on platforms where _GNU_SOURCE isn't unconditionally defined for C++. In file included from ../../gdb/../gdbsupport/scoped_fd.h:24, from ../../gdb/debuginfod-support.c:22: ../../gdb/../gdbsupport/filestuff.h: In function ‘int gdb_mkostemp_cloexec(char*, int)’: ../../gdb/../gdbsupport/filestuff.h:59:10: error: ‘mkostemp’ was not declared in this scope; did you mean ‘mkstemp’? gdb/ChangeLog: 2020-02-29 Jon Turney <jon.turney@dronecode.org.uk> * debuginfod-support.c: Include defs.h first.
2020-02-28Update libinproctrace.so path in lib/trace-support.expSimon Marchi2-1/+6
Following the move to gdbserver to the top-level, the path to libinproctrace.so in testsuite/lib/trace-support.exp is no longer valid. This can be observed by running: $ make check TESTS="gdb.trace/ftrace.exp" RUNTESTFLAGS="--target_board=native-gdbserver" ... ERROR: error copying "/home/smarchi/build/binutils-gdb/gdb/testsuite/../gdbserver/libinproctrace.so": no such file or directory Adjust the path to libinproctrace.so by adding a "..". With this patch, the test mentioned above runs fine. gdb/testsuite/ChangeLog: * lib/trace-support.exp (get_in_proc_agent): Adjust path to libinproctrace.so.
2020-02-28Fix SVE-related failure in gdb.arch/aarch64-fp.expLuis Machado2-6/+11
The gdb.arch/aarch64-fp.exp test assumes it is dealing with a regular SIMD target that exposes the V registers as raw registers. SVE-enabled targets turn the V registers into pseudo-registers. That is all fine, but the testcase uses the "info registers" command, which prints pseudo-register's contents twice. One for the hex format and another for the natural format of the type. (gdb) info registers v0 v0 {d = {f = {0x0, 0x0}, u = {0x1716151413121110, 0x1f1e1d1c1b1a1918}, s = {0x1716151413121110, 0x1f1e1d1c1b1a1918}}, s = {f = {0x0, 0x0, 0x0, 0x0}, u = {0x13121110, 0x17161514, 0x1b1a1918, 0x1f1e1d1c}, s = {0x13121110, 0x17161514, 0x1b1a1918, 0x1f1e1d1c}}, h = {f = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u = {0x1110, 0x1312, 0x1514, 0x1716, 0x1918, 0x1b1a, 0x1d1c, 0x1f1e}, s = {0x1110, 0x1312, 0x1514, 0x1716, 0x1918, 0x1b1a, 0x1d1c, 0x1f1e}}, b = {u = {0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f}, s = {0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f}}, q = {u = {0x1f1e1d1c1b1a19181716151413121110}, s = {0x1f1e1d1c1b1a19181716151413121110}}} {d = {f = {1.846323925681849e-197, 8.5677456166123577e-159}, u = {1663540288323457296, 2242261671028070680}, s = {1663540288323457296, 2242261671028070680}}, s = {f = {1.84362032e-27, 4.84942184e-25, 1.27466897e-22, 3.34818801e-20}, u = {319951120, 387323156, 454695192, 522067228}, s = {319951120, 387323156, 454695192, 522067228}}, h = {f = {0.00061798, 0.00086308, 0.0012398, 0.00173, 0.0024872, 0.0034676, 0.0049896, 0.0069504}, u = {4368, 4882, 5396, 5910, 6424, 6938, 7452, 7966}, s = {4368, 4882, 5396, 5910, 6424, 6938, 7452, 7966}}, b = {u = {16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31}, s = {16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31}}, q = {u = {41362427191743139026751447860679676176}, s = {41362427191743139026751447860679676176}}} (gdb) p/x $v0 $1 = {d = {f = {0x0, 0x0}, u = {0x1716151413121110, 0x1f1e1d1c1b1a1918}, s = {0x1716151413121110, 0x1f1e1d1c1b1a1918}}, s = {f = {0x0, 0x0, 0x0, 0x0}, u = {0x13121110, 0x17161514, 0x1b1a1918, 0x1f1e1d1c}, s = {0x13121110, 0x17161514, 0x1b1a1918, 0x1f1e1d1c}}, h = {f = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u = {0x1110, 0x1312, 0x1514, 0x1716, 0x1918, 0x1b1a, 0x1d1c, 0x1f1e}, s = {0x1110, 0x1312, 0x1514, 0x1716, 0x1918, 0x1b1a, 0x1d1c, 0x1f1e}}, b = {u = {0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f}, s = {0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f}}, q = {u = {0x1f1e1d1c1b1a19181716151413121110}, s = {0x1f1e1d1c1b1a19181716151413121110}}} Since the testcase is not expecting that, we run into a couple failures: FAIL: gdb.arch/aarch64-fp.exp: check register v0 value FAIL: gdb.arch/aarch64-fp.exp: check register v1 value The following patch switches to using "p/x" for printing register values, which prints the values once with the hex format, instead of twice. gdb/testsuite/ChangeLog 2020-02-28 Luis Machado <luis.machado@linaro.org> * gdb.arch/aarch64-fp.exp: Switch from "info registers" command to "p/x".
2020-02-28Fix gdb.arch/aarch64-dbreg-contents.exp build failuresLuis Machado2-0/+9
I ran into the following failures when running tests under QEMU: -- gdb compile failed, binutils-gdb/gdb/testsuite/gdb.arch/aarch64-dbreg-contents.c: In function 'set_watchpoint': binutils-gdb/gdb/testsuite/gdb.arch/aarch64-dbreg-contents.c:41:29: error: storage size of 'dreg_state' isn't known struct user_hwdebug_state dreg_state; ^~~~~~~~~~ In file included from /usr/include/aarch64-linux-gnu/bits/types/struct_iovec.h:23:0, from /usr/include/aarch64-linux-gnu/sys/uio.h:23, from binutils-gdb/gdb/testsuite/gdb.arch/aarch64-dbreg-contents.c:17: binutils-gdb/gdb/testsuite/gdb.arch/aarch64-dbreg-contents.c:69:18: error: invalid use of undefined type 'struct user_hwdebug_state' iov.iov_len = (offsetof (struct user_hwdebug_state, dbg_regs) ^ binutils-gdb/gdb/testsuite/gdb.arch/aarch64-dbreg-contents.c:74:5: warning: implicit declaration of function 'error'; did you mean 'errno'? [-Wimplicit-function-declaration] error (1, errno, "PTRACE_SETREGSET: NT_ARM_HW_WATCH"); ^~~~~ errno binutils-gdb/gdb/testsuite/gdb.arch/aarch64-dbreg-contents.c: In function 'main': binutils-gdb/gdb/testsuite/gdb.arch/aarch64-dbreg-contents.c:87:3: warning: implicit declaration of function 'atexit'; did you mean '_Exit'? [-Wimplicit-function-declaration] atexit (cleanup); ^~~~~~ _Exit binutils-gdb/gdb/testsuite/gdb.arch/aarch64-dbreg-contents.c:89:11: warning: implicit declaration of function 'fork' [-Wimplicit-function-declaration] child = fork (); ^~~~ -- The following patch fixes those by adding the necessary include files. With that said, the test doesn't pass at present. I'll have to investigate it a bit more. gdb/testsuite/ChangeLog: 2020-02-28 Luis Machado <luis.machado@linaro.org> * gdb.arch/aarch64-dbreg-contents.c: Include stdlib.h, unistd, asm/ptrace.h and error.h.
2020-02-28[gdb] Don't set initial language using previous languageTom de Vries2-3/+10
When language is set to auto, part of loading an executable is to update the language accordingly. This is implemented by set_initial_language. In case of a c++ executable without DW_AT_main_subprogram, set_initial_language finds "main" in the minimal symbols, and does a lookup of "main" in the symbol tables to determine the language of the symbol, and uses that as initial language. The symbol lookup is done using lookup_symbol which is a wrapper around lookup_symbol_in_language, using the current language. So, consider two c++ executables a.out and b.out, which we'll load one after another. If we track the resulting lookup_symbol_in_language calls: ... $ gdb -batch \ -ex "b lookup_symbol_in_language" \ -ex r -ex c -ex c \ --args gdb ... we find that indeed lookup_symbol_in_language is called once using language_c, and once using language_c_plus: ... (gdb) file a.out Reading symbols from a.out... Breakpoint 1, lookup_symbol_in_language (name=0x5555568c2050 "main", \ block=0x0, domain=VAR_DOMAIN, lang=language_c, is_a_field_of_this=0x0) \ at ../../gdb/symtab.c:1905 1905 { (gdb) file b.out Load new symbol table from "b.out"? (y or n) y Reading symbols from b.out... Breakpoint 1, lookup_symbol_in_language (name=0x5555568c2030 "main", \ block=0x0, domain=VAR_DOMAIN, lang=language_cplus, is_a_field_of_this=0x0) \ at ../../gdb/symtab.c:1905 1905 { (gdb) ... It seems like a bad idea to have the previous language play a role in determining the executable language. Fix this by using lookup_symbol_in_language in set_initial_language with the default language c as argument. Tested on x86_64-linux. gdb/ChangeLog: 2020-02-28 Tom de Vries <tdevries@suse.de> * symfile.c (set_initial_language): Use default language for lookup.
2020-02-28Pass correct die_reader_specs in cutu_reader::init_tu_and_read_dwo_diesSimon Marchi2-2/+6
Running anything with the fission.exp board fails since commit c0ab21c22bb ("Replace init_cutu_and_read_dies with a class"). GDB crashes while reading the DWARF info. cu is NULL in read_signatured_type: Thread 1 "gdb" received signal SIGSEGV, Segmentation fault. 0x000055555780663e in read_signatured_type sig_type=0x6210000c3600) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:22782 22782 gdb_assert (cu->die_hash == NULL); (top-gdb) bt #0 0x000055555780663e in read_signatured_type (sig_type=0x6210000c3600) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:22782 #1 0x00005555578062dd in load_full_type_unit (per_cu=0x6210000c3600) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:22758 #2 0x00005555577c5fb7 in queue_and_load_dwo_tu (slot=0x60600007fc00, info=0x6210000c34e0) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:12674 #3 0x0000555559934232 in htab_traverse_noresize (htab=0x60b000063670, callback=0x5555577c5e61 <queue_and_load_dwo_tu(void**, void*)>, info=0x6210000c34e0) at /home/simark/src/binutils-gdb/libiberty/hashtab.c:775 #4 0x00005555577c6252 in queue_and_load_all_dwo_tus (per_cu=0x6210000c34e0) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:12701 #5 0x000055555777ebd8 in dw2_do_instantiate_symtab (per_cu=0x6210000c34e0, skip_partial=false) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:2371 #6 0x000055555777eea2 in dw2_instantiate_symtab (per_cu=0x6210000c34e0, skip_partial=false) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:2395 #7 0x0000555557786ab6 in dw2_lookup_symbol (objfile=0x614000007240, block_index=GLOBAL_BLOCK, name=0x602000025310 "main", domain=VAR_DOMAIN) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:3539 After creating the reader object, the reader.cu field should not be NULL. By checking the commit previous to the faulty one mentioned above, I noticed that the cu field is normally set by init_cu_die_reader, called from read_cutu_die_from_dwo, itself called from cutu_reader::init_tu_and_read_dwo_dies, itself called from cutu_reader's constructor. However, cutu_reader::init_tu_and_read_dwo_dies calls read_cutu_die_from_dwo, passing a pointer to a local `die_reader_specs` variable. So it's the `cu` field of that object that gets set. cutu_reader itself is a `die_reader_specs` (it inherits from it), and the intention was most likely to pass `this` to read_cutu_die_from_dwo. This way, the fields of the cutu_reader object, which read_signatured_type will use, are set. With this, I am able to use: make check RUNTESTFLAGS='--target_board=fission' and it looks much better. There are still some failures to be investigated, but that's the usual state of the testsuite. gdb/ChangeLog: * dwarf2/read.c (cutu_reader::init_tu_and_read_dwo_dies): Remove reader variable, pass `this` to read_cutu_die_from_dwo.
2020-02-28[gdb/testsuite] Fix psymtab expansion postponement in c-linkage-name.expTom de Vries4-26/+89
The test-case gdb.base/c-linkage-name.exp starts with the following test: ... gdb_test "print symada__cS" \ " = {a = 100829103}" \ "print symada__cS before partial symtab expansion" ... However, printing the state of the partial symtabs using maint info psymtabs shows that in fact the symtab has already been expanded: ... { psymtab c-linkage-name.c ((struct partial_symtab *) 0x1e27b40)^M readin yes^M ... This is due to set_initial_language, which looks up the main symbol, which expands the psymtab containing main. Fix this by moving all but main into a separate source file c-linkage-name-2.c. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-02-28 Tom de Vries <tdevries@suse.de> * gdb.base/c-linkage-name.c (main): Call do_something_other_cu. (struct wrapper, do_something, mundane/symada__cS): Move ... * gdb.base/c-linkage-name-2.c: ... here. New source file. * gdb.base/c-linkage-name.exp: Add verification of psymtab expansion. Update "print symada__cS before partial symtab expansion" regexp. Update breakpoint location. Flush symbol cache after expansion.
2020-02-28Harden gdb.arch/aarch64-pauth.exp and fix a failureLuis Machado2-1/+10
When running this testcase against a QEMU with PAC support, i noticed we were failing to recognize the additional [PAC] that is emitted in the backtrace, resulting in this failure: FAIL: gdb.arch/aarch64-pauth.exp: backtrace I've made the test use multi_line to make the pattern more clear. Tested against aarch64-linux-gnu with and without PAC support. gdb/testsuite/ChangeLog: 2020-02-28 Luis Machado <luis.machado@linaro.org> * gdb.arch/aarch64-pauth.exp: Recognize optional PAC output.
2020-02-27gdb: Check for nullptr when computing srcpathAaron Merey2-2/+7
This fixes a regression caused by commit 0d79cdc494d5: $ make check TESTS="gdb.dwarf2/dw2-ranges-base.exp" [...] ERROR: GDB process no longer exists This error is caused by an abort during the computation of srcpath when SYMTAB_DIRNAME (s) == NULL. Computing srcpath only when SYMTAB_DIRNAME (s) is not NULL fixes this error. Also change the condition for calling debuginfod_source_query to include whether srcpath could be computed. gdb/ChangeLog: 2020-02-27 Aaron Merey <amerey@redhat.com> * source.c (open_source_file): Check for nullptr when computing srcpath.
2020-02-27Remove field_info::nfields memberTom Tromey2-7/+15
I noticed that there's no real reason to have field_info::nfields in the DWARF reader. It simply mirrors information that is already available. This patch removes it, in favor of a convenience method. gdb/ChangeLog 2020-02-27 Tom Tromey <tromey@adacore.com> * dwarf2/read.c (struct field_info) <nfields>: Now a method, not a member. (dwarf2_add_field): Don't update nfields. (dwarf2_attach_fields_to_type, process_structure_scope): Update.
2020-02-27gdb: Use std::abs instead of abs on LONGEST typesAndrew Burgess2-2/+7
Use std::abs so that we get the C++ overloaded version that matches the argument type instead of the C abs function which is only for int arguments. There should be no user visible change after this commit. gdb/ChangeLog: * gdbtypes.c (create_array_type_with_stride): Use std::abs not abs.
2020-02-27[gdb/testsuite] Remove unused globalsTom de Vries8-25/+12
Remove unused global variable declarations. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-02-27 Tom de Vries <tdevries@suse.de> * config/sid.exp: Remove unused globals. * gdb.base/attach.exp: Same. * gdb.base/catch-load.exp: Same. * gdb.base/dbx.exp: Same. * lib/gdb.exp: Same. * lib/mi-support.exp: Same. * lib/prompt.exp: Same.
2020-02-27[gdb/testsuite] Fix spawn in tuiterm.expTom de Vries2-1/+10
When running gdb.stabs/weird.exp by itself it passes, but if we run a gdb.tui test before it, we get: ... $ make check RUNTESTFLAGS="gdb.stabs/weird.exp gdb.tui/basic.exp" Running /data/gdb_versions/devel/src/gdb/testsuite/gdb.tui/basic.exp ... Running /data/gdb_versions/devel/src/gdb/testsuite/gdb.stabs/weird.exp ... ERROR: Couldn't make test case. -1 {spawn failed} ... In more detail, using -v: ... Executing on build: sed -f aout.sed weird.def weird.s (timeout = 300) builtin_spawn [open ...]^M pid is 19060 19061 -19060 -19061 spawn -open file10 failed, 1 can't read "spawn_out(slave,name)": \ no such variable, can't read "spawn_out(slave,name)": no such variable while executing "set gdb_spawn_name $spawn_out(slave,name)" (procedure "spawn" line 5) invoked from within "spawn -ignore SIGHUP -leaveopen file10" invoked from within "catch "spawn -ignore SIGHUP -leaveopen $id" result2" ERROR: Couldn't make test case. -1 {spawn failed} ... When running the gdb.tui test, spawn gets renamed to a local version from lib/tuiterm.exp. The local version calls expect's spawn, and then makes the local spawn_out(slave,name) variable accessible in the global variable gdb_spawn_name. However, the weird.exp test-case uses remote_exec build, which ends up using local_exec, which given that there's input/output redirection uses open: ... set result [catch {open "| ${commandline} $inp |& tee $outpf" RDONLY} id] ... followed by spawn using the -leaveopen option: ... set result [catch "spawn -ignore SIGHUP -leaveopen $id" result2] ... which apparently has the effect that spawn_out(slave,name) is not set. Fix this in the lib/tuiterm.exp local spawn proc by detecting the case that spawn_out(slave,name) is not set, and handling it accordingly. Tested gdb.stabs/weird.exp and gdb.tui/*.exp on x86_64-linux. gdb/testsuite/ChangeLog: 2020-02-27 Tom de Vries <tdevries@suse.de> * lib/tuiterm.exp (spawn): Handle case that spawn_out(slave,name) is not set.
2020-02-26Specialize partial_symtab for DWARF include filesTom Tromey2-19/+49
Include files are represented by a partial symtab, but don't expand to anything. From dwarf2_psymtab::expand_psymtab: if (per_cu == NULL) { /* It's an include file, no symbols to read for it. Everything is in the parent symtab. */ readin = true; return; } This patch introduces a new specialization of partial_symtab to handle this case. In addition to being slightly smaller, I believe an include file is the only situation where a DWARF psymtab can result in a null compunit_symtab. This adds an assert to that effect as well. This change will simplify one of the psymtab sharing patches. gdb/ChangeLog 2020-02-26 Tom Tromey <tom@tromey.com> * dwarf2/read.c (struct dwarf2_include_psymtab): New. (dwarf2_create_include_psymtab): Use dwarf2_include_psymtab. (dwarf2_psymtab::expand_psymtab, dwarf2_psymtab::readin_p) (dwarf2_psymtab::get_compunit_symtab): Remove null checks for per_cu_data.
2020-02-26Remove casts from dwarf2/index-write.cTom Tromey2-13/+21
dwarf2/index-write.c casts pointers to "dwarf2_psymtab *", but as far as I can tell, it does not actually use any DWARF-specific fields of the psymtab. So, this patch changes this code to use partial_symtab instead. This removes nearly every cast, leaving just the unavoidable one from addrmap iteration. gdb/ChangeLog 2020-02-26 Tom Tromey <tom@tromey.com> * dwarf2/index-write.c (psym_index_map): Change type. (add_address_entry_worker, write_one_signatured_type) (recursively_count_psymbols, recursively_write_psymbols) (class debug_names, psyms_seen_size, write_gdbindex) (write_debug_names): Use partial_symtab, not dwarf2_psymtab.