aboutsummaryrefslogtreecommitdiff
path: root/gdb/testsuite
AgeCommit message (Collapse)AuthorFilesLines
2019-04-08Tests for gdb.InferiorThread.handleKevin Buettner2-3/+44
gdb/testsuite/ChangeLog: * gdb.python/py-thrhandle.exp: Add tests for gdb.InferiorThread.handle.
2019-04-01gdb/fortran: Handle internal function callsAndrew Burgess3-1/+21
If an convenience function is defined in python (or guile), then currently this will not work in Fortran, instead the user is given this message: (gdb) set language fortran (gdb) p $myfunc (3) Cannot perform substring on this type Compare this to C: (gdb) set language c (gdb) p $myfunc (3) $1 = 1 After this patch we see the same behaviour in both C and Fortran. I've extended the test to check that all languages can call the convenience functions - only Fortran was broken. When calling convenience functions in Fortran we don't need to perform the same value preparation (passing by pointer) that we would for calling a native function - passing the real value is fine. gdb/ChangeLog: * eval.c (evaluate_subexp_standard): Handle internal functions during Fortran function call handling. gdb/testsuite/ChangeLog: * gdb.python/py-function.exp: Check calling helper function from all languages. * lib/gdb.exp (gdb_supported_languages): New proc.
2019-04-01gdb: Add $_cimag and $_creal internal functionsAndrew Burgess4-0/+119
Add two new internal functions $_cimag and $_creal that extract the imaginary and real parts of a complex value. These internal functions can take a complex value of any type 'float complex', 'double complex', or 'long double complex' and return a suitable floating point value 'float', 'double', or 'long double'. So we can now do this: (gdb) p z1 $1 = 1.5 + 4.5 * I (gdb) p $_cimag (z1) $4 = 4.5 (gdb) p $_creal (z1) $4 = 1.5 The components of a complex value are not strictly named types in DWARF, as the complex type is itself the base type. However, once we are able to extract the components it makes sense to be able to ask what the type of these components is and get a sensible answer back, rather than the error we would currently get. Currently GDB says: (gdb) ptype z1 type = complex double (gdb) p $_cimag (z1) $4 = 4.5 (gdb) ptype $ type = <invalid type code 9> With the changes in dwarf2read.c, GDB now says: (gdb) ptype z1 type = complex double (gdb) p $_cimag (z1) $4 = 4.5 (gdb) ptype $ type = double Which seems to make more sense. gdb/ChangeLog: * NEWS: Mention new internal functions. * dwarf2read.c (dwarf2_init_complex_target_type): New function. (read_base_type): Use dwarf2_init_complex_target_type. * value.c (creal_internal_fn): New function. (cimag_internal_fn): New function. (_initialize_values): Register new internal functions. gdb/doc/ChangeLog: * gdb.texinfo (Convenience Funs): Document '$_creal' and '$_cimag'. gdb/testsuite/ChangeLog: * gdb.base/complex-parts.c: New file. * gdb.base/complex-parts.exp: New file.
2019-04-01Handle DW_AT_ranges when reading partial symtabsTom Tromey4-0/+210
add_partial_subprogram does not handle DW_AT_ranges, while the full symtab reader does. This can lead to discrepancies where a function is not put into a partial symtab, and so is not available to "break" and the like -- but is available if the full symtab has somehow been read. This patch fixes the bug by arranging to read DW_AT_ranges when reading partial DIEs. This is PR symtab/23331. The new test case is derived from dw2-ranges-func.exp, which is why I kept the copyright dates. gdb/ChangeLog 2019-04-01 Tom Tromey <tromey@adacore.com> PR symtab/23331: * dwarf2read.c (partial_die_info::read): Handle DW_AT_ranges. gdb/testsuite/ChangeLog 2019-04-01 Tom Tromey <tromey@adacore.com> PR symtab/23331: * gdb.dwarf2/dw2-ranges-main.c: New file. * gdb.dwarf2/dw2-ranges-psym.c: New file. * gdb.dwarf2/dw2-ranges-psym.exp: New file.
2019-04-01Add gdb.Value.format_string ()Marco Barisione3-0/+1124
The str () function, called on a gdb.Value instance, produces a string representation similar to what can be achieved with the print command, but it doesn't allow to specify additional formatting settings, for instance disabling pretty printers. This patch introduces a new format_string () method to gdb.Value which allows specifying more formatting options, thus giving access to more features provided by the internal C function common_val_print (). gdb/ChangeLog: 2019-04-01 Marco Barisione <mbarisione@undo.io> Add gdb.Value.format_string (). * python/py-value.c (copy_py_bool_obj): (valpy_format_string): Add gdb.Value.format_string (). * NEWS: Document the addition of gdb.Value.format_string (). gdb/doc/ChangeLog: 2019-04-01 Marco Barisione <mbarisione@undo.io> * python.texi (Values From Inferior): Document gdb.Value.format_string (). gdb/testsuite/ChangeLog: 2019-04-01 Marco Barisione <mbarisione@undo.io> Test gdb.Value.format_string (). * gdb.python/py-format-string.exp: New test. * gdb.python/py-format-string.c: New file. * gdb.python/py-format-string.py: New file.
2019-03-30Introduce new convenience variables $_gdb_major and $_gdb_minorEli Zaretskii2-0/+7
gdb/ChangeLog: 2019-03-30 Eli Zaretskii <eliz@gnu.org> * NEWS: Announce $_gdb_major and $_gdb_minor. * top.c (init_gdb_version_vars): New function. (gdb_init): Call init_gdb_version_vars. gdb/testsuite/ChangeLog: 2019-03-30 Simon Marchi <simark@simark.ca> * gdb.base/default.exp: Add values for $_gdb_major and $_gdb_minor. gdb/doc/ChangeLog: 2019-03-30 Eli Zaretskii <eliz@gnu.org> * gdb.texinfo (Convenience Vars): Document $_gdb_major and $_gdb_minor.
2019-03-29Add usage for commands in printcmd.cTom Tromey2-1/+5
I noticed that the help for "info addr" did not include a "usage" line; and when adding it I went through and fixed a few minor issues in printcmd.c: * Added usage lines to all commands * Updated the help text for some commands * Changed some help to use upper case metasyntactic variables * Removed some dead code Regression tested on x86-64 Fedora 29. gdb/ChangeLog 2019-03-29 Tom Tromey <tromey@adacore.com> * printcmd.c (_initialize_printcmd): Add usage lines. Update some help text. Remove dead code. gdb/testsuite/ChangeLog 2019-03-29 Tom Tromey <tromey@adacore.com> * gdb.base/help.exp: Tighten apropos regexp.
2019-03-29Allow really large fortran array bounds: fortran type/value printersKeith Seitz3-0/+81
This is the fortran part of the patch, including tests, which are essentially unchanged from Siddhesh's original 2012 submission: https://sourceware.org/ml/gdb-patches/2012-08/msg00562.html There is, however, one large departure. In the above thread, Jan pointed out problems with GCC debuginfo for -m32 builds (filed usptream as gcc/54934). After investigating the issue, I am dropping the hand-tweaked assembler source file to workaround this case. While I would normally do something to accommodate this, in this case, given the ubiquity of 64-bit systems today (where the tests pass) and the apparent lack of urgency on the compiler side (by users), I don't think the additional complexity and maintenance costs are worth it. It will be very routinely tested on 64-bit systems. [For example, at Red Hat, we always test -m64 and -m32 configurations for all GDB releases.] gdb/ChangeLog: From Siddhesh Poyarekar: * f-lang.h (f77_get_upperbound): Return LONGEST. (f77_get_lowerbound): Likewise. * f-typeprint.c (f_type_print_varspec_suffix): Expand UPPER_BOUND and LOWER_BOUND to LONGEST. Use plongest to format print them. (f_type_print_base): Expand UPPER_BOUND to LONGEST. Use plongest to format print it. * f-valprint.c (f77_get_lowerbound): Return LONGEST. (f77_get_upperbound): Likewise. (f77_get_dynamic_length_of_aggregate): Expand UPPER_BOUND, LOWER_BOUND to LONGEST. (f77_create_arrayprint_offset_tbl): Likewise. gdb/testsuite/ChangeLog: * gdb.fortran/array-bounds.exp: New file. * gdb.fortran/array-bounds.f90: New file.
2019-03-28Fix gdb.multi/multi-term-settings.exp blocking under high load/slow gdbPhilippe Waroquiers2-1/+5
Similarly to multi-arch-exec.exp, increase the alarm timer to avoid test blocking under high load or with a slow gdb. 2019-03-28 Philippe Waroquiers <philippe.waroquiers@skynet.be> * gdb.multi/multi-term-settings.c (main): Increase alarm timer.
2019-03-28Fix gdb.multi/multi-arch-exec.exp blocking under high load/slow gdbPhilippe Waroquiers2-1/+5
When running multi-arch-exec.exp under valgrind, the test succeeds when the machine is not loaded, but blocks when the machine is highly loaded (e.g. when running the testsuite with valgrind with -j X where X is one more than the nr of available cores). The problem is that the hello program dies too early due to the alarm (30). So, increase the alarm timer. Note that this does not make the test take longer (it takes about 3.5 seconds on my system). As I understand, the alarm is just there to avoid hello staying there forever in case of another problem. 2019-03-28 Philippe Waroquiers <philippe.waroquiers@skynet.be> * gdb.multi/hello.c (main): Increase alarm timer.
2019-03-28Fix stepping past unwritable kernel helper on nios2-linux-gnu.Sandra Loosemore2-13/+26
This patch fixes a problem on nios2-linux-gnu with stepping past the kernel helper __kuser_cmpxchg, which was exposed by the testcase gdb.threads/watchpoint-fork.exp. The kernel maps this function into user space on an unwritable page. In this testcase, the cmpxchg helper is invoked indirectly from the setbuf call in the test program. Since this target lacks hardware breakpoint/watchpoint support, GDB tries to single-step through the program by setting software breakpoints, and was just giving an error when it reached the function on the unwritable page. The solution here is to always step over the call instead of stepping into it; cmpxchg is supposed to be an atomic operation so this behavior seems reasonable. The hook in nios2_get_next_pc is somewhat generic, but at present cmpxchg is the only helper provided by the Linux kernel that is invoked by an ordinary function call. (Signal return trampolines also go through the unwritable page but not by a function call.) Fixing this issue also revealed that the testcase needs a much larger timeout factor when software single-stepping is used. That has also been fixed in this patch. gdb/ChangeLog 2019-03-28 Sandra Loosemore <sandra@codesourcery.com> * nios2-tdep.h (struct gdbarch_tdep): Add is_kernel_helper. * nios2-tdep.c (nios2_get_next_pc): Skip over kernel helpers. * nios2-linux-tdep.c (nios2_linux_is_kernel_helper): New. (nios2_linux_init_abi): Install it. gdb/testsuite/ChangeLog 2019-03-28 Sandra Loosemore <sandra@codesourcery.com> * gdb.threads/watchpoint-fork.exp (test): Use large timeout factor when no hardware watchpoint support.
2019-03-28Testsuite: set sysroot when using gdbserverAlan Hayward2-0/+8
When testing using native-gdbserver and native-extended-gdbserver, the sysroot is not set. This results in a warning from GDB and files are sent via the remote protocol, which can be slow. On Ubuntu 18.04 (unlike most distros) the debug versions of the standard libraries are included by default in /usr/lib/debug/. These file reads are causing a complete native-gdbserver run on the AArch64 buildbot slave to timeout after 2.5 hours. This is also causing the builds to back up on the slave. The solution is to ensure the sysroot is set to / for all local boards. This drastically reduces the time of a test. For example, gdb.base/sigall.exp drops from 23 seconds to 4 seconds. A full native-gdbserver run on the AArch64 slave now takes 8 minutes. gdb/testsuite/ChangeLog: * boards/local-board.exp: set sysroot to /.
2019-03-27Testsuite: Ensure interrupt-daemon-attach doesn't run foreverAlan Hayward2-2/+14
Looking at the AArch64 buildbot, I noticed about two dozen old instances of interrupt-daemon-attach taking up a full 100% cpu each. If the test fails then the test binary relies on an alarm to ensure it dies after 60 seconds. As per the Linux man page for alarm: Alarms created by alarm() ... are not inherited by children created via fork. Update the test to add an alarm in the child and also put a sleep in the child loop so it does not constantly consume cpu. Note I haven't managed to re-create why the test failed. This fix will just stop it hanging and consuming cpu when it does. gdb/testsuite/ChangeLog: * gdb.base/interrupt-daemon-attach.c (main): Add alarm and sleep in child.
2019-03-26gdb: Make python display_hint None handling defined behaviourAndrew Burgess4-1/+31
The documentation say that the display_hint method must return a string to serve as a display hint, and then goes on to list some acceptable strings. However, if we don't supply the display_hint method then we get a default display style behaviour and there's currently no way (in the python api) to force this default behaviour. The guile api allows #f to be used in order to force the default display style behaviour, and this is documented. Currently, using None in the python api also forces the default display behaviour. This commit extends the documentation to make returning None from the display_hint method an official mechanism by which the user can get the default display style. I've extended one of the existing tests to cover this case. gdb/doc/ChangeLog: * python.texi (Pretty Printing API): Document use of None for the display_hint. gdb/testsuite/ChangeLog: * gdb.python/py-prettyprint.c (struct container) <is_map_p>: New field. (make_container): Initialise new field. * gdb.python/py-prettyprint.exp: Add new tests. * gdb.python/py-prettyprint.py (class ContainerPrinter) <display_hint>: New method.
2019-03-26gdb/testsuite: Make test names unique in gdb.python/py-prettyprint.expAndrew Burgess2-12/+21
This makes the test names unique in gdb.python/py-prettyprint.exp, it also switches to use gdb_breakpoint and gdb_continue_to_breakpoint more so that we avoid test names with the source line number in - this is bad if the test source ever changes as the test names will then change. One final change is to switch from using gdb_py_test_silent_cmd to use gdb_test_no_output, the former should be used for running python commands and can catch any thrown exception. However, in this case the command being run is not a python command, its just a normal GDB CLI command that produces no output, so lets use the appropriate wrapper function. gdb/testsuite/ChangeLog: * gdb.python/py-prettyprint.exp: Use gdb_breakpoint and gdb_continue_to_breakpoint more throughout this test. (run_lang_tests) Supply unique test names, and use gdb_test_no_output.
2019-03-26gdb: Avoid trailing whitespace when pretty printingAndrew Burgess4-1/+118
While writing a new test for 'set print pretty on' I spotted that GDB will sometimes add a trailing whitespace character when pretty printing. This commit removes the trailing whitespace and updates the expected results in one tests where this was an issue. I've added an extra test for 'set print pretty on' as it doesn't seem to have much testing. gdb/ChangeLog: * cp-valprint.c (cp_print_value_fields): Don't print trailing whitespace when pretty printing is on. gdb/testsuite/ChangeLog: * gdb.base/finish-pretty.exp: Update expected results. * gdb.base/pretty-print.c: New file. * gdb.base/pretty-print.exp: New file.
2019-03-25Fix testsuite hangs when gdb_test_multiple body errors outPedro Alves2-2/+26
This commit fixes a regression in the testsuite itself, triggered by errors being raised from within gdb_test_multiple, originally reported by Pedro Franco de Carvalho's at <https://sourceware.org/ml/gdb-patches/2019-03/msg00160.html>. Parts of the commit message are based on his report. This started happening due to a commit that was introduced recently, and it can cause the testsuite to hang. The commit that triggers this is: fe1a5cad302b5535030cdf62895e79512713d738 [gdb/testsuite] Log wait status on process no longer exists error That commit introduces a new "eof" block in gdb_test_multiple. That is not incorrect itself, but dejagnu's remote_expect is picking that block as the "default" action when an error is raised from within the commands inside a call to gdb_test_multiple: # remote_expect works basically the same as standard expect, but it # also takes care of getting the file descriptor from the specified # host and also calling the timeout/eof/default section if there is an # error on the expect call. # proc remote_expect { board timeout args } { I find that "feature" surprising, and I don't really know why it exists, but this means that the eof section that remote_expect picks as the error block can be executed even when there was no actual eof and the GDB process is still running, so the wait introduced in the commit that tries to get the exit status of GDB hangs forever, while GDB itself waits for input. This only happens when there are internal testsuite errors (not testcase failures). This can be reproduced easily with a testcase such as: gdb_start gdb_test_multiple "show version" "show version" { -re ".*" { error "forced error" } } I think that working around this in GDB is useful so that the testsuite doesn't hang in these cases. Adding an empty "default" block at the end of the expect body in gdb_test_multiple doesn't work, because dejagnu gives preference to "eof" blocks: if { $x eq "eof" } { set save_next 1 } elseif { $x eq "default" || $x eq "timeout" } { if { $error_sect eq "" } { set save_next 1 } } And we do have "eof" blocks. So we need to make sure that the last "eof" block is safe to use as the default error block. It's also pedantically incorrect to print "ERROR: Process no longer exists" which is what we'd get if the last eof block we have was selected (more below on this). So this commit solves this by appending an "eof" with an empty spawn_id list, so that it won't ever match. Now, why is the first "eof" block selected today as the error block, instead of the last one? The reason is that remote_expect, while parsing the body to select the default block to execute after an error, is affected by the comments in the body (since they are also parsed). If this comment in gdb_test_multiple # patterns below apply to any spawn id specified. is changed to # The patterns below apply to any spawn id specified. then the second eof block is selected and there is no hang. Any comment at that same place with an even number of tokens also works. This is IMO a coincidence caused by how comments work in TCL. Comments should only appear in places where a command can appear. And here, remote_expect is parsing a list of options, not commands, so it's not unreasonable to not parse comments, similarly to how this: set a_list { an_element # another_element } results in a list with three elements, not one element. The fact that comments with an even number of tokens work is just a coincidence of how remote_expect's little state machine is implemented. I thought we could solve this by stripping out comment lines in gdb_expect, but I didn't find an easy way to do that. Particularly, a couple naive approaches I tried run into complications. For example, we have gdb_test calls with regular expressions that include sequences like "\r\n#", and by the time we get to gdb_expect, the \r\n have already been expanded to a real newline, so just splitting the whole body at newline boundaries, looking for lines that start with # results in incorrectly stripping out half of the gdb_text regexp. I think it's better (at least in this commit), to move the comments out of the list, because it's much simpler and risk free. gdb/testsuite/ChangeLog: 2019-03-25 Pedro Alves <palves@redhat.com> * lib/gdb.exp (gdb_test_multiple): Split appends to $code and move comments outside list. Append '-i "" eof' section.
2019-03-22Testsuite: Ensure pie is disabled on some testsAlan Hayward5-4/+53
Recent versions of Ubuntu and Debian default GCC to enable pie. In dump.exp, pie will causes addresses to be out of range for IHEX. In break-interp.exp, pie is explicitly set for some tests and assumed to be disabled for the remainder. Ensure pie is disabled for these tests when required. In addition, add a pie option to gdb_compile to match the nopie option and simplify use. gdb/testsuite/ChangeLog: * README: Add pie options. * gdb.base/break-interp.exp: Ensure pie is disabled. * gdb.base/dump.exp: Likewise. * lib/gdb.exp (gdb_compile): Add pie option.
2019-03-19Don't show "display"s twice in MITom Tromey3-0/+123
If you run "gdb -i=mi2" and set a "display", then when "next"ing the displays will be shown twice: ~"1: x = 23\n" ~"7\t printf(\"%d\\n\", x);\n" ~"1: x = 23\n" *stopped,reason="end-stepping-range",frame={addr="0x0000000000400565",func="main",args=[],file="q.c",fullname="/tmp/q.c",line="7"},thread-id="1",stopped-threads="all",core="1" The immediate cause of this is this code in mi_on_normal_stop_1: print_stop_event (mi_uiout); console_interp = interp_lookup (current_ui, INTERP_CONSOLE); if (should_print_stop_to_console (console_interp, tp)) print_stop_event (mi->cli_uiout); ... which obviously prints the stop twice. However, I think the first call to print_stop_event is intended just to emit the MI *stopped notification, which explains why the source line does not show up two times. This patch fixes the bug by changing print_stop_event to only call do_displays for non-MI-like ui-outs. Tested on x86-64 Fedora 29. gdb/ChangeLog 2019-03-19 Tom Tromey <tromey@adacore.com> * mi/mi-interp.c (mi_on_normal_stop_1): Only show displays once. * infrun.h (print_stop_event): Add "displays" parameter. * infrun.c (print_stop_event): Add "displays" parameter. gdb/testsuite/ChangeLog 2019-03-19 Tom Tromey <tromey@adacore.com> * gdb.mi/mi2-cli-display.c: New file. * gdb.mi/mi2-cli-display.exp: New file.
2019-03-18Fix Ada "ptype" bug with array typesTom Tromey5-0/+116
Using ptype on an array type in Ada can sometimes show an incorrect high bound. This happens because ada_evaluate_subexp will create an array with an incorrect upper bound in the EVAL_AVOID_SIDE_EFFECTS case. This patch fixes the problem by arranging to always create such an array with valid bounds. Tested on x86-64 Fedora 29. gdb/ChangeLog 2019-03-18 Tom Tromey <tromey@adacore.com> * ada-lang.c (empty_array): Add "high" parameter. (ada_evaluate_subexp): Update. gdb/testsuite/ChangeLog 2019-03-18 Joel Brobecker <brobecker@adacore.com> Tom Tromey <tromey@adacore.com> * gdb.ada/ptype_array/pck.adb: New file. * gdb.ada/ptype_array/pck.ads: New file. * gdb.ada/ptype_array/foo.adb: New file. * gdb.ada/ptype_array.exp: New file.
2019-03-14Add the "set style source" commandTom Tromey2-0/+10
This adds "set style source" (and "show style source") commands. This gives the user control over whether source code is highlighted. gdb/ChangeLog 2019-03-14 Tom Tromey <tromey@adacore.com> * NEWS: Add item for "style sources" commands. * source-cache.c (source_cache::get_source_lines): Check source_styling. * cli/cli-style.c (source_styling): New global. (_initialize_cli_style): Add "style sources" commands. (show_style_sources): New function. * cli/cli-style.h (source_styling): Declare. gdb/doc/ChangeLog 2019-03-14 Tom Tromey <tromey@adacore.com> * gdb.texinfo (Output Styling): Document "set style source" and "show style source". gdb/testsuite/ChangeLog 2019-03-14 Tom Tromey <tromey@adacore.com> * gdb.base/style.exp: Add "set style sources" test.
2019-03-13Fix MI output for multi-location breakpointsSimon Marchi4-56/+139
New in v2: - Addressed comments about doc, updated the MI version table - New doc for the Breakpoint information format - New -fix-multi-location-breakpoint-output command, with associated doc, test and NEWS updated accordingly - Fixed the output, the locations list is now actually in the tuple representing the breakpoint. Various MI commands or events related to breakpoints output invalid MI records when printing information about a multi-location breakpoint. For example: -break-insert allo ^done,bkpt={...,addr="<MULTIPLE>",...},{number="1.1",...},{number="1.2",...} The problem is that according to the syntax [1], the top-level elements are of type "result" and should be of the form "variable=value". This patch changes the output to wrap the locations in a list: ^done,bkpt={...,addr="<MULTIPLE>",locations=[{number="1.1",...},{number="1.2",...}]} The events =breakpoint-created, =breakpoint-modified, as well as the -break-info command also suffer from this (and maybe others I didn't find). Since this is a breaking change for MI, we have to deal somehow with backwards compatibility. The approach taken by this patch is to bump the MI version, use the new syntax in MI3 while retaining the old syntax in MI2. Frontends are expected to use a precise MI version (-i=mi2), so if they do that they should be unaffected. The patch also adds the command -fix-multi-location-breakpoint-output, which front ends can use to enable this behavior with MI <= 2. [1] https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Output-Syntax.html#GDB_002fMI-Output-Syntax gdb/ChangeLog: * NEWS: Mention that the new default MI version is 3. Mention changes to the output of commands and events that deal with multi-location breakpoints. * breakpoint.c: Include "mi/mi-out.h". (print_one_breakpoint): Change output syntax if using MI version >= 3. * mi/mi-main.h (mi_cmd_fix_multi_location_breakpoint_output): New. (mi_multi_location_breakpoint_output_fixed): New. * mi/mi-main.c (fix_multi_location_breakpoint_output): New. (mi_cmd_fix_multi_location_breakpoint_output): New. (mi_multi_location_breakpoint_output_fixed): New. * mi/mi-cmds.c (mi_cmds): Register command -fix-multi-location-breakpoint-output. * mi/mi-out.c (mi_out_new): Instantiate version 3 when using interpreter "mi". gdb/testsuite/ChangeLog: * mi-breakpoint-location-ena-dis.exp: Rename to ... * mi-breakpoint-multiple-locations.exp: ... this. (make_breakpoints_pattern): New proc. (do_test): Add mi_version parameter, test -break-insert, -break-info and =breakpoint-created. gdb/doc/ChangeLog: * gdb.texinfo (Mode Options): Mention mi3. (Interpreters): Likewise. (GDB/MI Development and Front Ends): Add entry for MI 3 in version table. Document -fix-multi-location-breakpoint-output. (GDB/MI Breakpoint Information): Document format of breakpoint location output.
2019-03-12gdb/testsuite: Prepare for DejaGnu 1.6.2Andrew Burgess8-13/+12
Changes in DejaGnu 1.6.2 mean that our testsuite will no longer run. This is because of some confusion over how the gdb.exp file is handled. The gdb.exp file is really the tool init file, which is loaded from within the DejaGnu core, and it should not be loaded directly from any other file in the testsuite. DejaGnu tries to prevent the same library being loaded twice by remembering the names of library files as they are loaded. Until recently loading the tool init file in DejaGnu was very similar to loading a library file, as a result, loading the gdb.exp tool init file simply recorded 'gdb.exp' as having been loaded, future attempts to load 'gdb.exp' as a library would then be ignored (as the file was marked as already loaded). DejaGnu has now changed so that it supports having both a tool init file and a library with the same name, something that was not possible before. What this means however is that when the core loads the 'gdb.exp' tool init file it no longer marks the library 'gdb.exp' as having been loaded. When we then execute 'load_lib gdb.exp' we then try to reload the 'gdb.exp' file. Unfortunately our gdb.exp file can only be loaded once. It use of 'rename cd builtin_cd' means that a second attempt to load this file will fail. This was discussed on the DejaGnu list here: http://lists.gnu.org/archive/html/dejagnu/2019-03/msg00000.html and the suggested advice is that, unless we have some real requirement to load the tool init file twice, we should remove calls to 'load_lib gdb.exp' and rely on DejaGnu to load the file for us, which is what this patch does. I've tested with native X86-64/GNU Linux and see no regressions. gdb/testsuite/ChangeLog: * config/default.exp: Remove 'load_lib gdb.exp'. * config/monitor.exp: Likewise. * config/sid.exp: Likewise. * config/sim.exp: Likewise. * config/slite.exp: Likewise. * config/unix.exp: Likewise. * gdb.base/default.exp: Remove unhelpful comment.
2019-03-06gdb/fortran: Handle older TYPE*SIZE typenamesAndrew Burgess2-0/+27
This patch adds support for the older TYPE*SIZE typenames that are still around in older code. For implementation this currently reuses the kind mechanism, as under gFortran the kind number is equivalent to the size, however, this is not necessarily true for all compilers. If the rules for other compilers are better understood then this code might need to be improved slightly to allow for a distinction between size and kind, however, adding this extra complexity now seems pointless. gdb/ChangeLog: * f-exp.y (direct_abs_decl): Handle TYPE*SIZE type names. gdb/testsuite/ChangeLog: * gdb.fortran/type-kinds.exp: Extend to cover TYPE*SIZE cases.
2019-03-06gdb/fortran: Add support for the ABS intrinsic functionAndrew Burgess2-0/+13
Adds support for the abs intrinsic function, this requires adding a new pattern to the Fortran parser. Currently only float and integer argument types are supported to ABS, complex is still not supported, this can be added later if needed. gdb/ChangeLog: * f-exp.y: New token, UNOP_INTRINSIC. (exp): New pattern using UNOP_INTRINSIC token. (f77_keywords): Add 'abs' keyword. * f-lang.c: Add 'target-float.h' and 'math.h' includes. (value_from_host_double): New function. (evaluate_subexp_f): Support UNOP_ABS. gdb/testsuite/ChangeLog: * gdb.fortran/intrinsics.exp: Extend to cover ABS.
2019-03-06gdb/fortran: Use TYPE_CODE_CHAR for character typesAndrew Burgess2-1/+5
Switch to using TYPE_CODE_CHAR for character types. This appears to have little impact on the test results as gFortran uses the DW_TAG_string_type to represent all character variables (as far as I can see). The only place this has an impact is when the user casts a variable to a character type, in which case GDB does now use the CHAR type, and prints the variable as both a value and a character, for example, before: (gdb) p ((character) 97) $1 = 97 and after: (gdb) p ((character) 97) $1 = 97 'a' gdb/ChangeLog: * f-lang.c (build_fortran_types): Use TYPE_CODE_CHAR for character types. gdb/testsuite/ChangeLog: * gdb.fortran/type-kinds.exp: Update expected results.
2019-03-06gdb/fortran: Add builtin 8-byte integer type with (kind=8) supportAndrew Burgess2-0/+5
Add a new builtin type, an 8-byte integer, and allow GDB to parse 'integer (kind=8)', returning the new 8-byte integer. gdb/ChangeLog: * f-exp.y (convert_to_kind_type): Handle integer (kind=8). * f-lang.c (build_fortran_types): Setup builtin_integer_s8. * f-lang.h (struct builtin_f_type): Add builtin_integer_s8 field. gdb/testsuite/ChangeLog: * gdb.fortran/type-kinds.exp: Test new integer type kind.
2019-03-06gdb/fortran: Expand the set of types that support (kind=N)Andrew Burgess2-1/+47
Expand the number of types that can be adjusted with a (kind=N) type extension. gdb/ChangeLog: * f-exp.y (convert_to_kind_type): Handle more type kinds. gdb/testsuite/ChangeLog: * gdb.fortran/type-kinds.exp (test_cast_1_to_type_kind): New function. (test_basic_parsing_of_type_kinds): Expand types tested. (test_parsing_invalid_type_kinds): New function.
2019-03-06gdb/fortran: Add Fortran 'kind' intrinsic and keywordAndrew Burgess4-0/+122
The 'kind' keyword has two uses in Fortran, it is the name of a builtin intrinsic function, and it is also a keyword used to create a type of a specific kind. This commit adds support for using kind as an intrinsic function, and also adds some initial support for using kind to create types of a specific kind. This commit only allows the creation of the type 'character(kind=1)', however, it will be easy enough to extend this in future to support more type kinds. The kind of any expression can be queried using the kind intrinsic function. At the moment the kind returned corresponds to the size of the type, this matches how gfortran handles kinds. However, the correspondence between kind and type size depends on the compiler and/or the specific target, so this might not be correct for everyone. If we want to support different compilers/targets in future the code to compute the kind from a type will need to be updated. gdb/ChangeLog: * expprint.c (dump_subexp_body_standard): Support UNOP_KIND. * f-exp.y: Define 'KIND' token. (exp): New pattern for KIND expressions. (ptype): Handle types with a kind extension. (direct_abs_decl): Extend to spot kind extensions. (f77_keywords): Add 'kind' to the list. (push_kind_type): New function. (convert_to_kind_type): New function. * f-lang.c (evaluate_subexp_f): Support UNOP_KIND. * parse.c (operator_length_standard): Likewise. * parser-defs.h (enum type_pieces): Add tp_kind. * std-operator.def: Add UNOP_KIND. gdb/testsuite/ChangeLog: * gdb.fortran/intrinsics.exp: New file. * gdb.fortran/intrinsics.f90: New file. * gdb.fortran/type-kinds.exp: New file.
2019-03-06gdb/fortran: Simplify handling of Fortran dot operations and keywordsAndrew Burgess2-0/+127
Use strncasecmp to compare Fortran dot operations (like .AND.) and for the keywords list. This allows for some duplication to be removed from the token arrays. I've also performed whitespace cleanup around the code I've changed. I have added some tests to ensure that upper and lowercase dot operations are correctly tested. The keywords list remains always lowercase for now. There should be no user visible changes after this commit. gdb/ChangeLog: * f-exp.y (struct token): Add comments. (dot_ops): Remove uppercase versions and the end marker. (f77_keywords): Likewise. (yylex): Use ARRAY_SIZE to iterate over dot_ops, assert all entries in the dot_ops array are case insensitive, and use strncasecmp to compare strings. Also some whitespace cleanup in this area. Similar for the f77_keywords array, except entries in this list might be case sensitive. gdb/testsuite/ChangeLog: * gdb.fortran/dot-ops.exp: New file.
2019-03-06gdb/fortran: Cleanup code for parsing logical constantsAndrew Burgess2-1/+9
This patch cleans up the code used for parsing the Fortran logical constants '.TRUE.' and '.FALSE.'. Instead of listing both upper and lowercase versions of these strings we now use strncasecmp. I've also switched to use ARRAY_SIZE for the array iteration, and I've cleaned up whitespace in the vicinity of the code I've changed. Finally, I've added a test to ensure that both the upper and lower case versions of the logical constants are understood by GDB, something that was missing previously. There should be no user visible changes after this commit. gdb/ChangeLog: * f-exp.y (struct f77_boolean_val): Add comments. (boolean_values): Remove uppercase versions, and end marker. (yylex): Use ARRAY_SIZE for iterating over boolean_values array, and use strncasecmp to achieve case insensitivity. Additionally, perform whitespace cleanup around this code. gdb/testsuite/ChangeLog: * gdb.fortran/types.exp (test_logical_literal_types_accepted): Check upper and lower case logical literals.
2019-03-06gdb/fortran: Remove some duplicate testsAndrew Burgess2-4/+5
Make the test names unique in gdb.fortran/types.exp by removing a few duplicate tests. gdb/testsuite/ChangeLog: * gdb.fortran/types.exp (test_float_literal_types_accepted): Remove duplicate tests.
2019-03-06Testsuite: Ensure changing directory does not break the log fileAlan Hayward2-2/+43
get_compiler_info switches to a new log file before checking the compiler to ensure the checks are not logged. Afterwards it restores back to using the original log file. However, the logfile uses a relative path name - if the current test has changed the current directory then all further output for the test will be lost. This can confuse the code that collates the main gdb.log file at the end of a FORCE_PARALLEL run. fullpath-expand.exp calls gdb_compile after changing the current directory. The "Ensure stack protection is off for GCC" patch added a call to get_compiler_info from inside of gdb_compile, causing log file collection to break for FORCE_PARALLEL runs. The ideal solution would be to ensure the log file is always created using an absolute path name. However, this is set at multiple points in Makefile.in and in some instances just relies on dejagnu common code to set the log file directory to "." The simpler and safer solution is to override the builtin cd function. The new function checks the current log file and if the path is relative, then it resets the logging using an absolute path. Finally it calls the builtin cd. This ensures get_compiler_info (and any other code) can correctly backup and restore the current log file. gdb/testsuite/ChangeLog: * lib/gdb.exp (builtin_cd): rename of cd. (cd): Override builtin.
2019-03-06Fortran function calls with argumentsRichard Bunt3-0/+350
Prior to this patch, calling functions on the inferior with arguments and then using these arguments within a function resulted in an invalid memory access. This is because Fortran arguments are typically passed as pointers to values. It is possible to call Fortran functions, but memory must be allocated in the inferior, so a pointer can be passed to the function, and the language must be set to C to enable C-style casting. This is cumbersome and not a pleasant debug experience. This patch implements the GNU Fortran argument passing conventions with caveats. Firstly, it does not handle the VALUE attribute as there is insufficient DWARF information to determine when this is the case. Secondly, functions with optional parameters can only be called with all parameters present. Both these cases are marked as KFAILS in the test. Since the GNU Fortran argument passing convention has been implemented, there is no guarantee that this patch will work correctly, in all cases, with other compilers. Despite these limitations, this patch improves the ease with which functions can be called in many cases, without taking away the existing approach of calling with the language set to C. Regression tested on x86_64, aarch64 and POWER9 with GCC 7.3.0. Regression tested with Ada on x86_64. Regression tested with native-extended-gdbserver target board. gdb/ChangeLog: * eval.c (evaluate_subexp_standard): Call Fortran argument wrapping logic. * f-lang.c (struct value): A value which can be passed into a Fortran function call. (fortran_argument_convert): Wrap Fortran arguments in a pointer where appropriate. (struct type): Value ready for a Fortran function call. (fortran_preserve_arg_pointer): Undo check_typedef, the pointer is needed. * f-lang.h (fortran_argument_convert): Declaration. (fortran_preserve_arg_pointer): Declaration. * infcall.c (value_arg_coerce): Call Fortran argument logic. gdb/testsuite/ChangeLog: * gdb.fortran/function-calls.exp: New file. * gdb.fortran/function-calls.f90: New test.
2019-03-04gdbserver short-circuit-argument-list failuresRichard Bunt3-26/+89
This patch fixes test case failures observed when running short-circuit-argument-list.exp with gdb server boards. Thanks to Sergio Durigan Junior for pointing this out. Assertions failed with the native{,-extended}-gdbserver boards as the standard output from the test program appears in a different location than observed on non-gdbserver boards. This standard output was used to determine whether a function, which had been logically short-circuited, was called or not. Since the location of the standard out cannot be relied upon to verify this, a new mechanism was needed. The test program now records function calls in variables named the same as the function with a "_called" suffix. These variables can then be queried from the test case to verify the occurrence of a call. A method to reset the call counts has been included in the test case, so that any future assertions added to this test can ensure a fresh set of initial values before proceeding. Not resetting values between groups of assertions creates a dependency between them, which increases the likelihood that a single failure causes subsequent assertions to fail. Regression tested on x86_64, aarch64 and ppc64le. Regression tested with Ada on x86_64. Regression tested with the native{,-extended}-gdbserver boards on x86_64.
2019-02-28Testsuite: Catch gdbserver socket listen errorsAlan Hayward2-1/+6
When launching gdbserver, the testsuite checks for binding failure but does not check for failure to listen to socket error (which can happen due to another gdbserver binding to the socket at the same time). When this error occurs, the test will ignore the error and connect GDB to the failed port. This may succeed and GDB will now be connected to the gdbserver from another test. This eventually causes both tests to fail. When running the tests suite with native-gdbserver across many cores, this issue may happen once or twice, each causing random failures for two .exp testscripts. Example gdb.log output for the failure: The testsuite sucessfully notices a failure to connect to port 2348. It launches again with port 2349, which also fails. The testsuite ignores this error and uses gdb to connect to the port - which succeeds. spawn /work/build/gdb/testsuite/../gdbserver/gdbserver --once localhost:2348 /work/build/gdb/testsuite/outputs/gdb.ada/arrayidx/p^M Can't bind address: Address already in use.^M Exiting^M Port 2348 is already in use. spawn /work/build/gdb/testsuite/../gdbserver/gdbserver --once localhost:2349 /work/build/gdb/testsuite/outputs/gdb.ada/arrayidx/p^M Can't listen on socket: Address already in use.^M Exiting^M target remote localhost:2349^M Remote debugging using localhost:2349^M Reading /lib/ld-linux-aarch64.so.1 from remote target...^M warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.^M Reading /lib/ld-linux-aarch64.so.1 from remote target...^M Reading symbols from target:/lib/ld-linux-aarch64.so.1...^M Reading /lib/ld-2.23.so from remote target...^M Reading /lib/.debug/ld-2.23.so from remote target...^M Reading /work/build/install/lib/debug//lib/ld-2.23.so from remote target...^M Reading /work/build/install/lib/debug/lib//ld-2.23.so from remote target...^M Reading target:/work/build/install/lib/debug/lib//ld-2.23.so from remote target...^M (No debugging symbols found in target:/lib/ld-linux-aarch64.so.1)^M 0x0000ffffbf6d2cc0 in ?? () from target:/lib/ld-linux-aarch64.so.1^M (gdb) continue^M Continuing.^M Reading /lib/aarch64-linux-gnu/libc.so.6 from remote target...^M Reading /lib/aarch64-linux-gnu/libc-2.23.so from remote target...^M Reading /lib/aarch64-linux-gnu/.debug/libc-2.23.so from remote target...^M Reading /work/build/install/lib/debug//lib/aarch64-linux-gnu/libc-2.23.so from remote target...^M Reading /work/build/install/lib/debug/lib/aarch64-linux-gnu//libc-2.23.so from remote target...^M Reading target:/work/build/install/lib/debug/lib/aarch64-linux-gnu//libc-2.23.so from remote target...^M [Inferior 1 (process 35351) exited normally]^M (gdb) FAIL: gdb.ada/arrayidx.exp: can't run to main Meanwhile, at the same time, in another test, gdbserver successfully connects to port 2349. GDB then tries to connect to the port, but it times out because the GDB in the test above has already connected to it. spawn /work/build/gdb/testsuite/../gdbserver/gdbserver --once localhost:2348 /work/build/gdb/testsuite/outputs/gdb.ada/rdv_wait/foo^M Can't bind address: Address already in use.^M Exiting^M Port 2348 is already in use. spawn /work/build/gdb/testsuite/../gdbserver/gdbserver --once localhost:2349 /work/build/gdb/testsuite/outputs/gdb.ada/rdv_wait/foo^M Process /work/build/gdb/testsuite/outputs/gdb.ada/rdv_wait/foo created; pid = 65162^M Listening on port 2349^M Remote debugging from host 127.0.0.1, port 45154^M target remote localhost:2349^M localhost:2349: Connection timed out.^M (gdb) ^CQuit^M (gdb) task 2^M Cannot inspect Ada tasks when program is not running^M gdb/testsuite/ChangeLog: * lib/gdbserver-support.exp (gdbserver_start): Check for listen failure.
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.
generated by cgit v1.1 at 2024-09-15 09:44:43 +0000