Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Make command-repeat work after gdb.execute

Since commit

  56bcdbea2bed ("Let gdb.execute handle multi-line commands")

command repetition after using the `gdb.execute` Python function
fails (the previous command is not repeated anymore). This happens
because read_command_lines_1 sets dont_repeat, but the call to
prevent_dont_repeat in execute_gdb_command is later.

The fix is to move the call to prevent_dont_repeat to the beginning of
the function.

Tested on my laptop (ArchLinux-x86_64).

gdb/ChangeLog:

PR python/23714
* gdb/python/python.c (execute_gdb_command): Call
prevent_dont_repeat earlier to avoid affecting dont_repeat.

gdb/testuite/ChangeLog:

PR python/23714
* gdb.python/python.exp: Test command repetition after
gdb.execute.

Automatic date update in version.in

Automatic date update in version.in

gdb.base/warning.exp tweaks

#1- Check that the warning is emitted.

#2- Avoid overriding INTERNAL_GDBFLAGS, as per documentated in
    gdb/testsuite/README:

 ~~~
 The testsuite does not override a value provided by the user.
 ~~~

We don't actually need to tweak INTERNAL_GDBFLAGS, we just need to
append out -data-directory to GDBFLAGS, because each passed
-data-directory option leads to a call to the warning:

 $ ./gdb -data-directory=foo -data-directory=bar
 Warning: foo: No such file or directory.
 Warning: bar: No such file or directory.
 [...]

2018-11-19  Pedro Alves  <palves@redhat.com>

* gdb.base/warning.exp: Don't override INTERNAL_FLAGS.  Use
gdb_spawn_with_cmdline_opts instead of gdb_start.  Check that we
see the expected warning.

Avoid crash when calling warning too early

I noticed that if you pass the name of an existing file (not a
directory) as the argument to --data-directory, gdb will crash:

    $ ./gdb -nx  --data-directory  ./gdb
    ../../binutils-gdb/gdb/target.c:590:56: runtime error: member call on null pointer of type 'struct target_ops'

This was later reported as PR gdb/23838.

This happens because warning ends up calling
target_supports_terminal_ours, which calls current_top_target, which
returns nullptr this early.

This fixes the problem by handling this case specially in
target_supports_terminal_ours.  I also changed
target_supports_terminal_ours to return bool.

2018-11-08  Tom Tromey  <tom@tromey.com>

PR gdb/23555:
PR gdb/23838:
* target.h (target_supports_terminal_ours): Return bool.
* target.c (target_supports_terminal_ours): Handle case where
current_top_target returns nullptr.  Return bool.

gdb/testsuite/ChangeLog
2018-11-08  Tom Tromey  <tom@tromey.com>

PR gdb/23555:
PR gdb/23838:
* gdb.base/warning.exp: New file.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

python: Make gdb.execute("show commands") work (PR 23669)

Since commit

  56bcdbea2bed ("Let gdb.execute handle multi-line commands")

trying to use a command like gdb.execute("show commands") in Python
fails.  GDB ends up trying to run the "commands" command.

The reason is that GDB gets confused with the special "commands"
command.  In process_next_line, the lookup_cmd_1 function returns the
cmd_list_element representing the "commands" sub-command of "show".
Lower, we check the cmd_list_element to see if it matches various
control commands by name, including the "commands" command.  This is
where we wrongfully conclude that the executed command must be
"commands", when in reality it was "show commands".

The fix proposed in this patch removes the comparisons by name, instead
comparing the cmd_list_element object by pointer with the objects
created at initialization time.

Tested on the buildbot, though on a single builder (Fedora-x86_64-m64).

gdb/ChangeLog:

PR python/23669
* breakpoint.c (commands_cmd_element): New.
(_initialize_breakpoint): Assign commands_cmd_element.
* breakpoint.h (commands_cmd_element): New.
* cli/cli-script.c (while_cmd_element, if_command,
define_cmd_element): New.
(command_name_equals): Remove.
(process_next_line): Compare commands by pointer, not by name.
(_initialize_cli_script): Assign the various cmd_list_element
variables.
* compile/compile.c (compile_cmd_element): New.
(_initialize_compile): Assign compile_cmd_element.
* compile/compile.h (compile_cmd_element): New.
* guile/guile.c (guile_cmd_element): New.
(install_gdb_commands): Assign guile_cmd_element.
* guile/guile.h (guile_cmd_element): New.
* python/python.c (python_cmd_element): New.
(_initialize_python): Assign python_cmd_element.
* python/python.h (python_cmd_element): New.
* tracepoint.c (while_stepping_cmd_element): New.
(_initialize_tracepoint): Assign while_stepping_cmd_element.
* tracepoint.h (while_stepping_cmd_element): New.

gdb/testsuite/ChangeLog:

PR python/23669
* gdb.python/python.exp: Test gdb.execute("show commands").

Automatic date update in version.in

Automatic date update in version.in

Move 'is_regular_file' from common-utils.c to filestuff.c

There is no reason for 'is_regular_file' to be in common-utils.c; it
belongs to 'filestuff.c'.  This commit moves the function definition
and its prototype to the appropriate files.

The motivation behind this move is a failure that happens on certain
cross-compilation environments when compiling the IPA library, due to
the way gnulib probes the need for a 'stat' call replacement.  Because
configure checks when cross-compiling are more limited, gnulib decides
that it needs to substitute the 'stat' calls its own 'rpl_stat';
however, the IPA library doesn't link with gnulib, which leads to an
error when compiling 'common-utils.c':

  ...
  /opt/x86-core2--musl--bleeding-edge-2018.09-1/bin/i686-buildroot-linux-musl-g++  -shared -fPIC -Wl,--soname=libinproctrace.so -Wl,--no-undefined -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -Os      -I. -I. -I./../common -I./../regformats -I./.. -I./../../include -I./../gnulib/import -Ibuild-gnulib-gdbserver/import -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-narrowing -Wno-error=maybe-uninitialized  -DGDBSERVER \
   -Wl,--dynamic-list=./proc-service.list -o libinproctrace.so ax-ipa.o common-utils-ipa.o errors-ipa.o format-ipa.o print-utils-ipa.o regcache-ipa.o remote-utils-ipa.o rsp-low-ipa.o tdesc-ipa.o tracepoint-ipa.o utils-ipa.o vec-ipa.o linux-i386-ipa.o linux-x86-tdesc-ipa.o arch/i386-ipa.o -ldl -pthread
  /opt/x86-core2--musl--bleeding-edge-2018.09-1/lib/gcc/i686-buildroot-linux-musl/8.2.0/../../../../i686-buildroot-linux-musl/bin/ld: common-utils-ipa.o: in function `is_regular_file(char const*, int*)':
  common-utils.c:(.text+0x695): undefined reference to `rpl_stat'
  collect2: error: ld returned 1 exit status
  Makefile:413: recipe for target 'libinproctrace.so' failed
  make[1]: *** [libinproctrace.so] Error 1
  ...

More details can also be found at:

  https://sourceware.org/ml/gdb-patches/2018-09/msg00304.html

The most simple fix for this problem is to move 'is_regular_file' to
'filestuff.c', which is not used by IPA.  This ends up making the
files more logically organized as well, since 'is_regular_file' is a
file operation.

No regressions found.

gdb/ChangeLog:
2018-09-15  Sergio Durigan Junior  <sergiodj@redhat.com>

PR gdb/23663
* common/common-utils.c: Don't include '<sys/stat.h>'.
(is_regular_file): Move to...
* common/filestuff.c (is_regular_file): ... here.
* common/common-utils.h (is_regular_file): Move to...
* common/filestuff.h (is_regular_file): ... here.

Automatic date update in version.in

Automatic date update in version.in

Make Rust error message mention the field name

I noticed a spot in rust-lang.c where the placeholder "foo" was used
instead of the actual field name.  This patch fixes the bug.

2018-09-13  Tom Tromey  <tom@tromey.com>

PR rust/23650:
* rust-lang.c (rust_evaluate_subexp): Use field name, not "foo".

gdb/testsuite/ChangeLog
2018-09-13  Tom Tromey  <tom@tromey.com>

PR rust/23650:
* gdb.rust/simple.exp: Add test for enum field access error.

Fix crash with empty Rust enum

While testing my Rust compiler patch to fix the DWARF representation
of Rust enums (https://github.com/rust-lang/rust/pull/54004), I found
a gdb crash coming from one of the Rust test cases.

The bug here is that the new variant support in gdb does not handle
the case where there are no variants in the enum.

This patch fixes the problem in a straightforward way.  Note that the
new tests are somewhat lax because I did not want to try to fully fix
this corner case for older compilers.  If you think that's
unacceptable, let meknow.

Tested on x86-64 Fedora 28 using several versions of the Rust
compiler.  I intend to push this to the 8.2 branch as well.

2018-09-13  Tom Tromey  <tom@tromey.com>

PR rust/23626:
* rust-lang.c (rust_enum_variant): Now static.
(rust_empty_enum_p): New function.
(rust_print_enum, rust_evaluate_subexp, rust_print_struct_def):
Handle empty enum.

gdb/testsuite/ChangeLog
2018-09-13  Tom Tromey  <tom@tromey.com>

PR rust/23626:
* gdb.rust/simple.rs (EmptyEnum): New type.
(main): Use it.
* gdb.rust/simple.exp (test_one_slice): Add empty enum test.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Fix "make install-strip" failure to install gdb-add-index.sh

gdb/ChangeLog:
2018-09-10  Eli Zaretskii  <eliz@gnu.org>

* Makefile.in (transformed_name): Use INSTALL_SCRIPT instead of
INSTALL_PROGRAM to install gdb-add-index.sh.  Don't append
$(EXEEXT) to the script, as it is not a program.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Bump GDB version number to 8.2.0.DATE-git.

gdb/ChangeLog:

* version.in: Set GDB version number to 8.2.0.DATE-git.
* PROBLEMS: Likewise.

Document the GDB 8.2 release in gdb/ChangeLog

gdb/ChangeLog:

GDB 8.2 released.

Set GDB version number to 8.2.

gdb/ChangeLog:

* version.in: Set GDB version number to 8.2.
* PROBLEMS: Likewise.