aboutsummaryrefslogtreecommitdiff
path: root/gdb/testsuite
AgeCommit message (Collapse)AuthorFilesLines
2019-02-28Can't interrupt process without controlling terminal on Solaris (PR gdb/8527)Rainer Orth3-0/+158
If gdb attaches to a process that either has no controlling terminal, or the controlling terminal differs from the one gdb is running under, break/^C doesn't interrupt the debugged process on Solaris. Fixed as follows, analogous to what all all other targets do. Patch from the PR, recently re-submitted by Brian Vandenberg. Tested on amd64-pc-solaris2.11, sparcv9-sun-solaris2.11, and x86_64-pc-linux-gnu. 2019-02-28 Brian Vandenberg <phantall@gmail.com> Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> gdb: PR gdb/8527 * procfs.c (proc_wait_for_stop): Wrap write of PCWSTOP in set_sigint_trap, clear_sigint_trap. gdb/testsuite: PR gdb/8527 * gdb.base/interrupt-daemon-attach.c, gdb.base/interrupt-daemon-attach.exp: New test.
2019-02-27Test "set width/height -1"Pedro Alves2-0/+7
As a follow up to the previous commit, add a test for "set width/height -1", to make sure we don't overflow in readline with negative values either. gdb/testsuite/ChangeLog: 2019-02-27 Pedro Alves <palves@redhat.com> * gdb.base/page.exp: Add tests for "set width/height -1".
2019-02-27Make 'show width/height' display "unlimited" when capped for readlinePedro Alves2-0/+29
When we cap the height/width sizes before passing to readline, tweak the corresponding command variable to show "unlimited": (gdb) set height 0x8000 (gdb) show height Number of lines gdb thinks are in a page is unlimited. Instead of the current output: (gdb) set height 0x8000 (gdb) show height Number of lines gdb thinks are in a page is 32768. gdb/ChangeLog: 2019-02-27 Pedro Alves <palves@redhat.com> * utils.c (set_screen_size): When we cap the height/width sizes, tweak the corresponding command variable to show "unlimited": gdb/testsuite/ChangeLog: 2019-02-27 Pedro Alves <palves@redhat.com> * gdb.base/page.exp: Add tests for "set/show width/height" with "infinite" values.
2019-02-27Remove Python 2.4 and 2.5 supportTom Tromey3-19/+7
This removes all the remainings spots I could find that work around issues in Python 2.4 and 2.5. I don't have a good way to test that Python 2.6 still works. Tested by the buildbot. gdb/ChangeLog 2019-02-27 Tom Tromey <tromey@adacore.com> * config.in, configure: Rebuild. * configure.ac (HAVE_LIBPYTHON2_4, HAVE_LIBPYTHON2_5): Never define. * python/py-value.c: Remove Python 2.4 workaround. * python/py-utils.c (gdb_pymodule_addobject): Remove Python 2.4 workaround. * python/py-type.c (convert_field, gdbpy_initialize_types): Remove Python 2.4 workaround. * python/python-internal.h: Remove Python 2.4 comment. (Py_ssize_t): Don't define. (PyVarObject_HEAD_INIT, Py_TYPE): Don't define. (gdb_Py_DECREF): Remove Python 2.4 workaround. (gdb_PyObject_GetAttrString, PyObject_GetAttrString): Remove. (gdb_PyObject_HasAttrString, PyObject_HasAttrString): Remove. * python/python.c (do_start_initialization): Remove Python 2.4 workaround. * python/py-prettyprint.c (class dummy_python_frame): Remove. (print_children): Remove Python 2.4 workaround. * python/py-inferior.c (buffer_procs): Remove Python 2.4 workaround. (CHARBUFFERPROC_NAME): Remove. * python/py-breakpoint.c (gdbpy_initialize_breakpoints): Remove Python 2.4 workaround. gdb/testsuite/ChangeLog 2019-02-27 Tom Tromey <tromey@adacore.com> * lib/gdb.exp (skip_python_tests_prompt): Don't check for Python 2.4. * gdb.python/py-finish-breakpoint.exp: Remove Python 2.4 workaround. gdb/ChangeLog 2019-02-27 Tom Tromey <tromey@adacore.com> * config.in, configure: Rebuild. * configure.ac (HAVE_LIBPYTHON2_4, HAVE_LIBPYTHON2_5): Never define. * python/py-value.c: Remove Python 2.4 workaround. * python/py-utils.c (gdb_pymodule_addobject): Remove Python 2.4 workaround. * python/py-type.c (convert_field, gdbpy_initialize_types): Remove Python 2.4 workaround. * python/python-internal.h: Remove Python 2.4 comment. (Py_ssize_t): Don't define. (PyVarObject_HEAD_INIT, Py_TYPE): Don't define. (gdb_Py_DECREF): Remove Python 2.4 workaround. (gdb_PyObject_GetAttrString, PyObject_GetAttrString): Remove. (gdb_PyObject_HasAttrString, PyObject_HasAttrString): Remove. * python/python.c (do_start_initialization): Remove Python 2.4 workaround. * python/py-prettyprint.c (class dummy_python_frame): Remove. (print_children): Remove Python 2.4 workaround. * python/py-inferior.c (buffer_procs): Remove Python 2.4 workaround. (CHARBUFFERPROC_NAME): Remove. * python/py-breakpoint.c (gdbpy_initialize_breakpoints): Remove Python 2.4 workaround.
2019-02-27gdb: Handle alignment for C++ structures with static membersAndrew Burgess2-53/+132
In 'type_align' when computing the alignment of a structure we should not consider the alignment of static structure members, these are usually stored outside of the structure and therefore don't have any impact on the structures alignment requirements. I've extended the existing alignment calculating test to compile in both C and C++ now so that we can create structures with static members. gdb/ChangeLog: * gdbtypes.c (type_align): Don't consider static members when computing structure alignment. gdb/testsuite/ChangeLog: * gdb.base/align.exp: Extend to compile in both C and C++, and add tests for structs with static members.
2019-02-26Fix new py-value.exp test caseTom Tromey2-1/+6
The new test case in py-value.exp fails -- the code was changed to throw ValueError, but the test still checks for TypeError. This patch fixes the problem. I'm checking this in. Tested on x86-64 Fedora 29. gdb/testsuite/ChangeLog 2019-02-26 Tom Tromey <tromey@adacore.com> * gdb.python/py-value.exp (test_value_from_buffer): Check for ValueError, not TypeError.
2019-02-26Add tests for gdb.Value(bufobj, type) constructorKevin Buettner2-0/+50
gdb/testsuite/ChangeLog: * gdb.python/py-value.exp (test_value_from_buffer): New proc with call from main program.
2019-02-23Update copyright year range in gdb.ada/mi_ref_changeable testcaseJoel Brobecker6-5/+13
This patch fixes the copyright year range which escaped the 2019 update, because the patch was submitted in 2018, but only really pushed in 2019. Pushed: https://www.sourceware.org/ml/gdb-patches/2019-02/msg00109.html Submitted: https://www.sourceware.org/ml/gdb-patches/2018-12/msg00444.html We normally are pretty good at remembering those little things, but this one fell through the cracks. This commit fixes this, by re-running the copyright.py script and checking in the changes made by that script. gdb/testsuite/ChangeLog: * gdb.ada/mi_ref_changeable.exp: Update copyright year range. * gdb.ada/mi_ref_changeable/foo_rb20_056.adb: Likewise. * gdb.ada/mi_ref_changeable/pck.adb: Likewise. * gdb.ada/mi_ref_changeable/pck.ads: Likewise. * gdb.dwarf2/inlined_subroutine-inheritance.exp: Likewise.
2019-02-22Add missing ChangeLog entries for commit ↵Keith Seitz1-0/+6
bb995d00b3eef2f48d0be895c3509a7ddd8280a1
2019-02-22Fix symtab/23853: symlinked default symtabKeith Seitz2-0/+71
This patch attempts to fix a bug dealing with setting breakpoints in default symtabs that are symlinks. For example: (gdb) list 11 GNU General Public License for more details. 12 13 You should have received a copy of the GNU General Public License 14 along with this program. If not, see <http://www.gnu.org/licenses/>. */ 15 16 static int 17 foo (void) 18 { 19 return 0; /* break here */ 20 } (gdb) 21 22 int 23 main (void) 24 { 25 return foo (); 26 } (gdb) b 19 No line 19 in the current file. Make breakpoint pending on future shared library load? (y or [n]) The problem here is that when create_sals_line_offset sets the default symtab, it immediately calls symtab_to_fullname, passing that fullname to collect_symtabs_from_filename to find all matching symtabs. This fails because we end up looking for a symtab with the name of the actual file on disk (which is different in this case because of the symlink) instead of the one stored in the debug info. Since we already have the lookup name of the default symtab, use it instead of the fullname. [This fullname thing was originally added in 2007 in a series dealing with *displaying* absolute file names. Clearly, this instance has nothing to do with the display of file names.] gdb/ChangeLog PR symtab/23853 * linespec.c (create_sals_line_offset): Search for the default symtab's filename instead of its fullname. gdb/testsuite/ChangeLog PR symtab/23853 * gdb.base/symlink-sourcefile.c: New file. * gdb.base/symlink-sourcefile.exp: New file.
2019-02-20Fix typos in symtab_symbol_infoTom Tromey2-2/+6
symtab_symbol_info has a couple of messages that say "regulation expression". I think "regular expression" was meant, so this patch changes it. gdb/ChangeLog 2019-02-20 Tom Tromey <tom@tromey.com> * symtab.c (symtab_symbol_info): Fix typos. gdb/testsuite/ChangeLog 2019-02-20 Tom Tromey <tom@tromey.com> * gdb.base/info_qt.exp: Update.
2019-02-19Fix error message and use-after-free on errors in nested sourced filesSimon Marchi4-9/+44
Errors that happen in nested sourced files (when a sourced file sources another file) lead to a wrong error message, or use-after-free. For example, if I put this in "a.gdb": command_that_doesnt_exist and this in "b.gdb": source a.gdb and try to "source b.gdb" in GDB, the result may look like this: (gdb) source b.gdb b.gdb:1: Error in sourced command file: _that_doesnt_exist:1: Error in sourced command file: Undefined command: "command_that_doesnt_exist". Try "help". Notice the wrong file name where "a.gdb" should be. The exact result may differ, depending on the feelings of the memory allocator. What happens is: - The "source a.gdb" command is saved by command_line_append_input_line in command_line_input's static buffer. - Since we are sourcing a file, the script_from_file function stores the script name (a.gdb) in the source_file_name global. However, it doesn't do a copy, it just saves a pointer to command_line_input's static buffer. - The "command_that_doesnt_exist" command is saved by command_line_append_input_line in command_line_input's static buffer. Depending on what xrealloc does, source_file_name may now point to freed memory, or at the minimum the data it was pointing to was overwritten. - When the error is handled in script_from_file, we dererence source_file_name to print the name of the file in which the error occured. To fix it, I made source_file_name an std::string, so that keeps a copy of the file name instead of pointing to a buffer with a too small lifetime. With this patch, the expected filename is printed, and no use-after-free occurs: (gdb) source b.gdb b.gdb:1: Error in sourced command file: a.gdb:1: Error in sourced command file: Undefined command: "command_that_doesnt_exist". Try "help". I passed explicit template parameters to make_scoped_restore (<std::string, const std::string &>), so that the second parameter is passed by reference and avoid a copy. It was not as obvious as I first thought to change gdb.base/source.exp to test this, because source commands inside sourced files are interpreted relative to GDB's current working directory, not the directory of the currently sourced file. As a workaround, I moved the snippet that tests errors after the snippet that adds the source directory to the search path. This way, the "source source-error-1.gdb" line in source-error.exp manages to find the file. For reference, here is what ASAN reports when use-after-free occurs: (gdb) source b.gdb ================================================================= ==18498==ERROR: AddressSanitizer: heap-use-after-free on address 0x60c000019847 at pc 0x7f1d3645de8e bp 0x7ffdcb892e50 sp 0x7ffdcb8925c8 READ of size 6 at 0x60c000019847 thread T0 #0 0x7f1d3645de8d in printf_common /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors_format.inc:546 #1 0x7f1d36477175 in __interceptor_vasprintf /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:1525 #2 0x5632eaffa277 in xstrvprintf(char const*, __va_list_tag*) /home/simark/src/binutils-gdb/gdb/common/common-utils.c:122 #3 0x5632eaff96d1 in throw_it /home/simark/src/binutils-gdb/gdb/common/common-exceptions.c:351 #4 0x5632eaff98df in throw_verror(errors, char const*, __va_list_tag*) /home/simark/src/binutils-gdb/gdb/common/common-exceptions.c:379 #5 0x5632eaff9a2a in throw_error(errors, char const*, ...) /home/simark/src/binutils-gdb/gdb/common/common-exceptions.c:394 #6 0x5632eafca21a in script_from_file(_IO_FILE*, char const*) /home/simark/src/binutils-gdb/gdb/cli/cli-script.c:1553 #7 0x5632eaf8a500 in source_script_from_stream /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:569 #8 0x5632eaf8a735 in source_script_with_search /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:605 #9 0x5632eaf8ab20 in source_command /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:664 #10 0x5632eafa8b4a in do_const_cfunc /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:106 #11 0x5632eafb0687 in cmd_func(cmd_list_element*, char const*, int) /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:1892 #12 0x5632ebf3dd87 in execute_command(char const*, int) /home/simark/src/binutils-gdb/gdb/top.c:630 #13 0x5632eb3b25d3 in command_handler(char const*) /home/simark/src/binutils-gdb/gdb/event-top.c:583 #14 0x5632ebf3cf09 in read_command_file(_IO_FILE*) /home/simark/src/binutils-gdb/gdb/top.c:425 #15 0x5632eafca054 in script_from_file(_IO_FILE*, char const*) /home/simark/src/binutils-gdb/gdb/cli/cli-script.c:1547 #16 0x5632eaf8a500 in source_script_from_stream /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:569 #17 0x5632eaf8a735 in source_script_with_search /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:605 #18 0x5632eaf8ab20 in source_command /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:664 #19 0x5632eafa8b4a in do_const_cfunc /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:106 #20 0x5632eafb0687 in cmd_func(cmd_list_element*, char const*, int) /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:1892 #21 0x5632ebf3dd87 in execute_command(char const*, int) /home/simark/src/binutils-gdb/gdb/top.c:630 #22 0x5632eb3b25d3 in command_handler(char const*) /home/simark/src/binutils-gdb/gdb/event-top.c:583 #23 0x5632eb3b2f87 in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) /home/simark/src/binutils-gdb/gdb/event-top.c:770 #24 0x5632eb3b0fe1 in gdb_rl_callback_handler /home/simark/src/binutils-gdb/gdb/event-top.c:213 #25 0x5632ec1c8729 in rl_callback_read_char /home/simark/src/binutils-gdb/readline/callback.c:220 #26 0x5632eb3b0b8f in gdb_rl_callback_read_char_wrapper_noexcept /home/simark/src/binutils-gdb/gdb/event-top.c:175 #27 0x5632eb3b0da1 in gdb_rl_callback_read_char_wrapper /home/simark/src/binutils-gdb/gdb/event-top.c:192 #28 0x5632eb3b2186 in stdin_event_handler(int, void*) /home/simark/src/binutils-gdb/gdb/event-top.c:511 #29 0x5632eb3aa6a9 in handle_file_event /home/simark/src/binutils-gdb/gdb/event-loop.c:733 #30 0x5632eb3aaf41 in gdb_wait_for_event /home/simark/src/binutils-gdb/gdb/event-loop.c:859 #31 0x5632eb3a88ea in gdb_do_one_event() /home/simark/src/binutils-gdb/gdb/event-loop.c:347 #32 0x5632eb3a89bf in start_event_loop() /home/simark/src/binutils-gdb/gdb/event-loop.c:371 #33 0x5632eb76fbfc in captured_command_loop /home/simark/src/binutils-gdb/gdb/main.c:330 #34 0x5632eb772ea8 in captured_main /home/simark/src/binutils-gdb/gdb/main.c:1176 #35 0x5632eb773071 in gdb_main(captured_main_args*) /home/simark/src/binutils-gdb/gdb/main.c:1192 #36 0x5632eabfe7f9 in main /home/simark/src/binutils-gdb/gdb/gdb.c:32 #37 0x7f1d3554f222 in __libc_start_main (/usr/lib/libc.so.6+0x24222) #38 0x5632eabfe5dd in _start (/home/simark/build/binutils-gdb/gdb/gdb+0x195d5dd) 0x60c000019847 is located 7 bytes inside of 128-byte region [0x60c000019840,0x60c0000198c0) freed by thread T0 here: #0 0x7f1d36502491 in __interceptor_realloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:105 #1 0x5632eaff9f47 in xrealloc /home/simark/src/binutils-gdb/gdb/common/common-utils.c:62 #2 0x5632eaff6b44 in buffer_grow(buffer*, char const*, unsigned long) /home/simark/src/binutils-gdb/gdb/common/buffer.c:40 #3 0x5632eb3b271d in command_line_append_input_line /home/simark/src/binutils-gdb/gdb/event-top.c:614 #4 0x5632eb3b28c6 in handle_line_of_input(buffer*, char const*, int, char const*) /home/simark/src/binutils-gdb/gdb/event-top.c:654 #5 0x5632ebf402a6 in command_line_input(char const*, char const*) /home/simark/src/binutils-gdb/gdb/top.c:1252 #6 0x5632ebf3cee9 in read_command_file(_IO_FILE*) /home/simark/src/binutils-gdb/gdb/top.c:422 #7 0x5632eafca054 in script_from_file(_IO_FILE*, char const*) /home/simark/src/binutils-gdb/gdb/cli/cli-script.c:1547 #8 0x5632eaf8a500 in source_script_from_stream /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:569 #9 0x5632eaf8a735 in source_script_with_search /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:605 #10 0x5632eaf8ab20 in source_command /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:664 #11 0x5632eafa8b4a in do_const_cfunc /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:106 #12 0x5632eafb0687 in cmd_func(cmd_list_element*, char const*, int) /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:1892 #13 0x5632ebf3dd87 in execute_command(char const*, int) /home/simark/src/binutils-gdb/gdb/top.c:630 #14 0x5632eb3b25d3 in command_handler(char const*) /home/simark/src/binutils-gdb/gdb/event-top.c:583 #15 0x5632ebf3cf09 in read_command_file(_IO_FILE*) /home/simark/src/binutils-gdb/gdb/top.c:425 #16 0x5632eafca054 in script_from_file(_IO_FILE*, char const*) /home/simark/src/binutils-gdb/gdb/cli/cli-script.c:1547 #17 0x5632eaf8a500 in source_script_from_stream /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:569 #18 0x5632eaf8a735 in source_script_with_search /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:605 #19 0x5632eaf8ab20 in source_command /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:664 #20 0x5632eafa8b4a in do_const_cfunc /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:106 #21 0x5632eafb0687 in cmd_func(cmd_list_element*, char const*, int) /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:1892 #22 0x5632ebf3dd87 in execute_command(char const*, int) /home/simark/src/binutils-gdb/gdb/top.c:630 #23 0x5632eb3b25d3 in command_handler(char const*) /home/simark/src/binutils-gdb/gdb/event-top.c:583 #24 0x5632eb3b2f87 in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) /home/simark/src/binutils-gdb/gdb/event-top.c:770 #25 0x5632eb3b0fe1 in gdb_rl_callback_handler /home/simark/src/binutils-gdb/gdb/event-top.c:213 #26 0x5632ec1c8729 in rl_callback_read_char /home/simark/src/binutils-gdb/readline/callback.c:220 #27 0x5632eb3b0b8f in gdb_rl_callback_read_char_wrapper_noexcept /home/simark/src/binutils-gdb/gdb/event-top.c:175 #28 0x5632eb3b0da1 in gdb_rl_callback_read_char_wrapper /home/simark/src/binutils-gdb/gdb/event-top.c:192 #29 0x5632eb3b2186 in stdin_event_handler(int, void*) /home/simark/src/binutils-gdb/gdb/event-top.c:511 previously allocated by thread T0 here: #0 0x7f1d36502491 in __interceptor_realloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:105 #1 0x5632eaff9f47 in xrealloc /home/simark/src/binutils-gdb/gdb/common/common-utils.c:62 #2 0x5632eaff6b44 in buffer_grow(buffer*, char const*, unsigned long) /home/simark/src/binutils-gdb/gdb/common/buffer.c:40 #3 0x5632eb3b271d in command_line_append_input_line /home/simark/src/binutils-gdb/gdb/event-top.c:614 #4 0x5632eb3b28c6 in handle_line_of_input(buffer*, char const*, int, char const*) /home/simark/src/binutils-gdb/gdb/event-top.c:654 #5 0x5632ebf402a6 in command_line_input(char const*, char const*) /home/simark/src/binutils-gdb/gdb/top.c:1252 #6 0x5632ebf3cee9 in read_command_file(_IO_FILE*) /home/simark/src/binutils-gdb/gdb/top.c:422 #7 0x5632eafca054 in script_from_file(_IO_FILE*, char const*) /home/simark/src/binutils-gdb/gdb/cli/cli-script.c:1547 #8 0x5632eaf8a500 in source_script_from_stream /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:569 #9 0x5632eaf8a735 in source_script_with_search /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:605 #10 0x5632eaf8ab20 in source_command /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:664 #11 0x5632eafa8b4a in do_const_cfunc /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:106 #12 0x5632eafb0687 in cmd_func(cmd_list_element*, char const*, int) /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:1892 #13 0x5632ebf3dd87 in execute_command(char const*, int) /home/simark/src/binutils-gdb/gdb/top.c:630 #14 0x5632eb3b25d3 in command_handler(char const*) /home/simark/src/binutils-gdb/gdb/event-top.c:583 #15 0x5632eb3b2f87 in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) /home/simark/src/binutils-gdb/gdb/event-top.c:770 #16 0x5632eb3b0fe1 in gdb_rl_callback_handler /home/simark/src/binutils-gdb/gdb/event-top.c:213 #17 0x5632ec1c8729 in rl_callback_read_char /home/simark/src/binutils-gdb/readline/callback.c:220 #18 0x5632eb3b0b8f in gdb_rl_callback_read_char_wrapper_noexcept /home/simark/src/binutils-gdb/gdb/event-top.c:175 #19 0x5632eb3b0da1 in gdb_rl_callback_read_char_wrapper /home/simark/src/binutils-gdb/gdb/event-top.c:192 #20 0x5632eb3b2186 in stdin_event_handler(int, void*) /home/simark/src/binutils-gdb/gdb/event-top.c:511 #21 0x5632eb3aa6a9 in handle_file_event /home/simark/src/binutils-gdb/gdb/event-loop.c:733 #22 0x5632eb3aaf41 in gdb_wait_for_event /home/simark/src/binutils-gdb/gdb/event-loop.c:859 #23 0x5632eb3a88ea in gdb_do_one_event() /home/simark/src/binutils-gdb/gdb/event-loop.c:347 #24 0x5632eb3a89bf in start_event_loop() /home/simark/src/binutils-gdb/gdb/event-loop.c:371 #25 0x5632eb76fbfc in captured_command_loop /home/simark/src/binutils-gdb/gdb/main.c:330 #26 0x5632eb772ea8 in captured_main /home/simark/src/binutils-gdb/gdb/main.c:1176 #27 0x5632eb773071 in gdb_main(captured_main_args*) /home/simark/src/binutils-gdb/gdb/main.c:1192 #28 0x5632eabfe7f9 in main /home/simark/src/binutils-gdb/gdb/gdb.c:32 #29 0x7f1d3554f222 in __libc_start_main (/usr/lib/libc.so.6+0x24222) SUMMARY: AddressSanitizer: heap-use-after-free /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors_format.inc:546 in printf_common gdb/ChangeLog: * top.h (source_file_name): Change to std::string. * top.c (source_file_name): Likewise. (command_line_input): Adjust. * cli/cli-script.c (script_from_file): Adjust. gdb/testsuite/ChangeLog: * gdb.base/source.exp: Move "error in sourced script" code to the end. * gdb.base/source-error.gdb: Move contents to source-error-1.gdb. Add new code to source source-error-1.gdb. * gdb.base/source-error-1.gdb: New file, from previous source-error.gdb.
2019-02-17Add styling to macro commandsTom Tromey3-1/+23
This adds filename styling to "info macro". gdb/ChangeLog 2019-02-17 Tom Tromey <tom@tromey.com> * macrocmd.c (show_pp_source_pos): Style the file names. gdb/testsuite/ChangeLog 2019-02-17 Tom Tromey <tom@tromey.com> * gdb.base/style.exp: Use -g3 to compile when possible. Add test for macro styling. * gdb.base/style.c (SOME_MACRO): New macro.
2019-02-17Fix pager bugs with style outputTom Tromey3-0/+37
I believe this fixes all the pager output problems with styling that Philippe pointed out, plus at least one more. The patch is somewhat hard to reason about, so you may wish to give it a try. Even writing the tests was hard. This removes the style caching, because it was difficult to keep the style cache correct in all cases. Since this would cause more style escapes to be emitted, instead it changes fputs_styled to try to avoid unnecessary changes. Another bug was that the wrap buffer was not flushed in the case where wrap_column==0. In the old (pre-patch series) code, characters were directly emitted in this case; so flushing the wrap buffer here restores this behavior. On error the wrap buffer must be emptied. Otherwise, interrupting output can leave characters in the buffer that will be emitted later. As discussed on gdb-patches, this fixes the ada-lang.c problem where filtered and unfiltered printing were mixed. Now user_select_syms uses filtered printing, which is what its callees were already doing. Finally, it was possible for source line highlighting to be garbled (and invalid escape sequences emitted) if the pager was invoked at the wrong spot. To fix this, the patch arranges for source line escapes to always be emitted as a unit. gdb/ChangeLog 2019-02-17 Tom Tromey <tom@tromey.com> * ada-lang.c (user_select_syms): Use filtered printing. * utils.c (wrap_style): New global. (desired_style): Remove. (emit_style_escape): Add stream parameter. (set_output_style, reset_terminal_style, prompt_for_continue): Update. (flush_wrap_buffer): Only flush gdb_stdout. (wrap_here): Set wrap_style. (fputs_maybe_filtered): Clear the wrap buffer on exception. Don't treat escape sequences as a character. Change when wrap buffer is flushed. (fputs_styled): Do not set the output style when the default is requested. * ui-style.h (struct ui_file_style) <is_default>: New method. * source.c (print_source_lines_base): Emit escape sequences in one piece. gdb/testsuite/ChangeLog 2019-02-17 Tom Tromey <tom@tromey.com> * gdb.base/style.exp: Add line-wrapping tests. * gdb.base/page.exp: Add test for quitting during pagination.
2019-02-17(Ada) fix GDB crash printing packed arrayJoel Brobecker6-1/+140
Trying to print a packed array sometimes leads to a crash (see attached testcase for an example of when this happens): | (gdb) p bad | [1] 65571 segmentation fault gdb -q foo Variable "bad" is declared in the debug information as an array where the array's type name has an XPnnn suffix: | .uleb128 0xc # (DIE (0x566) DW_TAG_typedef) | .long .LASF200 # DW_AT_name: "pck__t___XP1" | [loc info attributes snipped] | .long 0x550 # DW_AT_type | .byte 0x1 # DW_AT_alignment The signals to GDB that the debugging information follows a GNAT encoding used for packed arrays, and an in order to decode it, we need to find the type whose name is the same minus the "___XPnnn" suffix: "pck__t". For that, we make a call to ada-lang.c::standard_lookup, which is a simple function which essentially does: | /* Return the result of a standard (literal, C-like) lookup of NAME in | given DOMAIN, visible from lexical block BLOCK. */ | | [...] | sym = lookup_symbol_in_language (name, block, domain, language_c, 0); Unfortunately for us, while the intent of this call was to perform an exact-match lookup, in our case, it returns ... type pck__t___XP1 instead! In other words, it finds itself back. The reason why it finds this type is a confluence of two factors: (1) Forcing the lookup into language_c currently does not affect how symbol matching is done anymore, because we look at the symbol's language to determine which kind of matching should be done; (2) The lookup searches the local context (via block) first, beforei doing a more general lookup. And looking at the debug info for the main subprogram, we see that type "pck__t" is not declared there, only in the debug info for pck.ads. In other words, there is no way that we accidently find "pck__t" by random chance. I believe Pedro added a new function called ada_lookup_encoded_symbol for that specific purpose, so I started by replacing the lookup by language above by this. Unfortunately, still no joy. This was because, even though ada_lookup_encoded_symbol puts angle- brackets around the search name to signal that we want a verbatim search, we end up losing that information in the function called to compare a symbol with the search name: | static bool | do_full_match (const char *symbol_search_name, | const lookup_name_info &lookup_name, | completion_match_result *comp_match_res) | { | return full_match (symbol_search_name, ada_lookup_name (lookup_name)); ^^^^^^^^^^^^^^^ | <=> lookup_name.m_ada.m_encoded_name (no angle brackets) The way I fixed this was by introducing a new function called do_exact_match, and then adjust ada_get_symbol_name_matcher to return that function when seeing that we have a verbatim non-wild-match search. As it happens, this fixes an incorrect test in gdb.ada/homony.exp, where we were inserting a breakpoint on a symbol using the angle-brackets notation, and got 2 locations for that breakpoint... (gdb) b <homonym__get_value> Breakpoint 1 at 0x4029fc: <homonym__get_value>. (2 locations) ... each location being in a different function: (gdb) info break Num Type Disp Enb Address What 1 breakpoint keep y <MULTIPLE> 1.1 y 0x00000000004029fc in homonym.get_value at /[...]/homonym.adb:32 1.2 y 0x0000000000402a3a in homonym.get_value at /[...]/homonym.adb:50 (gdb) x /i 0x00000000004029fc 0x4029fc <homonym__get_value+8>: movl $0x1d,-0x4(%rbp) (gdb) x /i 0x0000000000402a3a 0x402a3a <homonym__get_value__2+8>: movl $0x11,-0x4(%rbp) Since we used angle-brackets, we shouldn't be matching the second one, something this patch fixes. gdb/ChangeLog: * ada-lang.c (standard_lookup): Use ada_lookup_encoded_symbol instead of lookup_symbol_in_language (do_exact_match): New function. (ada_get_symbol_name_matcher): Return do_exact_match when doing a verbatim match. gdb/testsuite/ChangeLog: * gdb.ada/big_packed_array: New testcase. * gdb.ada/homonym.exp: Fix incorrect expected output for "break <homonym__get_value>" test. Tested on x86_64-linux.
2019-02-14Updating test caseWeimin Pan3-13/+17
gdb.arch/aarch64-dbreg-contents.exp: * Replaced "run" with "runto_main + continue". * Replaced "gdb_compile + clean_restart" with "prepare_for_testing". * Added comment for case "exited with code 01". gdb.arch/aarch64-dbreg-contents.c: * Removed SET_WATCHPOINT marco. * Removed redundent cleanup (). * Cleaned up comment.
2019-02-13Adding a test caseWeimin Pan3-0/+185
gdb/testsuite/ChangeLog 2019-02-12 Weimin Pan <weimin.pan@oracle.com> PR breakpoints/21870 * gdb.arch/aarch64-dbreg-contents.exp: New file. * gdb.arch/aarch64-dbreg-contents.c: New file.
2019-02-10(Ada) -var-update crash for variable whose type is a reference to changeableJoel Brobecker5-0/+149
Consider the following variable, which is a string whose value is not known at compile time, because it is the return value from a function call (Get_Name): A : String := Get_Name; If one tries to create a varobj for that variable, everything works as expected: | (gdb) -var-create a * a | ^done,name="a",numchild="19",value="[19] \"Some kind of string\"",type="<ref> array (1 .. 19) of character",thread-id="1",has_more="0" However, try then to request an update, regardless of whether the string has changed or not, and we get a crash: | -var-update a | ~"/[...]/gdb/varobj.c:1379: internal-error: bool install_new_value(varobj*, value*, bool): Assertion `!value_lazy (var->value.get ())' failed.\nA problem internal to GDB has been detected,\nfurther debugging may prove unreliable.\nQuit this debugging session? (y or n) " When the varobj gets created (-var-create), the expression is evaluated and transformed into a value. The debugging information describes our variables as a reference to an array of characters, so our value has the corresponding type. We then call varobj.c::install_new_value to store that value inside our varobj, and we see that this function pretty starts by determining weither our varobj is changeable, via: | changeable = varobj_value_is_changeable_p (var); (where 'var' is the varobj we are building, and where the function varobj_value_is_changeable_p simply dispatches to the Ada version of this routine: ada_value_is_changeable_p). At this point, the varobj doesn't have a value, yet, but it does have a type which was provided by varobj_create a little bit before install_new_value was called. So ada_value_is_changeable_p uses that to determine whether or not our type is changeable. Since our type is a reference to an array, and that the value of such objects is displayed as if there weren't a reference, it means that our object is changeable -- in other words, if an element of the string changes, then the "value" field of the varobj will change accordingly. But unfortunately, ada_value_is_changeable_p mistakenly returns false, because it is missing the handling of reference types. As a consequence of this, install_new_value doesn't feel it is necessary to fetch the value's contents, as explained by the following comment inside that function: /* The new value might be lazy. If the type is changeable, that is we'll be comparing values of this type, fetch the value now. Otherwise, on the next update the old value will be lazy, which means we've lost that old value. */ This means that a lazy value gets installed inside our varobj as a result of the mistake in ada_value_is_changeable_p. Another important detail is that, after determining whether our varobj is changeable or not, it then purposefully removes the reference layer from our value: /* We are not interested in the address of references, and given that in C++ a reference is not rebindable, it cannot meaningfully change. So, get hold of the real value. */ if (value) value = coerce_ref (value); The consequence of those two facts on shows up only later, when the user requests an update (-var-update). When doing so, GDB evaluates the expression again into a value which is once more a reference to a string, and then calls install_new_value again to install the new value and report any changes. This time around, the call to... | changeable = varobj_value_is_changeable_p (var); ... now gets a varobj which has a value, and one which had the reference layer removed! So, this time, we classify the varobj correctly, and say it is changeable. And because it is changeable, we then go into the section of code in install_new_value which checks for changes, where we need the varobj's value to not be lazy, as explained by the comment we quoted above. That's what the assertion was about. This patch fixes the issues by teaching ada_value_is_changeable_p to ignore reference layers when evaluating a given varobj's type. gdb/ChangeLog: * ada-varobj.c (ada_value_is_changeable_p): Add handling of TYPE_CODE_REF types. gdb/testsuite/ChangeLog: * gdb.ada/mi_ref_changeable: New testcase. Prior to this patch, this testcase reports 2 unresolved tests (due to GDB hitting the internal error). With this patch, all tests in this testcase pass. Tested on x86_64-linux, no regression.
2019-02-07gdbserver: When attaching, add process before lwpsAlan Hayward2-21/+88
The recent BP/WP changes for AArch64 swapping the order in add_lwp() so that the process was added before the lwp. This was due to the lwp creation requiring the process data. This also needs changing in linux_attach(). Also add additional checks to make sure cannot attach to the same process twice. Add test case for this - do this by splitting attach.exp into distinct pass and error case sections. Fixes gdb.server/ext-attach.exp on Aarch64. gdb/gdbserver/ChangeLog: * linux-low.c (linux_attach): Add process before lwp. * server.c (attach_inferior): Check if already attached. gdb/testsuite/ChangeLog: * gdb.base/attach.exp: Add double attach test.
2019-02-07Make gdb.base/corefile.exp work on terminals with few rowsSimon Marchi2-24/+26
When creating a pty to spawn a subprocess (such as gdb), Expect copies the settings of its own controlling terminal, including the number of rows and columns. If you "make check" on a terminal with just a few rows (e.g. 4), GDB will paginate before reaching the initial prompt. In default_gdb_start, used by most tests, this is already handled: if we see the pagination prompt, we sent \n to continue. Philippe reported that gdb.base/corefile.exp didn't work in terminals with just a few rows. This test spawns GDB by hand, because it needs to check things before the initial prompt, which it couldn't do if it used default_gdb_start. In this case I think it's not safe to use the same technique as in default_gdb_start. Even if we could send a \n if we see a pagination prompt, we match some multiline regexes in there. So if a pagination slips in there, it might make the regexes not match and fail the test. It's also not possible to use -ex "set height 0" or -iex "set height 0", it is handled after the introduction text is shown. The simplest way I found to avoid showing the pagination completely is to set stty_init (documented in expect's man page) to initialize gdb's pty with a fixed number of rows. And actually, if we set stty_init in gdb_init, it works nicely as a general solution applicable to all tests. We can therefore remove the solution introduced in e882ef3cfc3 ("testsuite: expect possible pagination when starting gdb") where we matched the pagination prompt during startup. gdb/testsuite/ChangeLog: * lib/gdb.exp (default_gdb_start): Don't match pagination prompt. (gdb_init): Set stty_init.
2019-01-27Remove duplicate skip_python_tests invocationTom Tromey2-3/+5
I noticed that py-finish-breakpoint.exp had two calls to skip_python_tests, in quick succession. This patch removes the second one. gdb/testsuite/ChangeLog 2019-01-27 Tom Tromey <tom@tromey.com> * gdb.python/py-finish-breakpoint.exp: Remove duplicate call to skip_python_tests.
2019-01-24AArch64 AAPCS: Ignore static membersAlan Hayward3-6/+221
Static members in C++ structs are global data and therefore not part of the list of struct members considered for passing in registers. Note the corresponding code in GCC (from which the GDB AAPCS code is based) does not have any static member checks due to the static members not being part of the struct type at that point. Extend gdb.base/infcall-nested-structs.exp to test structs with static members when compiled for C++. XFAIL more cases for x86_64 (see gdb/24104). For completeness, ensure some test cases have both empty structures and static members. Also fixes gdb.dwarf2/dw2-cp-infcall-ref-static.exp. gdb/ChangeLog: * aarch64-tdep.c (aapcs_is_vfp_call_or_return_candidate_1): Check for static members. (pass_in_v_vfp_candidate): Likewise. gdb/testsuite/ChangeLog: * gdb.base/infcall-nested-structs.c (struct struct_static_02_01): New structure. (struct struct_static_02_02): Likewise. (struct struct_static_02_03): Likewise. (struct struct_static_02_04): Likewise. (struct struct_static_04_01): Likewise. (struct struct_static_04_02): Likewise. (struct struct_static_04_03): Likewise. (struct struct_static_04_04): Likewise. (struct struct_static_06_01): Likewise. (struct struct_static_06_02): Likewise. (struct struct_static_06_03): Likewise. (struct struct_static_06_04): Likewise. (cmp_struct_static_02_01): Likewise. (cmp_struct_static_02_02): Likewise. (cmp_struct_static_02_03): Likewise. (cmp_struct_static_02_04): Likewise. (cmp_struct_static_04_01): Likewise. (cmp_struct_static_04_02): Likewise. (cmp_struct_static_04_03): Likewise. (cmp_struct_static_04_04): Likewise. (cmp_struct_static_06_01): Likewise. (cmp_struct_static_06_02): Likewise. (cmp_struct_static_06_03): Likewise. (cmp_struct_static_06_04): Likewise. (call_all): Test new structs. * gdb.base/infcall-nested-structs.exp: Likewise.
2019-01-21AArch64 AAPCS: Empty structs have non zero size in C++Alan Hayward2-13/+48
When gdb.base/infcall-nested-structs.c is complied as C++, the compiler will not pass structs containing empty structs via float arguments. This is because structs in C++ have a minimum size of 1, causing padding in the struct once compiled. The AAPCS does not allow structs with padding to be passed in float arguments. Add padding checks to AArch64 and add C++ compile variant to the test. Some of the tests fail on X86_64. This has been raised as bug gdb/24104. gdb/ChangeLog: * aarch64-tdep.c (aapcs_is_vfp_call_or_return_candidate_1): Check for padding. gdb/testsuite/ChangeLog: * gdb.base/infcall-nested-structs.exp: Test C++ in addition to C.
2019-01-21Testsuite: Ensure stack protection is off for GCCAlan Hayward5-3/+124
Using -fstack-protector-strong will cause GDB to break on the wrong line when placing a breakpoint on a function. This is due to inadequate dwarf line numbering, and is being tracked by the GCC bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88432 GCC (and Clang) provided by Debian/Ubuntu default to stack protector being enabled. Ensure that when running the GDB testsuite, stack protector is always turned off for GCC 4.1.0 (when stack protector was added) and above. Ensure that this does not cause infinite recursion due to test_compiler_info having to compile a file itself. Add a test to explicitly test breakpoints with various levels of stack protection on both GCC and Clang, with xfail for the known errors. Restore change in ovldbreak.exp which worked around the issue. gdb/testsuite/ChangeLog: 2019-01-18 Alan Hayward <alan.hayward@arm.com> * gdb.base/stack-protector.c: New test. * gdb.base/stack-protector.exp: New file. * gdb.cp/ovldbreak.exp: Only allow a single break line. * lib/gdb.exp (get_compiler_info): Use getting_compiler_info option. (gdb_compile): Remove stack protector for GCC and prevent recursion.
2019-01-16Introduce dwarf2_cu::get_builderKeith Seitz2-0/+218
This patch is an attempt to deal with a variety of bugs reported where GDB segfaults attempting to access a dwarf2_cu's builder. In certain circumstances, this builder can be NULL. This is especially common when inheriting DIEs via inlined subroutines in other CUs. The test case demonstrates one such situation reported by users. See gdb/23773, rhbz1638798, and dups for other concrete examples. The approach taken here is to save the ancestor CU into the dwarf2_cu of all CUs with DIEs that are "imported." This can happen whenever follow_die_offset and friends are called. This essentially introduces a chain of CUs that caused the importation of a DIE from a CU. Whenever a builder is requested of a CU that has none, the ancestors are searched for the first one with a builder. A design side effect of this is that the builder can now only be accessed by getter and setter methods because the builder itself is private. The bulk of the patch is relatively mindless text conversion from "cu->builder" to "cu->get_builder ()". I've included one test which was derived from one (of the many) bugs reported on the issue in both sourceware and Fedora bugzillas. gdb/ChangeLog: PR gdb/23773 * dwarf2read.c (dwarf2_cu) <ancestor>: New field. <builder>: Rename to .. <m_builder>: ... this and make private. (dwarf2_cu::get_builder): New method. Change all users of `builder' to use this method. (dwarf2_start_symtab): Move to ... (dwarf2_cu::start_symtab): ... here. Update all callers (setup_type_unit_groups): Move to ... (dwarf2_cu::setup_type_unit_groups): ... here. Update all callers. (dwarf2_cu::reset_builder): New method. (process_full_compunit, process_full_type_unit): Use dwarf2_cu::reset_builder. (follow_die_offset): Record the ancestor CU if it is different from the followed DIE's CU. (follow_die_sig_1): Likewise. gdb/testsuite/ChangeLog: PR gdb/23773 * gdb.dwarf2/inlined_subroutine-inheritance.exp: New file.
2019-01-14[PowerPC] Aliases for vector registersPedro Franco de Carvalho5-2/+137
This patch defines pseudo-registers "v0" through "v31" as aliases that map to the corresponding raw "vr0" through "vr31" vector registers for Power. The motivation behind this is that although GDB defines these registers as "vrX", the disassembler prints them as "vX", e.g. as the operands in instructions such as "vaddubm v2,v1,v1". This can be confusing to users trying to print out the values of the operands while inspecting the disassembled code. The new aliases are made not to belong to any register group, to avoid duplicated values in "info register vector" and "info register all". The arch-specific rs6000_pseudo_register_reggroup_p function had previously been removed since the other pseudo-registers could have their groups inferred by their type. It restored with this patch to handle the aliases. Membership for the other pseudo-registers is still determined using the default function. A new tests checks that GDB prints the expected values of vector registers after they are filled by the inferior, by using both the raw names and the aliases. Two other existing tests are modified to also test the aliases. gdb/ChangeLog: 2019-01-14 Pedro Franco de Carvalho <pedromfc@linux.ibm.com> * ppc-tdep.h (struct gdbarch_tdep) <ppc_v0_alias_regnum>: New field. * rs6000-tdep.c: Include reggroups.h. (IS_V_ALIAS_PSEUDOREG): Define. (rs6000_register_name): Return names for the "vX" aliases. (rs6000_pseudo_register_type): Return type for the "vX" aliases. (rs6000_pseudo_register_reggroup_p): Restore. Handle "vX" aliases. Call default_register_reggroup_p for all other pseudo-registers. (v_alias_pseudo_register_read, v_alias_pseudo_register_write): New functions. (rs6000_pseudo_register_read, rs6000_pseudo_register_write): Handle "vX" aliases. (v_alias_pseudo_register_collect): New function. (rs6000_ax_pseudo_register_collect): Handle "vX" aliases. (rs6000_gdbarch_init): Initialize "vX" aliases as pseudo-registers. Restore registration of rs6000_pseudo_register_reggroup_p with set_tdesc_pseudo_register_reggroup_p. gdb/testsuite/ChangeLog: 2019-01-14 Pedro Franco de Carvalho <pedromfc@linux.ibm.com> * gdb.arch/vsx-regs.exp: Add tests that use the vector register aliases. * gdb.arch/altivec-regs.exp: Likewise. Fix indentation of two tests. * gdb.arch/powerpc-vector-regs.c: New file. * gdb.arch/powerpc-vector-regs.exp: New file. gdb/doc/ChangeLog: 2019-01-14 Pedro Franco de Carvalho <pedromfc@linux.ibm.com> * gdb.texinfo (PowerPC Features): Document the alias pseudo-registers for the org.gnu.gdb.power.altivec feature.
2019-01-14[PowerPC] Fix "info vector" test in gdb.arch/altivec-regs.expPedro Franco de Carvalho2-38/+10
This patch fixes one of the tests in gdb.arch/altivec-regs.exp that was passing an incorrect list to gdb_expect_list, which always matched. gdb/testsuite/ChangeLog: 2019-01-14 Pedro Franco de Carvalho <pedromfc@linux.ibm.com> * gdb.arch/altivec-regs.exp: Fix the list passed to gdb_expect_list when testing "info vector".
2019-01-12gdb/testsuite: Don't allow paths to appear in test nameAndrew Burgess2-0/+5
Having paths in the test names makes it harder to compare results between two runs in different directories. Give the test a name so that the path doesn't appear. gdb/ChangeLog: * gdb.base/style.exp: Don't include path in testname.
2019-01-10gdb/23712: Test case for multidictionaryKeith Seitz2-0/+163
This is a test derived from one of the reproducers in symtab/23010. The DIE tree used here is typical of compilations with LTO, where an artificial parent DIE of language C99 imports DIEs of other languages. gdb/testsuite/ChangeLog: PR gdb/23712 PR symtab/23010 * gdb.dwarf2/multidictionary.exp: New file.
2019-01-09gdb: Remove support for old mangling schemesSimon Marchi2-1416/+12
An upcoming sync with gcc's libiberty [1] will remove support for old mangling schemes (GNU v2, Lucid, ARM, HP and EDG). It will remove the cplus_demangle_opname function, so we need to get rid of its usages in GDB (it's a GNU v2 specific function). I think the changes are mostly relatively obvious, some hacks that were necessary to support overloaded operators with GNU v2 mangling are not needed anymore. The change in stabsread.c is perhaps less obvious. I think we could get rid of more code in that region that is specific to old mangling schemes, but I chose to do only the minimal changes required to remove the cplus_demangle_opname uses. There is also a detailed comment just above that explaining how GNU v2 and v3 mangled symbols are handled, I decided to leave it as-is, since I wasn't sure which part to remove, change or leave there. [1] The commit "Remove support for demangling GCC 2.x era mangling schemes.", specifically. gdb/ChangeLog: * gdbtypes.c (check_stub_method_group): Remove handling of old mangling schemes. * linespec.c (find_methods): Likewise. * stabsread.c (read_member_functions): Likewise. * valops.c (search_struct_method): Likewise. (value_struct_elt_for_reference): Likewise. * NEWS: Mention this change. gdb/testsuite/ChangeLog: * gdb.cp/demangle.exp (test_gnu_style_demangling): Rename to... (test_gnuv3_style_demangling): ... this. (test_lucid_style_demangling): Remove. (test_arm_style_demangling): Remove. (test_hp_style_demangling): Remove. (do_tests): Remove calls to the above. gdb/doc/ChangeLog: * gdb.texinfo (Print Settings): Remove mention of specific demangle-style values, just refer to the in-process help.
2019-01-09gdb/testsuite: Remove interactive prompt case from mi_gdb_testAndrew Burgess2-5/+5
I noticed that when running this test: make check-gdb RUNTESTFLAGS="--target_board=native-gdbserver gdb.mi/mi-break.exp" I would occasionally see some UNRESOLVED test results like this: (gdb) PASS: gdb.mi/mi-break.exp: mi-mode=separate: breakpoint at main Expecting: ^(kill[ ]+)?(.*[ ]+[(]gdb[)] [ ]*) kill &"kill\n" ~"Kill the program being debugged? (y or n) [answered Y; input not from terminal]\n" =thread-group-exited,id="i1" ERROR: Got interactive prompt. UNRESOLVED: gdb.mi/mi-break.exp: mi-mode=separate: The problem appears to be that the expect buffer fills up to include the '(y or n)' prompt without including the following lines. The pattern supplied by the outer test script is looking for the following lines. As the following lines are not present then expect matches on the interactive prompt case rather than the case for the user supplied pattern. The problem with this is that we are not really at an interactive prompt, GDB is providing an answer for us and then moving on. When I examine a successful run of the test the output from GDB is identical, the only difference is where expect happens to buffer the output from GDB. This patch remove all special handling of the interactive prompt case. This means that if we ever break GDB and start seeing an unexpected interactive prompt then tests will rely on a timeout to fail, instead of having dedicated interactive prompt detection, but this solves the problem that an auto-answered prompt looks very similar to an interactive prompt. With this patch in place I can now leave the following loop running indefinitely, where before it would fail usually after ~10 iterations. while make check-gdb RUNTESTFLAGS="--target_board=native-gdbserver gdb.mi/mi-break.exp"; \ do /bin/true; \ done gdb/testsuite/ChangeLog: * lib/mi-support.exp (mi_gdb_test): Remove interactive prompt case.
2019-01-06Fix crash in "finish"Tom Tromey2-0/+107
PR gdb/28155 notes a crash in "finish" that occurs with a particular source file compiled by clang. The bug is the typical gdb problem of a missing call to check_typedef. clang emits a function whose return type is a typedef to void. get_return_value asserts that the return type is not void, but the callers were not using check_typedef first. gdb/ChangeLog 2019-01-06 Tom Tromey <tom@tromey.com> PR gdb/28155: * python/py-finishbreakpoint.c (bpfinishpy_init): Use check_typedef. * infcmd.c (finish_command_fsm_should_stop): Use check_typedef. (print_return_value): Likewise. gdb/testsuite/ChangeLog 2019-01-06 Tom Tromey <tom@tromey.com> PR gdb/28155: * gdb.dwarf2/typedef-void-finish.exp: New file.
2019-01-01Update copyright year range in all GDB files.Joel Brobecker3472-3472/+3472
This commit applies all changes made after running the gdb/copyright.py script. Note that one file was flagged by the script, due to an invalid copyright header (gdb/unittests/basic_string_view/element_access/char/empty.cc). As the file was copied from GCC's libstdc++-v3 testsuite, this commit leaves this file untouched for the time being; a patch to fix the header was sent to gcc-patches first. gdb/ChangeLog: Update copyright year range in all GDB files.
2018-12-28Fix a crash in jit.cTom Tromey4-0/+109
A user at Mozilla pointed out a crash in jit.c. In his situation, an inferior using the JIT API exec'd an executable that did not use it. This caused an assertion failure when jit.c:free_objfile_data called delete_breakpoint with NULL. This patch fixes the problem in the obvious way. New test case included. gdb/ChangeLog 2018-12-28 Tom Tromey <tom@tromey.com> * jit.c (free_objfile_data): Only delete breakpoint if non-null. gdb/testsuite/ChangeLog 2018-12-28 Tom Tromey <tom@tromey.com> Simon Marchi <simark@simark.ca> * gdb.base/jit-exec.exp: New file. * gdb.base/jit-exec.c: New file. * gdb.base/jit-execd.c: New file.
2018-12-28Style addressesTom Tromey2-1/+5
This changes gdb to style addresses. gdb/ChangeLog 2018-12-28 Tom Tromey <tom@tromey.com> * ui-out.h (enum class ui_out_style_kind) <ADDRESS>: New constant. * ui-out.c (ui_out::field_core_addr): Add styling. * stack.c (print_frame): Add styling. * printcmd.c (print_address): Add styling. (print_address_demangle, info_address_command): Likewise. * cli/cli-style.h (address_style): Declare. * cli/cli-style.c (address_style): New global. (_initialize_cli_style): Register new commands. * cli-out.c (cli_ui_out::do_field_string): Update. gdb/testsuite/ChangeLog 2018-12-28 Tom Tromey <tom@tromey.com> * gdb.base/style.exp: Update test to check for address styling.
2018-12-28Style the "Reading symbols" messageTom Tromey2-0/+9
The "Reading symbols" message does not use ui-out (perhaps it should?), so this styles it using the low-level API. gdb/ChangeLog 2018-12-28 Tom Tromey <tom@tromey.com> * symfile.c (symbol_file_add_with_addrs): Style file name. gdb/testsuite/ChangeLog 2018-12-28 Tom Tromey <tom@tromey.com> * gdb.base/style.exp: Add test for styling of "Reading symbols" message.
2018-12-28Style the gdb welcome messageTom Tromey2-0/+10
This changes gdb to style the welcome message that is shown by default. The styling is only done interactively. gdb/ChangeLog 2018-12-28 Tom Tromey <tom@tromey.com> * top.c (print_gdb_version): Style gdb version number. gdb/testsuite/ChangeLog 2018-12-28 Tom Tromey <tom@tromey.com> * gdb.base/style.exp: Add test for version number styling.
2018-12-28Style print_address_symbolicTom Tromey2-0/+6
print_address_symbolic does not use ui-out, so it did not style function names. This patch changes it to use the low-level style code directly. gdb/ChangeLog 2018-12-28 Tom Tromey <tom@tromey.com> * printcmd.c (print_address_symbolic): Style function name. gdb/testsuite/ChangeLog 2018-12-28 Tom Tromey <tom@tromey.com> * gdb.base/style.exp: Add test for print_address_symbolic.
2018-12-28Style locations when setting a breakpointTom Tromey2-1/+8
say_where does not use ui-out, so function and file names printed by it were not styled. This patch changes say_where to use the low-level style code directly. gdb/ChangeLog 2018-12-28 Tom Tromey <tom@tromey.com> * breakpoint.c (say_where): Style file name. gdb/testsuite/ChangeLog 2018-12-28 Tom Tromey <tom@tromey.com> * gdb.base/style.exp: Add test for breakpoint setting.
2018-12-28Style variable namesTom Tromey2-1/+6
This adds style support for variable names. For the time being, this is only done in backtraces, not in ptype or print; those places do not use ui-out and so would need ad hoc changes. This also adds styling to the names printed for local variables in "backtrace full". This code does not use ui-out, so the styling is done using the low-level API. gdb/ChangeLog 2018-12-28 Tom Tromey <tom@tromey.com> * ui-out.h (enum class ui_out_style_kind) <VARIABLE>: New global. * stack.c (print_frame_arg): Style name. * printcmd.c (print_variable_and_value): Style variable name. * cli/cli-style.h (variable_name_style): Declare. * cli/cli-style.c (variable_name_style): New global. (_initialize_cli_style): Update. * cli-out.c (cli_ui_out::do_field_string): Update. gdb/testsuite/ChangeLog 2018-12-28 Tom Tromey <tom@tromey.com> * gdb.base/style.exp: Add test for variable names.
2018-12-28Add output styles to gdbTom Tromey3-0/+66
This adds some output styling to the CLI. A style is currently a foreground color, a background color, and an intensity (dim or bold). (This list could be expanded depending on terminal capabilities.) A style can be applied while printing. For ui-out, this is done by passing the style constant as an argument. For low-level cases, fprintf_styled and fputs_styled are provided. Users can control the style via a number of new set/show commands. In the interest of not typing many nearly-identical documentation strings, I automated this. On the down side, this is not very i18n-friendly. I've chose some default colors to use. I think it would be good to enable this by default, so that when users start the new gdb, they will see the new feature. Stylizing is done if TERM is set and is not "dumb". This could be improved when the TUI is available by using the curses has_colors call. That is, the lowest layer could call this without committing to using curses everywhere; see my other patch for TUI colorizing. I considered adding a new "set_style" method to ui_file. However, because the implementation had to interact with the pager code, I didn't take this approach. But, one idea might be to put the isatty check there and then have it defer to the lower layers. gdb/ChangeLog 2018-12-28 Tom Tromey <tom@tromey.com> * utils.h (set_output_style, fprintf_styled) (fputs_styled): Declare. * utils.c (applied_style, desired_style): New globals. (emit_style_escape, set_output_style): New function. (prompt_for_continue): Emit style escapes. (fputs_maybe_filtered): Likewise. (fputs_styled, fprintf_styled): New functions. * ui-out.h (enum class ui_out_style_kind): New. (class ui_out) <field_string, field_stream, do_field_string>: Add style parameter. * ui-out.c (ui_out::field_stream, ui_out::field_string): Add style parameter. * tui/tui-out.h (class tui_ui_out) <do_field_string>: Add style parameter. * tui/tui-out.c (tui_ui_out::do_field_string): Add style parameter. (tui_ui_out::do_field_string): Update. * tracepoint.c (print_one_static_tracepoint_marker): Style output. * stack.c (print_frame_info, print_frame): Style output. * source.c (print_source_lines_base): Style output. * skip.c (info_skip_command): Style output. * record-btrace.c (btrace_call_history_src_line): Style output. (btrace_call_history): Likewise. * python/py-framefilter.c (py_print_frame): Style output. * mi/mi-out.h (class mi_ui_out) <do_field_string>: Add style parameter. * mi/mi-out.c (mi_ui_out::do_table_header) (mi_ui_out::do_field_int): Update. (mi_ui_out::do_field_string): Update. * disasm.c (gdb_pretty_print_disassembler::pretty_print_insn): Style output. * cli/cli-style.h: New file. * cli/cli-style.c: New file. * cli-out.h (class cli_ui_out) <do_field_string>: Add style parameter. * cli-out.c (cli_ui_out::do_table_header) (cli_ui_out::do_field_int, cli_ui_out::do_field_skip): Update. (cli_ui_out::do_field_string): Add style parameter. Style the output. * breakpoint.c (print_breakpoint_location): Style output. (update_static_tracepoint): Likewise. * Makefile.in (SUBDIR_CLI_SRCS): Add cli-style.c. (HFILES_NO_SRCDIR): Add cli-style.h. gdb/testsuite/ChangeLog 2018-12-28 Tom Tromey <tom@tromey.com> * gdb.base/style.exp: New file. * gdb.base/style.c: New file.
2018-12-28Change gdb test suite's TERM settingTom Tromey3-49/+59
This changes the gdb test suite to set TERM to "dumb" by default. This setting disables terminal styling, so that the existing tests do not need to be updated. gdb/testsuite/ChangeLog 2018-12-28 Tom Tromey <tom@tromey.com> * lib/gdb.exp (gdb_init): Set the TERM environment variable to "dumb". * gdb.base/readline.exp (operate_and_get_next): Save and restore the TERM environment variable.
2018-12-27Translate PyExc_KeyboardInterrupt to gdb "quit"Tom Tromey2-0/+45
A while back I typed "info pretty-printers" with a large number of printers installed, and I typed "q" to stop the pagination. I noticed that gdb printed a Python exception in this case. It seems to me that, instead, quitting pagination (or control-c'ing a Python command generally) should be handled the same way that gdb normally handles a quit. This patch implements this idea by changing gdbpy_handle_exception to treat PyExc_KeyboardInterrupt specially. gdb/ChangeLog 2018-12-27 Tom Tromey <tom@tromey.com> * python/py-utils.c (gdbpy_handle_exception): Translate PyExc_KeyboardInterrupt to quit. gdb/testsuite/ChangeLog 2018-12-27 Tom Tromey <tom@tromey.com> * gdb.python/py-cmd.exp (test_python_inline_or_multiline): Add pagination test.
2018-12-27Fix gdb.ada/fun_renaming.exp by using more unique names.Philippe Waroquiers4-14/+16
The test fails due to conflict between var 'next' and s-pooloc.adb next: (gdb) print next(1) Multiple matches for next [0] cancel [1] pack.next (integer) return integer at /bd/home/philippe/gdb/git/binutils-gdb/gdb/testsuite/gdb.ada/fun_renaming/pack.adb:19 [2] system.pool_local.next (system.address) return system.pool_local.acc_address at s-pooloc.adb:151 > FAIL: gdb.ada/fun_renaming.exp: print next(1) (timeout) Fix by making the names and renamings more unique. gdb/testsuite/ChangeLog 2018-12-26 Philippe Waroquiers <philippe.waroquiers@skynet.be> * gdb.ada/fun_renaming/pack.ads (Next): Rename to Fun_Rename_Test_Next. (Renamed_Next): Rename to Renamed_Fun_Rename_Test_Next. gdb.ada/fun_renaming/pack.adb (Next): Rename to Fun_Rename_Test_Next. gdb.ada/fun_renaming/fun_renaming.adb (N): Rename to Fun_Rename_Test_N. gdb.ada/fun_renaming.exp: Update accordingly.
2018-12-27Fix gdb.ada/assign_arr.exp by using more unique names.Philippe Waroquiers3-3/+3
The test fails (timeout) due to conflict between var 'input' and s-ststop.adb 'input': (gdb) print input.u2 := (0.25,0.5,0.75) Multiple matches for input [0] cancel [1] system.strings.stream_ops.storage_array_ops.input (access ada.streams.root_stream_type; system.strings.stream_ops.io_kind; natural) return system.storage_elements.storage_array at s-ststop.adb:127 [2] system.strings.stream_ops.stream_element_array_ops.input (access ada.streams.root_stream_type; system.strings.stream_ops.io_kind; natural) return ada.streams.stream_element_array at s-ststop.adb:127 [3] system.strings.stream_ops.string_ops.input (access ada.streams.root_stream_type; system.strings.stream_ops.io_kind; natural) return string at s-ststop.adb:127 [4] system.strings.stream_ops.wide_string_ops.input (access ada.streams.root_stream_type; system.strings.stream_ops.io_kind; natural) return wide_string at s-ststop.adb:127 [5] system.strings.stream_ops.wide_wide_string_ops.input (access ada.streams.root_stream_type; system.strings.stream_ops.io_kind; natural) return wide_wide_string at s-ststop.adb:127 [6] target_wrapper.input at /bd/home/philippe/gdb/git/info_t/gdb/testsuite/gdb.ada/assign_arr/target_wrapper.ads:24 > FAIL: gdb.ada/assign_arr.exp: print input.u2 := (0.25,0.5,0.75) (timeout) gdb/testsuite/ChangeLog 2018-12-26 Philippe Waroquiers <philippe.waroquiers@skynet.be> * gdb.ada/assign_arr/target_wrapper.ads (Input): Rename to Assign_Arr_Input. main_p324_051.adb: Update accordingly. gdb.ada/assign_arr.exp: Likewise.
2018-12-27Improve gdb.ada/rename_subscript_param.exp by using more unique names.Philippe Waroquiers2-6/+6
With old compilers, the test fails because no debug info is generated for 'B' and GDB finds some 'b' in atnat.h: (gdb) print b Multiple matches for b [0] cancel [1] b at ../sysdeps/ieee754/dbl-64/atnat.h:106 [2] b at ../sysdeps/ieee754/dbl-64/atnat.h:106 [3] b at ../sysdeps/ieee754/dbl-64/atnat.h:106 > FAIL: gdb.ada/rename_subscript_param.exp: print b before changing its value (timeout) Avoid the timeout by renaming 'b' to rename_subscript_param_b. Also, change 'before' to 'after' in the gdb_test message that prints the value after changing it. The test still fails with old compilers that do not properly generate debug info for this renaming: (gdb) print rename_subscript_param_b No definition of "rename_subscript_param_b" in current context. (gdb) FAIL: gdb.ada/rename_subscript_param.exp: print rename_subscript_param_b before changing its value Note: if the compiler would generate the correct debug info, the test should succeed with the name B. However, waiting for this fix, changing the name ensures that the test fails directly, instead of causing a timeout. 2018-12-26 Philippe Waroquiers <philippe.waroquiers@skynet.be> PR ada/23381 * gdb.ada/rename_subscript_param/pkg.adb (B): Rename to Rename_Subscript_Param_B. All users updated. gdb.ada/rename_subscript_param.exp: Test names made unique. Note that PR ada/23381 is only fully fixed when using a recent compiler.
2018-12-27Fix gdb.ada/packed_array_assign.exp by using more unique names.Philippe Waroquiers2-5/+7
The test gdb.ada/packed_array_assign fails due to conflict between component 'w' and system.dim.mks.w: (gdb) print pra := ((x => 2, y => 0, w => 17), pr, (x => 7, y => 1, w => 23)) Unknown component name: system.dim.mks.w. (gdb) FAIL: gdb.ada/packed_array_assign.exp: print pra := ((x => 2, y => 0, w => 17), pr, (x => 7, y => 1, w => 23)) Also, depending on the compiler version, the component w might be reordered and placed before components x and y. So, change the component order in the source, so that both an old compiler (GNATMAKE 6.3.0, gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516) and a new compiler (GNATMAKE Pro 20.0w (20181210-82), based on gcc 8.2.1) produce the same component order (checked by using -gnatR3s). So, update to test the new (more unique) names in the source order. 2018-12-26 Philippe Waroquiers <philippe.waroquiers@skynet.be> * gdb.ada/packed_array_assign/aggregates.ads (Packed_Rec): Rename components to Packed_Array_Assign_[X|Y|W]. Place component Packed_Array_Assign_W as first component, to ensure old and new compilers have the same representation. All users updated.
2018-12-24gdb: Allow struct fields named doubleAndrew Burgess3-0/+169
The 64-bit RISC-V target currently models the floating point registers as having the following type: union riscv_double { builtin_type_ieee_single float; builtin_type_ieee_double double; } Notice the choice of names for the fields of this struct, possibly not ideal choices, as these are not valid field names in C. However, this type is only ever defined within GDB (or in the target description), and no restriction seems to exist on the field names in that case. The problem though is that currently: (gdb) info registers $ft0 ft0 {float = 0, double = 0} (raw 0x0000000000000000) (gdb) p $ft0.float $1 = 0 (gdb) p $ft0.double A syntax error in expression, near `double'. We can access the 'float' field, but not the 'double' field. This is because the string 'double' is handled differently to the string 'float' in c-exp.y. In both cases the string '$ft0' is parsed as a VARIABLE expression. In the 'float' case, the string 'float' becomes a generic NAME token in 'lex_one_token', which then allows the rule "exp '.' name" to match and the field name lookup to occur. The 'double' case is different. In order to allow parsing of the type string 'long double', the 'double' string becomes the token DOUBLE_KEYWORD. At this point there's no rule to match "exp '.' DOUBLE_KEYWORD", so we can never lookup the field named 'double'. We could rename the fields for RISC-V, and maybe that would be the best solution. However, its not hard to allow for fields named 'double', which is what this patch does. A new case is added to the 'field_name' rule to match the DOUBLE_KEYWORD, and create a suitable 'struct stoken'. With this done the "exp '.' field_name" pattern can now match, and we can lookup the double field. With this patch in place I now see this behaviour: (gdb) info registers $ft0 ft0 {float = 0, double = 0} (raw 0x0000000000000000) (gdb) p $ft0.float $1 = 0 (gdb) p $ft0.double $2 = 0 I've gone ahead and handled INT_KEYWORD, LONG, SHORT, SIGNED_KEYWORD, and UNSIGNED as well within field_name. I've added a new test for this functionality. This change was tested on x86-64 GNU/Linux with no regressions. gdb/ChangeLog: * c-exp.y (field_name): Allow DOUBLE_KEYWORD, INT_KEYWORD, LONG, SHORT, SIGNED_KEYWORD, and UNSIGNED tokens to act as a field names. (typename_stoken): New function. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-unusual-field-names.c: New file. * gdb.dwarf2/dw2-unusual-field-names.exp: New file.
2018-12-24Fix gdb.ada bp_fun_addr failure due to conflict between fun 'a' and ↵Philippe Waroquiers3-7/+13
s-dimmks.ads 'A'. The test fails (timeout) due to: (gdb) PASS: gdb.ada/bp_fun_addr.exp: break *a'address run Starting program: /bd/home/philippe/gdb/git/build_info_t/gdb/testsuite/outputs/gdb.ada/bp_fun_addr/a Multiple matches for a [0] cancel [1] a at /bd/home/philippe/gdb/git/info_t/gdb/testsuite/gdb.ada/bp_fun_addr/a.adb:18 [2] system.dim.mks.a at s-dimmks.ads:115 > FAIL: gdb.ada/bp_fun_addr.exp: run until breakpoint at a'address (timeout) testcase /home/philippe/gdb/git/build_info_t/gdb/testsuite/../../../info_t/gdb/testsuite/gdb.ada/bp_fun_addr.exp completed in 10 seconds Fix this by using a fun name that has more chances to be unique. 2018-12-24 Philippe Waroquiers <philippe.waroquiers@skynet.be> * gdb.ada/bp_fun_addr/a.adb (a): Rename to bp_fun_addr. Filename a.adb changed to bp_fun_addr.adb. gdb.ada/bp_fun_addr.exp: Update test accordingly.
2018-12-21Fix various tests to use -no-pie linker flag when neededJan Vrany9-7/+38
Various tests use test code written in i386 / x86_64 assembly that cannot be used to create PIE executables. Therefore compilation of test programs failed on systems where the compiler default is to create PIE executable. The solution is to use -no-pie linker flag, however, such flag may not (is not) supported by all compilers GDB needs to support (e.g. gcc 4.8). To handle this, introduce a new flag to gdb_compile - nopie - which inserts -no-pie linker flag where supported and is no-op where it is not. By default, -no-pie flag is inserted since most modern compiler do support it.
generated by cgit v1.1 at 2025-09-20 22:37:50 +0000