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.
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.
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.
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.
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.
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.
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.
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.
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.
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 /.
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.
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.
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.
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.
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:
fe1a5cad30
[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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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".
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Andrew Burgess
Tom Tromey
Marco Barisione
Eli Zaretskii
Keith Seitz
Philippe Waroquiers
Sandra Loosemore
Alan Hayward
Pedro Alves
Simon Marchi
Richard Bunt
Rainer Orth
Kevin Buettner
Joel Brobecker
Tom Tromey
Simon Marchi