aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2017-07-17Rename make_symbol_completion_list_fn -> symbol_completerPedro Alves8-16/+26
"make_symbol_completion_list_fn" is odly named when you look at a list of "standard" completers, like the Python/Guile completer lists adjusted by this patch. Rename / move it to completers.h/c, for consistency. gdb/ChangeLog: 2017-07-17 Pedro Alves <palves@redhat.com> * completer.c (symbol_completer): New function, based on make_symbol_completion_list_fn. * completer.h (symbol_completer): New declaration. * guile/scm-cmd.c (cmdscm_completers): Adjust. * python/py-cmd.c (completers): Adjust. * symtab.c (make_symbol_completion_list_fn): Delete. * symtab.h (make_symbol_completion_list_fn): Delete. * cli/cli-decode.c (add_cmd): Adjust.
2017-07-17Fix TAB-completion + .gdb_index slowness (generalize filename_seen_cache)Pedro Alves6-132/+221
Tab completion when debugging a program binary that uses GDB index is surprisingly much slower than when GDB uses psymtabs instead. Around 1.5x/3x slower. That's surprising, because the whole point of GDB index is to speed things up... For example, with: set pagination off set $count = 0 while $count < 400 complete b string_prin # matches gdb's string_printf printf "count = %d\n", $count set $count = $count + 1 end $ time ./gdb --batch -q ./gdb-with-index -ex "source script.cmd" real 0m11.042s user 0m10.920s sys 0m0.042s $ time ./gdb --batch -q ./gdb-without-index -ex "source script.cmd" real 0m4.635s user 0m4.590s sys 0m0.037s Same but with: - complete b string_prin + complete b zzzzzz to exercise the no-matches worst case, master currently gets you something like: with index without index real 0m11.971s 0m8.413s user 0m11.912s 0m8.355s sys 0m0.035s 0m0.035s Running gdb under perf shows 80% spent inside maybe_add_partial_symtab_filename, and 20% spent in the lbasename inside that. The problem that tab completion walks over all compunit symtabs, and for each, walks the contained file symtabs. And there a huge number of file symtabs (each included system header, etc.) that appear in each compunit symtab's file symtab list. As in, when debugging GDB, I have 367381 symtabs iterated, when of those only 5371 filenames are unique... This was a regression from the earlier (nice) split of symtabs in compunit symtabs + file symtabs. The fix here is to add a cache of unique filenames per objfile so that the walk / uniquing is only done once. There's already a abstraction for this in symtab.c; this patch moves that code out to a separate file and C++ifies it bit. This makes the worst-case scenario above consistently drop to ~2.5s (1.5s for the "string_prin" hit case), making it over 3.3x times faster than psymtabs in this use case (7x in the "string_prin" hit case). gdb/ChangeLog: 2017-07-17 Pedro Alves <palves@redhat.com> * Makefile.in (COMMON_OBS): Add filename-seen-cache.o. * dwarf2read.c: Include "filename-seen-cache.h". * dwarf2read.c (dwarf2_per_objfile) <filenames_cache>: New field. (dw2_map_symbol_filenames): Build and use a filenames_seen_cache. * filename-seen-cache.c: New file. * filename-seen-cache.h: New file. * symtab.c: Include "filename-seen-cache.h". (struct filename_seen_cache, INITIAL_FILENAME_SEEN_CACHE_SIZE) (create_filename_seen_cache, clear_filename_seen_cache) (delete_filename_seen_cache, filename_seen): Delete, parts moved to filename-seen-cache.h/filename-seen-cache.c. (output_source_filename, sources_info) (maybe_add_partial_symtab_filename) (make_source_files_completion_list): Adjust to use filename_seen_cache.
2017-07-17C++ify dwarf2_per_objfilePedro Alves2-133/+184
This makes dwarf2_per_objfile a class with cdtors. A following patch will add a non-trivial field to struct dwarf2_per_objfile, making dwarf2_per_objfile itself non-trivial. Since dwarf2_per_objfile is allocated in an obstack, we need to run its cdtors manually. Tested on x86-64 GNU/Linux. gdb/ChangeLog: 2017-07-17 Pedro Alves <palves@redhat.com> * dwarf2read.c (dwarf2_per_objfile): In-class initialize all fields. (dwarf2_per_objfile::dwarf2_per_objfile(objfile*, const dwarf2_debug_sections*)): New. (dwarf2_per_objfile::dwarf2_per_objfile(const dwarf2_per_objfile&)): Declare as deleted. (dwarf2_per_objfile::operator=): Declare as deleted. (dwarf2_per_objfile::dwarf2_per_objfile) (dwarf2_per_objfile::~dwarf2_per_objfile) (dwarf2_per_objfile::free_cached_comp_units): New. (dwarf2_has_info): dwarf2_per_objfile initialization code moved to ctor. Call dwarf2_per_objfile's ctor manually. (dwarf2_locate_sections): Deleted/refactored as ... (dwarf2_per_objfile::locate_sections): ... this new method. (free_cached_comp_units): Defer to dwarf2_per_objfile::free_cached_comp_units. (dwarf2_free_objfile): Call dwarf2_per_objfile's dtor manually.
2017-07-15gdb: Make some test names uniqueAndrew Burgess2-7/+11
Make sure all of the tests have unique names in gdb.mi/mi-vla-fortran.exp. gdb/testsuite/ChangeLog: * gdb.mi/mi-vla-fortran.exp: Make test names unique.
2017-07-14Handle sizeof(type) in RustTom Tromey4-7/+36
PR rust/21764 notes that "sizeof" does not work correctly for all types in Rust. The bug turns out to be an error in the conversion of the AST to gdb expressions. This patch fixes the bug and also avoids generating incorrect expressions in another case. Tested on the buildbot. I'm checking this in. 2017-07-14 Tom Tromey <tom@tromey.com> PR rust/21764: * rust-exp.y (convert_ast_to_expression): Add "want_type" parameter. <UNOP_SIZEOF>: Split into separate case. <UNOP_VAR_VALUE>: Handle want_type. Add error case. 2017-07-14 Tom Tromey <tom@tromey.com> PR rust/21764: * gdb.rust/simple.exp: Add tests.
2017-07-14Make gdb.lookup_typename work for Rust typesTom Tromey5-4/+31
PR rust/21763 points out that gdb.lookup_typename does not work properly for (some) Rust types. I tracked this down to a missing case in symbol_matches_domain. Tested by the buildbot. 2017-07-14 Tom Tromey <tom@tromey.com> PR rust/21763: * symtab.c (symbol_matches_domain): Add language_rust to special case. * rust-exp.y (convert_ast_to_expression) <OP_VAR_VALUE>: Don't treat LOC_TYPEDEF symbols as variables. 2017-07-14 Tom Tromey <tom@tromey.com> * gdb.rust/simple.exp: Add regression test for PR rust/21763.
2017-07-14Fix gdb.base/completion.exp with --target_board=dwarf4-gdb-indexPedro Alves6-26/+121
This is the same patch as posted at <https://sourceware.org/ml/gdb-patches/2017-02/msg00644.html>, with the test at <https://sourceware.org/ml/gdb-patches/2017-02/msg00687.html> squashed in. This patch fixes: -FAIL: gdb.base/completion.exp: tab complete break break.c:ma (timeout) -FAIL: gdb.base/completion.exp: complete break break.c:ma +PASS: gdb.base/completion.exp: tab complete break break.c:ma +PASS: gdb.base/completion.exp: delete breakpoint for tab complete break break.c:ma +PASS: gdb.base/completion.exp: complete break break.c:ma When run with --target_board=dwarf4-gdb-index. The issue here is that make_file_symbol_completion_list_1, used when completing a symbol restricted to a given source file, uses lookup_symtab to look up the symtab with the given name, and search for matching symbols inside. This assumes that there's only one symtab for the given source file. This is an incorrect assumption with (for example) -fdebug-types-section, where we'll have an extra extra symtab containing the types. lookup_symtab finds that symtab, and inside that symtab there are no functions... gdb/ChangeLog: 2017-07-14 Pedro Alves <palves@redhat.com> * symtab.c (make_file_symbol_completion_list_1): Iterate over symtabs matching all symtabs with SRCFILE as file name instead of only considering the first hit, with lookup_symtab. gdb/testsuite/ChangeLog: 2017-07-14 Pedro Alves <palves@redhat.com> * gdb.linespec/base/one/thefile.cc (z1): New function. * gdb.linespec/base/two/thefile.cc (z2): New function. * gdb.linespec/linespec.exp: Add tests.
2017-07-14ax-gdb: Remove more unused argumentsSimon Marchi2-4/+8
gdb/ChangeLog: * ax-gdb.c (gen_aggregate_elt_ref): Remove operand_name and operator_name parameters. (gen_expr): Update function call.
2017-07-14ax-gdb: Remove unnecessary gdbarch parametersSimon Marchi5-60/+78
In multiple places, we pass the gdbarch as an argument to some functions, even though it's available in the agent_expr structure also passed to the same functions. Remove these arguments and replace their usage with accesses to agent_expr::gdbarch. gdb/ChangeLog: * dwarf2loc.h (dwarf2_compile_expr_to_ax): Remove gdbarch parameter. * symtab.h (struct symbol_computed_ops::tracepoint_var_ref): Likewise. * dwarf2loc.c (dwarf2_compile_expr_to_ax): Remove gdbarch parameter, use agent_expr::gdbarch instead, update function calls. (locexpr_tracepoint_var_ref): Likewise. (loclist_tracepoint_var_ref): Likewise. * ax-gdb.c (gen_trace_static_fields): Likewise. (gen_traced_pop): Likewise. (gen_frame_args_address): Likewise. (gen_frame_locals_address): Likewise. (gen_var_ref): Likewise. (gen_struct_ref_recursive): Likewise. (gen_static_field): Likewise. (gen_maybe_namespace_elt): Likewise. (gen_expr): Likewise. (gen_trace_for_var): Likewise. (gen_trace_for_expr): Likewise. (gen_trace_for_return_address): Likewise.
2017-07-14ax-gdb: Remove two unused agent_expr *ax parametersSimon Marchi2-8/+14
gdb/ChangeLog: * ax-gdb.c (gen_deref, gen_address_of): Remove unused ax parameter. (gen_struct_ref, gen_expr, gen_expr_binop_rest): Update call.
2017-07-14ax-gdb: Use ax->gdbarch instead of exp->gdbarch, remove unused parametersSimon Marchi2-91/+90
In many ax generation functions, the "expression *exp" parameter is only used to access the gdbarch. The same value can be found in the "agent_expr *ax" parameter, which needs to be passed in any case. By using ax->gdbarch instead of exp->gdbarch, we can avoid passing exp in many of these functions. gdb/ChangeLog: * ax-gdb.c (gen_usual_unary): Remove exp parameter, get gdbarch from ax, update calls. (gen_usual_arithmetic): Likewise. (gen_integral_promotions): Likewise. (gen_bitfield_ref): Likewise. (gen_primitive_field): Likewise. (gen_struct_ref_recursive): Likewise. (gen_struct_ref): Likewise. (gen_maybe_namespace_elt): Likewise. (gen_struct_elt_for_reference): Likewise. (gen_namespace_elt): Likewise. (gen_aggregate_elt_ref): Likewise. (gen_expr): Get gdbarch from ax, update calls. (gen_expr_binop_rest): Likewise.
2017-07-13gdb: Fix more parameter passing to mi_create_breakpointAndrew Burgess2-2/+8
In the test gdb.mi/mi-vla-fortran.exp the parameters passed to mi_create_breakpoint are passed in the wrong order. By good luck the tests still passes, however the wrong test name is used. All fixed in this commit. A previous commit fixed most of these, but I missed this last one. gdb/testsuite/ChangeLog: * gdb.mi/mi-vla-fortran.exp: Correct even more parameter passing to mi_create_breakpoint.
2017-07-13Fix x86-64 GNU/Linux crashesPedro Alves11-29/+54
Ref: https://sourceware.org/ml/gdb-patches/2017-07/msg00162.html Debugging x86-64 GNU/Linux programs currently crashes GDB in tdesc_use_registers during gdbarch initialization: Program received signal SIGSEGV, Segmentation fault. 0x0000000001093eaf in htab_remove_elt_with_hash (htab=0x2ef9fa0, element=0x26af960, hash=557151073) at src/libiberty/hashtab.c:728 728 if (*slot == HTAB_EMPTY_ENTRY) (top-gdb) p slot $1 = (void **) 0x0 (top-gdb) bt #0 0x0000000001093eaf in htab_remove_elt_with_hash (htab=0x2ef9fa0, element=0x26af960, hash=557151073) at src/libiberty/hashtab.c:728 #1 0x0000000001093e79 in htab_remove_elt (htab=0x2ef9fa0, element=0x26af960) at src/libiberty/hashtab.c:714 #2 0x00000000009121b0 in tdesc_use_registers (gdbarch=0x3001240, target_desc=0x2659cb0, early_data=0x2881cb0) at src/gdb/target-descriptions.c:1328 #3 0x000000000047c93e in i386_gdbarch_init (info=..., arches=0x0) at src/gdb/i386-tdep.c:8634 #4 0x0000000000818d5f in gdbarch_find_by_info (info=...) at src/gdb/gdbarch.c:5394 #5 0x00000000007198a8 in set_gdbarch_from_file (abfd=0x2f48250) at src/gdb/arch-utils.c:618 #6 0x00000000007f21cb in exec_file_attach (filename=0x7fffffffddb0 "/home/pedro/gdb/tests/threads", from_tty=1) at src/gdb/exec.c:380 #7 0x0000000000865c18 in catch_command_errors_const (command=0x7f1d83 <exec_file_attach(char const*, int)>, arg=0x7fffffffddb0 "/home/pedro/gdb/tests/threads", from_tty=1) at src/gdb/main.c:403 #8 0x00000000008669cf in captured_main_1 (context=0x7fffffffd860) at src/gdb/main.c:1035 #9 0x0000000000866de2 in captured_main (data=0x7fffffffd860) at src/gdb/main.c:1142 #10 0x0000000000866e24 in gdb_main (args=0x7fffffffd860) at src/gdb/main.c:1160 #11 0x000000000041312d in main (argc=3, argv=0x7fffffffd968) at src/gdb/gdb.c:32 The direct cause of the crash is that we tried to remove an element from the hash which supposedly exists, but does not. (htab_remove_elt shouldn't really crash in this case, but that's secondary.) The real problem is that early_data passed to tdesc_use_registers includes regs from a target description that is not the target_desc, which violates its assumptions. The registers in question are the fs_base/gs_base registers, added by amd64_init_abi: tdesc_numbered_register (feature, tdesc_data_segments, AMD64_FSBASE_REGNUM, "fs_base"); tdesc_numbered_register (feature, tdesc_data_segments, AMD64_GSBASE_REGNUM, "gs_base"); and that happens because amd64_linux_init_abi uses amd64_init_abi as helper, but they don't coordinate on which fallback tdesc to use. amd64_init_abi does: if (! tdesc_has_registers (tdesc)) tdesc = tdesc_amd64; and then adds the fs_base/gs_base registers of the "tdesc_amd64" tdesc to the tdesc_arch_data. After amd64_init_abi returns, amd64_linux_init_abi does: if (! tdesc_has_registers (tdesc)) tdesc = tdesc_amd64_linux; tdep->tdesc = tdesc; and we end up tdesc_amd64_linux installed in tdep->tdesc. The fix is to make sure that amd64_linux_init_abi and amd64_init_abi agree on default tdesc, by adding a "default tdesc" parameter to amd64_init_abi, instead of having amd64_init_abi hardcode a default. With this, amd64_init_abi creates the fs_base/gs_base registers using the tdesc_amd64_linux tdesc. Tested on x86-64 GNU/Linux, -m64. I don't have an x32 setup handy. Thanks to John Baldwin, Yao Qi and Simon Marchi for the investigation. gdb/ChangeLog: 2017-07-13 Pedro Alves <palves@redhat.com> * amd64-darwin-tdep.c (x86_darwin_init_abi_64): Pass tdesc_amd64 as default tdesc. * amd64-dicos-tdep.c (amd64_dicos_init_abi): * amd64-fbsd-tdep.c (amd64fbsd_init_abi): * amd64-linux-tdep.c (amd64_linux_init_abi): Pass tdesc_amd64_linux as default tdesc. Get final tdesc from the tdep. (amd64_x32_linux_init_abi): Pass tdesc_x32_linux as default tdesc. Get final tdesc from the tdep. * amd64-nbsd-tdep.c (amd64nbsd_init_abi): Pass tdesc_amd64 as default tdesc. * amd64-obsd-tdep.c (amd64obsd_init_abi): Likewise. * amd64-sol2-tdep.c (amd64_sol2_init_abi): Likewise. * amd64-tdep.c (amd64_init_abi): Add 'default_tdesc' parameter. Use it as default tdesc. (amd64_x32_init_abi): Add 'default_tdesc' parameter, and pass it down to amd_init_abi. No longer handle fallback tdesc here. * amd64-tdep.h (tdesc_x32): Declare. (amd64_init_abi, amd64_x32_init_abi): Add 'default_tdesc' parameter. * amd64-windows-tdep.c (amd64_windows_init_abi): Pass tdesc_amd64 as default tdesc.
2017-07-13gdb: Fix parameter passing to mi_create_breakpointAndrew Burgess2-15/+26
In the test gdb.mi/mi-vla-fortran.exp the parameters passed to mi_create_breakpoint are passed in the wrong order. By good luck the tests still passes, however the wrong test name is used. All fixed in this commit. gdb/testsuite/ChangeLog: * gdb.mi/mi-vla-fortran.exp: Correct parameter passing to mi_create_breakpoint.
2017-07-13S390: Add record/replay support for arch12 instructionsAndreas Arnez2-24/+101
Support record/replay of the z/Architecture instructions that were introduced with arch12. gdb/ChangeLog: * s390-linux-tdep.c (s390_process_record): Add support for instructions new in arch12.
2017-07-11Support the fs_base and gs_base registers on FreeBSD/amd64 native processes.John Baldwin2-0/+61
Use ptrace operations to fetch and store the fs_base and gs_base registers for FreeBSD/amd64 processes. Note that FreeBSD does not currently store the value of these registers in core dumps, so these registers are only available when inspecting a running process. gdb/ChangeLog: * amd64-bsd-nat.c (amd64bsd_fetch_inferior_registers): Use PT_GETFSBASE and PT_GETGSBASE. (amd64bsd_store_inferior_registers): Use PT_SETFSBASE and PT_SETGSBASE.
2017-07-11Include the fs_base and gs_base registers in amd64 target descriptions.John Baldwin20-233/+302
This permits these registers to be used with non-Linux targets. gdb/ChangeLog: * features/Makefile (amd64.dat, amd64-avx.dat, amd64-mpx.dat) (amd64-avx-mpx.dat, amd64-avx-avx512.dat) (amd64-avx-mpx-avx512-pku.dat): Add i386/64bit-segments.xml in those rules. * features/i386/amd64-avx-avx512.xml: Add 64bit-segments.xml. * features/i386/amd64-avx-mpx-avx512-pku.xml: Add 64bit-segments.xml. * features/i386/amd64-avx-mpx.xml: Add 64bit-segments.xml. * features/i386/amd64-avx.xml: Add 64bit-segments.xml. * features/i386/amd64-mpx.xml: Add 64bit-segments.xml. * features/i386/amd64.xml: Add 64bit-segments.xml. * features/i386/amd64-avx-avx512.c: Regenerated. * features/i386/amd64-avx-mpx-avx512-pku.c: Regenerated. * features/i386/amd64-avx-mpx.c: Regenerated. * features/i386/amd64-avx.c: Regenerated. * features/i386/amd64-mpx.c: Regenerated. * features/i386/amd64.c: Regenerated. * regformats/i386/amd64-avx-avx512.dat: Regenerated. * regformats/i386/amd64-avx-mpx-avx512-pku.dat: Regenerated. * regformats/i386/amd64-avx-mpx.dat: Regenerated. * regformats/i386/amd64-avx.dat: Regenerated. * regformats/i386/amd64-mpx.dat: Regenerated. * regformats/i386/amd64.dat: Regenerated.
2017-07-11Sync dlang demangling tests from upstream libiberty testsuite.Iain Buclaw2-1/+5
Rationale behind the change instead of adding a `.init$' postfix being that "initializer for symbol" is much more informative when inspecting D runtime type information in gdb, which is the only place where you would encounter references to this compiler-generated symbol. gdb/testsuite/ChangeLog: * gdb.dlang/demangle.exp: Update for demangling changes.
2017-07-10Add missing ChangeLog etriesAnton Kolesov1-0/+16
This adds the missing ChangeLog entries for my previous patch 3d99e81 Import setenv and unsetenv from gnulib
2017-07-10Re-generate i386/amd64-avx-avx512-linux.c and ↵Yao Qi3-2/+7
i386/amd64-avx-mpx-avx512-pku-linux.c gdb: 2017-07-10 Yao Qi <yao.qi@linaro.org> * features/i386/amd64-avx-avx512-linux.c: Re-generated. * features/i386/amd64-avx-mpx-avx512-pku-linux.c: Re-generated.
2017-07-10Re-indent the codeYao Qi2-1/+5
gdb/gdbserver: 2017-07-10 Yao Qi <yao.qi@linaro.org> * linux-x86-low.c (x86_linux_read_description): Re-indent the code.
2017-07-10Import setenv and unsetenv from gnulibAnton Kolesov12-9/+1201
This patch supersedes https://sourceware.org/ml/gdb-patches/2017-07/msg00009.html --- Patch [1] broke a build on MinGW hosts, because MinGW doesn't provide POSIX functions setenv () and unsetenv (). This can be fixed by using implementations from gnulib. [1] https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=9a6c7d9c0 gdb/ChangeLog yyyy-mm-dd Anton Kolesov <Anton.Kolesov@synopsys.com> * gnulib/update-gnulib.sh (IMPORTED_GNULIB_MODULES): Add setenv and unsetenv. * gnulib/aclocal.m4: Regenerate. * gnulib/config.in: Regenerate. * gnulib/configure: Regenerate. * gnulib/import/Makefile.am: Regenerate. * gnulib/import/Makefile.in: Regenerate. * gnulib/import/m4/gnulib-cache.m4: Regenerate. * gnulib/import/m4/gnulib-comp.m4: Regenerate. * gnulib/import/m4/environ.m4: New file. * gnulib/import/m4/setenv.m4: New file. * gnulib/import/setenv.c: New file. * gnulib/import/unsetenv.c: New file.
2017-07-09compile-loc2c: Fix uninitialized variable errorSimon Marchi2-0/+6
Compiling with clang gives this warning/error: /home/emaisin/src/binutils-gdb/gdb/compile/compile-loc2c.c:731:6: error: variable 'uoffset' is uninitialized when used here [-Werror,-Wuninitialized] uoffset += dwarf2_per_cu_text_offset (per_cu); ^~~~~~~ /home/emaisin/src/binutils-gdb/gdb/compile/compile-loc2c.c:669:23: note: initialize the variable 'uoffset' to silence this warning uint64_t uoffset, reg; ^ = 0 I am really not sure if what this patch does is good, but it is my best guess. DW_OP_addr means that there's an constant address provided by the DWARF bytecode that should be pushed on the stack. That address is considered skipped by the "op_ptr += addr_size", but it is never read. uoffset is indeed read just after, without having been assigned first. So I think the intent is to read the address, it was just omitted. gdb/ChangeLog: * compile/compile-loc2c.c (do_compile_dwarf_expr_to_c): Read address when op is DW_OP_addr.
2017-07-09Fix size check in dwarf2_evaluate_loc_desc_fullTom Tromey4-1/+112
This Rust bug report: https://github.com/rust-lang/rust/issues/41970 noted an error from gdb. What is happening here (for me, the original report had a different error) is that a pieced DWARF expression is not writing to every byte in the resulting value. GDB errors in this case. However, it seems to me that it is always valid to write fewer bytes; the issue comes from writing too many -- that is, the test is reversed. The test was also checking the sub-object, but this also seems incorrect, as it's expected for the expression to write the entirety of the enclosing object. So, this patch reverses the test and applies it to the outer type, not the subobject type. Regtested on the buildbot. gdb/ChangeLog 2017-07-09 Tom Tromey <tom@tromey.com> * dwarf2loc.c (dwarf2_evaluate_loc_desc_full): Reverse size check and apply to outer type. gdb/testsuite/ChangeLog 2017-07-09 Tom Tromey <tom@tromey.com> * gdb.dwarf2/shortpiece.exp: New file.
2017-07-07Read signal information from FreeBSD core dumps.John Baldwin2-0/+75
FreeBSD recently added a new ELF core note which dumps the entire LWP info structure (the same structure returned by the ptrace PT_LWPINFO operation) for each thread. The plan is for this note to eventually supplant the older "thrmisc" ELF core note as it contains more information and it permits new information to be exported via both ptrace() and core dumps using the same structure. For signal information, the implementation is similar to the native implementation for FreeBSD processes. The PL_FLAG_SI flag must be checked to determine if the embedded siginfo_t structure is valid, and if so it is transferred into the caller's buffer. gdb/ChangeLog: * fbsd-tdep.c (LWPINFO_OFFSET, LWPINFO_PL_FLAGS) (LWPINFO64_PL_SIGINFO, LWPINFO32_PL_SIGINFO, PL_FLAG_SI) (SIZE64_SIGINFO_T, SIZE32_SIGINFO_T, fbsd_core_xfer_siginfo): New. (fbsd_init_abi): Install gdbarch "core_xfer_siginfo" method.
2017-07-07Use the thread_section_name helper class in fbsd_core_thread_name.John Baldwin2-4/+7
gdb/ChangeLog: * fbsd-tdep.c (fbsd_core_thread_name): Use thread_section_name.
2017-07-07Add a new gdbarch method to fetch signal information from core files.John Baldwin6-24/+92
Previously the core_xfer_partial method used core_get_siginfo to handle TARGET_OBJECT_SIGNAL_INFO requests. However, core_get_siginfo looked for Linux-specific sections in the core file. To support fetching siginfo from cores on other systems, add a new gdbarch method (`core_xfer_siginfo`) and move the body of the existing core_get_siginfo into a linux_core_xfer_siginfo implementation of this method in linux-tdep.c. gdb/ChangeLog: * corelow.c (get_core_siginfo): Remove. (core_xfer_partial): Use the gdbarch "core_xfer_siginfo" method instead of get_core_siginfo. * gdbarch.sh (core_xfer_siginfo): New gdbarch callback. * gdbarch.h: Re-generate. * gdbarch.c: Re-generate. * linux-tdep.c (linux_core_xfer_siginfo): New. (linux_init_abi): Install gdbarch "core_xfer_siginfo" method.
2017-07-07Move the thread_section_name class to gdbcore.h.John Baldwin3-45/+50
This allows it to be used outside of corelow.c.
2017-07-07Fetch signal information for native FreeBSD processes.John Baldwin2-0/+170
Use the `pl_siginfo' field in the `struct ptrace_lwpinfo' object returned by the PT_LWPINFO ptrace() request to supply the current contents of $_siginfo for each thread. Note that FreeBSD does not supply a way to modify the signal information for a thread, so $_siginfo is read-only for FreeBSD. To handle 32-bit processes on a 64-bit host, define types for 32-bit compatible siginfo_t and convert the 64-bit siginfo_t to the 32-bit equivalent when supplying information for a 32-bit process. gdb/ChangeLog: * fbsd-nat.c [PT_LWPINFO && __LP64__] (union sigval32) (struct siginfo32): New. [PT_LWPINFO] (fbsd_siginfo_size, fbsd_convert_siginfo): New. (fbsd_xfer_partial) [PT_LWPINFO]: Handle TARGET_OBJECT_SIGNAL_INFO via ptrace(PT_LWPINFO).
2017-07-07Implement the "get_siginfo_type" gdbarch method for FreeBSD architectures.John Baldwin2-0/+130
As with Linux architectures, cache the created type in the gdbarch when it is first created. Currently FreeBSD uses an identical siginfo type on all architectures, so there is no support for architecture-specific fields. gdb/ChangeLog: * fbsd-tdep.c (fbsd_gdbarch_data_handle, struct fbsd_gdbarch_data) (init_fbsd_gdbarch_data, get_fbsd_gdbarch_data) (fbsd_get_siginfo_type): New. (fbsd_init_abi): Install gdbarch "get_siginfo_type" method. (_initialize_fbsd_tdep): New.
2017-07-06Fission support for multiple CUs per DWO fileDavid Blaikie7-47/+564
In some cases a compiler may produce a single object file (& thus single DWO file) representing multiple source files. The most common example of this is in whole program optimization (such as LLVM's LTO). Fission may still be a beneficial feature to use here - to avoid the need to read/link the debug info with system libraries and the like. This change adds basic support for multiple CUs in a single DWO file to support LLVM's output in this situation. There is still outstanding work to design and implement a solution for cross-CU references (usually using DW_FORM_ref_addr) in this scenario. For now LLVM works around this by duplicating DIEs rather than making cross-CU references in DWO files. This degrades debugger behavior/quality especially for file-local entities. 2017-07-06 David Blaikie <dblaikie@gmail.com> * dwarf2read.c (struct dwo_file): Use a htab of dwo_unit* (rather than a singular dwo_unit*) to support multiple CUs in the same way that multiple TUs are supported. (create_cus_hash_table): Replace create_dwo_cu with a function for parsing multiple CUs from a DWO file. (open_and_init_dwo_file): Use create_cus_hash_table rather than create_dwo_cu. (lookup_dwo_cutu): Lookup CU in the hash table in the dwo_file with htab_find, rather than comparing the signature to a singleton CU in the dwo_file. 2017-07-06 David Blaikie <dblaikie@gmail.com> * gdb.dwarf2/fission-multi-cu.S: Test containing multiple CUs in a DWO, built from fissiont-multi-cu{1,2}.c. * gdb.dwarf2/fission-multi-cu.exp: Test similar to fission-base.exp, except putting 'main' and 'func' in separate CUs in the same DWO file. * gdb.dwarf2/fission-multi-cu1.c: First CU for the multi-CU-single-DWO test. * gdb.dwarf2/fission-multi-cu2.c: Second CU in the multi-CU-single-DWO test.
2017-07-06Fix Python unwinder frames regressionPedro Alves4-2/+11
The gdb.python/py-unwind.exp test is crashing GDB / leaving core dumps in the test dir, even though it all passes cleanly. The crash is not visible in gdb.sum/gdb.log because it happens as side effect of the "quit" command, while flushing the frame cache. The problem is simply a typo in a 'for' loop's condition, introduced by a recent change [4fa847d78edd ("Remove MAX_REGISTER_SIZE from py-unwind.c")], resulting in infinite loop / double-free. The new test exposes the crash, like: Running src/gdb/testsuite/gdb.python/py-unwind.exp ... ERROR: Process no longer exists gdb/ChangeLog: 2017-07-06 Pedro Alves <palves@redhat.com> * python/py-unwind.c (pyuw_dealloc_cache): Fix for loop condition. gdb/testsuite/ChangeLog: 2017-07-06 Pedro Alves <palves@redhat.com> * gdb.python/py-unwind.exp: Test flushregs.
2017-07-04Garbage collect TYPE_STATIC and several TYPE_FN_FIELD_xPedro Alves3-24/+12
Nothing uses these. Most of the TYPE_FN_FIELD_ ones were probably used by the gcj support. gdb/ChangeLog: 2017-07-04 Pedro Alves <palves@redhat.com> * gdbtypes.c (recursive_dump_type): Don't reference TYPE_STATIC. * gdbtypes.h (TYPE_STATIC): Delete. (struct fn_field) <is_public, is_abstract, is_static, is_final, is_synchronized, is_native>: Delete. <dummy>: Bump. (TYPE_FN_FIELD_PUBLIC, TYPE_FN_FIELD_STATIC, TYPE_FN_FIELD_FINAL) (TYPE_FN_FIELD_SYNCHRONIZED, TYPE_FN_FIELD_NATIVE) (TYPE_FN_FIELD_ABSTRACT): Delete.
2017-07-03buffer.h: Fix spelling mistakesSimon Marchi2-1/+5
gdb/ChangeLog: * buffer.h (buffer_finish): Fix spelling mistakes.
2017-07-01Setup .dir-locals.el to use C-style comments by defaultEli Zaretskii2-0/+7
gdb/ChangeLog: 2017-07-01 Eli Zaretskii <eliz@gnu.org> * .dir-locals.el: Automatically switch to C-style comments in versions of Emacs that support the feature.
2017-06-30PR cli/21688: Detect aliases when issuing python/compile/guile commands (and ↵Sergio Durigan Junior4-18/+54
fix last commit) My last commit fixed a regression that happened when using inline/multi-line commands for Python/Compile/Guile, but introduced another regression: it is now not possible to use aliases for the commands mentioned above. The fix is to almost revert the change I've made and go back to using the 'struct cmd_list_element *', but at the same time make sure that we advance the 'cmd_name' variable past all the whitespace characters after the command name. If, after skipping the whitespace, we encounter a '\0', it means that the command is not inline. Otherwise, it is. This patch also expands the testcase in order to check for aliases and for trailing whitespace after the command name. gdb/ChangeLog: 2017-06-30 Sergio Durigan Junior <sergiodj@redhat.com> Pedro Alves <palves@redhat.com> PR cli/21688 * cli/cli-script.c (command_name_equals_not_inline): Remove function. (process_next_line): New variable 'inline_cmd'. Adjust 'if' clauses for "python", "compile" and "guile" to use 'command_name_equals' and check for '!inline_cmd'. gdb/testsuite/ChangeLog: 2017-06-30 Sergio Durigan Junior <sergiodj@redhat.com> PR cli/21688 * gdb.python/py-cmd.exp (test_python_inline_or_multiline): Add new tests for alias commands and trailing whitespace.
2017-06-30PR cli/21688: Fix multi-line/inline command differentiationSergio Durigan Junior4-4/+62
This bug is a regression caused by the following commit: 604c4576fdcfc4e7c28f569b3748a1b6b4e0dbd4 is the first bad commit commit 604c4576fdcfc4e7c28f569b3748a1b6b4e0dbd4 Author: Jerome Guitton <guitton@adacore.com> Date: Tue Jan 10 15:15:53 2017 +0100 The problem happens because, on cli/cli-script.c:process_next_line, GDB is not using the command line string to identify which command to run, but it instead using the 'struct cmd_list_element *' that is obtained by using the mentioned string. The problem with that is that the 'struct cmd_list_element *' doesn't have any information on whether the command issued by the user is a multi-line or inline one. A multi-line command is a command that will necessarily be composed of more than 1 line. For example: (gdb) if 1 >python >print ('hello') >end >end As can be seen in the example above, the 'python' command actually "opens" a new command line (represented by the change in the indentation) that will then be used to enter Python code. OTOH, an inline command is a command that is "self-contained" in a single line, for example: (gdb) if 1 >python print ('hello') >end This Python command is a one-liner, and therefore there is no other Python code that can be entered for this same block. There is also no change in the indentation. So, the fix is somewhat simple: we have to revert the change and use the full command line string passed to process_next_line in order to identify whether we're dealing with a multi-line or an inline command. This commit does just that. As can be seen, this regression also affects other languages, like guile or the compile framework. To make things clearer, I decided to create a new helper function responsible for identifying a non-inline command. Testcase is attached. gdb/ChangeLog: 2017-06-30 Sergio Durigan Junior <sergiodj@redhat.com> PR cli/21688 * cli/cli-script.c (command_name_equals_not_inline): New function. (process_next_line): Adjust 'if' clauses for "python", "compile" and "guile" to use command_name_equals_not_inline. gdb/testsuite/ChangeLog: 2017-06-30 Sergio Durigan Junior <sergiodj@redhat.com> PR cli/21688 * gdb.python/py-cmd.exp (test_python_inline_or_multiline): New procedure. Call it.
2017-06-29Expression completer should not match explicit location optionsPedro Alves4-1/+16
This commit fixes a mismatch between what "print" command completer thinks the command understands, and what the command actually understands. The explicit location options are understood by commands that take (linespecs and) explicit locations as argument. I.e, breakpoint commands, and "list". For example: (gdb) b -source file.c -function my_func So for those commands, it makes sense that the completer completes: "b -sour[TAB]" -> "b -source " "b -functi[TAB]" -> "b -function " etc. However, completion for commands that take expressions (not linespecs/locations) as arguments, such as the "print" command, also completes the explicit location options, even though those switches aren't really understood by these commands. Instead, "-foo" is understood as an expression applying unary minus on a symbol named "foo" (think "print -1"): (gdb) p -func[TAB] (gdb) p -function [RET] No symbol "function" in current context. The patch fixes this by having the expression_completer function bypass the function that completes explicit locations. New regression tests included. gdb/ChangeLog: 2017-06-29 Pedro Alves <palves@redhat.com> * completer.c (expression_completer): Call linespec_location_completer instead of location_completer. gdb/testsuite/ChangeLog: 2017-06-29 Pedro Alves <palves@redhat.com> * gdb.base/printcmds.exp: Add tests.
2017-06-29Remove old stale expression_completer hackPedro Alves2-9/+6
The code in question was introduced by: https://sourceware.com/ml/gdb-patches/2008-06/msg00143.html "The fix is to make sure that the entire expression is passed to expression_completer, then duplicate some logic there in the case where location_completer is called." The logic that was duplicated was much later on removed by the original explicit locations patch: commit 87f0e7204722a986f79f245eee716f0870832d47 Author: Keith Seitz <keiths@redhat.com> AuthorDate: Tue Aug 11 17:09:36 2015 -0700 Commit: Keith Seitz <keiths@redhat.com> CommitDate: Tue Aug 11 17:09:36 2015 -0700 Explicit locations: add UI features for CLI @@ -688,16 +880,6 @@ complete_line_internal (const char *text, rl_completer_word_break_characters = gdb_completer_file_name_break_characters; } - else if (c->completer == location_completer) - { - /* Commands which complete on locations want to - see the entire argument. */ - for (p = word; - p > tmp_command - && p[-1] != ' ' && p[-1] != '\t'; - p--) - ; - } However this case in expression_completer was left behind. I couldn't come up with a test where this currently makes any difference. gdb/ChangeLog: 2017-06-29 Pedro Alves <palves@redhat.com> * completer.c (expression_completer): Remove code that recomputes 'text' from 'word'.
2017-06-29Use target_desc fields expedite_regs and xmltarget ifndef IN_PROCESS_AGENTYao Qi4-0/+16
struct target_desc is used by both GDBserver and IPA, but fields expedite_regs and xmltarget are only used in GDBserver, so this patch wraps these two fields by ifndef IN_PROCESS_AGENT. This patch also changes regformats/regdat.sh to generate .c files in this way too. gdb/gdbserver: 2017-06-29 Yao Qi <yao.qi@linaro.org> * tdesc.h (struct target_desc) [IN_PROCESS_AGENT] <expedite_regs>: Remove. [IN_PROCESS_AGENT] <xmltarget>: Likewise. gdb: 2017-06-29 Yao Qi <yao.qi@linaro.org> * regformats/regdat.sh: Generate code with "ifndef IN_PROCESS_AGENT".
2017-06-28gdb/command.h: Include common/scoped_restore.hPedro Alves2-0/+5
command.h depends on scoped_restore: extern scoped_restore_tmpl<int> prevent_dont_repeat (void); But doesn't include the corresponding header ("common/scoped_restore.h"). We haven't noticed a problem because utils.h includes scoped_restore.h, and defs.h includes utils.h. However, a patch that makes "symtab.h" include "completer.h", exposed the issue: https://sourceware.org/ml/gdb-patches/2017-06/msg00023.html. Without this fix that would break building all .o files like this: In file included from src/gdb/completer.h:21:0, from src/gdb/symtab.h:28, from src/gdb/language.h:26, from src/gdb/frame.h:72, from src/gdb/gdbarch.h:39, from src/gdb/defs.h:636, from src/gdb/top.c:20: src/gdb/command.h:434:8: error: ‘scoped_restore_tmpl’ does not name a type extern scoped_restore_tmpl<int> prevent_dont_repeat (void); ^ Makefile:1911: recipe for target 'top.o' failed because defs.h includes gdbarch.h before it includes utils.h. gdb/ChangeLog: 2017-06-28 Pedro Alves <palves@redhat.com> * command.h: Include "common/scoped_restore.h".
2017-06-28Use obstack_grow_strYao Qi2-2/+7
We already have macro obstack_grow_str, which is helpful to shorten the code. gdb: 2017-06-28 Yao Qi <yao.qi@linaro.org> * mi/mi-cmd-break.c (mi_argv_to_format): Use obstack_grow_str instead of obstack_grow.
2017-06-28Fix PR 21337: segfault when re-reading symbols.Doug Gilmore5-3/+115
Fix issue exposed by commit 3e29f34. The basic issue is that section data referenced through an objfile pointer can also be referenced via the program-space data pointer, although via a separate mapping mechanism, which is set up by update_section_map. Thus once section data attached to an objfile pointer is released, the section map associated with the program-space data pointer must be marked dirty to ensure that update_section_map is called to prevent stale data being referenced. For the matter at hand this marking is being done via a call to objfiles_changed. Before commit 3e29f34 objfiles_changed could be called after all of the objfile pointers were processed in reread_symbols since section data references via the program-space data pointer would not occur in the calls of read_symbols performed by reread_symbols. With commit 3e29f34 MIPS target specific calls to find_pc_section were added to the code for DWARF information processing, which is called via read_symbols. Thus in reread_symbols the call to objfiles_changed needs to be called before calling read_symbols, otherwise stale section data can be referenced. Thanks to Luis Machado for providing text for the main comment associated with the change. gdb/ 2017-06-28 Doug Gilmore <Doug.Gilmore@imgtec.com> PR gdb/21337 * symfile.c (reread_symbols): Call objfiles_changed just before read_symbols. gdb/testsuite/ 2017-06-28 Doug Gilmore <Doug.Gilmore@imgtec.com> PR gdb/21337 * gdb.base/reread-readsym.exp: New file. * gdb.base/reread-readsym.c: New file.
2017-06-27completion_list_add_name wrapper functionsPedro Alves2-14/+35
Replace macros with functions. gdb/ChangeLog: 2017-06-27 Pedro Alves <palves@redhat.com> * symtab.c (COMPLETION_LIST_ADD_SYMBOL) (MCOMPLETION_LIST_ADD_SYMBOL): Delete macros, replace with ... (completion_list_add_symbol, completion_list_add_msymbol): ... these new functions. (add_symtab_completions) (default_make_symbol_completion_list_break_on_1): Adjust.
2017-06-27objfile_per_bfd_storage non-PODPedro Alves4-19/+41
A following patch will want to add a std::vector to objfile_per_bfd_storage. That makes it non-trivially constructible/destructible. Since objfile_per_bfd_storage objects are allocated on an obstack, we need to call their ctors/dtors manually. This is what this patch does. And then since we can now rely on ctors/dtors being run, make objfile_per_bfd_storage::storage_obstack be an auto_obstack. gdb/ChangeLog: 2017-06-27 Pedro Alves <palves@redhat.com> * objfiles.c (get_objfile_bfd_data): Call bfd_alloc instead of bfd_zalloc. Call objfile_per_bfd_storage's ctor. (free_objfile_per_bfd_storage): Call objfile_per_bfd_storage's dtor. * objfiles.h (objfile_per_bfd_storage): Add ctor. Make 'storage_obstack' field an auto_obstack. In-class initialize all non-bitfield fields. Make minsyms_read bool. * symfile.c (read_symbols): Adjust.
2017-06-27Remove MAX_REGISTER_SIZE from remote-sim.cAlan Hayward2-21/+22
gdb/ * remote-sim.c (gdbsim_fetch_register): Use byte_vector. (gdbsim_store_register): Likewise.
2017-06-27Eliminate make_cleanup_obstack_free, introduce auto_obstackPedro Alves14-100/+88
This commit eliminates make_cleanup_obstack_free, replacing it with a new auto_obstack type that inherits obstack to add cdtors. These changes in the parsers may not be obvious: - obstack_init (&name_obstack); - make_cleanup_obstack_free (&name_obstack); + name_obstack.clear (); Here, the 'name_obstack' variable is a global. The change means that the obstack's contents from a previous parse will stay around until the next parsing starts. I.e., memory won't be reclaimed until then. I don't think that's a problem, these objects don't really grow much at all. The other option I tried was to add a separate type that is like auto_obstack but manages an external obstack, just for those cases. I like the current approach better as that other approach adds more boilerplate and yet another type to learn. gdb/ChangeLog: 2017-06-27 Pedro Alves <palves@redhat.com> * c-exp.y (name_obstack): Now an auto_obstack. (yylex): Use auto_obstack::clear. (c_parse): Use auto_obstack::clear instead of reinitializing and freeing the obstack. * c-lang.c (evaluate_subexp_c): Use auto_obstack. * d-exp.y (name_obstack): Now an auto_obstack. (yylex): Use auto_obstack::clear. (d_parse): Use auto_obstack::clear instead of reinitializing and freeing the obstack. * dwarf2loc.c (fetch_const_value_from_synthetic_pointer): Use auto_obstack. * dwarf2read.c (create_addrmap_from_index) (dwarf2_build_psymtabs_hard) (update_enumeration_type_from_children): Likewise. * gdb_obstack.h (auto_obstack): New type. * go-exp.y (name_obstack): Now an auto_obstack. (build_packaged_name): Use auto_obstack::clear. (go_parse): Use auto_obstack::clear instead of reinitializing and freeing the obstack. * linux-tdep.c (linux_make_mappings_corefile_notes): Use auto_obstack. * printcmd.c (printf_wide_c_string, ui_printf): Use auto_obstack. * rust-exp.y (work_obstack): Now an auto_obstack. (rust_parse, rust_lex_tests): Use auto_obstack::clear instead of reinitializing and freeing the obstack. * utils.c (do_obstack_free, make_cleanup_obstack_free): Delete. (host_char_to_target): Use auto_obstack. * utils.h (make_cleanup_obstack_free): Delete declaration. * valprint.c (generic_emit_char, generic_printstr): Use auto_obstack.
2017-06-27darwin: Do not add a dummy threadSimon Marchi2-47/+38
Starting a process on macOS/Darwin currently leads to this error: /Users/simark/src/binutils-gdb/gdb/darwin-nat.c:383: internal-error: void darwin_check_new_threads(struct inferior *): Assertion `tp' failed. with the corresponding partial backtrace (sorry, taken with lldb, because well, gdb is broken :)): frame #9: 0x000000010004605a gdb`darwin_check_new_threads(inf=0x0000000100edf670) at darwin-nat.c:383 frame #10: 0x0000000100045848 gdb`darwin_init_thread_list(inf=0x0000000100edf670) at darwin-nat.c:1710 frame #11: 0x00000001000452f8 gdb`darwin_ptrace_him(pid=8375) at darwin-nat.c:1792 frame #12: 0x0000000100041d95 gdb`fork_inferior(...) at fork-inferior.c:440 frame #13: 0x0000000100043f82 gdb`darwin_create_inferior(...) at darwin-nat.c:1841 frame #14: 0x000000010034ac32 gdb`run_command_1(args=0x0000000000000000, from_tty=1, tbreak_at_main=1) at infcmd.c:611 The issue was introduced by commit "Share fork_inferior et al with gdbserver" because it changed the place where the dummy thread (pid, 0, 0) is added, relative to the call to the init_trace_fun callback. In this callback, darwin checks for new threads in the program (there should be exactly one) in order to update this dummy thread with the right tid. Previously, things happened in this order: - fork_inferior calls fork() - fork_inferior adds dummy thread - fork_inferior calls init_trace_fun callback, which updates the dummy thread info Following the commit mentioned above, the new thread is added in the darwin-nat code, after having called fork_inferior (in darwin_create_inferior). So gdb tries to do things in this order: - fork_inferior calls fork() - fork_inferior calls init_trace_fun callback, which tries to update the dummy thread info - darwin_create_inferior adds the dummy thread The error happens while trying to update the dummy thread that has not been added yet. I don't think this dummy thread is necessary for darwin. Previously, it was fork_inferior that was adding this thread, for all targets, so darwin had to deal with it. Now that it's done by targets themselves, we can just skip that on darwin. darwin_check_new_threads called indirectly by init_trace_fun/darwin_ptrace_him will simply notice the new thread and add it with the right information. My level of testing was: try to start a process and try to attach to a process, and it seems to work somewhat like it did before. I tried to run the testsuite, but it leaves a huge amount of zombie processes that launchd doesn't seem to reap, leading to exhaustion of system resources (number of processes). gdb/ChangeLog: * darwin-nat.c (darwin_check_new_threads): Don't handle dummy thread. (darwin_init_thread_list): Don't update dummy thread. (darwin_create_inferior, darwin_attach): Don't add a dummy thread.
2017-06-26record-full: Remove unused function netorder16Simon Marchi2-10/+4
clang shows this warning: /home/emaisin/src/binutils-gdb/gdb/record-full.c:2344:1: error: unused function 'netorder16' [-Werror,-Wunused-function] netorder16 (uint16_t input) ^ Remove this function, which, AFAIK, has never been used. Note that GCC doesn't warn about this, because the function is marked as inline. According to gcc's man page, it should ideed not warn: -Wunused-function Warn whenever a static function is declared but not defined or a non-inline static function is unused. This warning is enabled by -Wall. So it's probably not a GCC bug that it doesn't find this unused function, but a different definition of "unused". gdb/ChangeLog: * record-full.c (netorder16): Remove.
2017-06-26vec: Silence -Wunused-function warnings on clangSimon Marchi3-2/+49
clang has a too aggressive (or broken, depends on how you want to see it) -Wunused-function warning, which is triggered by the functions defined by DEF_VEC_* but not used in the current source file. Normally, it won't warn about unused static inline functions defined in header files, because it's expected that a source file won't use all functions defined in a header file it includes. However, if the DEF_VEC_* macro is used in a source file, it considers those functions as defined in the source file, which leads it to think that we should remove those functions. It is therefore missing a check to see whether those functions are resulting from macro expansion. A bug already exists for that: https://bugs.llvm.org//show_bug.cgi?id=22712 It's quite easy to silence this warning in a localized way, that is in the DEF_VEC_* macros. gdb/ChangeLog: * common/diagnostics.h: Define macros for GCC. (DIAGNOSTIC_IGNORE_UNUSED_FUNCTION): New macro. * common/vec.h: Include diagnostics.h. (DIAGNOSTIC_IGNORE_UNUSED_VEC_FUNCTION): New macro. (DEF_VEC_I, DEF_VEC_P, DEF_VEC_O): Ignore -Wunused-function warning.
generated by cgit v1.1 at 2025-01-05 15:50:39 +0000