aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2019-10-23infcall: refactor 'call_function_by_hand_dummy'Tankut Baris Aktemur2-25/+45
Extract out the code region that reserves stack space to a separate function. Fix the comment of 'call_function_by_hand_dummy' to remove reference to the NARGS argument that was removed in commit (e71585ffe2e "Use gdb:array_view in call_function_by_hand & friends"). gdb/ChangeLog: 2019-10-23 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * infcall.c (call_function_by_hand_dummy): Fix the function comment. And extract out a code section into... (reserve_stack_space): ...this new function. Change-Id: I8938ef4134aff68a0a21724aaa2406bfe453438a
2019-10-23infcall: remove unused parameter in 'value_arg_coerce'Tankut Baris Aktemur2-5/+9
Remove the unused SP parameter from the auxiliary function 'value_arg_coerce'. gdb/ChangeLog: 2019-10-23 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * infcall.c (value_arg_coerce): Remove an unused parameter. (call_function_by_hand_dummy): Update the call to 'value_arg_coerce'. Change-Id: If324a1dda3fa5d4c145790b92bd3f656c00296f4
2019-10-23infcall: move assertions in 'call_function_by_hand_dummy' to an earlier spotTankut Baris Aktemur2-20/+25
This is a refactoring that performs type assertions on the callee function at the beginning of 'call_function_by_hand_dummy' rather than at a later point so that - the checks are grouped together at the beginning of the function for improved readability, and - we don't have to align and push things on the stack only to find out later that the function call is illegal. gdb/ChangeLog: 2019-10-23 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * infcall.c (call_function_by_hand_dummy): Refactor. Change-Id: I411ac083ac6a9ee6eb93c4b82393a81a4fc927be
2019-10-23Add myself to the gdb/MAINTAINERS write-after-approval listTankut Baris Aktemur2-0/+5
gdb/ChangeLog: 2019-10-23 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * MAINTAINERS (Write After Approval): Add Tankut Baris Aktemur.
2019-10-23Add a note for how to get the list of threadsChristian Biesinger2-0/+8
It's not immediately obvious how to get the list of threads, so add a note about that in the "Threads in Python" section. gdb/doc/ChangeLog: 2019-10-23 Christian Biesinger <cbiesinger@google.com> * python.texi (Threads In Python): Add a note for how to get the list of threads. Change-Id: I0fef8a7aff161fc347c09052319048c907a6e8c3
2019-10-23Check for sigprocmask in common.m4Tom Tromey7-5/+21
I noticed that gdbsupport uses HAVE_SIGPROCMASK, but common.m4 does not check for it. This means that gdbserver may not compile some gdbsupport code properly. This patch fixes this error. gdb/ChangeLog 2019-10-23 Tom Tromey <tom@tromey.com> * configure: Rebuild. * configure.ac: Don't check for sigprocmask. * gdbsupport/common.m4 (GDB_AC_COMMON): Check for sigprocmask. gdb/gdbserver/ChangeLog 2019-10-23 Tom Tromey <tom@tromey.com> * configure, config.in: Rebuild. Change-Id: I2c0a4dd2c376507b9483b38707a242382faa8163
2019-10-23Use m4_include, not sinclude in .m4 filesTom Tromey6-30/+45
Pedro pointed out that sinclude does not error if a file is missing. This patch changes gdb to only use m4_include, which seems more correct. gdb/ChangeLog 2019-10-23 Tom Tromey <tom@tromey.com> * configure: Rebuild. * acinclude.m4: Use m4_include, not sinclude. gdb/gdbserver/ChangeLog 2019-10-23 Tom Tromey <tom@tromey.com> * configure: Rebuild. * acinclude.m4: Use m4_include, not sinclude. gdb/testsuite/ChangeLog 2019-10-23 Tom Tromey <tom@tromey.com> * configure: Rebuild. * aclocal.m4: Use m4_include, not sinclude. Change-Id: I970362e0af7875f9f72796401126acf0ff6dba11
2019-10-23[gdb/breakpoints] Fix fullname.exp when run from symlink dirTom de Vries2-0/+8
I run into this error with gdb.base/fullname.exp: ... (gdb) file /data/gdb_versions/devel/build/gdb/testsuite/outputs/\ gdb.base/fullname/fullname Reading symbols from /data/gdb_versions/devel/build/gdb/testsuite/outputs/\ gdb.base/fullname/fullname... (gdb) break /data/gdb_versions/devel/build/gdb/testsuite/\ outputs/gdb.base/fullname/tmp-fullname.c:21 No source file named /data/gdb_versions/devel/build/gdb/testsuite/outputs/\ gdb.base/fullname/tmp-fullname.c. Make breakpoint pending on future shared library load? (y or [n]) n (gdb) FAIL: gdb.base/fullname.exp: set breakpoint by full path before loading symbols - built relative ... The FAIL is due to this comparison in iterate_over_some_symtabs failing: ... 481 if (FILENAME_CMP (real_path, fullname) == 0) (gdb) p real_path $2 = 0x1a201f0 "/data/gdb_versions/devel/build/gdb/testsuite/outputs/\ gdb.base/fullname/tmp-fullname.c" (gdb) p fullname $3 = 0x1a1de80 "/home/vries/gdb_versions/devel/build/gdb/testsuite/outputs/\ gdb.base/fullname/tmp-fullname.c" ... The difference in pathnames is due to having a symlink dir: ... $ ls -la /home/vries/gdb_versions lrwxrwxrwx 1 vries users 18 26 jun 2018 /home/vries/gdb_versions -> /data/gdb_versions ... and the test passses when eliminating it: ... $ ( cd $(pwd -P); make check RUNTESTFLAGS=gdb.base/fullname.exp ) ... The FAIL is a regression from commit a0c1ffedcf1 "Only compute realpath when basenames_may_differ is set". Before, find_and_open_source was returning a real-path, resulting in variable 'fullname' being the same as varible 'real_path' in the comparison listed above. But after, that's no longer the case. Fix the FAIL by applying gdb_realpath on the fullname variable before the comparison. Tested on x86_64-linux. I wasn't able to write a test-case. The FAIL starts at: ... $ cd build/gdb $ mv testsuite testsuite.bla $ ln -s testsuite.bla testsuite ... but already this doesn't trigger it anymore: ... $ cd build/gdb/outputs $ mv outputs outputs.bla $ ln -s outputs.bla outputs ... gdb/ChangeLog: 2019-10-23 Tom de Vries <tdevries@suse.de> PR breakpoints/24687 * symtab.c (iterate_over_some_symtabs): Apply gdb_realpath on fullname. Change-Id: I1ace62a234458781e958980f3b425edf1490df27
2019-10-22Make demangled_name_entry::language not a bitfieldChristian Biesinger2-1/+6
Having it as a bitfield causes extra work, and this is not memory-sensitive. Furthermore, once https://sourceware.org/ml/gdb-patches/2019-10/msg00812.html lands, the bitfield won't even save any memory at all. gdb/ChangeLog: 2019-10-22 Christian Biesinger <cbiesinger@google.com> * symtab.c (struct demangled_name_entry) <language>: Change from bitfield to regular variable. Change-Id: I4ea31d1cfcbe0f09a09bd058cd304862308dc388
2019-10-22Fix compile error & incorrect pushChristian Biesinger4-9/+34
I accidentally pushed the wrong version of the patch for commit 7bb43059820c5febb4509b15202a93efde442bc6 (where the review comments were not fixed), and I did a bad conflict resolution for ccb1ba62299edce72053dd567b9d384814e11885 leading to a compile error when libxxhash is available. This fixes both issues. gdb/ChangeLog: 2019-10-22 Christian Biesinger <cbiesinger@google.com> * symtab.c (struct demangled_name_entry): Add a constructor. (free_demangled_name_entry): New function to call the destructor for demangled_name_entry. (create_demangled_names_hash): Pass free_demangled_name_entry to htab_create_alloc. (symbol_set_names): Call placement new for demangled_name_entry. * utils.c: No longer include xxhash.h here, now that fast_hash is inlined in the header. * utils.h: Instead, include it here. Change-Id: If776099d39a65a12733d42efcb859feca1b07a39
2019-10-22Use libxxhash for hashing, if presentChristian Biesinger7-2/+545
XXHash is faster than htab_hash_string: ------------------------------------------------------------ Benchmark Time CPU Iterations ------------------------------------------------------------ BM_xxh3 11 ns 11 ns 65887249 BM_xxh32 19 ns 19 ns 36511877 BM_xxh64 16 ns 16 ns 42964585 BM_hash_string 182 ns 182 ns 3853125 BM_iterative_hash 77 ns 77 ns 9087638 Unfortunately, XXH3 is still experimental (see https://github.com/Cyan4973/xxHash#user-content-new-experimental-hash-algorithm) However, regular XXH64 is still a lot faster than htab_hash_string per my benchmark above. I used the following string for the benchmark: static constexpr char str[] = "_ZZZL13make_gdb_typeP7gdbarchP10tdesc_typeEN16gdb_type_creator19make_gdb_type_flagsEPK22tdesc_type_with_fieldsE19__PRETTY_FUNCTION__"; htab_hash_string is currently 4.35% + 7.98% (rehashing) of gdb startup when attaching to Chrome's content_shell. An additional 5.21% is spent in msymbol_hash, which does not use this hash function. Unfortunately, since it has to lowercase the string, it can't use this hash function. BM_msymbol_hash 52 ns 52 ns 13281495 It may be worth investigating if strlen+XXHash is still faster than htab_hash_string, which would make it easier to use in more places. Debian ships xxhash as libxxhash{0,-dev}. Fedora ships it as xxhash-devel. gdb/ChangeLog: 2019-10-22 Christian Biesinger <cbiesinger@google.com> * Makefile.in: Link with libxxhash. * config.in: Regenerate. * configure: Regenerate. * configure.ac: Search for libxxhash. * utils.c (fast_hash): Use xxhash if present. Change-Id: Icab218388b9f829522ed3977f04301ae6d4fc4ca
2019-10-22Add a fast_hash function in common-utilsChristian Biesinger3-1/+18
Also updates a caller in symtab.c. For now this just calls htab_hash_string but the next patch will change it to xxhash, if available. gdb/ChangeLog: 2019-10-22 Christian Biesinger <cbiesinger@google.com> * utils.h (fast_hash): New function. * symtab.c (hash_demangled_name_entry): Call new function fast_hash. Change-Id: I77cac0d9aa78fc65316a2af449f52edcae72dc9b
2019-10-22Store the mangled name as a string_viewChristian Biesinger2-7/+21
This should be a bit faster (because we can compare the size first), but it is also a dependency for the next patch. (3.47% of gdb startup time is spent in eq_demangled_name_entry when attaching to Chrome's content_shell binary) gdb/ChangeLog: 2019-10-22 Christian Biesinger <cbiesinger@google.com> * symtab.c (struct demangled_name_entry): Change type of mangled to gdb::string_view. Also adds a constructor that takes the mangled name. (hash_demangled_name_entry): Update. (eq_demangled_name_entry): Update. (free_demangled_name_entry): New function to call the destructor now that this is not a POD anymore. (create_demangled_names_hash): Pass free_demangled_name_entry to htab_create_alloc. (symbol_set_names): Update. Change-Id: I24711ae2bcaa9e79ca89a6f8fda385d400419175
2019-10-21DWARF 5 support: Handle line table and file indexesAli Tamur2-75/+137
* Fix handling of file and directory indexes in line tables; in DWARF 5 the indexes are zero-based. Make file_names field private to abstract this detail from the clients. Introduce file_names, is_valid_file_index and file_names_size methods. Reflect these changes in clients. * Handle DW_FORM_data16 in read_formatted_entries; it is used to record MD5 of the file entries in DWARF 5. * Fix a bug in line header parsing that calculates the length of the header incorrectly. (Seemingly this manifests itself only in DWARF 5). Tested with CC=/usr/bin/gcc (version 8.3.0) against master branch (also with -gsplit-dwarf and -gdwarf-4 flags) and there was no increase in the set of tests that fails. (gdb still cannot debug a 'hello world' program with DWARF 5, so for the time being, this is all we care about). This is part of an effort to support DWARF 5 in gdb. gdb/ChangeLog: * dwarf2read.c (dir_index): Change type. (file_name_index): Likewise. (line_header::include_dir_at): Change comment and implementation on whether it is DWARF 5. (line_header::is_valid_file_index): New function. (line_header::file_name_at): Change comment and implementation on whether it is DWARF 5. (line_header::file_names): Change to private field renamed as m_file_names and introduce a new accessor method. (line_header::file_names_size): New method. (line_header::include_dirs): Change to private field and rename as m_include_dirs. (dw2_get_file_names_reader): Define local var at a smaller scope and reflect API change. (dwarf2_cu::setup_type_unit_groups): Reflect API change. (process_structure_scope): Likewise. (line_header::add_include_dir): Change message and reflect renaming. (line_header::add_file_name): Likewise. (read_formatted_entries): Handle DW_FORM_data16. (dwarf_decode_line_header): Fix line header length calculation. (psymtab_include_file_name): Change comment and API. (lnp_state_machine::m_file): Update comment and reflect type change. (lnp_state_machine::record_line): Reflect type change. (dwarf_decode_lines): Reflect API change. (file_file_name): Likewise. (file_full_name): Likewise.
2019-10-21gdb: Ensure that !(a < a) is true in sort_cmp on obj_section objectsAndrew Burgess2-6/+14
After the switch to use std::sort, if GDB is compiled with the -D_GLIBCXX_DEBUG=1 flag then we see an error when using sort_cmp (in objfiles.c) to sort obj_section objects. The problem is that std::sort checks that the condition !(a < a) holds, and currently this is not true. GDB's sort_cmp is really designed to sort lists in which no obj_section repeats, however, there is some code in place to try and ensure we get a stable sort order if there is a bug in GDB, unfortunately this code fails the above check. By reordering some of the checks inside sort_cmp, it is pretty easy to ensure that the !(a < a) condition holds. I've not bothered to make this condition check optimal, like I said this code is only in place to ensure that we get stable results if GDB goes wrong, so I've made the smallest change needed to get the correct behaviour. After this commit I see no regressions when running GDB compiled with -D_GLIBCXX_DEBUG=1. gdb/ChangeLog: * objfiles.c (sort_cmp): Ensure that !(a < a) holds true. Change-Id: I4b1e3e1640865104c0896cbb6c3fdbbc04d9645b
2019-10-21Remove tui_exec_info_contentTom Tromey2-2/+4
I happened to notice that the tui_exec_info_content typedef is unused. This patch removes it. Tested by rebuilding. gdb/ChangeLog 2019-10-21 Tom Tromey <tom@tromey.com> * tui/tui-winsource.h (tui_exec_info_content): Remove typedef. Change-Id: I768edc482366e830eb4528c799686bb27518cdcb
2019-10-21Fix creation of nm.h when configure is changedTom Tromey4-31/+30
My earlier patch -- commit c5adaa192 ("Fix creation of stamp-h by gdb's configure script") -- broke the creation of nm.h. In particular, configure removes nm.h, so if you touch configure and rebuild, nothing will re-create the link, breaking the build. This patch fixes the bug, and also updates configure.ac to use AC_CONFIG_LINKS, rather than the obsolete AC_LINK_FILES. Finally, I noticed that gcore is in generated_files in the Makefile.in. I think this is incorrect, as generated_files is only needed for files that can be the target of a #include. So, this patch removes it. gdb/ChangeLog 2019-10-21 Tom Tromey <tom@tromey.com> * configure.ac (nm.h): Conditionally create nm.h link. Subst NM_H. Use AC_CONFIG_LINKS. * configure: Rebuild. * Makefile.in (NM_H): New variable. (generated_files): Add NM_H. Remove gcore. (nm.h, stamp-nmh): New targets. Change-Id: I8dd539785d52455e85389425e4bb996c8a127a0e
2019-10-21[gdb/testsuite] Compile infcall-nested-structs.exp with -O2Tom de Vries3-35/+63
As mentioned in commit 745ff14e6e1 "[gdb/tdep] Fix 'Unexpected register class' assert in amd64_push_arguments", of the 12 KFAILs added there, 3 are KPASSing with g++ 4.8.5. The KPASSes are due to: - gdb incorrectly expecting the second half of the result of function rtn_str_struct_02_01 in register %rdx. - rtn_str_struct_02_01 using %rdx as a temporary, thereby accidentally setting it to the expected value. Reduce the chance of hiding errors due accidental register settings by compiling the test-case with -O2. This fixes the KPASSes when applied on top of commit 745ff14e6e1. Tested on x86_64-linux. Tested with g++ 4.8.5, 7.4.1, 8.3.1, 9.2.1. gdb/testsuite/ChangeLog: 2019-10-21 Tom de Vries <tdevries@suse.de> * gdb.base/infcall-nested-structs.c: Add __attribute__((noinline,noclone)) to all functions. (call_all): Add missing variable initialization. Simplify return value. (breakpt): Increment volatile variable, to prevent call from being optimized out. * gdb.base/infcall-nested-structs.exp: Compile with -O2. Change-Id: Ic027e1c957fecd6686345639db99f5eaee3cdf05
2019-10-20Make unlink_objfile and put_objfile_before staticTom Tromey3-37/+29
I noticed an obsolete comment just before unlink_objfile, and then I noticed that both unlink_objfile and put_objfile_before could be static. This patch makes these changes, and also moves unlink_objfile earlier, so that a forward declaration is not needed. Tested by rebuilding. gdb/ChangeLog 2019-10-20 Tom Tromey <tom@tromey.com> * objfiles.h (unlink_objfile, put_objfile_before): Don't declare. * objfiles.c (unlink_objfile): Move earlier. Now static. Remove obsolete comment. (put_objfile_before): Now static. Change-Id: I1b5927a60fd1cc59bfc9c6761f61652a01ef13e0
2019-10-19gdb: Make startswith return a boolSimon Marchi2-3/+7
gdb/ChangeLog: * gdbsupport/common-utils.h (startswith): Change return type to bool. Change-Id: I1c11b9bb7f89b3885c1bb55097adb5be6d333ad4
2019-10-19Replace some more qsort calls with std::sortChristian Biesinger12-134/+114
This has better typesafety, avoids a function pointer indirection, and can benefit from inlining. gdb/ChangeLog: 2019-10-19 Christian Biesinger <cbiesinger@google.com> * bcache.c (bcache::print_statistics): Use std::sort instead of qsort. * breakpoint.c (bp_locations_compare): Rename to... (bp_location_is_less_than): ...this, and change to std::sort semantics. (update_global_location_list): Use std::sort instead of qsort. * buildsym.c (compare_line_numbers): Rename to... (lte_is_less_than): ...this, and change to std::sort semantics. (buildsym_compunit::end_symtab_with_blockvector): Use std::sort instead of qsort. * disasm.c (compare_lines): Rename to... (line_is_less_than): ...this, and change to std::sort semantics. (do_mixed_source_and_assembly_deprecated): Call std::sort instead of qsort. * dwarf2-frame.c (qsort_fde_cmp): Rename to... (fde_is_less_than): ...this, and change to std::sort semantics. (dwarf2_build_frame_info): Call std::sort instead of qsort. * mdebugread.c (compare_blocks): (block_is_less_than): ...this, and change to std::sort semantics. (sort_blocks): Call std::sort instead of qsort. * objfiles.c (qsort_cmp): Rename to... (sort_cmp): ...this, and change to std::sort semantics. (update_section_map): Call std::sort instead of qsort. * remote.c (compare_pnums): Remove. (map_regcache_remote_table): Call std::sort instead of qsort. * utils.c (compare_positive_ints): Remove. * utils.h (compare_positive_ints): Remove. * xcoffread.c (compare_lte): Remove. (arrange_linetable): Call std::sort instead of qsort. Change-Id: Ibcddce12a3d07448701e731b7150fa23611d86de
2019-10-19Fix typos in symfile.c and i386-darwin-tdep.cSergio Durigan Junior3-2/+7
This commit fixes two simple typos, one in gdb/symfile.c and the other in gdb/i386-darwin-tdep.c. s/wether/whether/. 2019-10-19 Sergio Durigan Junior <sergiodj@redhat.com> * symfile.c (init_entry_point_info): Fix typo. * i386-darwin-tdep.c (darwin_dwarf_signal_frame_p): Fix typo. Change-Id: I1fbb39c32009c61c862b6bd56ce12f24a9edb2c4
2019-10-18[gdb] Fix more typos in commentsTom de Vries96-157/+255
Fix typos in comments. NFC. Tested on x86_64-linux. gdb/ChangeLog: 2019-10-18 Tom de Vries <tdevries@suse.de> * aarch64-tdep.c: Fix typos in comments. * ada-lang.c: Same. * ada-tasks.c: Same. * alpha-tdep.c: Same. * alpha-tdep.h: Same. * amd64-nat.c: Same. * amd64-windows-tdep.c: Same. * arc-tdep.c: Same. * arc-tdep.h: Same. * arch-utils.c: Same. * arm-nbsd-tdep.c: Same. * arm-tdep.c: Same. * ax-gdb.c: Same. * blockframe.c: Same. * btrace.c: Same. * c-varobj.c: Same. * coff-pe-read.c: Same. * coffread.c: Same. * cris-tdep.c: Same. * darwin-nat.c: Same. * dbxread.c: Same. * dcache.c: Same. * disasm.c: Same. * dtrace-probe.c: Same. * dwarf-index-write.c: Same. * dwarf2-frame-tailcall.c: Same. * dwarf2-frame.c: Same. * dwarf2read.c: Same. * eval.c: Same. * exceptions.c: Same. * fbsd-tdep.c: Same. * findvar.c: Same. * frame.c: Same. * frv-tdep.c: Same. * gnu-v3-abi.c: Same. * go32-nat.c: Same. * h8300-tdep.c: Same. * hppa-tdep.c: Same. * i386-linux-tdep.c: Same. * i386-tdep.c: Same. * ia64-libunwind-tdep.c: Same. * ia64-tdep.c: Same. * infcmd.c: Same. * infrun.c: Same. * linespec.c: Same. * linux-nat.c: Same. * linux-thread-db.c: Same. * machoread.c: Same. * mdebugread.c: Same. * mep-tdep.c: Same. * mn10300-tdep.c: Same. * namespace.c: Same. * objfiles.c: Same. * opencl-lang.c: Same. * or1k-tdep.c: Same. * osabi.c: Same. * ppc-linux-nat.c: Same. * ppc-linux-tdep.c: Same. * ppc-sysv-tdep.c: Same. * printcmd.c: Same. * procfs.c: Same. * record-btrace.c: Same. * record-full.c: Same. * remote-fileio.c: Same. * remote.c: Same. * rs6000-tdep.c: Same. * s12z-tdep.c: Same. * score-tdep.c: Same. * ser-base.c: Same. * ser-go32.c: Same. * skip.c: Same. * sol-thread.c: Same. * solib-svr4.c: Same. * solib.c: Same. * source.c: Same. * sparc-nat.c: Same. * sparc-sol2-tdep.c: Same. * sparc-tdep.c: Same. * sparc64-tdep.c: Same. * stabsread.c: Same. * stack.c: Same. * symfile.c: Same. * symtab.c: Same. * target-descriptions.c: Same. * target-float.c: Same. * thread.c: Same. * utils.c: Same. * valops.c: Same. * valprint.c: Same. * value.c: Same. * varobj.c: Same. * windows-nat.c: Same. * xcoffread.c: Same. * xstormy16-tdep.c: Same. * xtensa-tdep.c: Same. Change-Id: I5175f1b107bfa4e1cdd4a3361ccb4739e53c75c4
2019-10-17Fix creation of stamp-h by gdb's configure scriptTom Tromey8-67/+27
I happened to notice that "make" would always print: CONFIG_HEADERS=config.h:config.in \ CONFIG_COMMANDS="default depdir" \ CONFIG_FILES= \ CONFIG_LINKS= \ /bin/sh config.status config.status: creating config.h config.status: config.h is unchanged on every rebuild. This seems to have changed due to an autoconf upgrade at some point in the past. In the autoconf gdb uses now, it works to use AC_CONFIG_HEADERS and then create the stamp file via the "commands" argument. This patch also fixes up Makefile.in to use the new-style config.status invocation. It's no longer necessary to pass the output file names via environment variables. gdb/ChangeLog 2019-10-17 Tom Tromey <tromey@adacore.com> * configure: Rebuild. * configure.ac: Use AC_CONFIG_HEADERS. Create stamp-h there, not in AC_CONFIG_FILES invocation. * Makefile.in (Makefile, data-directory/Makefile, stamp-h): Use new-style config.status invocation. gdb/gdbserver/ChangeLog 2019-10-17 Tom Tromey <tromey@adacore.com> * configure: Rebuild. * configure.ac: Use AC_CONFIG_HEADERS. Create stamp-h there, not in AC_CONFIG_FILES invocation. * Makefile.in (stamp-h, Makefile): Use new-style config.status invocation. Change-Id: Ia0530d1c5b9756812d29ddb8dc1062326155e61e
2019-10-17[gdb] Fix typos in commentsTom de Vries28-51/+81
Fix typos in comments. NFC. Tested on x86_64-linux. gdb/ChangeLog: 2019-10-17 Tom de Vries <tdevries@suse.de> * arm-nbsd-nat.c: Fix typos in comments. * arm-tdep.c: Same. * darwin-nat-info.c: Same. * dwarf2read.c: Same. * elfread.c: Same. * event-top.c: Same. * findvar.c: Same. * gdbtypes.c: Same. * hppa-tdep.c: Same. * i386-tdep.c: Same. * jit.c: Same. * main.c: Same. * mdebugread.c: Same. * moxie-tdep.c: Same. * nto-procfs.c: Same. * osabi.c: Same. * ppc-linux-tdep.c: Same. * remote.c: Same. * riscv-tdep.c: Same. * s390-tdep.c: Same. * sh-tdep.c: Same. * sparc-linux-tdep.c: Same. * sparc-nat.c: Same. * stack.c: Same. * target-descriptions.c: Same. * top.c: Same. * varobj.c: Same. Change-Id: I6047967abd2d51c9000dea15184d19f4e952c3ff
2019-10-17[gdb/testsuite] Fix gdb.fortran/module.exp for debug info from other filesTom de Vries2-1/+9
On openSUSE Leap 15.1, I get: ... FAIL: gdb.fortran/module.exp: info variables -n ... because the info variables command prints info also for init.c: ... File init.c:^M 24: const int _IO_stdin_used;^M ... while the regexps in the test-case only expect info for module.f90. Fix this by extending the regexps. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2019-10-17 Tom de Vries <tdevries@suse.de> * gdb.fortran/module.exp: Allow info variables to print info for files other than module.f90. Change-Id: I401d8018b121fc7343f6bc8b671900349462457f
2019-10-16Constify objfile::original_nameTom Tromey2-1/+5
I noticed that objfile::original_name could be a "const char *" rather than a plain "char *". This patch implements this change. Tested by rebuilding. gdb/ChangeLog 2019-10-16 Tom Tromey <tom@tromey.com> * objfiles.h (struct objfile) <original_name>: Now const.
2019-10-16gdb/fortran: Add test for module variables in 'info variables' outputAndrew Burgess2-0/+28
Recent work from Tom Tromey to better handle variables with associated copy relocations has fixed a Fortran issue where module variables wouldn't show up in the output of 'info variables'. This commit adds a test for this functionality to ensure it doesn't get broken in the future. gdb/testsuite/ChangeLog: * gdb.fortran/module.exp: Extend with 'info variables' test. Change-Id: I7306b1d0a9a72947fd48ad7a03f49df774d6573b
2019-10-16gdb/testsuite: Allow cc-with-tweaks board file to be used with FortranAndrew Burgess2-0/+15
The board file cc-with-tweaks is used as the core for lots of other board files, for example cc-with-gdb-index and cc-with-debug-names. This commit extends cc-with-tweaks so that it will wrap the Fortran compiler, allowing for more test coverage. I tested all of the board files that make use of cc-with-tweaks running the gdb.fortran/*.exp test set, and in some cases I did see extra failures. The "standard" results are: === gdb Summary === # of expected passes 953 # of known failures 2 With board file 'cc-with-dwz-m': === gdb Summary === # of expected passes 903 # of unexpected failures 1 # of known failures 2 # of untested testcases 4 With board file 'dwarf4-gdb-index': === gdb Summary === # of expected passes 950 # of unexpected failures 3 # of known failures 2 With board file 'fission-dwp': === gdb Summary === # of expected passes 949 # of unexpected failures 4 # of known failures 2 Despite these extra failure I don't think this should prevent this change going in as these failures presumably already exist in GDB. gdb/testsuite/ChangeLog: * boards/cc-with-tweaks.exp: Setup F90_FOR_TARGET and F77_FOR_TARGET. Change-Id: I06d412f94d0e119ad652dd6c20829f6705a54622
2019-10-16Allow not saving the signal state in SIGSETJMPChristian Biesinger3-3/+28
Saving the signal state is very slow (this patch is a 14% speedup). The reason we need this code is because signal handler will leave the signal blocked when we longjmp out of it. But in this case we can just manually unblock the signal instead of taking the unconditional perf hit. gdb/ChangeLog: 2019-10-16 Christian Biesinger <cbiesinger@google.com> * gdbsupport/gdb_setjmp.h (SIGSETJMP): Allow passing in the value to pass on to sigsetjmp's second argument. * cp-support.c (gdb_demangle): Unblock SIGSEGV if we caught a crash. Change-Id: Ib3010966050c64b4cc8b47d8cb45871652b0b3ea
2019-10-16DWARF reader: Reject sections with invalid sizesKeith Seitz2-0/+15
This is another fuzzer bug, gdb/23567. This time, the fuzzer has specifically altered the size of .debug_str: $ eu-readelf -S objdump Section Headers: [Nr] Name Type Addr Off Size ES Flags Lk Inf Al [31] .debug_str PROGBITS 0000000000000000 0057116d ffffffffffffffff 1 MS 0 0 1 When this file is loaded into GDB, the DWARF reader crashes attempting to access the string table (or it may just store a bunch of nonsense): [gdb-8.3-6-fc30] $ gdb -nx -q objdump BFD: warning: /path/to/objdump has a corrupt section with a size (ffffffffffffffff) larger than the file size Reading symbols from /path/to/objdump... Segmentation fault (core dumped) Nick has already committed a BFD patch to issue the warning seen above. [gdb master 6acc1a0b] $ gdb -BFD: warning: /path/to/objdump has a corrupt section with a size (ffffffffffffffff) larger than the file size Reading symbols from /path/to/objdump... (gdb) inf func All defined functions: File ./../include/dwarf2.def: 186: const 8 *>(.: ;'@�B); 747: const 8 *�(.: ;'@�B); 701: const 8 *�D � (.: ;'@�B); 71: const 8 *(.: ;'@�B); /* and more gibberish */ Consider read_indirect_string_at_offset_from: static const char * read_indirect_string_at_offset_from (struct objfile *objfile, bfd *abfd, LONGEST str_offset, struct dwarf2_section_info *sect, const char *form_name, const char *sect_name) { dwarf2_read_section (objfile, sect); if (sect->buffer == NULL) error (_("%s used without %s section [in module %s]"), form_name, sect_name, bfd_get_filename (abfd)); if (str_offset >= sect->size) error (_("%s pointing outside of %s section [in module %s]"), form_name, sect_name, bfd_get_filename (abfd)); gdb_assert (HOST_CHAR_BIT == 8); if (sect->buffer[str_offset] == '\0') return NULL; return (const char *) (sect->buffer + str_offset); } With sect_size being ginormous, the code attempts to access sect->buffer[GINORMOUS], and depending on the layout of memory, GDB either stores a bunch of gibberish strings or crashes. This is an attempt to mitigate this by implementing a similar approach used by BFD. In our case, we simply reject the section with the invalid length: $ ./gdb -nx -q objdump BFD: warning: /path/to/objdump has a corrupt section with a size (ffffffffffffffff) larger than the file size Reading symbols from /path/to/objdump... warning: Discarding section .debug_str which has a section size (ffffffffffffffff) larger than the file size [in module /path/to/objdump] DW_FORM_strp used without .debug_str section [in module /path/to/objdump] (No debugging symbols found in /path/to/objdump) (gdb) Unfortunately, I have not found a way to regression test this, since it requires poking ELF section headers. gdb/ChangeLog: 2019-10-16 Keith Seitz <keiths@redhat.com> PR gdb/23567 * dwarf2read.c (dwarf2_per_objfile::locate_sections): Discard sections whose size is greater than the file size. Change-Id: I896ac3b4eb2207c54e8e05c16beab3051d9b4b2f
2019-10-16Add initial compile command support to RISC-V port.Jim Wilson2-0/+63
This adds initial compile command support to the RISC-V port. This fixes about 228 testsuite failures on a riscv64-linux machine. We need to get the triplet right which is normally riscv64 or riscv32 instead of the default riscv. Also, we need to get the compiler options right, since we don't accept the default -m64 and -mcmodel=large options, so we need to construct -march and -mabi options which are correct for the target. We currently don't have info about all extensions used by the target, so this may need to be adjusted later. For now, I'm assuming that we have all extensions required by the linux platform spec. gdb/ * riscv-tdep.c (riscv_gcc_target_options): New. (riscv_gnu_triplet_regexp): New. (riscv_gdbarch_init): Call set_gdbarch_gcc_triplet_options and set_gdbarch_gnu_triplet_regexp. Change-Id: I315ce8de7789ddf7bdd3b532f917519464941294
2019-10-16Create xml-builtin.h to declare xml_builtinsChristian Biesinger8-7/+50
xml-builtin.c only has character arrays and no dependencies, so this creates a simple header file for that purpose so that gdbserver can include that instead of re-declaring xml_builtin. Despite the name, feature_to_c.sh is already specific to xml_builtins (it hardcodes the variable name), so making it always output the include for xml-builtin.h seems fine. gdb/ChangeLog: 2019-10-16 Christian Biesinger <cbiesinger@google.com> * Makefile.in: Add xml-builtin.h. * features/feature_to_c.sh: Add an include for xml-builtin.h to ensure that the compiler checks that the types match. * xml-builtin.h: New file. * xml-support.c (fetch_xml_builtin): Add missing const. * xml-support.h: Remove declaration of xml_builtins. gdb/gdbserver/ChangeLog: 2019-10-16 Christian Biesinger <cbiesinger@google.com> * server.c: Include xml-builtin.h. (get_xml_features): Don't declare xml_builtins here. Change-Id: I806ef0851c43ead90b545a11794e41f5e5178436
2019-10-16[gdb/tdep] Fix inferior call arg passing for amd64Tom de Vries4-55/+80
We currently have 12 KFAILS in gdb.base/infcall-nested-structs.exp for PR tdep/25096. A minimal version of the failure looks like this. Consider test.c: ... struct s { int c; struct { int a; float b; } s1; }; struct s ref = { 0, { 'a', 'b' } }; int __attribute__((noinline,noclone)) check (struct s arg) { return arg.s1.a == 'a' && arg.s1.b == 'b' && arg.c == 0; } int main (void) { return check (ref); } ... When calling 'check (ref)' from main, we have '1' as expected: ... $ g++ test.c -g ; ./a.out ; echo $? 1 ... But when calling 'check (ref)' from the gdb prompt, we get '0': ... $ gdb a.out -batch -ex start -ex "p check (ref)" Temporary breakpoint 1 at 0x400518: file test.c, line 8. Temporary breakpoint 1, main () at test.c:8 8 { return check (ref); } $1 = 0 ... The layout of struct s is this: - the field c occupies 4 bytes at offset 0, - the s1.a field occupies 4 bytes at offset 4, and - the s1.b field occupies 4 bytes at offset 8. When compiling at -O2, we can see from the disassembly of main: ... 4003f0: 48 8b 3d 31 0c 20 00 mov 0x200c31(%rip),%rdi \ # 601028 <ref> 4003f7: f3 0f 10 05 31 0c 20 movss 0x200c31(%rip),%xmm0 \ # 601030 <ref+0x8> 4003fe: 00 4003ff: e9 ec 00 00 00 jmpq 4004f0 <_Z5check1s> ... that check is called with fields c and s1.a passed in %rdi, and s1.b passed in %xmm0. However, the classification in theclass (a variable representing the first and second eightbytes, to put it in SYSV X86_64 psABI terms) in amd64_push_arguments is incorrect: ... (gdb) p theclass $1 = {AMD64_INTEGER, AMD64_INTEGER} ... and therefore the struct is passed using %rdi and %rsi instead of using %rdi and %xmm0, which explains the failure. The reason that we're misclassifying the argument in amd64_classify_aggregate has to do with how nested struct are handled. Rather than using fields c and s1.a for the first eightbyte, and using field s1.b for the second eightbyte, instead field c is used for the first eightbyte, and fields s1.a and s1.b are classified together in an intermediate eightbyte, which is then used to merge with both the first and second eightbyte. Fix this by factoring out a new function amd64_classify_aggregate_field, and letting it recursively handle fields of nested structs. Tested on x86_64-linux. Tested with g++ 4.8.5, 7.4.1, 8.3.1, 9.2.1. Tested with clang++ 5.0.2 (which requires removing additional_flags=-Wno-psabi and adding additional_flags=-Wno-deprecated). gdb/ChangeLog: 2019-10-16 Tom de Vries <tdevries@suse.de> PR tdep/25096 * amd64-tdep.c (amd64_classify_aggregate_field): Factor out of ... (amd64_classify_aggregate): ... here. (amd64_classify_aggregate_field): Handled fiels of nested structs recursively. gdb/testsuite/ChangeLog: 2019-10-16 Tom de Vries <tdevries@suse.de> PR tdep/25096 * gdb.base/infcall-nested-structs.exp: Remove PR25096 KFAILs. Change-Id: Id55c74755f0a431ce31223acc86865718ae0c123
2019-10-16[gdb/tdep] Fix 'Unexpected register class' assert in amd64_push_argumentsTom de Vries4-12/+21
Atm, when executing gdb.base/infcall-nested-structs.exp on x86_64-linux, we get: ... FAIL: gdb.base/infcall-nested-structs.exp: l=c++: types-tc-tf: \ p/d check_arg_struct_02_01 (ref_val_struct_02_01) FAIL: gdb.base/infcall-nested-structs.exp: l=c++: types-ts-tf: \ p/d check_arg_struct_02_01 (ref_val_struct_02_01) FAIL: gdb.base/infcall-nested-structs.exp: l=c++: types-ti-tf: \ p/d check_arg_struct_02_01 (ref_val_struct_02_01) === gdb Summary === nr of expected passes 9255 nr of unexpected failures 3 nr of expected failures 142 ... The 3 FAILs are reported as PR tdep/25096. The 142 XFAILs are for a gdb assertion failure, reported in PR tdep/24104, which should have been KFAILs since there's a problem in gdb rather than in the environment. A minimal version of the assertion failure looks like this. Consider test.c: ... struct s { struct { } es1; long f; }; struct s ref = { {}, 'f' }; int __attribute__((noinline,noclone)) check (struct s arg) { return arg.f == 'f'; } int main (void) { return check (ref); } ... When calling 'check (ref)' from main, we have '1' as expected: ... $ g++ test3.c -g && ( ./a.out; echo $? ) 1 ... But when calling 'check (ref)' from the gdb prompt, we get: ... $ gdb a.out -batch -ex start -ex "p check (ref)" Temporary breakpoint 1 at 0x4004f7: file test.c, line 8. Temporary breakpoint 1, main () at test.c:8 8 { return check (ref); } src/gdb/amd64-tdep.c:982: internal-error: \ CORE_ADDR amd64_push_arguments(regcache*, int, value**, CORE_ADDR, \ function_call_return_method): \ Assertion `!"Unexpected register class."' failed. ... The assert happens in this loop in amd64_push_arguments: ... for (j = 0; len > 0; j++, len -= 8) { int regnum = -1; int offset = 0; switch (theclass[j]) { case AMD64_INTEGER: regnum = integer_regnum[integer_reg++]; break; case AMD64_SSE: regnum = sse_regnum[sse_reg++]; break; case AMD64_SSEUP: gdb_assert (sse_reg > 0); regnum = sse_regnum[sse_reg - 1]; offset = 8; break; default: gdb_assert (!"Unexpected register class."); } ... } ... when processing theclass[0], which is AMD64_NO_CLASS: ... (gdb) p theclass $1 = {AMD64_NO_CLASS, AMD64_INTEGER} ... The layout of struct s is that the empty field es1 occupies one byte (due to c++) at offset 0, and the long field f occupies 8 bytes at offset 8. When compiling at -O2, we can see from the disassembly of main: ... 4003f0: 48 8b 3d 41 0c 20 00 mov 0x200c41(%rip),%rdi \ # 601038 <ref+0x8> 4003f7: e9 e4 00 00 00 jmpq 4004e0 <_Z5check1s> 4003fc: 0f 1f 40 00 nopl 0x0(%rax) ... that check is called with field f passed in %rdi, meaning that the classification in theclass is correct, it's just not supported in the loop in amd64_push_arguments mentioned above. Fix the assert by implementing support for 'AMD64_NO_CLASS' in that loop. This exposes 9 more FAILs of the PR tdep/25096 type, so mark all 12 of them as KFAIL. Tested on x86_64-linux. Tested with g++ 4.8.5, 7.4.1, 8.3.1, 9.2.1. With 4.8.5, 3 of the 12 KFAILs are KPASSing. Tested with clang++ 5.0.2 (which requires removing additional_flags=-Wno-psabi and adding additional_flags=-Wno-deprecated). gdb/ChangeLog: 2019-10-16 Tom de Vries <tdevries@suse.de> PR tdep/24104 * amd64-tdep.c (amd64_push_arguments): Handle AMD64_NO_CLASS in loop that handles 'theclass'. gdb/testsuite/ChangeLog: 2019-10-16 Tom de Vries <tdevries@suse.de> PR tdep/24104 * gdb.base/infcall-nested-structs.exp: Remove XFAIL for PR tdep/24104. Add KFAIL for PR tdep/25096. Change-Id: I8b66345bbf5c00209ca75b1209fd4d60b36e9ede
2019-10-16[gdb/testsuite] Fix local-static.exp with g++-4.8Tom de Vries2-3/+42
With g++-4.8, I see: ... (gdb) PASS: gdb.cp/local-static.exp: c++: print free_inline_func(void) print 'S::method()'::S_M_s_var_int^M No symbol "S_M_s_var_int" in specified context.^M (gdb) FAIL: gdb.cp/local-static.exp: c++: print 'S::method()'::S_M_s_var_int ... The variable is declared like this (showing pruned .ii): ... void S::method () { static int S_M_s_var_int = 4; } ... But the DWARF generated for the variable is encapsulated in an unnamed lexical block: ... <1><121>: Abbrev Number: 5 (DW_TAG_structure_type) <122> DW_AT_name : S ... <2><14f>: Abbrev Number: 6 (DW_TAG_subprogram) ... <150> DW_AT_name : (indirect string, offset: 0x599): method <156> DW_AT_linkage_name: (indirect string, offset: 0x517): \ _ZN1S6methodEv /* demangled: dS::method() */ ... <1><3f8>: Abbrev Number: 21 (DW_TAG_subprogram) <3f9> DW_AT_specification: <0x14f> ... <3fe> DW_AT_low_pc : 0x4004fc <406> DW_AT_high_pc : 0x2c /* 0x400528 */ ... <2><418>: Abbrev Number: 17 (DW_TAG_formal_parameter) <419> DW_AT_name : (indirect string, offset: 0x68a): this ... <2><424>: Abbrev Number: 18 (DW_TAG_lexical_block) <425> DW_AT_low_pc : 0x400508 <42d> DW_AT_high_pc : 0x1e /* 0x400526 */ <3><435>: Abbrev Number: 22 (DW_TAG_variable) <436> DW_AT_name : (indirect string, offset: 0x29d): S_M_s_var_int ... which has the effect that the variable is not addressable unless the program counter is in the range of the lexical block. This is caused by gcc PR debug/55541, which was fixed in gcc 5. Mark in total 225 FAILs as XFAIL. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2019-10-16 Tom de Vries <tdevries@suse.de> PR testsuite/25059 * gdb.cp/local-static.exp (do_test): Add xfails for gcc PR debug/55541. Change-Id: Ibe86707eecffc79f1bb474d7928ea7d0c39a00a2
2019-10-16[gdb/testsuite] Fix regexp for reg value in jit-reader.expTom de Vries2-20/+26
On openSUSE Leap 15.1 (as well as on Fedora-x86_64-m64 buildbot) I see: ... FAIL: gdb.base/jit-reader.exp: with jit-reader: after mangling: current frame: info registers ... The problem is that r10 is printed signed: ... r10 0xffffffffffffffb0 -80^M ... but the regexp expects a signed value: ... "r10 $hex +$decimal" \ ... Fix this by allowing signed values. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2019-10-16 Tom de Vries <tdevries@suse.de> * gdb.base/jit-reader.exp: Allow non-pointer registers to be printed as signed. Change-Id: Ie494d24fad7a9af7ac6bfaf731c4aa04f1333830
2019-10-15gdb/gdbserver: Remove reference to vec-ipa.oAndrew Burgess2-1/+4
This comit: commit 0dc327459b19e6765c8fe80957f5c8620611628e Date: Mon Oct 7 16:38:53 2019 +0100 gdb: Remove vec.{c,h} and update code to not include vec.h Broke the GDB build due to leaving a reference to vec-ipa.o in the Makefile.in, this file is built from vec.c which has been removed. I got away with this as I had an old version of the vec-ipa.o file still in my build tree. With this commit in place a clean build now completed successfully. gdb/ChangeLog: * Makefile.in: Remove references to vec-ipa.o. Change-Id: I4cf55951158dd7ee8f60cd054311a7c367e1d7bf
2019-10-15gdb: Update comments that reference VEC or vec.hAndrew Burgess11-22/+29
With the removal of the old VEC mechanism from the code base, update comments that still make reference to VECs. There should be no user visible changes after this commit. gdb/ChangeLog: * linespec.c (decode_digits_ordinary): Update comment. * make-target-delegates: No longer need to handle VEC case. * memrange.c (normalize_mem_ranges): Update comment. * namespace.c (add_using_directive): Update comment. * objc-lang.c (uniquify_strings): Update comment. * ppc-linux-nat.c (struct thread_points): Update comment. * probe.h (find_probes_in_objfile): Update comment. * target.h (enum flash_preserve_mode): Update comment. * varobj.c (varobj_restrict_range): Update comment. * varobj.h (varobj_list_children): Update comment. Change-Id: Iefd2e903705c3e79cd13b43395c7a1c167f9a088
2019-10-15gdb: Remove vec.{c,h} and update code to not include vec.hAndrew Burgess41-1312/+45
Removes vec.c and vec.h from the source tree, and remove all the remaining includes of vec.h. There should be no user visible changes after this commit. I did have a few issues rebuilding GDB after applying this patch due to cached dependencies, I found that running this command in the build directory resolved my build issues without requiring a 'make clean': rm -fr gdb/gdbserver/gdbsupport/.deps/ gdb/ChangeLog: * Makefile.in: Remove references to vec.h and vec.c. * aarch64-tdep.c: No longer include vec.h. * ada-lang.c: Likewise. * ada-lang.h: Likewise. * arm-tdep.c: Likewise. * ax.h: Likewise. * breakpoint.h: Likewise. * charset.c: Likewise. * cp-support.h: Likewise. * dtrace-probe.c: Likewise. * dwarf2read.c: Likewise. * extension.h: Likewise. * gdb_bfd.c: Likewise. * gdbsupport/gdb_vecs.h: Likewise. * gdbsupport/vec.c: Remove. * gdbsupport/vec.h: Remove. * gdbthread.h: Likewise. * guile/scm-type.c: Likewise. * inline-frame.c: Likewise. * machoread.c: Likewise. * memattr.c: Likewise. * memrange.h: Likewise. * namespace.h: Likewise. * nat/linux-btrace.h: Likewise. * osdata.c: Likewise. * parser-defs.h: Likewise. * progspace.h: Likewise. * python/py-type.c: Likewise. * record-btrace.c: Likewise. * rust-exp.y: Likewise. * solib-target.c: Likewise. * stap-probe.c: Likewise. * target-descriptions.c: Likewise. * target-memory.c: Likewise. * target.h: Likewise. * varobj.c: Likewise. * varobj.h: Likewise. * xml-support.h: Likewise. gdb/gdbserver/ChangeLog: * Makefile.in: Remove references to vec.c. Change-Id: I0c91d7170bf1b5e992a387fcd9fe4f2abe343bb5
2019-10-15gdb: Remove use of VEC from dwarf2read.cAndrew Burgess3-42/+84
This removes a use of VEC from GDB, from dwarf2read.c. This removal is not very clean, and would probably benefit from additional refactoring in the future. The problem here is that the VEC is contained within struct dwarf2_per_cu_data, which is treated as POD in dwarf2read.c. As such it is actually a VEC pointer. When converting this to a std::vector in an ideal world we would not use a std::vector pointer, and use the std::vector directly. Sadly, to do that would require some rewriting in dwarf2read.c - my concern would be introducing bugs during this rewrite. If we move to a std::vector pointer then we need to take care to handle the case where the pointer is null. The old VEC library would handle null for us, making the VEC interface very clean. With std::vector we need to handle the null pointer case ourselves. The achieve this then I've added a small number of function that wrap up access to the std::vector, hopefully hiding the null pointer management. The final ugliness with this conversion is that, ideally, when wrapping a data member behind an interface I would make the data member private, however, treating the structure as POD once again prevents this, so we are left with the data member being public, but access (ideally) being through the published interface functions. There should be no user visible changes after this commit. gdb/ChangeLog: * gdb/dwarf2read.c (dwarf2_per_objfile::~dwarf2_per_objfile): Update for new std::vector based implementation. (process_psymtab_comp_unit_reader): Likewise. (scan_partial_symbols): Likewise. (recursively_compute_inclusions): Likewise. (compute_compunit_symtab_includes): Likewise. (process_imported_unit_die): Likewise. (queue_and_load_dwo_tu): Likewise. (follow_die_sig_1): Likewise. * gdb/dwarf2read.h: Remove DEF_VEC_P. (typedef dwarf2_per_cu_ptr): Remove. (struct dwarf2_per_cu_data) <imported_symtabs_empty>: New function. (struct dwarf2_per_cu_data) <imported_symtabs_push>: New function. (struct dwarf2_per_cu_data) <imported_symtabs_size>: New function. (struct dwarf2_per_cu_data) <imported_symtabs_free>: New function. (struct dwarf2_per_cu_data) <imported_symtabs>: Change to std::vector. Change-Id: Id0f4bda977c9dd83b0ba3d7fb42f7e5e2b6869c8
2019-10-15Use %x when printing the TIDTom Tromey2-2/+7
One spot in windows-nat.c uses %ld to print the TID, but all other spots use %x, as does the infrun logging. This makes it unnecessarily hard to tell which other log messages correspond to this one. This patch changes the one outlier to use %x. gdb/ChangeLog 2019-10-15 Tom Tromey <tromey@adacore.com> * windows-nat.c (windows_nat_target::resume): Use %x when logging TID. Change-Id: Ic66efeb8a7ec08e7fb007320318f51acbf976734
2019-10-15Rename pid -> tid in windows-nat.cTom Tromey2-4/+9
A couple of spots in windows-nat.c used the name "pid" to refer to the thread ID. I found this confusing, so this patch changes the names. gdb/ChangeLog 2019-10-15 Tom Tromey <tromey@adacore.com> * windows-nat.c (windows_nat_target::fetch_registers) (windows_nat_target::store_registers): Rename "pid" to "tid". Change-Id: Ia1a447e8da822d01ad94a5ca3760342bbdc0e66c
2019-10-15Change gcc_target_options to return std::stringTom Tromey11-19/+35
This patch was inspired by a recent review that recommended using std::string in a new implementation of the gcc_target_options gdbarch function. It changes this function to return std::string rather than an ordinary xmalloc'd string. I believe this caught a latent memory leak in compile.c:get_args. Tested on x86-64 Fedora 29. gdb/ChangeLog 2019-10-15 Tom Tromey <tromey@adacore.com> * gdbarch.h, gdbarch.c: Rebuild. * gdbarch.sh (gcc_target_options): Change return type to std::string. * compile/compile.c (get_args): Update. * nios2-tdep.c (nios2_gcc_target_options): Return std::string. * arm-linux-tdep.c (arm_linux_gcc_target_options): Return std::string. * aarch64-linux-tdep.c (aarch64_linux_gcc_target_options): Return std::string. * arch-utils.c (default_gcc_target_options): Return std::string. * arch-utils.h (default_gcc_target_options): Return std::string. * s390-tdep.c (s390_gcc_target_options): Return std::string. Change-Id: I51f61703426a323089e646da8f22320a2cafbc1f
2019-10-15Make tui-winsource not use breakpoint_chainChristian Biesinger3-8/+11
That's an internal variable of breakpoint.c. Insted, use iterate_over_breakpoints to update the breakpoint list. gdb/ChangeLog: 2019-10-15 Christian Biesinger <cbiesinger@google.com> * breakpoint.c (breakpoint_chain): Make static. * tui/tui-winsource.c: Call iterate_over_breakpoints instead of accessing breakpoint_chain. Change-Id: Ic259b2c3a4c1f5a47f34cfd7fccbdcf274417429
2019-10-15Change iterate_over_breakpoints to take a function_viewChristian Biesinger8-38/+64
This allows callers to pass in capturing lambdas. Also changes the return type to bool. gdb/ChangeLog: 2019-10-15 Christian Biesinger <cbiesinger@google.com> * breakpoint.c (iterate_over_breakpoints): Change function pointer to a gdb::function_view and return value to bool. * breakpoint.h (iterate_over_breakpoints): Likewise. * dummy-frame.c (pop_dummy_frame_bpt): Update. (pop_dummy_frame): Update. * guile/scm-breakpoint.c (bpscm_build_bp_list): Update. (gdbscm_breakpoints): Update. * python/py-breakpoint.c (build_bp_list): Update. (gdbpy_breakpoints): Update. * python/py-finishbreakpoint.c (bpfinishpy_detect_out_scope_cb): Update. (bpfinishpy_handle_stop): Update. (bpfinishpy_handle_exit): Update. * solib-svr4.c (svr4_update_solib_event_breakpoint): Update. (svr4_update_solib_event_breakpoints): Update. Change-Id: Ia9de4deecae562a70a40f5cd49f5a74d64570251
2019-10-15s390: Fix infcalls passing a single-field struct with static membersAndreas Arnez2-3/+23
The infcall-nested-structs test case yields 36 FAILs on s390x because GCC and GDB disagree on how to pass a C++ struct like this as an argument to a function: struct s { float x; static float y; }; For the purpose of argument passing, GCC ignores static fields, while GDB does not. Thus GCC passes the argument in a floating-point register and GDB passes it via memory. Fix this by explicitly ignoring static fields when detecting single-field structs. gdb/ChangeLog: * s390-tdep.c (s390_effective_inner_type): Ignore static fields when unwrapping single-field structs.
2019-10-15[gdb/testsuite] Fix gdb.ada/mi_task_arg.expTom de Vries1-1/+7
On openSUSE Leap 15.1, we have: ... FAIL: gdb.ada/mi_task_arg.exp: -stack-list-arguments 1 (unexpected output) ... The problem is that the stack-list-arguments command prints a frame argument 'self_id' for function system.tasking.stages.task_wrapper: ... frame={level="2",args=[{name="self_id",value="0x12345678"}] ... where none (args=[]) is expected. The frame argument is in fact correct. The FAIL does not show for say, fedora 30, because there the executable uses the system.tasking.stages.task_wrapper from /lib64/libgnarl-9.so. Adding "additional_flags=-bargs additional_flags=-shared additional_flags=-largs" to the flags argument of gdb_compile_ada gives us the same PASS, but installing libada7-debuginfo gets us the same FAIL again. Fix the FAIL by allowing the 'self_id' argument. Tested on x86_64-linux. Change-Id: I5aee5856fa6aeb0cc78aa4fe69deecba5b00b77a
2019-10-14gdb.mi/list-thread-groups-available.exp: read entries one by one instead of ↵Simon Marchi2-9/+23
increasing timeout Commit 580f1034 ("Increase timeout in gdb.mi/list-thread-groups-available.exp") changed gdb.mi/list-thread-groups-available.exp to significantly increase the timeout, which was necessary for when running with make check-read1. Pedro suggested a better alternative, which is to use gdb_test_multiple and consume one entry at a time. This patch does that. gdb/testsuite/ChangeLog: * gdb.mi/list-thread-groups-available.exp: Read entries one by one instead of increasing timeout. Change-Id: I51b689458503240f24e401f054e6583d9172ebdf
2019-10-14gdb: remove unused includes from dwarf2read.cSimon Marchi2-12/+4
include-what-you-use says: ../../../src/binutils-gdb/gdb/dwarf2read.c should remove these lines: - #include <ctype.h> // lines 67-67 - #include <sys/stat.h> // lines 59-59 - #include <sys/types.h> // lines 83-83 - #include <cmath> // lines 88-88 - #include <forward_list> // lines 90-90 - #include <set> // lines 89-89 - #include <unordered_set> // lines 85-85 - #include "completer.h" // lines 60-60 - #include "expression.h" // lines 44-44 - #include "gdbsupport/byte-vector.h" // lines 78-78 - #include "gdbsupport/filestuff.h" // lines 71-71 - #include "gdbsupport/gdb_unlinker.h" // lines 74-74 After a quick glance, that makes sense, so this patch removes them. gdb/ChangeLog: * dwarf2read.c: Remove includes. Change-Id: I13cfcb2f1d747144fddba7f66b329630b79dae90
generated by cgit v1.1 at 2025-02-16 20:17:50 +0000