aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
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.
2017-06-26ada-lex: Ignore warnings about register keywordSimon Marchi3-0/+19
Some older versions of flex (such as the one shipped with macOS) generate code that use the register keyword, which clang warns about. This patch makes the compiler ignore those warnings for the portion of the code generated by flex. gdb/ChangeLog: * common/diagnostics.h (DIAGNOSTIC_IGNORE_DEPRECATED_REGISTER): New macro. * ada-lex.l: Ignore deprecated register warnings.
2017-06-25main: Don't add int to stringSimon Marchi2-1/+6
clang shows this warning: /home/emaisin/src/binutils-gdb/gdb/main.c:227:56: error: adding 'int' to a string does not append to the string [-Werror,-Wstring-plus-int] char *tmp_sys_gdbinit = xstrdup (SYSTEM_GDBINIT + datadir_len); ~~~~~~~~~~~~~~~^~~~~~~~~~~~~ /home/emaisin/src/binutils-gdb/gdb/main.c:227:56: note: use array indexing to silence this warning char *tmp_sys_gdbinit = xstrdup (SYSTEM_GDBINIT + datadir_len); ^ & [ ] It's quite easy to get rid of it by using &foo[len] instead of foo + len. I think this warning is relevant to keep enabled, because it can be an easy mistake to do. This warning is already discussed here in GCC bugzilla: https://gcc.gnu.org/ml/gcc-patches/2017-06/msg00729.html and a patch series for it was submitted very recently. gdb/ChangeLog: * main.c (get_init_files): Replace "SYSTEM_GDBINIT + datadir_len" with "&SYSTEM_GDBINIT[datadir_len]".
2017-06-25dtrace-probe: Put semicolon after while on its own lineSimon Marchi2-1/+7
clang shows this warning. /home/emaisin/src/binutils-gdb/gdb/dtrace-probe.c:424:52: error: while loop has empty body [-Werror,-Wempty-body] while (*p++ != '\0' && p - strtab < strtab_size); ^ /home/emaisin/src/binutils-gdb/gdb/dtrace-probe.c:424:52: note: put the semicolon on a separate line to silence this warning Putting the semicolon on its own line is not a big sacrifice to get rid of this warning. I think it's also useful to keep this, because it can catch errors like this: while (something); { ... } although gcc would warn about it in a different way (misleading indentation). This warning is already discussed here in the GCC bugzilla: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62184 gdb/ChangeLog: * dtrace-probe.c (dtrace_process_dof_probe): Put semi-colon on its own line.
2017-06-25x86-dregs: Print debug registers one per lineSimon Marchi2-10/+10
This get around this warning given by clang... /home/emaisin/src/binutils-gdb/gdb/nat/x86-dregs.c:209:7: error: variable 'i' is incremented both in the loop header and in the loop body [-Werror,-Wfor-loop-analysis] i++; ^ /home/emaisin/src/binutils-gdb/gdb/nat/x86-dregs.c:199:32: note: incremented here ALL_DEBUG_ADDRESS_REGISTERS (i) ^ ... I decided in the end to simply print the debug registers one per line. I don't think it particularly helps readability to have them two per line anyway. gdb/ChangeLog: * nat/x86-dregs.c (x86_show_dr): Print registers one per line.
2017-06-23Add XTENSA_MAX_REGISTER_SIZEAlan Hayward2-2/+11
gdb/ * xtensa-tdep.c (XTENSA_MAX_REGISTER_SIZE): Add. (xtensa_register_write_masked): Use XTENSA_MAX_REGISTER_SIZE. (xtensa_register_read_masked): Likewise.
2017-06-22Update comment on gdb_environ::unsetSergio Durigan Junior2-1/+5
gdb_environ::unset iterates using '.end () - 1' now, instead of '.cend () - 1'. This obvious patch updates the comment. gdb/ChangeLog: 2017-06-22 Sergio Durigan Junior <sergiodj@redhat.com> * common/environ.c (gdb_environ::unset): Update comment.
2017-06-22Fix cached_frame allocation in py-unwindAlan Hayward2-1/+9
gdb/ * python/py-unwind.c (pyuw_sniffer): Allocate space for registers.
2017-06-22Remove an instance of MAX_REGISTER_SIZE from record-full.cAlan Hayward2-3/+8
gdb/ * record-full.c (record_full_exec_insn): Use byte_vector.
2017-06-22Regenerate two regformats/i386/.dat filesYao Qi3-3/+6
The self tests which compare pre-generated target descriptions and dynamically created target descriptions fail, and it turns out that two pre-generated target descriptions are wrong, so regenerate them. gdb: 2017-06-22 Yao Qi <yao.qi@linaro.org> * regformats/i386/amd64-avx-mpx-avx512-pku-linux.dat: Regenerated. * regformats/i386/amd64-avx-mpx-avx512-pku.dat: Regenerated.
2017-06-22Remove MAX_REGISTER_SIZE from py-unwind.cAlan Hayward4-24/+30
gdb/ * remote.c (cached_reg): Move from here... * regcache.h (cached_reg): ...to here. * python/py-unwind.c (struct reg_info): Remove. (cached_frame_info): Use cached_reg_t. (pyuw_prev_register): Likewise. (pyuw_sniffer): Use cached_reg_t and allocate registers. (pyuw_dealloc_cache): Free all registers.
2017-06-22environ-selftests: Ignore -Wself-move warningPedro Alves3-0/+55
clang gives this warning: ..../gdb/unittests/environ-selftests.c:139:7: error: explicitly moving variable of type 'gdb_environ' to itself [-Werror,-Wself-move] env = std::move (env); ~~~ ^ ~~~ Ignoring the warning locally is the right thing to do, since it warns about behavior we want to unit test, while an explicit self-move in real code would likely be a mistake that we'd want to catch. To avoid cluttering the code with preprocessor conditionals, this commit adds the file common/diagnostics.h, in which we can put macros used to control compiler diagnostics. GCC enhancement request here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81159 gdb/ChangeLog: 2017-06-22 Pedro Alves <palves@redhat.com> Simon Marchi <simon.marchi@ericsson.com> * unittests/environ-selftests.c (run_tests): Ignore -Wself-move warning. * common/diagnostics.h: New file.
2017-06-22Add STRINGIFY to gdb/common/preprocessor.hPedro Alves4-8/+9
We have several copies of this common idiom under gdb/ currently. This commit moves them / factors them out to gdb/common/preprocessor.h. gdb/ChangeLog: 2017-06-22 Pedro Alves <palves@redhat.com> * common/agent.h: Include "common/preprocessor.h". (STRINGIZE_1, STRINGIZE): Delete. (IPA_SYM): Use STRINGIFY instead. * common/preprocessor.h (STRINGIFY_1, STRINGIFY): New. * compile/compile-c-support.c: Include "common/preprocessor.h". (STR, STRINGIFY): Delete. * ia64-libunwind-tdep.c: Include "common/preprocessor.h". (STRINGIFY2, STRINGIFY): Delete.
2017-06-22common/agent.h: Add missing include guardsPedro Alves2-0/+9
gdb/ChangeLog: 2017-06-22 Pedro Alves <palves@redhat.com> * common/agent.h: Add include guards.
2017-06-21Use noncapturing subpattern/parens in gdb_test implementationKevin Buettner2-1/+6
This is the portion of gdb_test which performs the match against the RE (regular expression) passed to it: return [gdb_test_multiple $command $message { -re "\[\r\n\]*($pattern)\[\r\n\]+$gdb_prompt $" { if ![string match "" $message] then { pass "$message" } } In a test that I've been working on recently, I wanted to use a backreference - that's the \1 in the the RE below: gdb_test "info threads" \ {.*[\r\n]+\* +([0-9]+) +Thread[^\r\n]* do_something \(n=\1\) at.*} Put into English, I wanted to make sure that the value of n passed to do_something() is the same as the thread number shown in the "info threads" Id column. (I've structured the test case so that this *should* be the case.) It didn't work though. It turned out that ($pattern) in the RE noted above is capturing the attempted backreference. So, in this case, the backreference does not refer to ([0-9]+) as intended, but instead refers to ($pattern). This is wrong because it's not what I intended, but is also wrong because, if allowed, it could only match a string of infinite length. This problem can be fixed by using parens for a "noncapturing subpattern". The way that this is done, syntactically, is to use (?:$pattern) instead of ($pattern). My research shows that this feature has been present since tcl8.1 which was released in 1999. The current tcl version is 8.6 - at least that's what I have on my machine. It appears to me that mingw uses some subversion of tcl8.4 which will also have this feature (since 8.4 > 8.1). So it seems to me that any platform upon which we might wish to test GDB will have a version of tcl which has this feature. That being the case, my hope is that there won't be any objections to its use. When I looked at the implementation of gdb_test, I wondered whether the parens were needed at all. I've concluded that they are. In the event that $pattern is an RE which uses alternation at the top level, e.g. a|b, we need to make $pattern a subpattern (via parens) to limit the extend of the alternation. I.e, we don't want the alternation to extend to the other portions of the RE which gdb_test uses to match potential blank lines at the beginning of the pattern or the gdb prompt at the end. gdb/testsuite/ChangeLog: * gdb.exp (gdb_test): Using noncapturing parens for the $pattern subpattern.
2017-06-21Change to_xfer_partial doc to use addressable memory unitsSimon Marchi2-5/+13
The commit d309493 target: consider addressable unit size when reading/writing memory introduced the possibility of reading memory of targets with non-8-bit-bytes (e.g. memories that store 16 bits at each address). The documentation of target_read and target_write was updated accordingly, but to_xfer_partial, which is very related, wasn't updated. This commit fixes that. gdb/ChangeLog: * target.h (struct target_ops) <to_xfer_partial>: Update doc to talk about addressable units instead of bytes.
2017-06-20Fix PR gdb/21606: SYMBOL_FUNCTIONS_DOMAIN misspelled in documentationSergio Durigan Junior3-2/+9
Both Python and Guile documentations misspelled SYMBOL_FUNCTIONS_DOMAIN, writing SYMBOL_FUNCTION_DOMAIN instead. This obvious commit fixes it. gdb/doc/ChangeLog: 2017-06-20 Sergio Durigan Junior <sergiodj@redhat.com> PR gdb/21606 * python.texi (Python representation of Symbols.): Replace SYMBOL_FUNCTION_DOMAIN by SYMBOL_FUNCTIONS_DOMAIN, fixing typo. * guile.texi (Guile representation of Symbols.): Likewise.
2017-06-20gdbserver/Makefile.in: Sort IPA_OBJSSimon Marchi2-3/+16
gdb/gdbserver/ChangeLog: * Makefile.in (IPA_OBJS): Sort and format one item per line.
2017-06-20Use '::iterator' instead of '::const_iterator' on environ.c (and fix ↵Sergio Durigan Junior2-2/+7
breakage on early versions of libstdc++) Even though C++11 supports modifying containers using a const_iterator (e.g., calling the 'erase' method of a std::vector), early versions of libstdc++ did not implement that. Some of our buildslaves are using these versions (e.g., the AArch64 buildslave uses gcc 4.8.8), and my previous commit causes a breakage on them. The solution is simple: just use a normal iterator, without const. gdb/ChangeLog: 2017-06-20 Sergio Durigan Junior <sergiodj@redhat.com> * common/environ.c (gdb_environ::unset): Use '::iterator' instead of '::const_iterator'.
2017-06-20C++ify gdb/common/environ.cSergio Durigan Junior17-189/+376
As part of the preparation necessary for my upcoming task, I'd like to propose that we turn gdb_environ into a class. The approach taken here is simple: the class gdb_environ contains everything that is needed to manipulate the environment variables. These variables are stored in an std::vector<char *>, which can be converted to a 'char **' and passed as argument to functions that need it. The usage has not changed much. As per Pedro's suggestion, this class uses a static factory method initialization. This means that when an instance is created, it is initially empty. When needed, it has to be initialized using the static method 'from_host_environ'. As mentioned before, this is a preparation for an upcoming work that I will be posting in the next few weeks or so. For that work, I'll probably create another data structure that will contain all the environment variables that were set by the user using the 'set environment' command, because I'll need access to them. This will be much easier with the class-ification of gdb_environ. As noted, this has been regression-tested with the new version of environ.exp and no regressions were found. gdb/ChangeLog: 2017-06-20 Sergio Durigan Junior <sergiodj@redhat.com> * Makefile.in (SUBDIR_UNITTESTS_SRCS): Add 'unittests/environ-selftests.c'. (SUBDIR_UNITTESTS_OBS): Add 'environ-selftests.o'. * charset.c (find_charset_names): Declare object 'iconv_env'. Update code to use 'iconv_env' object. Remove call to 'free_environ'. * common/environ.c: Include <utility>. (make_environ): Delete function. (free_environ): Delete function. (gdb_environ::clear): New function. (gdb_environ::operator=): New function. (gdb_environ::get): Likewise. (environ_vector): Delete function. (set_in_environ): Delete function. (gdb_environ::set): New function. (unset_in_environ): Delete function. (gdb_environ::unset): New function. (gdb_environ::envp): Likewise. * common/environ.h: Include <vector>. (struct gdb_environ): Delete; transform into... (class gdb_environ): ... this class. (free_environ): Delete prototype. (init_environ, get_in_environ, set_in_environ, unset_in_environ, environ_vector): Likewise. * infcmd.c (run_command_1): Update code to call 'envp' from 'gdb_environ' class. (environment_info): Update code to call methods from 'gdb_environ' class. (unset_environment_command): Likewise. (path_info): Likewise. (path_command): Likewise. * inferior.c (inferior::~inferior): Delete call to 'free_environ'. (inferior::inferior): Initialize 'environment' using the host's information. * inferior.h: Remove forward declaration of 'struct gdb_environ'. Include "environ.h". (class inferior) <environment>: Change type from 'struct gdb_environ' to 'gdb_environ'. * mi/mi-cmd-env.c (mi_cmd_env_path): Update code to call methods from 'gdb_environ' class. * solib.c (solib_find_1): Likewise * unittests/environ-selftests.c: New file. gdb/gdbserver/ChangeLog: 2017-06-20 Sergio Durigan Junior <sergiodj@redhat.com> * linux-low.c (linux_create_inferior): Adjust code to access the environment information via 'gdb_environ' class. * lynx-low.c (lynx_create_inferior): Likewise. * server.c (our_environ): Make it an instance of 'gdb_environ'. (get_environ): Return a pointer to 'our_environ'. (captured_main): Initialize 'our_environ'. * server.h (get_environ): Adjust prototype. * spu-low.c (spu_create_inferior): Adjust code to access the environment information via 'gdb_environ' class.
2017-06-20Adjust the order of 32bit-linux.xml and 32bit-sse.xml in i386/i386-linux.xmlYao Qi3-4/+10
Exchange the order of 32bit-linux.xml and 32bit-sse.xml in i386/i386-linux.xml, to align with other i386 linux .xml files. gdb: 2017-06-20 Yao Qi <yao.qi@linaro.org> * features/i386/i386-linux.xml: Exchange the order of including 32bit-linux.xml and 32bit-sse.xml. * features/i386/i386-linux.c: Regenerated.
2017-06-20Class-fy tdesc_reg tdesc_type and tdesc_featureYao Qi2-100/+113
This patch class-fies them, adding ctor, dtor, and deleting copy ctor and assignment operator. gdb: 2017-06-20 Yao Qi <yao.qi@linaro.org> * target-descriptions.c (tdesc_reg): Add ctor, dtor. Delete copy ctor and assignment operator. (tdesc_type): Likewise. (tdesc_feature): Likewise. (tdesc_free_reg): Remove. (tdesc_create_reg): Use new. (tdesc_free_type): Remove. (tdesc_create_vector): Use new. (tdesc_create_union): Likewise. (tdesc_create_flags): Likewise. (tdesc_create_enum): Likewise. (tdesc_free_feature): Delete. (free_target_description): Use delete.
2017-06-19Don't throw an error in 'info registers' for unavailable MIPS registers.John Baldwin2-2/+13
'info registers' for MIPS throws an error and when it first encounters an unavailable register. This does not match other architectures which annotate unavailable registers and continue to print out the values of subsequent registers. Replace the error by displaying an aligned "<unavailable>". This string is truncated to "<unavl>" when displaying a 32-bit register. gdb/ChangeLog: * mips-tdep.c (print_gp_register_row): Don't error for unavailable registers.
2017-06-19Update GDB test case for new lnia extended mnemonic.Peter Bergner3-3/+9
When I added the new lnia extended mnemonic for addpcis, I updated the assembler/disassembler test cases, but overlooked the GDB test cases. This patch fixes that oversight and associated test case failure. * gdb.arch/powerpc-power9.exp: Update test case for new lnia extended mnemonic. * gdb.arch/powerpc-power9.s: Likewise.
2017-06-19.gdb_index writer: close the file before unlinking itPedro Alves2-1/+10
We should close the file before unlinking because on MS-Windows one cannot delete a file that is still open. I considered making 'gdb::unlinker::unlinker(const char *)' 'noexcept(true)' and then adding static_assert (noexcept (gdb::unlinker (filename.c_str ())), ""); but that doesn't really work because gdb::unlinker has a gdb_assert, which can throw a QUIT if/when the assertion fails. 'noexcept(true)' would cause GDB to abruptly terminate if/when the assertion fails. gdb/ChangeLog: 2017-06-19 Pedro Alves <palves@redhat.com> * dwarf2read.c (write_psymtabs_to_index): Construct file_closer after gdb::unlinker.
2017-06-19Use getenv instead of gdb_environ on mi-cmd-env.cSergio Durigan Junior2-8/+9
This is a spinoff of <https://sourceware.org/ml/gdb-patches/2017-06/msg00437.html>. mi-cmd-env.c is using the whole gdb_environ machinery in order to access just one variable, which can be easily replaced by a simple call to getenv. This patch does that, and doesn't cause regressions. gdb/ChangeLog: 2017-06-18 Sergio Durigan Junior <sergiodj@redhat.com> * mi/mi-cm-env.c (_initialize_mi_cmd_env): Use getenv instead of gdb_environ to access an environment variable.
2017-06-18nat/linux-ptrace.c: add missing gdb_byte* castThomas Petazzoni2-1/+6
On noMMU platforms, the following code gets compiled: child_stack = xmalloc (STACK_SIZE * 4); Where child_stack is a gdb_byte*, and xmalloc() returns a void*. While the lack of cast is valid in C, it is not in C++, causing the following build failure: ../nat/linux-ptrace.c: In function 'int linux_fork_to_function(gdb_byte*, int (*)(void*))': ../nat/linux-ptrace.c:273:29: error: invalid conversion from 'void*' to 'gdb_byte* {aka unsigned char*}' [-fpermissive] child_stack = xmalloc (STACK_SIZE * 4); Therefore, this commit adds the appropriate cast. gdb/ChangeLog: * nat/linux-ptrace.c (linux_fork_to_function): Add cast to gdb_byte*. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-06-17Add ATTRIBUTE_PRINTF to trace_start_errorSimon Marchi2-1/+5
clang complains that the fmt passed to vwarning in trace_start_error is not a literal. This looks like a fair warning, which can be removed by adding ATTRIBUTE_PRINTF to the declaration of trace_start_error. gdb/ChangeLog: * nat/fork-inferior.h (trace_start_error): Add ATTRIBUTE_PRINTF.
2017-06-17linux-low: Remove usage of "register" keywordSimon Marchi2-8/+13
AFAIK, the register keyword is not relevant today, and clang complains about it: /home/emaisin/src/binutils-gdb/gdb/gdbserver/linux-low.c:5873:3: error: 'register' storage class specifier is deprecated and incompatible with C++1z [-Werror,-Wdeprecated-register] register PTRACE_XFER_TYPE *buffer; ^~~~~~~~~ I think we can safely remove it. gdb/gdbserver/ChangeLog: * linux-low.c (linux_read_memory, linux_write_memory): Remove usage of "register" keyword.
2017-06-17gdb: Add -Wno-mismatched-tagsSimon Marchi5-3/+15
clang complains that for some types, we use both the class and struct keywords in different places. It's not really a problem, so I think we can safely turn this warning off. gdb/ChangeLog: * configure: Re-generate. * warning.m4 (build_warnings): Add -Wno-mismatched-tags. gdb/gdbserver/ChangeLog: * configure: Re-generate.
2017-06-17gdb: Use -Werror when checking for (un)supported warning flagsSimon Marchi5-9/+19
In warning.m4, we pass all the warning flags one by one to the compiler to test if they are supported by this particular compiler. If the compiler exits with an error, we conclude that this warning flag is not supported and exclude it. This allows us to use warning flags without having to worry about which versions of which compilers support each flag. clang, by default, only emits a warning if an unknown flag is passed: warning: unknown warning option '-Wfoo' [-Wunknown-warning-option] The result is that we think that all the warning flags we use are supported by clang (they are not), and the compilation fails later when building with -Werror, since the aforementioned warning becomes an error. The fix is to also pass -Werror when probing for supported flags, then we'll correctly get an error when using an unknown warning, and we'll exclude it: error: unknown warning option '-Wfoo' [-Werror,-Wunknown-warning-option] I am not sure why there is a change in a random comment in gdbserver/configure, but I suppose it's a leftfover from a previous patch, so I included it. gdb/ChangeLog: * configure: Re-generate. * warning.m4: Pass -Werror to compiler when checking for supported warning flags. gdb/gdbserver/ChangeLog: * configure: Re-generate.
2017-06-17gdb: Pass -x c++ to the compilerSimon Marchi4-2/+10
Because we are compiling .c files containing C++ code, clang++ complains with: clang: error: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated If renaming all the source files to .cpp is out of the question, an alternative is to pass "-x c++" to convince the compiler that we are really compiling C++. It works fine with GCC too. gdb/ChangeLog: * Makefile.in (COMPILE.pre): Add "-x c++". gdb/gdbserver/ChangeLog: * Makefile.in (COMPILE.pre): Add "-x c++".
2017-06-16extract/store integer function templateYao Qi6-179/+159
This patch converts functions extract_{unsigned,signed}_integer to a function template extract_integer, which has two instantiations. It also does the similar changes to store__{unsigned,signed}_integer, regcache::raw_read_{unsigned,signed}, regcache::raw_write_{unsigned,signed}, regcache::cooked_read_{unsigned,signed}, regcache::cooked_write_{unsigned,signed}. This patch was posted here https://sourceware.org/ml/gdb-patches/2017-05/msg00492.html but the problem was fixed in a different way. However, I think the patch is still useful to shorten the code. gdb: 2017-06-16 Alan Hayward <alan.hayward@arm.com> Pedro Alves <palves@redhat.com> Yao Qi <yao.qi@linaro.org> * defs.h (RequireLongest): New. (extract_integer): Declare function template. (extract_signed_integer): Remove the declaration, but define it static inline. (extract_unsigned_integer): Likewise. (store_integer): Declare function template. (store_signed_integer): Remove the declaration, but define it static inline. (store_unsigned_integer): Likewise. * findvar.c (extract_integer): New function template. (extract_signed_integer): Remove. (extract_unsigned_integer): Remove. (extract_integer<LONGEST>, extract_integer<ULONGEST>): Explicit instantiations. (store_integer): New function template. (store_signed_integer): Remove. (store_unsigned_integer): Remove. (store_integer): Explicit instantiations. * regcache.c (regcache_raw_read_signed): Update. (regcache::raw_read): New function. (regcache::raw_read_signed): Remove. (regcache::raw_read_unsigned): Remove. (regcache_raw_read_unsigned): Update. (regcache_raw_write_unsigned): Update. (regcache::raw_write_signed): Remove. (regcache::raw_write): New function. (regcache_cooked_read_signed): Update. (regcache::raw_write_unsigned): Remove. (regcache::cooked_read_signed): Remove. (regcache_cooked_read_unsigned): Update. (regcache::cooked_read_unsigned): Remove. (regcache_cooked_write_signed): Update. (regcache_cooked_write_unsigned): Update. * regcache.h (regcache) <raw_read_signed>: Remove. <raw_write_signed, raw_read_unsigned, raw_write_unsigned>: Remove. <raw_read, raw_write>: New. <cooked_read_signed, cooked_write_signed>: Remove. <cooked_write_unsigned, cooked_read_unsigned>: Remove. <cooked_read, cooked_write>: New. * sh64-tdep.c (sh64_pseudo_register_read): Update. (sh64_pseudo_register_write): Update.
2017-06-16arc: Select CPU model properly before disassemblingAnton Kolesov2-6/+65
Enforce CPU model for disassembler via its options, if it was specified in XML target description, otherwise use default method of determining CPU implemented in disassembler - scanning ELF private header. The latter requires disassemble_info->section to be properly initialized. To make sure that info->section is set in all cases this patch partially reverts [1] for ARC: it reinstates arc_delayed_print_insn as a "print_insn" function for ARC, but now this function only sets disassemble_info->section and then calls default_print_insn to do the rest of the job. Support for CPU in disassembler options for ARC has been added in [2]. [1] https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=39503f82427e22ed8e04d986ccdc8562091ec62e [2] https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=10045478d984f9924cb945423388ba25b7dd3ffe gdb/ChangeLog: yyyy-mm-dd Anton Kolesov <anton.kolesov@synopsys.com> * arc-tdep.c (arc_disassembler_options): New variable. (arc_gdbarch_init): Set and use it. Use arc_delayed_print_insn instead of default_print_insn. (arc_delayed_print_insn): Set info->section when needed, use default_print_insn to retrieve a disassembler.
generated by cgit v1.1 at 2025-02-07 10:30:23 +0000